<div dir="ltr">As Mehdi mentioned, thinLTO backend processes use very little memory, you may get away without any additional flags (neither -Wl,--plugin-opt=jobs=.., nor -Dxxx for cmake to limit link parallesm) if your build machine has enough memory. Here is some build time data of parallel linking (with ThinLTO) 52 binaries in clang build (linking parallelism equals ninja parallelism). The machine has 32 logical cores and 64GB memory.<div><br></div><div>1) Using the default ninja parallelism, the peak 1min load-average is 537. The total elapse time is 9m43s</div><div>2) Using ninja -j16, the peak load is 411. The elapse time is 8m26s</div><div>3) ninja -j8 : elapse time is 8m34s</div><div>4) ninja -j4 : elapse time is 8m50s</div><div>5) ninja  -j2 : elapse time is 9m54s</div><div>6) ninja -j1 : elapse time is 12m3s</div><div><br></div><div>As you can see, doing serial thinLTO linking across multiple binaries do not give you the best performance. The build performance peaked at j16 in this configuration.   You may need to find your best LLVM_PARALLEL_LINK_JOBS value.</div><div><br></div><div>Having said that,  there is definitely  room for ThinLTO usability improvement so that ThinLTO parallel backend can coordinate well with the build system's parallelism so that user does not need to figure out the sweet spot.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 17, 2016 at 4:03 PM, Carsten Mattner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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 Sun, Sep 18, 2016 at 12:32 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
><br>
>> On Sep 17, 2016, at 3:19 PM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
>><br>
>> So, when I embark on the next ThinLTO try build, probably this Sunday,<br>
>> should I append -Wl,-plugin-opt,jobs=NUM_PHYS_<wbr>CORES to LDFLAGS<br>
>> and run ninja without -j or -jNUM_PHYS_CORES?<br>
><br>
><br>
> ThinLTO is fairly lean on memory: It should not consume more memory per thread than if you launch the same number of clang process in parallel to process C++ files.<br>
><br>
> For example when linking the clang binary itself, without debug info it consumes 0.6GB with 8 threads, 0.9GB with 16 threads, and 1.4GB with 32 threads.<br>
> With full debug info, we still have room for improvement, right now it consumes 2.3GB with 8 threads, 3.5GB with 16 threads, and 6.5GB with 32 threads.<br>
><br>
> So I believe that configuring with -DDLLVM_PARALLEL_LINK_JOBS=1 should be enough without other constrains, but your mileage may vary.<br>
<br>
</span>Sure, I'll try that to not introduce too many variables into the<br>
configure changes,<br>
though I have to ask if using lld would make it possible to have a common -Wl<br>
that works across platforms, being able to ignore if it's binutils.<br>
<br>
If I really wanted to pass that to cmake, overriding LDFLAGS would work, right?<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>