[PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface

[Jeff Law]

On 3/31/23 15:38, Palmer Dabbelt wrote:
> On Fri, 31 Mar 2023 14:35:36 PDT (-0700), jeffreyalaw@gmail.com wrote:
>>
>>
>> On 3/31/23 15:03, Palmer Dabbelt wrote:
>>> On Fri, 31 Mar 2023 13:19:19 PDT (-0700), jeffreyalaw@gmail.com wrote:
>>>
>>> [just snipping the rest so we can focus on Jeff's ask, the other stuff
>>> is interesting but a longer reply and we'd probably want to fork the
>>> thread anyway...]
>>>
>>>> So perhaps we can narrow down the scope right now even further.  Can we
>>>> agree to try and settle on a base implementation with no ISA extensions
>>>> and no uarch variants?  ISTM if we can settle on those implementations
>>>> that it should be usable immediately by the RV community at large and
>>>> doesn't depend on the kernel->glibc interface work.
>>>
>>> That base includes V and ZBB?  In that case we'd be dropping support for
>>> all existing hardware, which I would be very much against.
>> No, it would not include V or ZBB.  It would be something that could
>> work on any risc-v hardware.  Sorry if I wasn't clear about that.
> 
> I'm still kind of confused then, maybe it's just too abstract?  Is there 
> something you could propose as being the base?
So right now we use the generic (architecture independent) routines for 
str* and mem*.

If we look at (for example) strcmp there's hand written variants out 
there are are purported to have better performance than the generic code 
in glibc.

Note that any such performance claims likely predate the work from 
Adhemerval and others earlier this year to reduce the reliance on 
hand-coded assembly.

So the first step is to answer the question, for any str* or mem* where 
we've received a patch submission of a hand coded assembly variant 
(which isn't using ZBB or V), does that hand coded assembly variant 
significantly out perform the generic code currently in glibc.  If yes 
and the generic code can't be significantly improved, then we should 
declare that hand written variant as the standard baseline for risc-v in 
glibc.  Review, adjust, commit and move on.

My hope would be that many (most, all?) of the base architecture hand 
coded assembly variants no longer provide any significant benefit over 
the current generic versions.

That's my minimal proposal for now.  It's not meant to solve everything 
in this space, but at least carve out a chunk of the work and get it 
resolved one way or the other.

Does that help clarify what I'm suggesting?

Jeff