[EXT] [PATCH 1/1] riscv: Add Zbkb optimized repeat_bytes helper

[Pincheng Wang]

On 2025/9/18 02:04, Peter Bergner wrote:
> On 9/17/25 1:56 AM, Pincheng Wang wrote:
>> I also reran the microbenchmarks on the Raspberry Pi Pico 2. With the
>> corrected constraints, the v2 function (using temporaries) is about 4%
>> *slower* than v1 on this Hazard3 RV32 core.
> 
> Hi Pincheng,
> 
> So you're saying the:
> 
> 	packh a0,a0,a0
> 	pack. a0,a0,a0
> 
> sequence is actually faster than the:
> 
> 	packh a5,a0,a0
> 	pack. a0,a5,a5
> 
> sequence on your Hazard3 RV32 core?  If so, then I'm a little surprised,
> but I won't argue against actual data!  Higher performant cores with
> register renaming shouldn't care either way.  Thanks for taking the
> time to perform the tests!

Indeed, it's a rather interesting benchmark result. The original v1 
sequence (operating in-place on `a0`) does run measurably faster than 
the v2 variant (using a temporary register) on the Hazard3 RV32 core. 
I'm inclined to stick with the v1 implementation for now. That said, I 
plan to revisit and verify this result once I have access to actual RV64 
hardware with Zbkb support. It'll be interesting to see whether the 
performace characteristics hold across different microarchitectures.

> 
> Just as an FYI for me, how much slower was the generic code than the v1
> sequence?
> 

For the `repeat_bytes` function, the generic C implementation runs 
approximately 10.7% slower than the optimized v1 assembly sequence on 
the Hazard3 RV32 core.

On RV64 core, we might see a slightly smaller improvement due to the 
additional `pack` instruction required in the RV64 version compared to 
RV32. However, compared to the original C implementation, the optimized 
assembly still uses fewer instructions and incurs lower insturcion 
overhead, so we can resonably expect a smililar level of performace 
gain, even if slightly attenuated.

For reference, in an earlier qualitative benchmark on QEMU (RV64), we 
observed a 13.275% reduction in execution time (95% CI: [12.212%, 
14.432%]), suggesting the optimization remains valuable.

> 
>> Given these results, I'm inclined to keep the simpler v1 sequence, which
>> performs better here in practice. I'm happy to hear any further thoughts
>> from you or others on this trade-off. Once we settle on the preferred
>> approach, I will prepare and submit the v2 patch.
> 
> So given the above, it seems the only change needed then is Adhemerval's
> suggestion to remove the redundant __riscv_zbkb usage.
> 
> Peter
> 

Understood, I'll proceed with v2 of the patch. Thank you again for your 
help and feedback!

Best regards,
Pincheng Wang