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

[Peter Bergner]

On 6/10/26 11:09 PM, Jeffrey Law wrote:
> We can see the Zbb is just better all around.  There wasn't a single 
> case where RVV won.  It's pretty obvious that the vector version has a 
> higher fixed overhead, but I really expected vector to overcome that 
> overhead as the strings got longer.  As it stands the data says quite 
> clearly that we should be using Zbb on the K3 design and likely the K1 
> design (currently being tested).
> 
> Given the K1/K3 designs are what folks can get their hands on, I'd 
> recommend we make Zbb preferred over RVV.  We'll likely have to adjust 
> that as newer designs come into the market, but the decision should be 
> data driven.  I'm going to run this on our Veyron V2 design and Peter is 
> going to run on the Ascalon design, but neither of those are generally 
> available and probably shouldn't drive decisions, those are mostly for 
> informational purposes and to give a sense of whether or not higher 
> targeted designs are likely to benefit from the RVV variant when those 
> higher performance designs hit the market.

Yes, I'll have someone run the tests on our Ascalon design and report
back.

That said, this is looking good for a normal multiarch build, but for
a --disable-multiarch build, we'll need some sysdeps/riscv/preconfigure*
and Implies file changes, specifying the subdirectory search priority.
I believe "as is" with this patch, if we build with --disable-multiarch,
we'll never look in the zbb subdir, meaning zbb isn't in the subdirectory
search list at all.

With your data, it would seem we'd want to search the new zbb subdir
before the rvv subdir...at least for strlen, but I doubt we'd want
that for all other functions, right?  So do we go with, search rvv
first, followed by zbb and just take the perf hit for non-multiarch
builds?  Your thoughts?

Peter