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

[Andrew Jones]

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?

Thanks,
drew