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

Pincheng Wang pincheng.plct@isrc.iscas.ac.cn
Wed Sep 17 06:56:36 GMT 2025


On 2025/9/16 4:52, Peter Bergner wrote:
> On 9/15/25 7:40 AM, Pincheng Wang wrote:
>> op_t zbkb_v2_repeat_bytes(unsigned char c_in) {
>>     op_t out, t16;
>>     __asm__ volatile (
>>       "packh %0, %2, %2\n\t"
>>       "pack %1, %0, %0"
>>       : "=&r"(t16), "=&r"(out)
>>       : "r"((op_t)c_in));
>>     return out;
>> }
> 
> The "=&r"(out) operand doesn't need to be marked early clobber, since
> it is written after all the input and scratch registers have been
> read/used.  It's that unnecessary early clobber that is giving you
> the extra/unneeded mv insn.  Changing that operand to just "=r"(out),
> I see the following asm:
> 
> zbkb_v2_repeat_bytes:
> 	packh a5, a0, a0
> 	pack a0, a5, a5
> 	ret
> 
> Peter

Hi Peter,

Thank you for the pointer on the output constraint. After applying your 
suggestion, I now get the exact same assembly you showed.

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.

Crucially, while v2 removes register name reuse, it does not eliminate 
the true RAW dependency in the opration chain -- `pack` still consumes 
the result of the `packh`, so the critical producer-consumer path 
remains unchanged. More generally, because `packh`, `packw` and `pack` 
each double the width of their input, building a fully replicated 64-bit 
word from an 8-bit value in only three steps necessarily forms a serial 
chain: `packh` must feed `packw`, which must then feed `pack`. Breaking 
this chain would require computing two intermediate results in parallel 
and then combining them, which would need at least four instructions, so 
with only three instructions, some RAW dependency is unavoidable.

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.

Thanks again for your guidance and feedback!

Best regards,
Pincheng Wang



More information about the Libc-alpha mailing list