ed at modk.it
2015-Jul-16 18:39 UTC
[LLVMdev] [Clang] [lld] [llvm-link] Whole program / dead-code optimization
Hi All, After the initial learning curve, we're excited to have put together a completely gcc/binutils-free toolchain based on LLVM. Now that we have things working, we desperately need to optimize the resulting binaries. Our bin files are up to 10x their fully optimized gcc equivalent (1.5k vs 16k). This is for a bare metal ARM based system so this is significant. We're using lld for linking and the following dead code elimination techniques seem to be dead ends: 1) whole program optimization on our most egregious space waster (-fwhole-program not supported by clang) 2) link time optimization (looks like this is only supported by lld for the COFF path not the ELF path) 3) using a linker plugin like gold (-fuse-linker-plugin doesn't seem to be supported by clang) We have control over the whole codebase and could essentially compile all of our C/C++ code as single file if there was a way to tell clang that it is seeing the whole program. Any thoughts on how we could achieve this? This slidedeck suggests using llvm-link to accomplish this: http://llvm.org/devmtg/2013-11/slides/Gao-LTO.pdf. Is this the most promising way forward? Thanks, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/0b9f7e20/attachment.html>
John Criswell
2015-Jul-16 20:12 UTC
[LLVMdev] [Clang] [lld] [llvm-link] Whole program / dead-code optimization
On 7/16/15 1:39 PM, ed at modk.it wrote:> Hi All, > > After the initial learning curve, we're excited to have put together a > completely gcc/binutils-free toolchain based on LLVM. Now that we > have things working, we desperately need to optimize the resulting > binaries. Our bin files are up to 10x their fully optimized gcc > equivalent (1.5k vs 16k). This is for a bare metal ARM based system > so this is significant. > > We're using lld for linking and the following dead code elimination > techniques seem to be dead ends: > > 1) whole program optimization on our most egregious space waster > (-fwhole-program not supported by clang) > 2) link time optimization (looks like this is only supported by lld > for the COFF path not the ELF path) > 3) using a linker plugin like gold (-fuse-linker-plugin doesn't seem > to be supported by clang) > > We have control over the whole codebase and could essentially compile > all of our C/C++ code as single file if there was a way to tell clang > that it is seeing the whole program. > > Any thoughts on how we could achieve this? This slidedeck suggests > using llvm-link to accomplish this: > http://llvm.org/devmtg/2013-11/slides/Gao-LTO.pdf > <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_devmtg_2013-2D11_slides_Gao-2DLTO.pdf&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=TLoIRs6M_cYUZSKAcynkcq55H57t5tpplD2x6T-b3mM&s=kZfwoBElwGePaEljcvFWBQ2n9bCYoAS2bojmIpl1-QE&e=>. > Is this the most promising way forward?Is there a reason why LLVM's link-time optimization won't work for you? http://llvm.org/docs/GoldPlugin.html http://llvm.org/docs/LinkTimeOptimization.html Regards, John Criswell> > Thanks, > Ed > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/cf6694ff/attachment.html>
ed at modk.it
2015-Jul-16 20:26 UTC
[LLVMdev] [Clang] [lld] [llvm-link] Whole program / dead-code optimization
> > > Is there a reason why LLVM's link-time optimization won't work for you? > > http://llvm.org/docs/GoldPlugin.html > http://llvm.org/docs/LinkTimeOptimization.html > >Well the primary motivation to move to LLVM is licensing which is why we also ditched binutils since we can't package gcc for iOS due to the GPL. So in the end the gold plugin wouldn't work for licensing reasons even if we can get it to work technically but thanks for the links I'm still trying to wrap my head around the problem and any info helps. -Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/d3231b70/attachment.html>
Possibly Parallel Threads
- [LLVMdev] [Clang] [lld] [llvm-link] Whole program / dead-code optimization
- [LLVMdev] Error in building Gold on FreeBSD
- [LLVMdev] Error in building Gold on FreeBSD
- [LLVMdev] Error in building Gold on FreeBSD
- [LLVMdev] [Clang] Reasons for lack of -fsingle-precision-constant support? Alternatives?