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

[Darius Rad]

On Wed, Nov 05, 2025 at 08:49:37AM -0700, Jeff Law wrote:
> 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 do that first, or use dl_hwcap until it is available.  Don't break
something that's working.

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