[PATCH] D54720: [PPC64] toc-indirect to toc-relative relaxation.
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 28 04:21:16 PDT 2019
MaskRay added inline comments.
================
Comment at: ELF/Arch/PPC64.cpp:126
+
+ // The relocations are sorted by offset, and while the most common case is
+ // that every .toc entry will have a relocation, it is not guaranteed. For
----------------
MaskRay wrote:
> sfertile wrote:
> > MaskRay wrote:
> > > > The relocations are sorted by offset
> > >
> > > IIRC this is not guaranteed but I think it is fine to lose toc optimization if the input does not have this property.
> > >
> > > The linear search below `for (auto R : llvm::reverse(Relas.slice(0, Index))) {` concerns me.
> > >
> > > Is it possible to add a `LastRelaIndex` variable in `InputSectionBase::relocateAlloc`:
> > >
> > > if (!tryRelaxTocPPC64(Type, Rel, Expr, BufLoc, LastRelaIndex))
> > >
> > > and keep it monotonically increasing in `getSymAndAddend`? If the input doesn't guarantee increasing `r_offset`, it may lose TOC optimizations for some relocations, but as I said it should be fine.
> > >> The relocations are sorted by offset
> > > IIRC this is not guaranteed
> > I believe its guaranteed for binutils tools. We also sort the relocations for the .toc section in `scanRelocs` in case there are other tools which don't produce the relocations in sorted order.
> >
> > > The linear search below for (auto R : llvm::reverse(Relas.slice(0, Index))) { concerns me
> > I believe missing toc relocations to be an uncommon thing. As far as I am aware llvm will not place constants into the .toc section. gcc will for a few very specific cases but it is still not very common. xlc is the outlier here as I heard it will do this some what commonly despite there being no need to with the V2 abi.
> >
> > For the objects I found that were missing relocations when compiled with gcc , we either found the relocation we were looking for, or broke out of the search in a few comparisons. If a linear search does become a problem for some pathological inputs we could switch to a binary search but I think doing that initially we would end up pessimaling the common case for something that might not ever naturally occur.
> I was not suggesting a binary search.
>
> I suggested to change:
>
> ```
> for (const Relocation &Rel : Relocations) { // the loop is in relocateAlloc
> // Offset is increasing
> for (Index = computed(Rel); J >= 0; J--) // the loop is in PPC64.cpp getSymAndAddend
> if (Offset == Relas[Index].r_offset) {
> /* found */
> break;
> }
> }
> ```
>
> to
>
> ```
> Index = 0
> for (const Relocation &Rel : Relocations) { // the loop is in relocateAlloc
> // Offset is increasing
> for (; Index < Relas.size(); ++Index)
> // Index is increasing
> if (Offset == Relas[Index].r_offset) {
> /* found */
> break;
> }
> }
> ```
Sorry, see below:
```
for (const Relocation &Rel : Relocations) { // the loop is in relocateAlloc
// Offset is increasing
for (Index = computed(Rel); Index >= 0; Index--) // the loop is in PPC64.cpp getSymAndAddend
if (Offset == Relas[Index].r_offset) {
/* found */
break;
}
}
```
to
```
Index = 0
for (const Relocation &Rel : Relocations) { // the loop is in relocateAlloc
// Offset is increasing
for (; Index < Relas.size(); ++Index)
// Index is increasing
if (Offset == Relas[Index].r_offset) {
/* found */
break;
} else if (Offset < Relas[Index].r_offset)
break;
}
```
Repository:
rLLD LLVM Linker
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D54720/new/
https://reviews.llvm.org/D54720
More information about the llvm-commits
mailing list