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

[Jeffrey Law]

On 7/4/2026 4:50 AM, Florian Weimer wrote:
> * Jeffrey Law:
>
>> Neither the Zbb nor the RVV implementation seems at all sensitive to
>> data alignment concerns on the K3.  So we can safely ignore that input
>> axis and focus on how many cycles it takes to handle a string of a
>> particular length.
> The alignment affects the effective string length, though.
True.  My point was at least in the micro-benchmark data the data 
alignment doesn't seem to impact the results, at least not at a level 
that would impact if we decide to use Zbb over RVV for strlen.

>
> What about this (completely untested)?  The LLMs think it's never
> slower.  The two-word and and three-word cases should be faster.
>
> (I don't consider the attached version LLM-generated anymore.)
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.  Moreover it's running at about 
14bytes per cycle, which would imply the loop is running  at < 1c since 
the loop processes 8 bytes per iteration.   Could that be happening?  
Yea, I guess the OOO engine could do that, but it begs the question why 
the original didn't behave in the same manner.

So I'm still playing with it.

jeff