[PATCH bpf-next v5 1/3] riscv, bpf: Remap BPF_REG_0 and RV_REG_TCC

[Pu Lehui]

On 2026/9/5 17:42, bot+bpf-ci at kernel.org wrote:
>> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
>> index e7378be171a9..fc1c8c5480b6 100644
>> --- a/arch/riscv/net/bpf_jit_comp64.c
>> +++ b/arch/riscv/net/bpf_jit_comp64.c
>> @@ -23,11 +23,11 @@
>>   /* fentry and TCC init insns will be skipped on tailcall */
>>   #define RV_TAILCALL_OFFSET ((RV_FENTRY_NINSNS + 1) * 4)
>>
>> -#define RV_REG_TCC RV_REG_A6
>> +#define RV_REG_TCC RV_REG_T5
>>   #define RV_REG_ARENA RV_REG_S7 /* For storing arena_vm_start */
>>
>>   static const int regmap[] = {
>> -	[BPF_REG_0] =	RV_REG_A5,
>> +	[BPF_REG_0] =	RV_REG_T6,
>>   	[BPF_REG_1] =	RV_REG_A0,
>>   	[BPF_REG_2] =	RV_REG_A1,
>>   	[BPF_REG_3] =	RV_REG_A2,
> 
> This isn't a bug, but does moving BPF_REG_0 to t6 affect code density?
> arch/riscv/net/bpf_jit.h:is_creg() only accepts fp, s1, and a0-a5 for
> RVC-compressible forms. With CONFIG_RISCV_ISA_C, every emitter that gates
> on is_creg() now falls back to 4-byte instructions whenever BPF R0 is the
> destination or base register. Since R0 holds return values and helper
> results, could this measurably grow JIT image size for R0-heavy code?

This is expected. The bpf prog image size growth is expected to be 
negligible, and it is a necessary trade-off to free up registers for the 
calling convention.

> 
> The changelog explains why a5 and a6 needed to be freed, but it doesn't
> mention why t6 and t5 were chosen. Could a sentence be added about the
> register selection rationale, particularly since t4 appears unused by
> the JIT?

It's fine, let's mention here. We prefer caller-saved registers that are 
unused both now and going forward.

> 
>> @@ -47,13 +47,13 @@ static const int pt_regmap[] = {
>>   	[RV_REG_A2] = offsetof(struct pt_regs, a2),
>>   	[RV_REG_A3] = offsetof(struct pt_regs, a3),
>>   	[RV_REG_A4] = offsetof(struct pt_regs, a4),
>> -	[RV_REG_A5] = offsetof(struct pt_regs, a5),
>>   	[RV_REG_S1] = offsetof(struct pt_regs, s1),
>>   	[RV_REG_S2] = offsetof(struct pt_regs, s2),
>>   	[RV_REG_S3] = offsetof(struct pt_regs, s3),
>>   	[RV_REG_S4] = offsetof(struct pt_regs, s4),
>>   	[RV_REG_S5] = offsetof(struct pt_regs, s5),
>>   	[RV_REG_T0] = offsetof(struct pt_regs, t0),
>> +	[RV_REG_T6] = offsetof(struct pt_regs, t6),
>>   };
> 
> [ ... ]
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33956847598