[all-commits] [llvm/llvm-project] ffd574: [BPF] Enable relocation location for load/store/sh...

yonghong-song via All-commits all-commits at lists.llvm.org
Thu Dec 26 09:10:20 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: ffd57408efd4c8d455616a5ff4f623250e8580c9
      https://github.com/llvm/llvm-project/commit/ffd57408efd4c8d455616a5ff4f623250e8580c9
  Author: Yonghong Song <yhs at fb.com>
  Date:   2019-12-26 (Thu, 26 Dec 2019)

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

  Log Message:
  -----------
  [BPF] Enable relocation location for load/store/shifts

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.

Differential Revision: https://reviews.llvm.org/D71790




More information about the All-commits mailing list