[PATCH] D71790: [BPF] Enable relocation location for load/store/shifts

Yonghong Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 20 16:47:02 PST 2019


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

  Previous btf field relocation is always at assignment like
     r1 = 4
  which is converted from an ld_imm64 instruction.
  
  This patch did an optimization such that relocation
  instruction might be load/store/shift. Specically, the
  following insns may also have relocation, except BPF_MOV:
    LDB, LDH, LDW, LDD, STB, STH, STW, STD,
    LDB32, LDH32, LDW32, STB32, STH32, STW32,
    SLL, SRL, SRA
  
  To accomplish this, a few BPF target specific
  codegen only instructions are invented. They
  are generated at backend BPF SimplifyPatchable phase,
  which is at early llc phase when SSA form is available.
  The new codegen only instructions will be converted to
  real proper instructions at the codegen and BTF emission stage.
  
  Note that, as revealed by a few tests, this optimization might
  be actual generating more relocations:
  Scenario 1:
    if (...) {
      ... __builtin_preserve_field_info(arg->b2, 0) ...
    } else {
      ... __builtin_preserve_field_info(arg->b2, 0) ...
    }
    Compiler could do CSE to only have one relocation. But if both
    of the above is translated into codegen internal instructions,
    the compiler will not be able to do that.
  Scenario 2:
    offset = ... __builtin_preserve_field_info(arg->b2, 0) ...
    ...
    ...  offset ...
    ...  offset ...
    ...  offset ...
    For whatever reason, the compiler might be temporarily do copy
    propagation of the righthand of "offset" assignment like
    ...  __builtin_preserve_field_info(arg->b2, 0) ...
    ...  __builtin_preserve_field_info(arg->b2, 0) ...
    and CSE will be able to deduplicate later.
    But if these intrinsics are converted to BPF pseudo instructions,
    they will not be able to get deduplicated.
  
  I do not expect we have big instruction count difference.
  It may actually reduce instruction count since now relocation
  is in deeper insn dependency chain.
  For example, for test offset-reloc-fieldinfo-2.ll, this patch
  generates 7 instead of 6 relocations for non-alu32 mode, but it
  actually reduced instruction count from 29 to 26.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D71790

Files:
  llvm/lib/Target/BPF/BPFInstrInfo.td
  llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
  llvm/lib/Target/BPF/BTFDebug.cpp
  llvm/lib/Target/BPF/BTFDebug.h
  llvm/test/CodeGen/BPF/CORE/offset-reloc-end-load.ll
  llvm/test/CodeGen/BPF/CORE/offset-reloc-fieldinfo-1.ll
  llvm/test/CodeGen/BPF/CORE/offset-reloc-fieldinfo-2.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D71790.234989.patch
Type: text/x-patch
Size: 19715 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191221/1cfedf12/attachment.bin>


More information about the llvm-commits mailing list