[llvm-dev] (Thin)LTO llvm build

Mehdi Amini via llvm-dev
Fri, 30 Sep 2016 20:11:10 -0000

> On Sep 30, 2016, at 12:57 PM, Carsten Mattner <carstenmattner at
gmail.com> wrote:
>
> On Fri, Sep 30, 2016 at 6:35 PM, Teresa Johnson <tejohnson at
google.com> wrote:
>> I just built a stage-1 compiler from the 3.9 release bits and built
>> the lldb from head sources which worked fine. Let me try again using
>> 3.9 build compiler to build 3.9 bits.
>
> I had also started a build a few hours ago, what a coincidence. I had
> to ditch both build and source trees because of cmake failing to
> reconfigure due to some file it surprisingly had generated in the
> source (not build) tree.
>
> So, with -DBUILD_SHARED_LIBS=OFF, and a fresh checkout of the 3.9
> release branch, I've run into the same error, this time only 39 (not a
> typo, and not 3.9) ninja targets left.
>
> Some parts finished, so here's a surprising size difference for
clang-3.9.
>
> LTO=OFF  stripped clang-3.9 is 44MB
> LTO=Thin stripped clang-3.9 is 50MB

That’s expected: there’s more inlining and other optimizations happening.

Also we rely more on linker dead stripping with ThinLTO. On MacOS it works well
with the atom model, on ELF I’d expect the LTO equivalent of -ffunction-sections
to be used (I don’t know if Gold and the gold-plugin have such an option
though).

Finally, there are few other things that we need to do in ThinLTO to gain a few
more percents on this aspect.


>
> I would have expected more aggressive pruning or at least not an
> increase, though I don't know if it can be caused by
> -DBUILD_SHARED_LIBS=OFF.

BUILD_SHARED_LIBS is a non-sense from a performance point of view. It is really
not advised to use this.

>
> FYI, -DLLVM_PARALLEL_LINK_JOBS=1 didn't seem to make any difference,
> seeing how each LD stop was using all available cores.

It only helps limiting oversubscribing the number of cores, and reduces the peak
memory for the link.

—
Mehdi