[PATCH] D24826: [LTO] Add -flto-jobs=N to control backend parallelism

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Sep-22, at 09:53, Teresa Johnson <tejohnson at google.com> wrote:
> 
> tejohnson added a comment.
> 
> In https://reviews.llvm.org/D24826#549788, @mehdi_amini wrote:
> 
>> The Gold path looks fine. 
>> On OSX, we would have the clang driver relying on a LLVM cl::opt, for which I don't think there is any precedent. CC Duncan for advice.
> 
> 
> I do see other uses of -mllvm in lib/Driver/Tools.cpp, but are you talking about something else?

I think this is okay, since clang is talking to the same version of libLTO.dylib.  I feel like there might be another case where clang talks to libLTO.dylib through ld64 using -mllvm... perhaps, -O0?

Let's ask around though to be sure.

> 
>> Also I don't think the same option should be used for the parallel LTO codegen: it actually does not generate the same binary, which should deserve a dedicated opt-in (What if I mix ThinLTO and LTO, and I don't want // codegen?)
> 
> 
> Ok good point. I can change this to -fthinlto_jobs. However, while the two parallel settings are separate in the LTO API, currently the gold-plugin jobs option controls both, so I will need to do a preparatory gold-plugin patch to split this into thinlto_jobs and lto_jobs. On the libLTO/ld64 path, looks like the current -mllvm -threads only affects ThinLTO so there is no work to do there.

I actually like -flto-jobs=N better for this.  I expect "jobs" not to affect output at all.

I think the current parallel FullLTO CodeGen (where it *does* affect output) should have a special name that calls this out, perhaps -flto-partitions=N?  -flto-slices=N?  -flto-random-partitions=N?  Is it urgent to add that flag now though?

Note that I imagine someone will parallelizing FullLTO the hard way in the future, which won't affect output.  That implementation should use -flto-jobs=N.

> 
> https://reviews.llvm.org/D24826
> 
> 
>