[PATCH] D87153: [RFC] BPF: move AbstractMemberAccess and PreserveDIType passes to EP_EarlyAsPossible

Yonghong Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 4 09:32:31 PDT 2020


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

Move abstractMemberAccess and PreserveDIType passes as early as
possible, right after clang code generation.

Currently, compiler may transform the above code

  p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); 
  p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); 
  a = llvm.bpf.builtin.preserve_field_info(p2, EXIST);
  if (a) {
    p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); 
    p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); 
    bpf_probe_read(buf, buf_size, p2);
  }

to

  p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); 
  p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); 
  a = llvm.bpf.builtin.preserve_field_info(p2, EXIST);
  if (a) {
    bpf_probe_read(buf, buf_size, p2);
  }

and eventually assembly code looks like

  reloc_exist = 1;
  reloc_member_offset = 10; //calculate member offset from base
  p2 = base + reloc_member_offset;
  if (reloc_exist) {
    bpf_probe_read(bpf, buf_size, p2);
  }

if during libbpf relocation resolution, reloc_exist is actually
resolved to 0 (not exist), reloc_member_offset relocation cannot
be resolved and will be patched with illegal instruction.
This will cause verifier failure.

This patch attempts to address this issue by do chaining
analysis and replace chains with special globals right
after clang code gen. This will remove the cse possibility
described in the above. The IR typically looks like

  %6 = load @llvm.sk_buff:50:$0:0:0:2:0
  %7 = bitcast %struct.sk_buff* %2 to i8* 
  %8 = getelementptr i8, i8* %7, %6

for a particular address computation relocation.

But this transformation has another consequence, code sinking
may happen like below:

  PHI = <possibly different @preserve_*_access_globals>
  %7 = bitcast %struct.sk_buff* %2 to i8* 
  %8 = getelementptr i8, i8* %7, %6

For such cases, we will not able to generate relocations since
multiple relocations are merged into one.

Looking at LLVM code, inline asm or a non-merge function in
the code can prevent such simplifyCFG code sinking optimization.
This patch added a memory barrier at the end of basic block
involving btf relocation to prevent such optimization.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87153

Files:
  llvm/lib/Target/BPF/BPF.h
  llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
  llvm/lib/Target/BPF/BPFPreserveDIType.cpp
  llvm/lib/Target/BPF/BPFTargetMachine.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D87153.289984.patch
Type: text/x-patch
Size: 15939 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200904/a444297c/attachment-0001.bin>


More information about the llvm-commits mailing list