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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/055f50d3/attachment.html>
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. > > > > Thank you, > > Gaurav > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Teresa Johnson | Software Engineer | tejohnson at google.com | -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/cf68a253/attachment-0001.html>
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.
Seemingly Similar Threads
- LTO with Linker Scripts
- LLD: creating linker-generated sections as input sections instead of output sections
- LLD: creating linker-generated sections as input sections instead of output sections
- RFC: LLD: creating linker-generated sections as input sections instead of output sections
- [LLD] RFC Range Thunks Implementation review for ARM and Mips