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

[Palmer Dabbelt]

On Wed, 29 Oct 2025 18:24:25 PDT (-0700), bergner@tenstorrent.com wrote:
> On 10/29/25 4:37 PM, Jeff Law wrote:
>> On 10/29/25 12:03 PM, Darius Rad wrote:
>>> On Thu, Oct 30, 2025 at 12:10:22AM +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, not hwprobe, to decide whether to select vector
>>> or not, since vector may be present but not enabled (by prctl).
>> No, the preferred way for this on RISC-V is hwprobe, not hwcaps.
>
> I know we discussed this on the GCC patch review call, but might we want
> to control these ifuncs via GLIBC tunables like other architectures do [1]?
> If this is something we want to do eventually (we don't now), then I think
> we'll need to use the hwcaps.  If not, then yeah, hwprobe seems the way to go.

You're talking glibc-hwcaps though, right?  Jeff is saying AT_HWCAP, 
which is busted on RISC-V (we allocated a bunch of bits early and then 
vendors did whatever they wanted, V got specifically tied up with the 
V-0.7.1 stuff).

(and Darius is saying the vector-enable prctl needs to be checked, which 
is a different issue)

>
> Peter
>
> [1] https://sourceware.org/glibc/manual/latest/html_node/Hardware-Capability-Tunables.html