[llvm-dev] LTO with Linker Scripts

[Peter Smith via llvm-dev]

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


________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 18 November 2020 19:57
To: Mitra, Gaurav
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] LTO with Linker Scripts

On 2020-11-18, Teresa Johnson via llvm-dev wrote:
>AFAIK this effort stalled when Tobias changed jobs. Adding Sergei who may
>know the current status of the support within Qualcomm.
>
>Teresa
>
>On Wed, Nov 18, 2020 at 11:12 AM Mitra, Gaurav via llvm-dev <
>llvm-dev at lists.llvm.org> wrote:
>
>> 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.

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.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev