> 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 //
> 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.
cfe-commits mailing list