riscv: Implement Zbb based strlen and prefer it over the RVV based strlen implementation when Zbb is available

[Adhemerval Zanella Netto]

On 12/06/26 13:56, Peter Bergner wrote:
> On 6/11/26 2:51 PM, Adhemerval Zanella Netto wrote:
>> And there is another question if adding a zbb sysdep is really a good move here.
>> My understanding is chip produces and distros are moving to RVA23U64/RVA23S64,
>> which implies in zbb and thus you can select it without the need to add an 
>> specific implementation.
> 
> So there is an question here, which hopefully Adhemerval can correct me if
> I'm wrong or confirm my memory is correct.  For non-multiarch builds, it's
> the sysdeps/riscv/preconfigure fragment that detects which sysdeps/riscv/*
> subdirectory to start our subdirectory search priority with by setting the
> "machine" variable.  The Implies file in that subdirectory then points to
> the next subdirectory to search in, etc. etc.  I believe (Adhemerval correct
> me if I'm wrong), is that if preconfigure says start at subdirectory "a" and
> its Implies file points to "b" and "b"'s Implies points to "c", etc, then if
> "a" is enabled via compiler flags, that implies "b", "c", etc. are all also
> enabled via the compiler flags, correct?  Meaning if "a" is enabled, then
> it cannot be that case that any of "b", "c", etc. are disabled, correct?
> 
> If that is the case, then we have a slight problem, in that rvv and zbb are
> orthogonal extensions, so one doesn't "imply" the other, so it wouldn't really
> be "legal" to have one in the Implies file of the other.
> 
> However, from a practical standpoint, there are cores that have implemented zbb,
> but have not implemented rvv, but I don't know of any cores that have rvv
> without also implementing zbb, so from a purely practical standpoint, rvv
> seems to "imply" zbb.  That said, I'm not sure whether we should rely on that?

Yes, the sysdep and Implies files were modeled back when new ISAs versions
were a subset of the previous one (like PowerPC POWERX, and 32 bit ARM armvX). 
And even then, we had some outliers like power6x/arm thumb which has some 
instructions not implemented in newer versions, and that required is own sysdeps 
subfolder *without* Implies file.

Newer ISAs now to push for extensions that might or not be implemented, which
includes x86_64, aarch64, and RISCV.  For these, the strategy will depend how 
the glibc would be deployed, the ISA support for GNU extensions (like IFUNC),
and what kind of hardware the deployer aims for.  

AArch64, for instance, is still setting a minimal ISA supported version of
ARMv8.0: all the sysdeps/aarch64/ optimizations assumes it.  Nothing prevents
a deployer to build glibc with a -march=armvX.Y, although ARM did take some
care to avoid potential pitfalls like add atomic outliers (so armv8.1 LSE
can be used by libgcc) and defining PAC+BTI in the NOP space (so a glibc build 
with --enable-standard-branch-protection still run on older hardware). 

For x86_64 we have added the x86_64-vX microarchitectures, along with glibc-hwcaps.
It allows deploying glibc built for the x86_64 baseline, but it still allows
build and use libraries with a higher microarchitecture level. The glibc loader
avoids the SIGILL issue by using the PT_GNU_PROPERTY (if present).  If ld.so sees
that libexample.so has GNU_PROPERTY_X86_ISA_1_NEEDED set to x86_64-v3 (AVX2), but
detects that you are running on an older x86_64-v2 CPU, the dynamic linker will
refuse to load it.

> 
> It's also opposite the order we want the strlen implementation to be picked up,
> which is zbb first and then fallback to rvv.
> 
> I suppose one option is if we decide that rvv does (from a practical standpoint)
> imply zbb, then we could create the zbb subdir, have it in rvv's Implies file
> and then remove the strlen-vector.S and place your strlen-zbb.S in the zbb
> subdir.  That would make all zbb only and rvv+zbb cores use the zbb strlen.
> 
Now for RISCV with its potentially dozens of extensions (plus the vendors ones),
I would suggest you to *avoid* adds extensions sysdeps (as this patch did), and
move any performance optimization only to multiarch - as aarch64 does for ISA
extensions one like SVE/MOPS. You already did for RVV, so I would suggest you
to circle back and only add them on the sysdeps/riscv/multiarch. 

Maybe also re-evalute whether rvd/rvf/rv64/rv32 is really required here, or
whether we can consolidate the implementations. I would also explicit disable
configuring with some broken configurations, like float-only (rvf).

It does not help for --disable-multi-arch, but it is also no the usual mode
to deploy glibc.

For this, a sysdep *might* make sense for the RISC-V *profiles. It would selecte
a baseline of arch-specific implementation (like vector ones).  I would also follow
AArch64 and try to provide *optimized baselines* implementation, so there is no
need to have this dance of which optimization each chip would benefit more.

You can have the over-complicated x86_64 way, to have multiple tuned implementation
for each specific chips (where it selects which vector instruction it use, in
which size range, etc); but again I would suggest you to follow AArch64 and
try to simplify things if possible.