[PATCH] D78466: BPF: fix a CORE optimization bug

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song created this revision.
yonghong-song added reviewers: ast, anakryiko.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

For the test case in this patch like below

  struct t { int a; } __attribute__((preserve_access_index));
  int foo(void *); 
  int test(struct t *arg) {
      long param[1];
      param[0] = (long)&arg->a;
      return foo(param);
  }

The IR right before BPF SimplifyPatchable phase:

  %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
  %2:gpr = LDD killed %1:gpr, 0
  %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
  STD killed %3:gpr, %stack.0.param, 0

After SimplifyPatchable phase, the incorrect IR is generated:

  %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
  %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %1:gpr
  CORE_MEM killed %3:gpr, 306, %0:gpr, @"llvm.t:0:0$0:0"

Note that CORE_MEM pseudo op is introduced to encode
memory operations related to CORE. In the above, we intend
to check whether we have a store like

  *(%3:gpr + 0) = ... 

and if this is the case, we could replace it with

  *(%0:gpr + @"llvm.t:0:0$0:0"_ = ... 

Unfortunately, in the above, IR for the store is

  *(%stack.0.param + 0) = %3:gpr

and transformation should not happen.

Note that we won't have problem if the actual CORE
dereference (arg->a) happens.

This patch fixed the problem by skip CORE optimization if
the use of ADD_rr result is not the base address of the store
operation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78466

Files:
  llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
  llvm/test/CodeGen/BPF/CORE/store-addr.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D78466.258635.patch
Type: text/x-patch
Size: 7209 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200420/0db25cbd/attachment-0001.bin>