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

[Jeff Law]

On 11/5/25 7:59 AM, Darius Rad wrote:
> On Tue, Nov 04, 2025 at 03:58:05PM -0700, Jeff Law wrote:
>> On 11/4/25 7:33 AM, Darius Rad wrote:
>>> On Tue, Nov 04, 2025 at 08:37:49PM +0800, Yao Zihong wrote:
>>>> 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).
>>>
>>> This needs to use dl_hwcap, as I said before [1].
>>>
>>> [1] https://sourceware.org/pipermail/libc-alpha/2025-October/171687.html
>> No.  This was sorted out across glibc, gcc and the linux kernel a couple of
>> years ago.  The right interface is hwprobe.  I don't understand why we're
>> revisiting this decision at this point.
>>
> 
> I don't care about dl_hwcap, I care about not breaking a working
> configuration.  If this was sorted out, what is the alternative?  The fact
> remains, short of reading prctl, dl_hwcap is the only way for user space to
> know whether vector is enabled or not.  This is what the Linux
> documentation currently says.
That "working configuration" is very niche -- someone (linux kernel and 
glibc developers) need to figure out how to support this *within* the 
hwprobe mechanism, it's that simple.



>>> This patch certainly has regressions compared with glibc master.
>>> Presently, if one has an environment that implements the vector extension,
>>> but it is disabled at runtime with prctl, glibc will operate properly.
>>> After this patch, running in such an environment will trigger an illegal
>>> instruction fault whenever memset is run.
>>>
>> Set this aside.  It's not the most important thing to resolve.
>>
> 
> Respectfully, no.  Deliberately breaking a working configuration is in fact
> one of the most important things to resolve.
I would disagree.  We're essentially holding up an entire community for 
something that just isn't that important and *not* part of how this 
stuff was designed to work.

We've had approval for the riscv probe stuff for roughly a year, the 
only reason it hasn't moved forward is I didn't have the time to push 
the approved patch into the tree.  Yao has kindly picked up the effort 
and it's ready to move forward.   hwprobe is the approved mechanism to 
handle this stuff across the various relevant projects.  If there's 
capabilities missing in that interface, then that's what needs to be 
fixed.  But we shouldn't make perfect be the enemy of the good IMHO.

So if you want to address this particular problem, work with the kernel 
and glibc teams to make it work within the hwprobe API.

Jeff