[PATCH] D54720: [PPC64] toc-indirect to toc-relative relaxation.

[Sean Fertile via Phabricator via llvm-commits]

sfertile marked 6 inline comments as done.
sfertile added inline comments.


================
Comment at: ELF/Arch/PPC64.cpp:120
+  auto SymAndAddend =
+      [TocSec](typename ELFT::Rela Rela) -> std::pair<Defined *, int64_t> {
+    Symbol &IndirectSym = TocSec->getFile<ELFT>()->getRelocTargetSym(Rela);
----------------
ruiu wrote:
> When we define a local helper lambda function inside a function, we capture variables just by `[&]` instead of explicitly enumerating variables.
I've updated to follow suit, but can I ask the rational behind this? For a lambda as small as this one its easy to see that only one variable is used and its not modified, but in general I would prefer to be explicit and not capture anymore then I used. 


================
Comment at: ELF/Arch/PPC64.cpp:174
+  assert(Expr == R_PPC64_RELAX_TOC &&
+         "unexpected RelExpr for got-indirect to toc-relative relaxation");
+  assert(Config->TocOptimize &&
----------------
MaskRay wrote:
> The title of this revision says "toc-indirect" while here and some other places say "got-indirect". Which term is preferred? (Or maybe they are two different things and I am confused..)
got-indirect is the term used in the ABI and so I have tried to stick mostly to that, especially for anything a user would see like a diagnostic.  toc-indirect is a term I made up to describe the way gcc/clang/xlc actually produce a got-indirecton as its a bit different then what I think most would expect. The 2 ways have slightly different input, but the output from the linker is the same.

got-indirect -> its up to the linker to allocate a got entry for sym. The got entry is accessed relative to the toc-pointer.
```
    addis r3, r2, sym at got@ha   
    ld        r3, sym at got@l(r3) 
   lwa       r3, r3
```

vs toc-indirect --> the compiler allocates an entry in the .toc section and puts a relocation for the symbols address into that .toc entry. The toc entry is accessed relative to the toc-pointer.
```
    addis r3, r2, .LC0 at toc@ha   
    ld        r3, .LC0 at toc@l(r3) 
   lwa       r3, r3
...

   .toc
.LC0:
   .tc sym[TC], sym # emits a relocation for sym. Roughly equivalent to .quad sym?
```

All this extra work in looking up the relocation to find the symbol thats being accessed is because the compiler emits the second form rather then the first. In the final binary the .toc sections are either merged into the .got section (bfd/gold) or allocated right after the .got section (lld) and you end up with a got-indirect access.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D54720