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

[Jeffrey Law]

On 7/5/2026 6:20 AM, Florian Weimer wrote:
> * Jeffrey Law:
>
>> I'm seeing some really weird results and I wish camel-cdr had data on
>> a Zbb implemenation to correlate against -- his data has been
>> incredibly helpful in confirming the vector behavior as well as the
>> generic implementation behavior.  But he didn't have a zbb variant.
>>
>> Basically it appears yours is meaningfully slower for small strings.
>> It starts off about 50% slower, but closes the gap for each 2^n length
>> bucket.  The crossover point is around 128 bytes after which it blows
>> away the other zbb variant -- it was still widening the gap at the 8k
>> bucket where it was about 60% faster.  *BUT* the loop itself is
>> unchanged and while it appears there's one less architectural register
>> in use, I'd be amazed if that one register was enough to make this
>> kind of difference at the uarch level.
> Hmm, maybe it's not working correctly and incorrectly returning early?
> As I said, it's untested.  Or maybe it's related to the .p2align?
>
> The dependency chains should be equal or shorter even for short strings,
> so the regression is surprising.  And the loop really should not get any
> faster.
So I poked around some more today and I'm increasingly suspicious that 
what we're seeing with your implementation is the same kind of jitter we 
were seeing in other performance efforts on the K1 design, but now 
showing their head on the K3.  I want to do a bit more testing, but this 
time with a taskset wrapper to force things onto the same core every time.

Essentially on the K1 we could see double-digit performance deltas 
run-to-run on benchmarks like spec2017 components.  We happened to also 
have L3 cache sensitivity data on each component of spec2017 on the 
Ventana design and we found the K1 jitter closely correlated to 
benchmarks that were L3 cache sensitive.  Yes, the K1 doesn't have an 
L3, the L3 data was a rough proxy for memory sensitivity.

We moved to using tasksets to run everything to tamp down this effect 
which brought run-to-run jitter down to the 1% range.  We've been using 
that on the K3, so we haven't really looked at run-to-run jitter on the K3.

Overall point being I think we're likely good with either 
implementation, but I need to do a bit more testing.

Jeff