[llvm-dev] [LLD] Linker Relaxation

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 11 08:02:54 PDT 2017


On Tue, Jul 11, 2017 at 4:40 PM, Peter Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Thanks for the example, it looks like relaxations can occur at any
> point within the section.
>

Welcome.


> I think that regardless of the approaches, you'll need a relaxation
> function that is in a similar place or is merged with createThunks().
> I don't know enough about RiscV to say if you can get away with doing
> all you need to do in one pass, or if you will need multiple passes
> with the address of each section recalculated after each relaxation
> pass.
>

Relocation is of course compulsory. Relaxation is optional. You can do zero
passes of it.

So I suppose it comes down to "how likely are you to get significant gains
from a 2nd (or later) relaxation pass"?

There is only one size of conditional branch: +/- 4 KB. In the rare case of
a function being bigger than that the compiler will invert the condition
and branch around an unconditional branch (range: +/- 1 MB) or luipc;jr
pair (range: +/- 2 GB). I don't even know whether the binutils linker will
relax a conditional branch around an unconditional branch. So that's I
suppose the major source of iterated relaxation not being relevent: x86 and
others with +/- 128 byte branches, which really do frequently have
cascading effects.

Relaxed 32 bit instruction function calls have +/- 1 MB range. The chances
of a 2nd round of relaxation tipping more call offsets from just over 1 MB
to just under 1 MB are fairly slim.

I would say that a 2nd pass of relaxation would seldom be profitable enough
to be worthwhile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170711/96cc08cf/attachment.html>


More information about the llvm-dev mailing list