Re: [PATCH 2/2] riscv: vectorised mem* and str* functions

[Jeff Law <jeffreyalaw@gmail.com>]

On 2/1/23 02:52, Sergei Lewis wrote:
> Initial implementations of memchr, memcmp, memcpy, memmove, memset, strchr,
> strcmp, strcpy, strlen, strncmp, strncpy, strnlen, strrchr, strspn
> targeting the riscv "V" extension, version 1.0
> 
> The vectorised implementations assume VLENB of at least 128 and at least 32
> registers (as mandated by the "V" extension spec). They also assume that
> VLENB is a power of two which is no larger than the page size, and (as
> vectorised code in glibc for other platforms does) that it is safe to read
> past null terminators / buffer ends provided one does not cross a page
> boundary.
> 
> Signed-off-by: Sergei Lewis <slewis@rivosinc.com>
> ---
>   sysdeps/riscv/rv64/rvv/Implies     |   2 +
>   sysdeps/riscv/rv64/rvv/memchr.S    | 127 +++++++++++++++++++
>   sysdeps/riscv/rv64/rvv/memcmp.S    |  93 ++++++++++++++
>   sysdeps/riscv/rv64/rvv/memcpy.S    | 154 +++++++++++++++++++++++
>   sysdeps/riscv/rv64/rvv/memmove.c   |  22 ++++
>   sysdeps/riscv/rv64/rvv/memset.S    |  89 ++++++++++++++
>   sysdeps/riscv/rv64/rvv/strchr.S    |  92 ++++++++++++++
>   sysdeps/riscv/rv64/rvv/strchrnul.c |  22 ++++
>   sysdeps/riscv/rv64/rvv/strcmp.S    | 108 +++++++++++++++++
>   sysdeps/riscv/rv64/rvv/strcpy.S    |  72 +++++++++++
>   sysdeps/riscv/rv64/rvv/strcspn.c   |  22 ++++
>   sysdeps/riscv/rv64/rvv/strlen.S    |  67 ++++++++++
>   sysdeps/riscv/rv64/rvv/strncmp.S   | 104 ++++++++++++++++
>   sysdeps/riscv/rv64/rvv/strncpy.S   |  96 +++++++++++++++
>   sysdeps/riscv/rv64/rvv/strnlen.S   |  81 +++++++++++++
>   sysdeps/riscv/rv64/rvv/strrchr.S   |  88 ++++++++++++++
>   sysdeps/riscv/rv64/rvv/strspn.S    | 189 +++++++++++++++++++++++++++++
Does this need to be revamped given the recent push to do more with 
generic code and target specific hooks for mem* and str*?

Shouldn't the implementations be in a multiarch directory?  I would 
fully expect we're going to need both a vector and scalar implementation 
selected by an ifunc.

I'm happy to pass along the current bits from VRULL which put that 
infrastructure in place.  I just haven't had the time to look at 
revamping their assembly implementations for the new generic+hooks scheme.

jeff