[PATCH] D24826: [LTO] Add -flto-jobs=N to control backend parallelism
Teresa Johnson via cfe-commits
cfe-commits at lists.llvm.org
Fri Sep 23 09:42:03 PDT 2016
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.
More information about the cfe-commits