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

  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.


Jerry Shih (2):
  riscv: vectorized mem* functions
  riscv: vectorized str* functions

Nick Knight (1):
  riscv: vectorized strchr and strnlen functions

Vincent Chen (1):
  riscv: Enabling vectorized mem*/str* functions in build time

Yun Hsiang (1):
  riscv: add vectorized __memcmpeq

 scripts/build-many-glibcs.py   | 10 ++++
 sysdeps/riscv/preconfigure     | 19 +++++++
 sysdeps/riscv/preconfigure.ac  | 18 +++++++
 sysdeps/riscv/rv32/rvv/Implies |  2 +
 sysdeps/riscv/rv64/rvv/Implies |  2 +
 sysdeps/riscv/rvv/memchr.S     | 63 +++++++++++++++++++++++
 sysdeps/riscv/rvv/memcmp.S     | 71 ++++++++++++++++++++++++++
 sysdeps/riscv/rvv/memcmpeq.S   | 69 +++++++++++++++++++++++++
 sysdeps/riscv/rvv/memcpy.S     | 51 +++++++++++++++++++
 sysdeps/riscv/rvv/memmove.S    | 72 ++++++++++++++++++++++++++
 sysdeps/riscv/rvv/memset.S     | 51 +++++++++++++++++++
 sysdeps/riscv/rvv/strcat.S     | 72 ++++++++++++++++++++++++++
 sysdeps/riscv/rvv/strchr.S     | 53 +++++++++++++++++++
 sysdeps/riscv/rvv/strcmp.S     | 93 ++++++++++++++++++++++++++++++++++
 sysdeps/riscv/rvv/strcpy.S     | 56 ++++++++++++++++++++
 sysdeps/riscv/rvv/strlen.S     | 54 ++++++++++++++++++++
 sysdeps/riscv/rvv/strncat.S    | 83 ++++++++++++++++++++++++++++++
 sysdeps/riscv/rvv/strncmp.S    | 85 +++++++++++++++++++++++++++++++
 sysdeps/riscv/rvv/strncpy.S    | 86 +++++++++++++++++++++++++++++++
 sysdeps/riscv/rvv/strnlen.S    | 56 ++++++++++++++++++++
 20 files changed, 1066 insertions(+)
 create mode 100644 sysdeps/riscv/rv32/rvv/Implies
 create mode 100644 sysdeps/riscv/rv64/rvv/Implies
 create mode 100644 sysdeps/riscv/rvv/memchr.S
 create mode 100644 sysdeps/riscv/rvv/memcmp.S
 create mode 100644 sysdeps/riscv/rvv/memcmpeq.S
 create mode 100644 sysdeps/riscv/rvv/memcpy.S
 create mode 100644 sysdeps/riscv/rvv/memmove.S
 create mode 100644 sysdeps/riscv/rvv/memset.S
 create mode 100644 sysdeps/riscv/rvv/strcat.S
 create mode 100644 sysdeps/riscv/rvv/strchr.S
 create mode 100644 sysdeps/riscv/rvv/strcmp.S
 create mode 100644 sysdeps/riscv/rvv/strcpy.S
 create mode 100644 sysdeps/riscv/rvv/strlen.S
 create mode 100644 sysdeps/riscv/rvv/strncat.S
 create mode 100644 sysdeps/riscv/rvv/strncmp.S
 create mode 100644 sysdeps/riscv/rvv/strncpy.S
 create mode 100644 sysdeps/riscv/rvv/strnlen.S
  

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.
  

Hi Adhemerval,

Thanks for the comment.
The patchset is mainly for the providing a default RVV implementation.
We know that the mechanism to choose ISA variant is not determined yet.
The first patch is a workaround to build Glibc, but won't be the final version.
This decouples the how Glibc get RISC-V hardware information and the RVV function implementation.
As the final decision has been made, we will send another patchset to use that mechanism, 
with the RVV function implementation all together as the version to merge.

I'll send another patchset to fix other obvious mistakes base on your review.
Sorry for sending multiple copies of the same patches. 
I am not familiar with the system and had some SMTP config errors.

Thank you!

Best,

Hau Hsu
Software Engineer
hau.hsu@sifive.com

CC Yi-Hsiu Hsu



> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> 於 2023年4月21日 下午8:09 寫道：
> 
> 
> 
> 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.