> On 2016-Sep-22, at 09:53, Teresa Johnson <tejohn...@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 

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

cfe-commits mailing list

Reply via email to