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.