[PATCH v2 1/1] riscv: Add RVV memset via multiarch/IFUNC

[Vineet Gupta]

Hi Yao,

On 11/11/25 04:15, Yao Zihong wrote:
> Hi all,
>
> Thanks for the feedback and discussion.
> For v3, the commit message will be updated to clarify the behavior
> mentioned by Darius [1]. But the resolver implementation will remain
> hwprobe-only as discussed in [2].
>
> The updated text would read as follows:
>
>> This patch adds an RVV-optimized implementation of memset for RISC-V and
>> enables it through the existing multiarch/IFUNC mechanism.
>>
>> 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 (V).
>>
>> Tested on MUSE-Pi (SpacemiT M1) and verified by Jeff Law on BPI and
>> Pioneer boards. No regressions were observed compared with glibc master
>> when the RVV extension was not disabled via prctl().
>>
>> Currently, the resolver still selects the RVV variant when the V extension
>> is disabled via prctl().

Discussed this separately with Peter, Jeff and some of the kernel folks here at
Rivos. It seems the prctl disabled status (at the time of startup, not after the
fact) can still be honored by doing an additional prctl (PR_RISCV_V_GET_CONTROL)
is hwprobe says V is present. This will be additional syscall for sure, but in
the grand scheme of things (syscalls during loader running time), this seems
negligible.
IMHO, this can be a followup and need not be tied to this patch and the baseline
should go in sooner than later.

-Vineet

> Just want to make sure this looks fine before moving forward.
>
> [1] https://inbox.sourceware.org/libc-alpha/aQoOnqyK8i4cLpa9@localhost.localdomain/
> [2] https://inbox.sourceware.org/libc-alpha/c2bf3a6f-4290-49d7-ad08-a15512c9636c@oss.tenstorrent.com/