[llvm-dev] (Thin)LTO llvm build

[Mehdi Amini via llvm-dev]

> On Sep 16, 2016, at 7:48 PM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote:
> 
> 
> 
> On Fri, Sep 16, 2016 at 7:40 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> 
> 
> On Sep 16, 2016, at 7:37 PM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote:
> 
>> 
>> 
>> On Fri, Sep 16, 2016 at 6:17 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>> > On Sep 16, 2016, at 6:13 PM, Carsten Mattner <carstenmattner at gmail.com <mailto: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 <mailto: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.
>> 
> 
> Well it depends what behavior you want :)
> 
> I should have used N to match ninja -jN.
> 
> 
> 
> 
>> 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.
> 
> 
> How does it affects parallel LTO backends?
> (I hope it doesn't)
> 
> In regular LTO mode, the option will also affect parallel LTO codegen, which is off by default. Is that what you meant? 

Yes. I’m sad that it is the same option: the parallel LTO changes the final binary, which is really not great in my opinion. 
In ThinLTO the parallel level has this important property that the codegen is unchanged!

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160916/6dab632a/attachment.html>