[llvm-dev] (Thin)LTO llvm build

[Carsten Mattner via llvm-dev]

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

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