Re: [PATCH v5 1/2] RISC-V: add infrastructure to allow different str* implementations

From: Conor Dooley <conor@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	christoph.muellner@vrull.eu, philipp.tomsich@vrull.eu,
	ajones@ventanamicro.com, jszhang@kernel.org,
	Heiko Stuebner <heiko.stuebner@vrull.eu>
Subject: Re: [PATCH v5 1/2] RISC-V: add infrastructure to allow different str* implementations
Date: Fri, 13 Jan 2023 21:59:06 +0000	[thread overview]
Message-ID: <Y8HUKgqYjcMkQjJQ@spud> (raw)
In-Reply-To: <20230113212301.3534711-2-heiko@sntech.de>

[-- Attachment #1.1: Type: text/plain, Size: 1961 bytes --]

Hey Heiko,

On Fri, Jan 13, 2023 at 10:23:00PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@vrull.eu>
> 
> Depending on supported extensions on specific RISC-V cores,
> optimized str* functions might make sense.
> 
> This adds basic infrastructure to allow patching the function calls
> via alternatives later on.
> 
> The Linux kernel provides standard implementations for string functions
> but when architectures want to extend them, they need to provide their
> own.
> 
> The added generic string functions are done in assembler (taken from
> disassembling the main-kernel functions for now) to allow us to control
> the used registers and extend them with optimized variants.
> 

> This doesn't override the compiler's use of builtin replacements. So still
> first of all the compiler will select if a builtin will be better suitable
> i.e. for known strings. For all regular cases we will want to later
  ^
i.e. suggests that this will only happen for known strings.

> select possible optimized variants and in the worst case fall back to the
> generic implemention added with this change.
          ^ typo btw

I'm not expecting a resend for this, that'd be stupid, but does the
following say the same thing? (What you wrote was a bit -ENOPARSE)

"This doesn't override the compiler's use of builtin replacements. The
compiler will still select a builtin if it will be better suited, e.g.
for known strings. For all regular cases, we may want to select possibly
optimized variants, and in the worst case fall back to the generic
implementation added with this change."

I'm a philistine who was okay with previous version of the asm, so you
could've kept the:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
I had a look and it seemed to match what Drew suggested.
Looking at the b4 diff output and seeing both side by side, the new one
does look nicer..

Thanks,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv