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

[Jeff Law <jeffreyalaw@gmail.com>]

On 3/31/23 13:32, Adhemerval Zanella Netto wrote:
> 
> It is still not clear to me what RISCV, as ABI and not as an specific vendor,
> wants to provide arch and vendor specific str* and mem* routines.  Christophe
> has hinted that the focus is not compile-only approach, so I take --with-cpu
> support (similar to what some old ABI used to provide, like powerpc) is not
> an option.  However, this is not what the RVV proposal does [3], which is to
> enable RVV iff you target glibc to rvv (so compile-only).
I believe there is consensus on the desire to use dynamic dispatch via 
an ifunc resolver.




> 
> And that's why I asked you guys to first define on how you want to approach
> it.
I think that's already done.  I don't really see any confusion in this 
space.

The patch from the sifive team has static dispatch, they made it clear 
they want dynamic dispatch though.  Static dispatch is just a stopgap 
until the dynamic dispatch work is ready AFAICT.

rivos had a dynamic dispatch mechanism based on riscv_hwprobe

VRULL had a dynamic dispatch based on an environment variable.  This was 
acknowledged to be a hack which would be dropped once the kernel->glibc 
interface bits were sorted out.

Ventana doesn't have patches in this space, but had been using the VRULL 
bits.  I don't really have a preference as far as implementations.  I 
just want to define good ones that cover the most important cases, 
particularly with regard to ISA extensions, but I'm even willing to 
narrow the immediate focus down further (see below).


> 
> So I take that RISCV want to follow what x86_64 and aarch64 do, which is
> provide optimized routines for a minimum abi (say rv64gc), and then provide
> runtime selection through ifunc for either ABI or vendor specific routines
> (including variant like the unaligned optimization).

Right.  That's basically what I think we're trying to do.  Find a 
suitable implementation we can agree upon for a given ISA architecture. 
The belief right now is that we need one for the baseline architecture, 
one for architectures implementing ZBB and another for architectures 
that implement RVV.  ZBB and RVV are not uarch variants; they are 
standardized, but optional ISA features.

I don't think anyone is (yet!) pushing for uarch variants.  In fact, I 
would very much like to avoid that as much as I can.  Palmer might see 
uarch variants are inevitable, I don't (and maybe I'm being naive).




   You can still follow
> what x86_64 and s390 recently did, which is if you define a minimum ABI
> version, you default the optimized version and either skip ifunc selection
> or setup a more restrict set (so in future, you can have a rvv-only build
> that does not need to provide old zbb or rv64gc support).
I'm focused on defining a implementation for the baseline architecture 
as well as one for ZBB and RVV ISAs.


> 
> Which then leads to how to actually test and provide such support.  The
> str* and mem* tests consult which ifunc variant are support
> (ifunc-impl-list.c) on the underlying hardware; while the selector returns
> the best option.  Both rely on how to query the hardware at or least which
> version are supported, so I think RISCV should first figure out this part
> (unless you do want to follow the compile-only approach...)

> 
> So it does not make sense to me to have ifunc variants not selected or
> tested in repo, only to be enabled in a foreseen future.
I think this is the core point we disagree on.   I understand your 
position, respectfully disagree, but I'm willing to set it aside.

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.


Jeff