This is an archive of the discontinued LLVM Phabricator instance.

[LTO] Stop always creating and running an LTO compilation if there is not a single LTO object
ClosedPublic

Authored by mehdi_amini on Aug 16 2016, 11:54 PM.

Details

Summary

I assume there was a use case, so maybe this strawman patch will help
clarifying if it is legit.
In any case the current situation is not legit: a ThinLTO compilation
should not trigger an unexpected full LTO compilation.
Right now, adding a --save-temps option triggers this and makes the
number of output differs.

Diff Detail

Repository
rL LLVM

Event Timeline

mehdi_amini retitled this revision from to [LTO] Stop always creating and running an LTO compilation if there is not a single LTO object.
mehdi_amini updated this object.
mehdi_amini added a reviewer: tejohnson.
mehdi_amini added subscribers: llvm-commits, pcc.
tejohnson edited edge metadata.Aug 17 2016, 7:03 AM

Thanks for working on this one! I believe this will cause an issue for gold as it is setting up a PreOptModuleHook to add common symbols to the combined module. However, I wonder if this is not working anyway, as the bug I mentioned on IRC appears to be related to a common symbol that is being internalized improperly. Let me see if I can get a better handle on what is going on there this morning. I don't recall the reasons pcc wanted these to be added to a separate module rather than marked prevailing in the current module.

Regardless, I think it is probably better for the client to indicate explicitly to the API when it needs a combined module to be constructed, rather than inferring by the existence of any hooks.

I understand that gold adds symbol to the first module, what I'm not sure about is why it needs to be the combined one, what is the impact of adding these to the first ThinLTO module instead?

mehdi_amini edited edge metadata.

Make sure ThinLTO task starts at 0 when no LTO module is present.

Giving this a try, but in the meantime there are a couple fixes needed to get the compile to succeed, noted below.

lib/LTO/LTO.cpp
307 ↗(On Diff #68351)

CombinedModule, Mover and Ctx need to all be prefixed with "RegularLTO." in this block of code.

357 ↗(On Diff #68351)

Mover is now a pointer.

Shame on me for submitting patches that don't build...

tejohnson added inline comments.Aug 17 2016, 10:14 AM
lib/LTO/LTO.cpp
710 ↗(On Diff #68371)

This change causes a different failure. We assert in thinLTOInternalizeModule/MustPreserveGV for the first ThinLTO module. The internalizer calls back to MustPreserveGV for the added common, but we assert because it is not in the DefinedGlobals since there was no summary for it in that module.

However, I found that with my internalize fix for commons we don't need this change with your patch. We simply keep the common symbol in the module where it was originally defined, as a common, which is what happened before the new API. Let me do some more testing with that fix, and see if it fixes the rest of the cpu2006 benchmark failures I was getting. If that works, then you could submit this patch (minus this particular change) afterwards.

However, while testing things I encountered another issue where the new API is going to cause problems for the distributed build system case. I first reverted this particular part of your patch and tested it on 403.gcc without my internalization fix. I expected to get undefs for the common symbols, thinking that they wouldn't be defined anywhere (we internalize the original copy and remove it since it didn't have uses there, and we would presumably not add it to any combined module which we shouldn't have with ThinLTO). However, we did end up with a combined module - there are several modules that don't have summary indexes, I believe because they contain inline assembly and we are currently preventing issues there by suppressing index generation). The test in LTO::add causes them to be added to a single combined module. This will be a problem for a distributed build where we compile with the thinlto-index-only plugin option as we will not get any index files for these files. The distributed build system is going to barf because it wants those as input to backend actions for those modules. I already hit a related issue since with the new API we stopped generating these files for the modules the linker decided not to include in the link, which is a change from the earlier behavior where gold would always emit the individual indexes (and imports files if requested) for all modules unconditionally, and I was planning to make a change to address this. I will also change things so we add modules as ThinLTO unconditionally under an option passed from the client.

What the current status for this one, with all the recent patches that got in?

What the current status for this one, with all the recent patches that got in?

The commons fix is in, so this one should be good to go with the change noted below. Why don't I test it right now with SPEC just to be sure...

lib/LTO/LTO.cpp
710 ↗(On Diff #68371)

However, I found that with my internalize fix for commons we don't need this change with your patch.
We simply keep the common symbol in the module where it was originally defined, as a common, which is
what happened before the new API. Let me do some more testing with that fix, and see if it fixes the rest of
the cpu2006 benchmark failures I was getting. If that works, then you could submit this patch (minus this
particular change) afterwards.

Since the commons fix is in, this change can be reverted.

mehdi_amini added inline comments.Aug 22 2016, 1:43 PM
lib/LTO/LTO.cpp
710 ↗(On Diff #68371)

Why wouldn't we want this change? I would include this independently from the commons thing

tejohnson added inline comments.Aug 22 2016, 1:49 PM
lib/LTO/LTO.cpp
710 ↗(On Diff #68371)

I suppose with the commons fix this won't cause the failure I described with symbols being added unexpectedly to a ThinLTO module...so maybe it is ok now. The comment above needs to be fixed though. I am building a compiler from this which I will test with SPEC...

tejohnson accepted this revision.Aug 22 2016, 5:54 PM
tejohnson edited edge metadata.

Passes SPEC

This revision is now accepted and ready to land.Aug 22 2016, 5:54 PM
This revision was automatically updated to reflect the committed changes.