[PATCH] D109073: BPF: make 32bit register spill with 64bit alignment

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song created this revision.
yonghong-song added reviewers: ast, iamkafai.
Herald added subscribers: hiraditya, qcolombet.
yonghong-song requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

In llvm, for non-alu32 mode, the stack alignment is 64bit so only one 
64bit spill per 64bit slot. For alu32 mode, the stack alignment
is 32bit, so it is possible to have two 32bit spills per 
64bit slot.

Currently, bpf kernel verifier does not preserve register states
for 32bit spills. That is, one 32bit register may hold a constant
value or a bounded range before spill. After reload from the 
stack, the information is lost and sometimes this may cause
verifier failure. For 64bit register spill, the verifier
indeed tries to preserve the register state for reloading.

The current verifier can be modestly changed to handle one 
32bit spill per 64bit stack slot with state-preserving reload.
Handling two 32bit spills per 64bit stack slot will require
substantial changes.

This patch changes stack alignment for alu32 to be 64bit.
This way, for any 64bit slot in alu32 mode, only one 
32bit or 64bit register values can be saved. Together
with previous-mentioned verifier enhancement, 32bit
spill can be handled with state preserving.

Note that  llvm stack slot coallescing
seems only doing adjacent packing which may leave some holes
in the stack. For example,

  stack slot 8   <== 8 bytes
  stack slot 4   <== 8 bytes with 4 byte hole
  stack slot 8   <== 8 bytes
  stack slot 4   <== 4 bytes


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109073

Files:
  llvm/lib/Target/BPF/BPFRegisterInfo.td
  llvm/test/CodeGen/BPF/spill-alu32.ll


Index: llvm/test/CodeGen/BPF/spill-alu32.ll
===================================================================
--- /dev/null
+++ llvm/test/CodeGen/BPF/spill-alu32.ll
@@ -0,0 +1,35 @@
+; RUN: llc -march=bpf -mcpu=v3 < %s | FileCheck %s
+;
+; Source code:
+;   void foo(int, int, int, long, int);
+;   int test(int a, int b, int c, long d, int e) {
+;     foo(a, b, c, d, e);
+;     __asm__ __volatile__ ("":::"r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "memory");
+;     foo(a, b, c, d, e);
+;     return 0;
+;   }
+; Compilation flag:
+;   clang -target bpf -S -emit-llvm -O2 -mcpu=v3 t.c
+
+; Function Attrs: nounwind
+define dso_local i32 @test(i32 %a, i32 %b, i32 %c, i64 %d, i32 %e) local_unnamed_addr #0 {
+entry:
+  tail call void @foo(i32 %a, i32 %b, i32 %c, i64 %d, i32 %e) #2
+  tail call void asm sideeffect "", "~{r0},~{r1},~{r2},~{r3},~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{memory}"() #2
+
+; CHECK:        *(u32 *)(r10 - 8) = w5
+; CHECK:        *(u64 *)(r10 - 16) = r4
+; CHECK:        *(u32 *)(r10 - 24) = w3
+; CHECK:        *(u32 *)(r10 - 32) = w2
+; CHECK:        *(u32 *)(r10 - 40) = w1
+; CHECK:        call foo
+
+  tail call void @foo(i32 %a, i32 %b, i32 %c, i64 %d, i32 %e) #2
+  ret i32 0
+}
+
+declare dso_local void @foo(i32, i32, i32, i64, i32) local_unnamed_addr #1
+
+attributes #0 = { nounwind "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="v3" }
+attributes #1 = { "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="v3" }
+attributes #2 = { nounwind }
Index: llvm/lib/Target/BPF/BPFRegisterInfo.td
===================================================================
--- llvm/lib/Target/BPF/BPFRegisterInfo.td
+++ llvm/lib/Target/BPF/BPFRegisterInfo.td
@@ -36,7 +36,7 @@
 }
 
 // Register classes.
-def GPR32 : RegisterClass<"BPF", [i32], 32, (add
+def GPR32 : RegisterClass<"BPF", [i32], 64, (add
   (sequence "W%u", 1, 9),
   W0, // Return value
   W11, // Stack Ptr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D109073.369974.patch
Type: text/x-patch
Size: 2038 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210901/1ea86797/attachment.bin>