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

[Andrew Jones]

On Wed, Jan 11, 2023 at 02:39:36PM +0100, Christoph Müllner wrote:
> On Wed, Jan 11, 2023 at 1:34 PM Andrew Jones <ajones at ventanamicro.com>
> wrote:
> 
> > On Tue, Jan 10, 2023 at 12:16:47PM +0100, Andrew Jones wrote:
> > > 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 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*) .
> >
> > Hi Heiko,
> >
> > Thinking about this some more, I'd still like to understand how/when the
> > compiler makes this choice. Are compiler flags involved? Or do some
> > heuristics dictate the choice?
> >
> 
> 1) Arch-independent expansion is used e.g. for calculating the result for
> statically known strings.
> 2) Arch-specific expansion (not mainline, but my series can be found here:
> [1]) can do whatever is reasonable.
> My series emits a bounded unrolled comparison loop for str(n)cmp with a
> bound that can be adjusted via flag.
> But it only triggers if both strings are known to be aligned.
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605993.html
> 

Thanks Christoph!

drew