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

[Adhemerval Zanella Netto]

On 13/06/26 01:46, Jeffrey Law wrote:
> 
> 
> On 6/12/2026 10:56 AM, 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?
>>
>> 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.
> While it's probably OK in practice right now, the fundamental nature of the RISC-V ISA is a designer can mix and match extensions.  As you note, there is no implies relationship between Zbb and RVV.  I'm not at all a fan of how that works, but it is what it is and we should try to do the right thing here.
> 
> I think that argues that Adhemerval's suggestion is probably the right way to go.  I need to look at it again, but the gist was to move the Zbb stuff into the multiarch directory, dropping zbb as a distinct sysdep directory.  This is an aspect of glibc I don't know well at all and I was largely trying to mimick what's being done elsewhere.  But this is fundamentally different.  Adhemerval's suggestion is actually how this stuff was implemented internally, it was only when I looked closely at how the final RVV stuff went into the tree that I mirrored some of that into the Zbb patch.
> 
> Note that I'm still generating and evaluating data on the other cases.  While strlen is a slam dunk right now for Zbb, the others aren't as clear cut.  That I think also argues that Zbb probably shouldn't be a sysdep.  I also would fully expect that as designs get better (let's face it, while K3 is a huge improvement over the K1, it's not would I would call a high performance design).
Another advantage of having the optimized routines as ifunc options is you can
have the selection logic on the ifunc resolver, instead of relying on some
specific build option being used (as to tune glibc build for a specific chip).

But you can still have a sysdeps folder, but I think for RISCV it would make
sense more a profile one.  It will then gather the preferred routines options,
and also disable ifunc selection if not required.