[lld] Dealing with limited branch reach?
Sean Silva via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 20 18:15:37 PDT 2015
On Tue, Oct 20, 2015 at 6:09 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Tue, Oct 20, 2015 at 6:03 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Tue, Oct 20, 2015 at 5:32 PM, Rui Ueyama via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> COFF ARM has the same problem which has not been solved yet. On ARM,
>>> just like PPC, jump instruction's displacement is limited, thus if the
>>> relocation target is too far, the linker has to create a stub which jumps
>>> to the desired function using an instruction with larger displacement, and
>>> rewrite the relocation to point to that stub.
>>>
>>> There are I think few requirements for production-quality linkers when
>>> handling such relocations.
>>>
>>> - We don't want to use stubs unless needed: The most simple "solution"
>>> would be to always create stubs at end of each function and always use
>>> them, but that makes all function calls indirect. That is not acceptable
>>> from the performance perspective.
>>>
>>> - We don't want to create unnecessary room between functions: We could
>>> make room between each function and backfill that space with stubs if stubs
>>> are needed. That's simple, but bloats code, so it's probably unacceptable.
>>>
>>> This is an interesting packing problem because we don't know the exact
>>> distance between two arbitrary instructions until we layout output
>>> sections. But when we fix the layout, it's too late to make room for stubs.
>>>
>>> I don't really know what's the best way to layout sections for such
>>> architecture, but what I was thinking for ARM is something like this:
>>>
>>> 1. Layout output sections without considering relocations
>>> 2. Visit all sections and all relocations to check if all displacements
>>> are within their range. If not, create a new "stub section", insert it
>>> after the current section, and rewrite the relocations.
>>> 3. Re-assign VMA and file offsets for each section.
>>> 4. Repeat 2 and 3 until a convergence is obtained.
>>>
>>> The reason why we need step 4 is because inserting a stub may make some
>>> relocations, which are previously reachable, unreachable. (I think that
>>> happens rarely, so it should converge quickly.)
>>>
>>
>> A variation of this approach is to do the opposite: initially lay out
>> everything using stubs, then iteratively relax. The advantage of the
>> relaxation approach is that the result is always "correct" and so we can
>> choose to always run only a single iteration of relaxation (or a fixed
>> number). This avoids a pathological worst-case behavior.
>>
>
> That's an interesting approach. I didn't think about that. It might be too
> pessimistic as it's going to create lots of stubs (one stub for one
> function call), though.
>
The first round of relaxation should remove most of the stubs.
> My approach can be relaxed to mitigate worst-case behavior by creating
> stubs for relocations that barely reach to their targets.
>
I don't think that will necessarily fix the worst case. A relocation might
potentially jump over multiple inserted stubs, so "barely" actually has to
be quite pessimistic to guarantee, say, <50 iterations.
-- Sean Silva
>
>
>>
>>
>
>> -- Sean Silva
>>
>>
>>>
>>> On Tue, Oct 20, 2015 at 4:56 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>>
>>>> Hi Rui, Rafael, et al.,
>>>>
>>>> In order to move PPC64 support in lld to a point where it can self
>>>> host, we need to deal with the following problem:
>>>>
>>>> On PPC, a relative branch can only have a signed 24-bit displacement
>>>> (which is really a 26-bit signed displacement, once the two assumed
>>>> lower-order bits are tacked on). Thus, the range is limited to +/- a few
>>>> (tens of) megabytes, and if there is more code than that, we need to make
>>>> other arrangements.
>>>>
>>>> As I understand it, other architectures (AArch64, for example), have
>>>> similar limitations.
>>>>
>>>> Existing linkers handle this situation by inserting branch stubs, and
>>>> placing the branch stubs close enough to the call sites.
>>>>
>>>> Here's a quick example:
>>>>
>>>> $ cat main.c
>>>> void foo();
>>>> int main() {
>>>> foo();
>>>> asm(".fill 50000000, 4, 0x60000000"); // lots of nops
>>>> return 0;
>>>> }
>>>>
>>>> $ cat foo.c
>>>> void foo() {}
>>>>
>>>> $ gcc -o btest main.c foo.c
>>>>
>>>> Now running objdump -d btest shows this relevant bit:
>>>>
>>>> 0000000010000500 <0000003a.plt_branch.foo+0>:
>>>> 10000500: 3d 82 ff ff addis r12,r2,-1
>>>> 10000504: e9 6c 7f e8 ld r11,32744(r12)
>>>> 10000508: 7d 69 03 a6 mtctr r11
>>>> 1000050c: 4e 80 04 20 bctr
>>>>
>>>> 0000000010000510 <.main>:
>>>> 10000510: 7c 08 02 a6 mflr r0
>>>> 10000514: f8 01 00 10 std r0,16(r1)
>>>> 10000518: fb e1 ff f8 std r31,-8(r1)
>>>> 1000051c: f8 21 ff 81 stdu r1,-128(r1)
>>>> 10000520: 7c 3f 0b 78 mr r31,r1
>>>> 10000524: 4b ff ff dd bl 10000500
>>>> <0000003a.plt_branch.foo+0>
>>>> 10000528: 60 00 00 00 nop
>>>> 1000052c: 60 00 00 00 nop
>>>> 10000530: 60 00 00 00 nop
>>>> 10000534: 60 00 00 00 nop
>>>> ...
>>>>
>>>> So it has taken the actual call target address and stuck it in a data
>>>> section (referenced from the TOC base pointer), and the stub loads the
>>>> address and jumps there.
>>>>
>>>> Currently, lld seems to write each input section that is part of an
>>>> output section, in order, consecutively into that output section. Dealing
>>>> properly with long-branch stubs, however, seems to require inserting
>>>> intervening stub segments in between other .text sections. This affects
>>>> not only direct calls, but calls into .plt too (since they too need to be
>>>> in range), or we need to split (and, perhaps, duplicate .plt entries) in
>>>> order to make sure they're close enough as well.
>>>>
>>>> One possible way to do this is:
>>>>
>>>> if (total size < some threshold) {
>>>> everything will fit, so do what we do now
>>>> } else {
>>>> group the input text segments so that each group (including the size
>>>> of stubs) is below the threshold (we can scan each segment for branch
>>>> relocations to determine if stubs are necessary)
>>>> insert the necessary stub segments after each grouping
>>>> }
>>>>
>>>> Various heuristics can make the groupings chosen more or less optimal,
>>>> but perhaps that's another matter.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks again,
>>>> Hal
>>>>
>>>> --
>>>> Hal Finkel
>>>> Assistant Computational Scientist
>>>> Leadership Computing Facility
>>>> Argonne National Laboratory
>>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151020/a9b59f7a/attachment.html>
More information about the llvm-commits
mailing list