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

[Darius Rad]

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.

> 
> > 
> > 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.