[PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[Jianlin Lv]

A64_MOV is currently mapped to Add Instruction. Architecturally MOV
(register) is an alias of ORR (shifted register) and MOV (to or from SP)
is an alias of ADD (immediate).
This patch redefines A64_MOV and uses existing functionality
aarch64_insn_gen_move_reg() in insn.c to encode MOV (register) instruction.
For moving between register and stack pointer, rename macro to A64_MOV_SP.

Test:
	modprobe test_bpf test_name="SPILL_FILL"
	bpf_jit_disasm -o

without patch:
   0:   stp     x29, x30, [sp, #-16]!
        fd 7b bf a9
   4:   mov     x29, sp
        fd 03 00 91
	...
  14:   mov     x25, sp
        f9 03 00 91
	...
  24:   add     x19, x0, #0x0
        13 00 00 91
	...
  8c:   add     x0, x7, #0x0
        e0 00 00 91

with patch:
   0:   stp     x29, x30, [sp, #-16]!
        fd 7b bf a9
   4:   mov     x29, sp
        fd 03 00 91
	...
  14:   mov     x25, sp
        f9 03 00 91
	...
  24:   mov     x19, x0
        f3 03 00 aa
	...
  8c:   mov     x0, x7
        e0 03 07 aa

Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
---
 arch/arm64/net/bpf_jit.h      | 7 +++++--
 arch/arm64/net/bpf_jit_comp.c | 4 ++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h
index cc0cf0f5c7c3..a2c3cddb1d2f 100644
--- a/arch/arm64/net/bpf_jit.h
+++ b/arch/arm64/net/bpf_jit.h
@@ -108,8 +108,8 @@
 #define A64_CMN_I(sf, Rn, imm12) A64_ADDS_I(sf, A64_ZR, Rn, imm12)
 /* Rn - imm12; set condition flags */
 #define A64_CMP_I(sf, Rn, imm12) A64_SUBS_I(sf, A64_ZR, Rn, imm12)
-/* Rd = Rn */
-#define A64_MOV(sf, Rd, Rn) A64_ADD_I(sf, Rd, Rn, 0)
+/* Rd = Rn; MOV (to/from SP) */
+#define A64_MOV_SP(sf, Rd, Rn) A64_ADD_I(sf, Rd, Rn, 0)
 
 /* Bitfield move */
 #define A64_BITFIELD(sf, Rd, Rn, immr, imms, type) \
@@ -134,6 +134,9 @@
 #define A64_UXTH(sf, Rd, Rn) A64_UBFM(sf, Rd, Rn, 0, 15)
 #define A64_UXTW(sf, Rd, Rn) A64_UBFM(sf, Rd, Rn, 0, 31)
 
+/* Rd = Rm; MOV (register) */
+#define A64_MOV(sf, Rd, Rm) aarch64_insn_gen_move_reg(Rd, Rm, A64_VARIANT(sf))
+
 /* Move wide (immediate) */
 #define A64_MOVEW(sf, Rd, imm16, shift, type) \
 	aarch64_insn_gen_movewide(Rd, imm16, shift, \
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index f7b194878a99..2a118c0fcb30 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -229,7 +229,7 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
 
 	/* Save FP and LR registers to stay align with ARM64 AAPCS */
 	emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
-	emit(A64_MOV(1, A64_FP, A64_SP), ctx);
+	emit(A64_MOV_SP(1, A64_FP, A64_SP), ctx);
 
 	/* Save callee-saved registers */
 	emit(A64_PUSH(r6, r7, A64_SP), ctx);
@@ -237,7 +237,7 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
 	emit(A64_PUSH(fp, tcc, A64_SP), ctx);
 
 	/* Set up BPF prog stack base register */
-	emit(A64_MOV(1, fp, A64_SP), ctx);
+	emit(A64_MOV_SP(1, fp, A64_SP), ctx);
 
 	if (!ebpf_from_cbpf) {
 		/* Initialize tail_call_cnt */
-- 
2.25.1

Re: [PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[Will Deacon]

On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> is an alias of ADD (immediate).
> This patch redefines A64_MOV and uses existing functionality
> aarch64_insn_gen_move_reg() in insn.c to encode MOV (register) instruction.
> For moving between register and stack pointer, rename macro to A64_MOV_SP.

What does this gain us? There's no requirement for a BPF "MOV" to match an
arm64 architectural "MOV", so what's the up-side of aligning them like this?

Cheers,

Will

Re: [PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[Jianlin Lv]

On Tue, Mar 30, 2021 at 5:31 PM Will Deacon <will@kernel.org> wrote:
>
> On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> > A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> > (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> > is an alias of ADD (immediate).
> > This patch redefines A64_MOV and uses existing functionality
> > aarch64_insn_gen_move_reg() in insn.c to encode MOV (register) instruction.
> > For moving between register and stack pointer, rename macro to A64_MOV_SP.
>
> What does this gain us? There's no requirement for a BPF "MOV" to match an
> arm64 architectural "MOV", so what's the up-side of aligning them like this?
>
> Cheers,
>
> Will

According to the description in the Arm Software Optimization Guide,
Arithmetic(basic) and Logical(basic) instructions have the same
Exec Latency and Execution Throughput.
This change did not bring about a performance improvement.
The original intention was to make the instruction map more 'natively'.

Jianlin

Re: [PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[Will Deacon]

On Wed, Mar 31, 2021 at 05:22:18PM +0800, Jianlin Lv wrote:
> On Tue, Mar 30, 2021 at 5:31 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> > > A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> > > (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> > > is an alias of ADD (immediate).
> > > This patch redefines A64_MOV and uses existing functionality
> > > aarch64_insn_gen_move_reg() in insn.c to encode MOV (register) instruction.
> > > For moving between register and stack pointer, rename macro to A64_MOV_SP.
> >
> > What does this gain us? There's no requirement for a BPF "MOV" to match an
> > arm64 architectural "MOV", so what's the up-side of aligning them like this?
> 
> According to the description in the Arm Software Optimization Guide,
> Arithmetic(basic) and Logical(basic) instructions have the same
> Exec Latency and Execution Throughput.
> This change did not bring about a performance improvement.
> The original intention was to make the instruction map more 'natively'.

I think we should leave the code as-is, then. Having a separate MOV_SP
macro s confusing and, worse, I worry that somebody passing A64_SP to
A64_MOV will end up using the zero register.

Will

Re: [PATCH bpf-next] bpf: arm64: Redefine MOV consistent with arch insn

[Jianlin Lv]

On Wed, Mar 31, 2021 at 5:28 PM Will Deacon <will@kernel.org> wrote:
>
> On Wed, Mar 31, 2021 at 05:22:18PM +0800, Jianlin Lv wrote:
> > On Tue, Mar 30, 2021 at 5:31 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> > > > A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> > > > (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> > > > is an alias of ADD (immediate).
> > > > This patch redefines A64_MOV and uses existing functionality
> > > > aarch64_insn_gen_move_reg() in insn.c to encode MOV (register) instruction.
> > > > For moving between register and stack pointer, rename macro to A64_MOV_SP.
> > >
> > > What does this gain us? There's no requirement for a BPF "MOV" to match an
> > > arm64 architectural "MOV", so what's the up-side of aligning them like this?
> >
> > According to the description in the Arm Software Optimization Guide,
> > Arithmetic(basic) and Logical(basic) instructions have the same
> > Exec Latency and Execution Throughput.
> > This change did not bring about a performance improvement.
> > The original intention was to make the instruction map more 'natively'.
>
> I think we should leave the code as-is, then. Having a separate MOV_SP
> macro s confusing and, worse, I worry that somebody passing A64_SP to
> A64_MOV will end up using the zero register.
>
> Will

OK, your concerns are justified. I have made such mistakes.

Jianlin