[PATCH] D60958: [PPC64] toc-indirect to toc-relative relaxation

[Fangrui Song via Phabricator via llvm-commits]

MaskRay marked an inline comment as done.
MaskRay added inline comments.


================
Comment at: ELF/Arch/PPC64.cpp:114-115
+  ArrayRef<typename ELFT::Rela> Relas = TocSec->template relas<ELFT>();
+  while (TocRelIdx < Relas.size() && Relas[TocRelIdx].r_offset < Offset)
+    ++TocRelIdx;
+  if (!(TocRelIdx < Relas.size() && Relas[TocRelIdx].r_offset == Offset))
----------------
ruiu wrote:
> How fast is this statement? Don't you have to do binary search?
When resolving `R_PPC16_TOC_*` in a `.rela.text` section, `TocRelIdx` is monotonically increasing.
The loop is executed at most `num(R_PPC16_TOC_*)+size(.rela.text)` times.

The pessimistic case happens when you have many `.rela.text*` sections (`-ffunction-sections` or comdat `.text*`) that contain toc relocations.

When linking clang, the 4 object files with the most numbers of .rela.toc entries:
CheckerRegistry.o (.rela.toc has 951 entries) (8 .rela.text have toc relocations) (1172 toc relocations)
X86ISelLowering.o (.rela.toc has 723 entries) (208 .rela.text have toc relocations) (1108 toc relocations)
ScalarEvolution.o (.rela.toc has 492 entries) (153 .rela.text have toc relocations) (754 toc relocations)
X86FastIsel.o (.rela.toc has 462 entries) (242 .rela.text have toc relocations) (3901 toc relocations)
The 50th has 123 entries in its .rela.toc. 

For CheckerRegistry.o, the `TocRelIdx` optimization decreases the execution times of the loop from at most (951+1172)*951 to at most (951+8)*951. Using linear probing here should be ok.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D60958