[llvm-dev] (Thin)LTO llvm build
Teresa Johnson via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 16 19:37:53 PDT 2016
On Fri, 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>
> > 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?
> > 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)
Wait - this is to control the ThinLTO backend parallelism, right? In which
case you wouldn't want to use 1, but rather the number of physical cores.
When using gold the option is -Wl,-plugin-opt,jobs=N, where N is the amount
of backend parallel ThinLTO jobs that will be issued in parallel. So you
could try with the default, but if you have HT on then you might want to
try with the number of physical cores instead.
> >> 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
> >> 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
> > run ninja -j1. Would that
> > What's the workaround?
> Seems like you missed my previous email: : cmake
> 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.
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev