Details
- Reviewers
tejohnson
Diff Detail
Event Timeline
I like the direction, this looks much cleaner. A few initial comments about how this will interact with ThinLTO. There may be other issues, I need to think through it some more.
lib/Linker2/LinkModules.cpp | ||
---|---|---|
1260 ↗ | (On Diff #41415) | As mentioned in my comments on D14623, for ThinLTO we may discover other values that need to be linked as we copy in bodies (e.g. referenced comdat groups for which the source version is selected). I see the comdat selection logic is removed from this implementation, which makes sense for a linker like gold that has already decided this. But for ThinLTO we won't have the visibility to make those decisions until import time*. So for ThinLTO we need to be able to make some comdat selection decisions here, then add any referenced and selected from source comdat groups to the ValuesToLink. Perhaps this loop could use a worklist instead, initialized off ValuesToLink. Both would need to be updated with the new symbols to link.
|
1268 ↗ | (On Diff #41415) | This needs a similar change so that we don't link in unreferenced comdat members. |
Thanks for adding the worklist support. I've only skimmed through it but have a comment/question below in the new callback.
lib/Linker/LinkModules.cpp | ||
---|---|---|
50 | Add doxygen comment | |
664 | Is link once the only type we need to add support for linking lazily? If not, the Add(GV) call needs to move up above this check. Below when looking at the comdat members you are checking for !hasLocalLinkage(). Is it legal that some comdat members could be link once and others not? |
+ void addLazyFor(GlobalValue &GV, IRMover::ValueAdder Add);
bool shouldOverrideFromSrc() { return Flags & Linker::OverrideFromSrc; }
Add doxygen comment
Will do.
Comment at: lib/Linker/LinkModules.cpp:664
@@ +663,3 @@
+ // Add these to the internalize list
+ if (!GV.hasLinkOnceLinkage())+ return;
Is link once the only type we need to add support for linking lazily? If not, the Add(GV) call needs to move up above this check.
Note that the predicate cover linkonce and linkonce_odr. They are the
only linker visible GVs that can be dropped, so yes, I think they are
the only ones we have to ask.
Below when looking at the comdat members you are checking for !hasLocalLinkage(). Is it legal that some comdat members could be link once and others not?
Sure. What is illegal on ELF is for there to be a reference from
outside a comdat to local symbol inside a comdat.
Cheers,
Rafael
This addresses the comments and passes all tests.
The change to FunctionImport.cpp is a hack, but using a module that has been passed to the linker is a bug.
lib/Linker/LinkModules.cpp | ||
---|---|---|
127 | doxygen comments for here and below | |
313 | Why this change? I thought for a declaration it should be external_weak? If it needs to be changed the comment is stale. | |
697 | We should only need to promote and make these changes if we are inside the above if statement (i.e. promoting a local to global). So I think the setName, setLinkage and setVisibility can be moved within the if local linkage & promote body. |
lib/Linker/LinkModules.cpp | ||
---|---|---|
696 | Oh I see, this is handling the linkage changes in general for ThinLTO imported symbols. I'm not sure the function name doThinLTOPromotion is quite accurate then since it is doing more than promotion, but I can't think of a better name at the moment. doThinLTOSymbolHandling or something? |
LGTM with a couple nits and another renaming suggestion. Thanks for doing this, it looks much cleaner than the current approach.
lib/Linker/IRMover.cpp | ||
---|---|---|
363 | This comment is incorrect for this version of class ModuleLinker. | |
365 | It seems like a different class name might be better for this split part. Maybe IRLinker? | |
lib/Linker/LinkModules.cpp | ||
70 | Comment needs to be updated. |
This comment is incorrect for this version of class ModuleLinker.