[llvm-dev] (Thin)LTO llvm build

[Mehdi Amini via llvm-dev]

> On Sep 16, 2016, at 6:17 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On Sep 16, 2016, at 6:13 PM, Carsten Mattner <carstenmattner at gmail.com> wrote:
>> 
>> On Sat, Sep 17, 2016 at 2:07 AM, Teresa Johnson via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>>> Yes and to add on - the ThinLTO backend by default will
>>> kick off  std::thread::hardware_concurrency # of threads, which I'm finding is
>> 
>> Is it just me or does that sound not very intuitive or at least a
>> little unexpected?

I should add: this is an issue for LLVM because we link *a lot* of various binaries.
However, I don’t believe it is the case of most projects, which is why we have this default (which matches ninja’s default).

— 
Mehdi


>> It's good that it uses the resources eagerly, but in terms of build systems this
>> is certainly surprising if there's no control of that parameter via
>> make/ninja/xcode.
> 
> You can control the parallelism used by the linker, but the option is linker dependent
> (On MacOS:   -Wl,-mllvm,-threads=1)
> 
>> 
>>> too much for machines with hyperthreading. If that ends up being an issue I can
>>> give you a workaround (I've been struggling to find a way that works on various
>>> OS and arches to compute the max number of physical cores to fix this in the source).
>> 
>> I've been using ninja -jN so far. I suppose when building with ThinLTO I should
>> run ninja -j1. Would that
>> 
>> What's the workaround?
> 
> Seems like you missed my previous email: : cmake -DLLVM_PARALLEL_LINK_JOBS=1
> Also, ninja is parallel by default, so no need to pass -j.
> 
> This way you get nice parallelism during the compile phase, and ninja will issue only one link job at a time.