[PATCH v2 0/5] riscv: Vectorized mem*/str* function

[Adhemerval Zanella Netto]

On 21/04/23 04:54, Hau Hsu via Libc-alpha wrote:
> I am submitting version 2 of the patch for adding vectorized mem*/str*
> functions for RISC-V. This patch builds upon the previous version (v1)
> available at
> https://patchwork.sourceware.org/project/glibc/list/?series=17710.
> 
> In this version, we have included the __memcmpeq function and set lmul=1
> for memcmp, which improves its generality.
> 
>

Is this really the idea for RISCV? Because from last iteration with Jeff Law [1]
I understood that RISCV would not move to start providing ISA variants where to 
enable some optimization you will need to either configure with --with-cpu or 
tune the compiler flags.

To explain it better, what you are trying is follow what powerpc does: it has
sysdeps subfolder, each representing and ISA variant, and you only enables it 
by either forcing on configure or automatically with configure.ac.

Now, for aarch64 you only have one ABI variant and each CPU or ISA optimization
(for instance SVE) is enabled *iff* through iFUNC mechanism.  You also have a
further optimization, that x86_64 and s390 implements, where if you are using
an specific ABI level (say x86_64-v2) you can using this specific ABI level
as the base and only provide ifunc variants fro the ABI level higher than you
have defined (it is really not a big deal, it optimizes the code size a bit,
and some intra libc calls). But it is still implemented through multiarch folder 
mechanism, you don't have any sysdep subfolder.

And that's what I have understood from Jeff's last email, that RISCV will 
eventually sort out his kernel functionality query mechanism (either by hwcap 
or by the new syscall), get in on linux-next or linus tree, and then resume the
work to provide both the unaligned and rvv or whatever other extension you want.

But it is really up to you maintainers, you can mimic the powerpc way to enable 
ifunc, which basically adds a lot of boilerplate to include the arch-specific 
variants. The drawback is now you have another build permutation that you need 
to keep testing (as you did by adding another build-many-glibcs.py entry).

[1] https://sourceware.org/pipermail/libc-alpha/2023-March/146824.html

PS: you seemed to have sent multiple copies of the same patch, I will reply only
the ones linked to this cover letter.