[PATCH v4 4/5] RISC-V: add infrastructure to allow different str* implementations

[Heiko Stübner]

Hi Andrew,

Am Dienstag, 10. Januar 2023, 10:39:36 CET schrieb Andrew Jones:
> On Mon, Jan 09, 2023 at 07:17:54PM +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner at 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.
> 
> And the compiler provides builtins. In the previous series it appeared
> to be a bad idea to compile the kernel with the compiler's builtins
> disabled. How will the optimized string functions which will be based
> on this patch be selected?

yep, the consensus seemingly was that the compiler knows best when
to use builtins for some cases (which is probably correct), hence the move
away from the inline bases.

So I guess the first decision is the compiler's wether to use a builtin or
the kernel string function (same as for mem*) .

In my tests, I did see both getting used - so it's definitly not lost work :-) .

After that when landing in these here, we want to select the best variant
for the host-system the kernel runs on.

I.e. this one as baseline or for example using zbb as an "alternative".

As for the "more" variants, I currently have more patches on top, that
then use an ALTERNATIVE_2

ALTERNATIVE_2("nop",
      "j variant_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB,
      "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

with the "errata_id" being used as a bitfield to use extension combinations.
And a "not"-field, so I can do a has-zbb + has-not-fast-unaligned


Heiko