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

[bot+bpf-ci]

> 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?

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?

> @@ -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