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

Mon Jul 6 12:51:43 GMT 2026

Am Samstag, 4. Juli 2026, 15:34:26 Japanische Normalzeit schrieb Jeffrey Law:
> So this is the V2 patch of a Zbb strlen implementation.  As was 
> previously noted, this is 2-4X faster than the current RVV 
> implementation on the K3 and meaningfully faster on the K1 as well (I 
> don't remember that data offhand other than Zbb was the best choice 
> there too).

After the release please.

> 
> The most important difference between this and the first patch is 
> there's no longer a Zbb specific directory.  Per the discussion from 
> last month there aren't any plans to make any Implies relationships and 
> such.
> 
> The ifunc resolver has been improved ever-so-slightly to avoid an extra 
> round trip through the hwprobe interface.  We can get the state of Zbb 
> and RVV with a single round trip.  A few comment typos spotted by an 
> LLM  have been fixed as well.
> 
> 
> With dropping the Zbb subdirectory, the bits left in the multiarch 
> directory have all the hidden symbol, alias and related stuff. I'm not 
> at all familiar with what needs to be done in this case. So I'd 
> appreciate a close look at that code.
> 
> I've built and tested glibc on the K3 with this patch.  It shows no 
> regressions relative to the baseline build.  I've also verified the 
> performance data is not meaningfully changed.
> 
> Obviously hoping we can get this included in the upcoming release...
> 
> 
> --
> So we've had Zbb variants for strlen, strcmp and a few other routines 
> sitting here in our local repositories for a long time. The original 
> implementations were done by the VRULL team, then adjusted for minor 
> bugs caught by the glibc testsuite and later wired into the hwprobe 
> mechanism.
> 
> Much like the RVV implementations that have been dropping into the tree, 
> I want to focus on one routine at a time to make sure we're happy with 
> the result, then move onto the next one.  In this particular patch I'm 
> focused on strlen.
> 
> The implementation is largely derived from the bitmanip examples, just 
> cleaned up so that it ought to work for both rv32/rv64 and either big or 
> little endian (little endian is untested, I believe VRULL tested rv32 at 
> some point).
> 
> 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.
> 
> I asked the LLM model to take the performance data, convert it to cycles 
> per byte, then get the average cycles per byte over a range of lengths 
> new buckets starting a power of 2 boundaries.
> 
> Bucket        ZBB CPB        Vector CBP     Winner
> 1-1           4.227          17.312         ZBB is ~4.1x faster
> 2-3           1.714           7.232         ZBB is ~4.2x faster
> 4-7           0.870           3.287         ZBB is ~3.8x faster
> 8-15          0.563           1.950         ZBB is ~3.5x faster
> 16-31         0.446           0.954         ZBB is ~2.1x faster
> 32-63         0.299           0.477         ZBB is ~1.6x faster
> 64-127 0.190           0.414        ZBB is ~2.2x faster
> 
> And so-on with the cycles-per-byte dropping for both, but ZBB 
> consistently running ~2.1x faster than RVV up to a length of 8k.
> 
> 
> 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.
> 
> 
> You could also legitimately ask what GCC should be doing here. Right now 
> GCC will inline the strlen call, generating RVV code that is nearly 
> identical to what's in glibc.  So it's probably not a win for GCC to 
> inline an RVV strlen, though inlining does at least avoid the function 
> call overhead and allow for secondary optimization affects since there's 
> no call.
> 
> This has been built and regression tested on the c920 and K3, the K1 is 
> still running.  The c920 is interesting because it has neither RVV nor 
> Zbb, so confirming I didn't do anything dumb in the resolver was useful.
> --
> 
> OK for the trunk?
> 
> jeff

-- 
PD Dr. Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260706/98a61604/attachment.sig>