LTO with Linker Scripts

Project Infrastructure LLVM Dev List Archives
1

Hello All,

I’d like to pick up on an RFC about “(Thin)LTO with Linker Scripts” proposed by Tobias von Koch (http://lists.llvm.org/pipermail/llvm-dev/2018-May/123252.html) a couple years back.

Has this work been upstreamed or implemented in any toolchains?

We’re looking at bringing LTO support to our TI Arm Clang Compiler tools and would appreciate any information about similar efforts where Linker Scripts are used to control ELF image layout.

Thank you,

Gaurav

2

AFAIK this effort stalled when Tobias changed jobs. Adding Sergei who may know the current status of the support within Qualcomm.

Teresa

3

I agree that the bitcode files need to convey the input section names
for functions/variables and the linker needs to tell LTO about output
section names. I have an ICF change which is similar in concept:
https://reviews.llvm.org/rL371216

   .rom : { rom.o(.text) }
   .text : { *(.text .text1) *(.text.*) }
   // *(.text .text1) and *(.text.*) are called input section descriptions

What is unclear to me is whether the relevant optimization (inlining,
constant merging, outlining, etc) should be isolated within an output
section, or within an input section description.

I think isolating optimizations within an input section description
probably makes more sense considering the following:

   .rom : { rom.o(.text) }
   .text : { *(.text .text1) separator = .; *(.text.*) }

The intention is probably to split two parts with a separator symbol.

In any case, having output section names or input section descriptions before
compiling bitcode files is challenging within LLD and (I believe) gold's
frameworks, if there are desires to contribute to LLD or LLVMgold.so (which can
be used by both GNU ld and gold). It seems that we'll have to duplicate some
processSectionCommands() work before LTO.

4

I think restricting optimisations to InputSection Description may be going a bit too far. The memory attributes such as NOLOAD and OVERLAY work on an OutputSection granularity. It could be possible to make a program that relied on InputSectionDescriptions being separated but I think it would be rare, and could be emulated by adding more OutputSections.

I agree that doing early OutputSection/InputSection Description matching is going to require some thought. For example do we just match against existing OutputSections/InputSectionDescriptions and ignore Orphans or do we attempt to make OutputSections for Orphans to feed the information back.

Would like to see this progress as we've seen many embedded customers that could benefit from LTO, in particular the reductions in code-size but they often run into problems with linker scripts that they are unable or unwilling to resolve.

Peter