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

[Philipp Tomsich]

Drew,

the reason why alignment is critical for correctness of optimisations
in userspace applications is that exception semantics must be retained
when crossing page boundaries.

Philipp.

On Wed, 11 Jan 2023 at 14:39, Christoph Müllner
<christoph.muellner at vrull.eu> 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
>
> BR
> Christoph
>
>>
>> Thanks,
>> drew