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

[Peter Bergner]

On 6/12/26 1:12 PM, Adhemerval Zanella Netto wrote:
> 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. 
[snip]
> 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.

Talking with Jeff offline, I think we're both coming to the conclusion that
you are correct (not a surprise!) and that sysdep directories for a lot of
orthogonal extensions is going to be messy and unwieldy.  I do like your
suggestion of having sysdep directories for riscv profiles as those can pull
in lots of extensions at once and riscv profiles somewhat being supersets of
previous profiles more closely matches the behavior expected by the Implies
files.

I'll study how AArch64 implements those optimized baselines to see if we
can use the same design.  Thanks for the pointer.  I'm sure I'll be back
with questions though! :-)  ...and any pointers or gotchas to look out for
will be greatly appreciated.

Obviously, this would be a following release kind of thing though, given
where we are in the release process.

Peter