[llvm-dev] (Thin)LTO llvm build

[Teresa Johnson via llvm-dev]

On Fri, Sep 30, 2016 at 1:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

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

It does, but I found you have to pass the options to the plugin to get them
to kick in for any *LTO compile. See D24644 for my proposed fix. To
workaround, pass them to the plugin-opt:
-Wl,--gc-sections -Wl,-plugin-opt,-function-sections
 -Wl,-plugin-opt,-data-sections
Not sure if there is any benefit to passing them also on the command line
(-ffunction-sections -fdata-sections), but probably a good idea.


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

I actually think Carsten was not getting BUILD_SHARED_LIBS=ON as I had
originally thought given the DSO error: His cmake command didn't contain
it, and from his email earlier this week, the __morestack reference is
coming from lib/liblldb.so, not an llvm library built shared as I had
assumed. Which also explains why he is still getting it when configuring
with -DBUILD_SHARED_LIBS=OFF.


I am having a bunch of trouble getting a release-built 3.9 compiler, lots
of warnings when building with clang that are being turned into errors from
-Werror. Need to try again with -w...


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


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160930/22577a7b/attachment.html>