On Sat, Sep 10, 2016 at 6:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:> >> On Sep 10, 2016, at 3:03 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I tried building llvm, clang, lld, lldb from the 3.9 svn release >> branch with LTO, and some of the results were unexpected. >> >> I first tried to rebuild llvm with llvm-3.9, which has ThinLTO, by >> providing -DLLVM_ENABLE_LTO=Thin, but that failed very quickly, so I >> fell back to building with -DLLVM_ENABLE_LTO=On and using the system >> CC/CXX (gcc 6.1). >> >> The resulting installed build is many times bigger than the non-LTO >> version. Is this to be expected? I thought LTO would reduce size by >> detecting more unused code. > > LTO also inline more, thus increasing the size. But usually it is quite slight. > If you’re concerned about binary size, disabling clang plugin may help: > > cmake -DCLANG_PLUGIN_SUPPORT=OFFCurious to know why this would result in smaller binaries.>> The bindist .tar.xz archives are as follows: >> >> LTO=Off: 195MB >> LTO=On : 953MB >> >> Now, I am of course aware that falling back to gcc's lto support is >> not the same as llvm's lto or thinlto, but I only fell back after it >> failed to build that way, and I wasn't aware of gcc6 providing almost >> 5x large code than without lto. > > GCC may be using “fat” intermediate objects by default, i.e. it > generates both the binary and the IR in the intermediates files > and the static archives.Are you saying I should strip files?> What is the size of the final clang binary itself?Interestingly the non-LTO clang-3.9 is 49MB while the LTO one if 58MB.>> Also, given a fresh 3.9 install, on an otherwise gcc/libstdc++ system, >> how can I configure and build with -DLLVM_ENABLE_LTO=Thin? Is this >> supported, or does it require the use of some libXX too? > > You need to have Gold installed, but that is the same requirement as for LTO I believe. > Then if you’re using 3.9 as a host compiler, it should “just work”.$ c++ -v gcc version 6.2.1 20160830 (GCC) $ ld.gold --version GNU gold (GNU Binutils 2.27) 1.12 $ clang -v clang version 3.9.0 (branches/release_39 279763)
> On Sep 10, 2016, at 2:20 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > > On Sat, Sep 10, 2016 at 6:25 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> >>> On Sep 10, 2016, at 3:03 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I tried building llvm, clang, lld, lldb from the 3.9 svn release >>> branch with LTO, and some of the results were unexpected. >>> >>> I first tried to rebuild llvm with llvm-3.9, which has ThinLTO, by >>> providing -DLLVM_ENABLE_LTO=Thin, but that failed very quickly, so I >>> fell back to building with -DLLVM_ENABLE_LTO=On and using the system >>> CC/CXX (gcc 6.1). >>> >>> The resulting installed build is many times bigger than the non-LTO >>> version. Is this to be expected? I thought LTO would reduce size by >>> detecting more unused code. >> >> LTO also inline more, thus increasing the size. But usually it is quite slight. >> If you’re concerned about binary size, disabling clang plugin may help: >> >> cmake -DCLANG_PLUGIN_SUPPORT=OFF > > Curious to know why this would result in smaller binaries.Supporting Plugin implies that every function has to available, even if inlined everywhere they can’t be dead-stripped. Because the plugin may call into it. Disabling plugin allows to remove all this dead code.> >>> The bindist .tar.xz archives are as follows: >>> >>> LTO=Off: 195MB >>> LTO=On : 953MB >>> >>> Now, I am of course aware that falling back to gcc's lto support is >>> not the same as llvm's lto or thinlto, but I only fell back after it >>> failed to build that way, and I wasn't aware of gcc6 providing almost >>> 5x large code than without lto. >> >> GCC may be using “fat” intermediate objects by default, i.e. it >> generates both the binary and the IR in the intermediates files >> and the static archives. > > Are you saying I should strip files?I’m just saying, it depends what you’re measuring: what matters is the final binary usually, not the size of the intermediate files.> >> What is the size of the final clang binary itself? > > Interestingly the non-LTO clang-3.9 is 49MB while the LTO one if 58MB. > >>> Also, given a fresh 3.9 install, on an otherwise gcc/libstdc++ system, >>> how can I configure and build with -DLLVM_ENABLE_LTO=Thin? Is this >>> supported, or does it require the use of some libXX too? >> >> You need to have Gold installed, but that is the same requirement as for LTO I believe. >> Then if you’re using 3.9 as a host compiler, it should “just work”. > > $ c++ -v > gcc version 6.2.1 20160830 (GCC) > $ ld.gold --version > GNU gold (GNU Binutils 2.27) 1.12 > $ clang -v > clang version 3.9.0 (branches/release_39 279763)So ThinLTO should “just work” if you’re building with clang. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160910/f69a0539/attachment.html>
> On Sep 10, 2016, at 3:42 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Sep 10, 2016, at 2:20 PM, Carsten Mattner <carstenmattner at gmail.com <mailto:carstenmattner at gmail.com>> wrote: >> >> On Sat, Sep 10, 2016 at 6:25 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> >>>> On Sep 10, 2016, at 3:03 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> >>>> I tried building llvm, clang, lld, lldb from the 3.9 svn release >>>> branch with LTO, and some of the results were unexpected. >>>> >>>> I first tried to rebuild llvm with llvm-3.9, which has ThinLTO, by >>>> providing -DLLVM_ENABLE_LTO=Thin, but that failed very quickly, so I >>>> fell back to building with -DLLVM_ENABLE_LTO=On and using the system >>>> CC/CXX (gcc 6.1). >>>> >>>> The resulting installed build is many times bigger than the non-LTO >>>> version. Is this to be expected? I thought LTO would reduce size by >>>> detecting more unused code. >>> >>> LTO also inline more, thus increasing the size. But usually it is quite slight. >>> If you’re concerned about binary size, disabling clang plugin may help: >>> >>> cmake -DCLANG_PLUGIN_SUPPORT=OFF >> >> Curious to know why this would result in smaller binaries. > > Supporting Plugin implies that every function has to available, even if inlined everywhere they can’t be dead-stripped. Because the plugin may call into it. > Disabling plugin allows to remove all this dead code. > >> >>>> The bindist .tar.xz archives are as follows: >>>> >>>> LTO=Off: 195MB >>>> LTO=On : 953MB >>>> >>>> Now, I am of course aware that falling back to gcc's lto support is >>>> not the same as llvm's lto or thinlto, but I only fell back after it >>>> failed to build that way, and I wasn't aware of gcc6 providing almost >>>> 5x large code than without lto. >>> >>> GCC may be using “fat” intermediate objects by default, i.e. it >>> generates both the binary and the IR in the intermediates files >>> and the static archives. >> >> Are you saying I should strip files? > > I’m just saying, it depends what you’re measuring: what matters is the final binary usually, not the size of the intermediate files. > >> >>> What is the size of the final clang binary itself? >> >> Interestingly the non-LTO clang-3.9 is 49MB while the LTO one if 58MB. >> >>>> Also, given a fresh 3.9 install, on an otherwise gcc/libstdc++ system, >>>> how can I configure and build with -DLLVM_ENABLE_LTO=Thin? Is this >>>> supported, or does it require the use of some libXX too? >>> >>> You need to have Gold installed, but that is the same requirement as for LTO I believe. >>> Then if you’re using 3.9 as a host compiler, it should “just work”. >> >> $ c++ -v >> gcc version 6.2.1 20160830 (GCC) >> $ ld.gold --version >> GNU gold (GNU Binutils 2.27) 1.12 >> $ clang -v >> clang version 3.9.0 (branches/release_39 279763) > > So ThinLTO should “just work” if you’re building with clang.You may need to use llvm-ar/llvm-ranlib though: cmake -DCMAKE_AR=path/to/llvm-ar -DCMAKE_RANLIB=path/to/llvm-ranlib — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160910/f92cca46/attachment.html>
On Sun, Sep 11, 2016 at 12:42 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:> Supporting Plugin implies that every function has to available, even if > inlined everywhere they can’t be dead-stripped. Because the plugin may call > into it. > Disabling plugin allows to remove all this dead code.That makes sense, thanks.> I’m just saying, it depends what you’re measuring: what matters is the final > binary usually, not the size of the intermediate files.I had only measured the size of the installed tree and assumed any stripping that might happen would be the same as with LTO=OFF. Let's see if I can get ThinLTO+No_PLUGINS to build and the results of that. Might take a while.