[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 mailing list