tejohnson added a comment. > > 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. Ok, let me know what you find out. > > 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. Ok, sure that seems reasonable. I changed the option documentation to note that this is currently just for ThinLTO. See also https://reviews.llvm.org/D24873 where I split the gold-plugin options. https://reviews.llvm.org/D24826 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
