[PATCH v5 1/1] riscv: Add RVV memset for both multiarch and non-multiarch builds

[Peter Bergner]

On 12/11/25 7:33 AM, Yao Zihong wrote:
> This patch adds an RVV-optimized implementation of memset for RISC-V and
> enables it for both multiarch (IFUNC) and non-multiarch builds.
> 
> The implementation integrates Hau Hsu's 2023 RVV work under a unified
> ifunc-based framework. A vectorized version (__memset_vector) is added
> alongside the generic fallback (__memset_generic). The runtime resolver
> selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
> support (RVV).
> 
> Currently, the resolver still selects the RVV variant even when the RVV
> extension is disabled via prctl(). As a consequence, any process that
> has RVV disabled via prctl() will receive SIGILL when calling memset().
> 
> Tested on MUSE-Pi (SpacemiT M1). No regressions were observed compared
> with glibc master when the RVV extension was not disabled via prctl().

I'm sorry for the delay, but given the late development stage, I wanted to
do some extra testing with the patch myself.  I built the patch with and
without RVV enabled in GCC and with and without --disable-multi-arch and
I can confirm the no regressions result you found.  I also confirmed that
a no-RVV build using --disable-multi-arch always calls __memset_generic,
while a RVV --disable-multi-arch build always calls __memset_vector like
we want.  The no-RVV and RVV multiarch builds always call through the
ifunc resolver and we correctly call the __memset_vector routine when
running on a RVV enabled system.

So LGTM!

Reviewed-by: Peter Bergner <bergner@tenstorrent.com>


Thank you for all your hard work and patience in getting this in!
I know many of us are looking forward to seeing the rest of the
mem* and str* routines getting vector implementations too.

However, now that we're in the soft-freeze for the release, I'm
unsure whether this can or should go in.  Thoughts on that topic
from the others?  I think we should agree amongst ourselves before
possibly asking Andreas (H) whether this can go in or not.

One option would be to wait to push until after the release and
then let it burn-in on trunk for a bit before backporting to the
release branch.  I'm open to others' thoughts though.

Peter