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

[Jeff Law]

On 12/16/25 10:00 PM, Peter Bergner wrote:
> 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.
Agreed, 100%.  It's been a long road.  My thanks go out as well.

> 
> 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.
I'd support including it, even though we're at soft-freeze.  It was 
posted well in advance of the soft freeze and the implementation is very 
close to what we've been running internally for a year or more.  I've 
tested the core ifunc detection and routing bits on multiple hardware 
implementations and the memset implementation is dead simple.

> 
> 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.
I'd also be OK with this if this is what folks prefer.

And thanks Peter for picking this up as things got crazy for me!

Yao, which ones do you want to concentrate on next?  I'm happy to pass 
along the generic implementations we have here.  Though if you've 
already got them it may not be worth the effort.  Ours are a 
run-of-the-mill RVV impementation without any meaningful tuning.

Jeff