[PATCH] D61610: [PPC64] implement Thunk Section Spacing

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In D61610#1492927 <https://reviews.llvm.org/D61610#1492927>, @MaskRay wrote:

> @atanasyan Should MIPS override `getThunkSectionSpacing` as well? Then we can make the function pure virtual: `virtual uint32_t getThunkSectionSpacing() const = 0;`


I believe the Mips LA25 Thunks are not range extension thunks, they are PI to non-PI and they are a special case where they have to precede their Target Section. We do this with getTargetInputSection() so I think it doesn't matter for Mips.



================
Comment at: lld/ELF/Arch/PPC64.cpp:931
+  // REL14 range
+  return 0x8000;
+}
----------------
sfertile wrote:
> MaskRay wrote:
> > This probably should be slightly smaller than 0x8000.
> > 
> > @peter.smith probably has idea how the ARM/AArch64 constants were derived.
> > 
> > ```
> > uint32_t AArch64::getThunkSectionSpacing() const {
> >   // See comment in Arch/ARM.cpp for a more detailed explanation of
> >   // getThunkSectionSpacing(). For AArch64 the only branches we are permitted to
> >   // Thunk have a range of +/- 128 MiB
> >   return (128 * 1024 * 1024) - 0x30000;
> > }
> > ```
> The conditional branch instructions only encode a 14-bit immediate which gets shifted left 2 places to form a  4-byte aligned signed 16-bit offset. This gives us a range of [0x8000, 0x7ffc]. Since we have slightly less 'reach' with positive offsets we should start with a spacing of 0x7ffc instead of 0x8000.  Then I guess we want to make it slightly smaller so that a branch can reach more then just the first/last instruction in the thunk section.
Sorry for the delay in responding. The ThunkSectionSpacing is derived from the branch range - a slop-space (0x30000) bytes to account for the space of thunks that could be generated in between the branch and destination. This is quite pessimistic but given the range is 128 Megabytes, this isn't much of a problem. What I suggest is to think how many Thunks would get created in any [0x8000, 0x7ffc] span and then subtract the size in bytes from that.

It is worth noting that in terms of range, the implementation should fail safe, i.e. it will place any Thunk that can't read one of the pre-created ThunkSections prior in a newly created ThunkSection either before or after the Target.

I note that this caused a problem as there were two InputSections that should not be split by inserting a Thunk in between them. I think the only fool proof solution to that is to make the Thunk implementation aware of the restriction. Arm's proprietary linker has "inline thunks" for v4t that have control flow that falls-through into the following section, in that linker we had to make sure that no thunk got inserted in between the "inline thunk" and the following section. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61610