[PATCH] D104080: [LLD][LLVM] CG Graph profile using relocations

Alexander Yermolovich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 23 10:37:09 PDT 2021


ayermolo added inline comments.


================
Comment at: llvm/lib/MC/MCELFStreamer.cpp:498
+  MCObjectStreamer::emitRelocDirective(
+      *MCOffset, getAssembler().getBackend().getNoneRelcationName(), SRE,
+      SRE->getLoc(), *getContext().getSubtargetInfo());
----------------
MaskRay wrote:
> ayermolo wrote:
> > MaskRay wrote:
> > > it's ugly, but you can use `.reloc xxx, BFD_RELOC_NONE, sym`
> > This will reduce the scope of changes in this patch, but then new backend creator will need to know of this trick. I don't know the history of BFD_RELOC_NONE. Is it expected for architectures that have _NONE to have the mapping?
> > . .Case("BFD_RELOC_NONE", ELF::R_<arch>_NONE)
> > Is it expected for architectures that have _NONE to have the mapping? . .Case("BFD_RELOC_NONE", ELF::R_<arch>_NONE)
> 
> Yes. In GNU as, `BFD_RELOC_NONE` is generic and can be used on all targets. I have added `BFD_RELOC_NONE` to many LLVM targets. Note: .llvm.call-graph-profile is used by -fprofile-use=. The targets which don't support `BFD_RELOC_NONE` are not used by people for PGO. (If they do use PGO, adding the support should be trivial anyway.)
> 
> It probably makes sense to save the return value in a variable and assert it is `None`. I find that an unknown `BFD_RELOC_NONE` does not cause an error.
ok, will remove getNoneRelcationName(), and use BFD_RELOC_NONE here. Thanks for the background.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104080/new/

https://reviews.llvm.org/D104080



More information about the llvm-commits mailing list