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

[Jeffrey Law]

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

Jeff