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

From: Andrew Jones <ajones@ventanamicro.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	christoph.muellner@vrull.eu, conor@kernel.org,
	philipp.tomsich@vrull.eu, jszhang@kernel.org
Subject: Re: [PATCH v4 4/5] RISC-V: add infrastructure to allow different str* implementations
Date: Tue, 10 Jan 2023 12:16:47 +0100	[thread overview]
Message-ID: <20230110111647.vg4fdclz4hzcuaj3@orel> (raw)
In-Reply-To: <1994655.QkHrqEjB74@diego>

On Tue, Jan 10, 2023 at 11:46:40AM +0100, Heiko Stübner wrote:
> 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@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

Thanks, Heiko. This was the info I needed. It might be nice to put some of
it in the commit message too.

drew

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