[llvm-dev] [LLD] Linker Relaxation

Peter Smith via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 11 03:59:03 PDT 2017


To the best of my knowledge I think the closest analogue is something
like the Synthetic EHFrame and MergeInputSections, not strictly code
relaxation, but these do involve changes in size of sections.

Can I ask you a quick question?  In many architectures not all
pc-relative offsets are exposed to the linker as relocations so it
isn't safe to change the sizes of sections in arbitrary places [*];
does the RiscV ABI have restrictions on code-generation to allow a
linker to reduce the code-size of a code-sequence within a Section? If
there are constraints on the relaxations it might help us make a

I'm assuming that if you are doing some kind of range based relaxation
you'll need something like range extension thunks (I'm working on
these right now) this means you'll probably have to do your
calculations on what you can relax in finalizeSections() at a similar
point to createThunks(), or perhaps the mechanisms would need to be
merged as I think they'll need to converge on a point when no more
relaxations are possible and no more thunks can be added.

Writing out the relaxed sections will be interesting as you won't want
all of the InputSectionContents. I suggest looking at EHFrame and
MergeInputSections for ideas.

Hope that is of some use


[*] For example in pseudo ARM

    ldr r0, [pc, offset] ; where pc + offset == label
    relaxable sequence such as an indirect jump via a register
label: .word foo

If the compiler/assembler has pre-computed the offset to label then
changing the size of the relaxable sequence without also updating the
offset will break the program.

On 11 July 2017 at 11:09, PkmX via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi,
> Does lld support linker relaxation that may shrink code size? As far
> as I see lld seems to assume that the content of input sections to be
> fixed other than patching up relocations, but I believe some targets
> may benefit the extra optimization opportunity with relaxation.
> Specifically, I'm currently working on adding support for RISC-V in
> lld, and RISC-V heavily relies on linker relaxation to remove
> extraneous code and to handle alignment. Since linker relaxation may
> be of interest to other targets as well, I'm wondering what would be a
> good way to modify lld to support that. Thanks.
> --
> Chih-Mao Chen (PkmX)
> Software R&D, Andes Technology
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list