[llvm-dev] (Thin)LTO llvm build
Teresa Johnson via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 30 13:19:01 PDT 2016
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>
> > On Fri, Sep 30, 2016 at 6:35 PM, Teresa Johnson <tejohnson at google.com>
> >> 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
> > 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:
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
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.
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev