<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 1:39 PM, Carsten Mattner <span dir="ltr"><<a href="mailto:carstenmattner@gmail.com" target="_blank">carstenmattner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Sep 30, 2016 at 10:19 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br>
><br>
><br>
> On Fri, Sep 30, 2016 at 1:11 PM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
> ><br>
> ><br>
> > > On Sep 30, 2016, at 12:57 PM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > On Fri, Sep 30, 2016 at 6:35 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>><br>
> > > wrote:<br>
> > > > I just built a stage-1 compiler from the 3.9 release bits and<br>
> > > > built the lldb from head sources which worked fine. Let me try<br>
> > > > again using 3.9 build compiler to build 3.9 bits.<br>
> > ><br>
> > > I had also started a build a few hours ago, what a coincidence.<br>
> > > I had to ditch both build and source trees because of cmake<br>
> > > failing to reconfigure due to some file it surprisingly had<br>
> > > generated in the source (not build) tree.<br>
> > ><br>
> > > So, with -DBUILD_SHARED_LIBS=OFF, and a fresh checkout of the<br>
> > > 3.9 release branch, I've run into the same error, this time only<br>
> > > 39 (not a typo, and not 3.9) ninja targets left.<br>
> > ><br>
> > > Some parts finished, so here's a surprising size difference for<br>
> > > clang-3.9.<br>
> > ><br>
> > > LTO=OFF  stripped clang-3.9 is 44MB<br>
> > > LTO=Thin stripped clang-3.9 is 50MB<br>
> ><br>
> > That’s expected: there’s more inlining and other optimizations happening.<br>
<br>
</span>Right, though usually the chance to do complete whole program optimization<br>
provides enough opportunities for it to go the other way. Of course, it can<br>
also increase.<br>
<span class=""><br>
> > Also we rely more on linker dead stripping with ThinLTO. On MacOS<br>
> > it works well with the atom model, on ELF I’d expect the LTO<br>
> > equivalent of -ffunction-sections to be used (I don’t know if Gold<br>
> > and the gold-plugin have such an option though).<br>
><br>
><br>
> It does, but I found you have to pass the options to the plugin to get them<br>
> to kick in for any *LTO compile. See D24644 for my proposed fix. To<br>
> workaround, pass them to the plugin-opt:<br>
> -Wl,--gc-sections -Wl,-plugin-opt,-function-<wbr>sections<br>
> -Wl,-plugin-opt,-data-sections<br>
> Not sure if there is any benefit to passing them also on the command line<br>
> (-ffunction-sections -fdata-sections), but probably a good idea.<br>
<br>
</span>I'll extend LDFLAGS with that before running cmake the next time.<br>
Thank you.<br>
<span class=""><br>
> > Finally, there are few other things that we need to do in ThinLTO<br>
> > to gain a few more percents on this aspect.<br>
> ><br>
> > > I would have expected more aggressive pruning or at least not an<br>
> > > increase, though I don't know if it can be caused by<br>
> > > -DBUILD_SHARED_LIBS=OFF.<br>
> ><br>
> > BUILD_SHARED_LIBS is a non-sense from a performance point of view.<br>
> > It is really not advised to use this.<br>
><br>
><br>
> I actually think Carsten was not getting BUILD_SHARED_LIBS=ON as I<br>
> had originally thought given the DSO error: His cmake command didn't<br>
> contain it, and from his email earlier this week, the __morestack<br>
> reference is coming from lib/liblldb.so, not an llvm library built<br>
> shared as I had assumed. Which also explains why he is still getting<br>
> it when configuring with -DBUILD_SHARED_LIBS=OFF.<br>
<br>
</span>Correct.<br>
<span class=""><br>
> I am having a bunch of trouble getting a release-built 3.9 compiler,<br>
> lots of warnings when building with clang that are being turned into<br>
> errors from -Werror. Need to try again with -w...<br>
<br>
</span>Did it ever build warning-free, or why have you enabled -Werror? I<br>
mean, I see warnings here, so it would fail if promoted to errors.<br></blockquote><div><br></div><div>I enabled it in my cmake scripts awhile back so that I don't inadvertently introduce warnings that cause bots to fail when I commit. I guess I could just take that out instead of passing -w to the flags, but didn't want to muck with my scripts. I guess whatever bots build the branched sources don't enable -Werror.</div><div><br></div><div>Teresa</div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>