[llvm-dev] (Thin)LTO llvm build

[Mehdi Amini via llvm-dev]

> 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>