> 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 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 > > > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
