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.> > 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.
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. > > > > 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. >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. Teresa -- 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/a63afd5a/attachment.html>
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>
On Sat, Oct 1, 2016 at 4:40 PM, Teresa Johnson <tejohnson at google.com> wrote:> 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.Thanks for looking into this. I'm chasing a more urgent bug this weekend, so may not get around to another test for a day or two.> Can you zip up all of the inputs to your link and make it available to me?With my upload bandwidth it would be very impractical, sorry. How about I share my scripts I use to checkout, configure and build? Should I try building trunk in ThinLTO mode using 3.9? I mean, is trunk considered stable enough for building and later use as occasional CC/CXX? I might try the build regardles, just to check...