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. Teresa On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote:> > > On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com> > wrote: > >> On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> >> > Sure, I will try this and let you know. Unfortunately, though, I >> > have another big work commitment that is going to eat up most of my >> > time through Thu, although I may be able to find some time to try >> > it. >> >> No worries, if I get around it before you do, I will :). >> >> > I think so - what is confusing me is that your cmake command is >> > specifying the same $PREFIX for both the install destination and the >> > source of the llvm-ar/llvm-ranlib that will be used in the new >> > build. Should the llvm-ar/llvm-ranlib in the cmake command use your >> > moved-to PREFIX instead? >> >> Only if 'ninja install` would reference the two executables. If that's >> case, and I haven't gotten that far yet due to ThinLTO not finishing, >> I'll consider copying those to the local build tree first. >> >> > Can you nm the .so files in your lib dir and see if any reference >> > __morestack? >> >> $ for so in lib/*.so; do echo $so ; nm $so|grep __morestack;done >> lib/BugpointPasses.so >> lib/libclang.so >> lib/libgomp.so >> lib/libiomp5.so >> lib/liblldb.so >> U __morestack >> lib/libLTO.so >> lib/libomp.so >> lib/LLVMgold.so >> lib/LLVMHello.so >> lib/LLVMPolly.so >> >> Looks like liblldb.so does. Does that explain anything? >> > > Interesting, it doesn't in my build. Let me think about what might trigger > that difference... > >>-- 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/ffe434f8/attachment.html>
On Fri, Sep 30, 2016 at 9:35 AM, 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. Teresa >Nevermind - it looks like I didn't actually get the 3.9 bits. Anyone know how to get 3.9 via git or git-svn? Typically I use git svn like so to get trunk bits: git clone http://llvm.org/git/llvm.git llvm_${num} cd llvm_${num} git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=tejohnson git config svn-remote.svn.fetch :refs/remotes/origin/master git svn rebase -l I attempted to get 3.9 bits by modifying this slightly (the git svn init command): git clone http://llvm.org/git/llvm.git llvm_39_${num} cd llvm_39_${num} git svn init https://llvm.org/svn/llvm-project/llvm/branches/release_39 --username=tejohnson git config svn-remote.svn.fetch :refs/remotes/origin/master git svn rebase -l However, I still see latest trunk. Teresa> On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com> >> wrote: >> >>> On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com> >>> wrote: >>> >>> > Sure, I will try this and let you know. Unfortunately, though, I >>> > have another big work commitment that is going to eat up most of my >>> > time through Thu, although I may be able to find some time to try >>> > it. >>> >>> No worries, if I get around it before you do, I will :). >>> >>> > I think so - what is confusing me is that your cmake command is >>> > specifying the same $PREFIX for both the install destination and the >>> > source of the llvm-ar/llvm-ranlib that will be used in the new >>> > build. Should the llvm-ar/llvm-ranlib in the cmake command use your >>> > moved-to PREFIX instead? >>> >>> Only if 'ninja install` would reference the two executables. If that's >>> case, and I haven't gotten that far yet due to ThinLTO not finishing, >>> I'll consider copying those to the local build tree first. >>> >>> > Can you nm the .so files in your lib dir and see if any reference >>> > __morestack? >>> >>> $ for so in lib/*.so; do echo $so ; nm $so|grep __morestack;done >>> lib/BugpointPasses.so >>> lib/libclang.so >>> lib/libgomp.so >>> lib/libiomp5.so >>> lib/liblldb.so >>> U __morestack >>> lib/libLTO.so >>> lib/libomp.so >>> lib/LLVMgold.so >>> lib/LLVMHello.so >>> lib/LLVMPolly.so >>> >>> Looks like liblldb.so does. Does that explain anything? >>> >> >> Interesting, it doesn't in my build. Let me think about what might >> trigger that difference... >> >>> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 >-- 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/85bc834c/attachment.html>
> On Sep 30, 2016, at 9:55 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Fri, Sep 30, 2016 at 9:35 AM, Teresa Johnson <tejohnson at google.com <mailto: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. Teresa > > Nevermind - it looks like I didn't actually get the 3.9 bits. Anyone know how to get 3.9 via git or git-svn? Typically I use git svn like so to get trunk bits: > > git clone http://llvm.org/git/llvm.git <http://llvm.org/git/llvm.git> llvm_${num} > cd llvm_${num}Switch branch: git checkout release_39 I think (Try `git ls-remote origin` if needed) — Mehdi> git svn init https://llvm.org/svn/llvm-project/llvm/trunk <https://llvm.org/svn/llvm-project/llvm/trunk> --username=tejohnson > git config svn-remote.svn.fetch :refs/remotes/origin/master > git svn rebase -l > > I attempted to get 3.9 bits by modifying this slightly (the git svn init command): > > git clone http://llvm.org/git/llvm.git <http://llvm.org/git/llvm.git> llvm_39_${num} > cd llvm_39_${num} > git svn init https://llvm.org/svn/llvm-project/llvm/branches/release_39 <https://llvm.org/svn/llvm-project/llvm/branches/release_39> --username=tejohnson > git config svn-remote.svn.fetch :refs/remotes/origin/master > git svn rebase -l > > However, I still see latest trunk. > > Teresa > > > On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote: > > > On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com <mailto:carstenmattner at gmail.com>> wrote: > On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote: > > > Sure, I will try this and let you know. Unfortunately, though, I > > have another big work commitment that is going to eat up most of my > > time through Thu, although I may be able to find some time to try > > it. > > No worries, if I get around it before you do, I will :). > > > I think so - what is confusing me is that your cmake command is > > specifying the same $PREFIX for both the install destination and the > > source of the llvm-ar/llvm-ranlib that will be used in the new > > build. Should the llvm-ar/llvm-ranlib in the cmake command use your > > moved-to PREFIX instead? > > Only if 'ninja install` would reference the two executables. If that's > case, and I haven't gotten that far yet due to ThinLTO not finishing, > I'll consider copying those to the local build tree first. > > > Can you nm the .so files in your lib dir and see if any reference > > __morestack? > > $ for so in lib/*.so; do echo $so ; nm $so|grep __morestack;done > lib/BugpointPasses.so > lib/libclang.so > lib/libgomp.so > lib/libiomp5.so > lib/liblldb.so > U __morestack > lib/libLTO.so > lib/libomp.so > lib/LLVMgold.so > lib/LLVMHello.so > lib/LLVMPolly.so > > Looks like liblldb.so does. Does that explain anything? > > Interesting, it doesn't in my build. Let me think about what might trigger that difference... > > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com <mailto:tejohnson at google.com> | 408-460-2413 <tel:408-460-2413> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com <mailto:tejohnson at google.com> | 408-460-2413-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160930/9dbaa038/attachment.html>
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 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. FYI, -DLLVM_PARALLEL_LINK_JOBS=1 didn't seem to make any difference, seeing how each LD stop was using all available cores.
> 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 50MBThat’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). 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.> > 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