[llvm-dev] (Thin)LTO llvm build

[Teresa Johnson via llvm-dev]

On Fri, Sep 30, 2016 at 1:39 PM, Carsten Mattner <carstenmattner at gmail.com>
wrote:

> On Fri, Sep 30, 2016 at 10:19 PM, Teresa Johnson <tejohnson at google.com>
> wrote:
> >
> >
> > 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.
>
> Right, though usually the chance to do complete whole program optimization
> provides enough opportunities for it to go the other way. Of course, it can
> also increase.
>
> > > 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.
>
> I'll extend LDFLAGS with that before running cmake the next time.
> Thank you.
>

I completely forgot to add -Wl,--gc-sections. The *-sections options
enables gc-sections to work effectively. (edit: oh wait, it looks like you
already have that one on your link command, so you should be set there!)


Unfortunately, I just can't reproduce the DSO link error you are getting.
I've tried building head bits with a 3.9 compiler, and 3.9 bits with the
3.9 compiler, to no avail.

Can you zip up all of the inputs to your link and make it available to me?

Thanks,
Teresa



> > > 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.
>
> Correct.
>
> > 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...
>
> Did it ever build warning-free, or why have you enabled -Werror? I
> mean, I see warnings here, so it would fail if promoted to errors.
>



-- 
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/20161001/73a831dd/attachment.html>