Details
- Reviewers
tejohnson mehdi_amini - Commits
- rG9e3f4746d5c8: CodeGen: Replace ThinLTO backend implementation with a client of LTO/Resolution.
rC278541: CodeGen: Replace ThinLTO backend implementation with a client of LTO/Resolution.
rL278541: CodeGen: Replace ThinLTO backend implementation with a client of LTO/Resolution.
Diff Detail
Event Timeline
Sorry for the delay, comments below.
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
740 | Use ComputeCrossModuleImportForModule instead, since this is only for a single module and we don't need the ExportLists (and is the same routine invoked currently by the FunctionImportPass). | |
756 | OwnedImports is never read from. | |
lib/Driver/Tools.cpp | ||
3894 ↗ | (On Diff #61332) | This change and the associated test change seem independent of the rest of the patch and could be submitted now independently. |
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
757 | Can we pass along -save-temps here (i.e. invoke Conf.addSaveTemps)? |
Note that this will have the side effect of enabling linkonce/weak resolution and internalization for the distributed backends.
I had just sent a separate patch (D22356) to do the former, which includes a fix for a subtle linking issue in the distributed backend case. I was planning to follow that up with another patch to add the internalization, after first removing the forced linkonce linking. However, I like having the weak resolution and internalization outside of the FunctionImporter pass, as is done here. So I think the best thing is to change my D22356 to not add weak resolution to the pass, but just have it address the linker issue requiring the new PreserveNonPrevailing flag and the test case. It should probably go in immediately after this one (or my distributed backend testing will start getting failures).
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
740 | This should go away at some point right? |
lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
740 | The way they are passed down is via the individual combined index. So it simply computes via what is in the index, which will only include summaries for what should be imported. I suppose we could make the logic even simpler tho and just blindly import what is in the index. Peter, can you add a fixme? |
(I didn't mark it as accepted because Teresa did, but in case you're waiting for me, don't)
Use ComputeCrossModuleImportForModule instead, since this is only for a single module and we don't need the ExportLists (and is the same routine invoked currently by the FunctionImportPass).