This is an archive of the discontinued LLVM Phabricator instance.

Split the linker in 2
ClosedPublic

Authored by rafael on Nov 30 2015, 11:21 AM.

Details

Reviewers
tejohnson

Diff Detail

Event Timeline

rafael retitled this revision from to Split the linker in 2.
rafael updated this object.

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.

  • Longer term we can consider doing some extra work during the ThinLTO plugin layer, which currently just combines summaries, such as reading the symbol table out of the bitcode to make these decisions and then mark that info in the summary.
1268 ↗(On Diff #41415)

This needs a similar change so that we don't link in unreferenced comdat members.

rafael updated this revision to Diff 42183.Dec 8 2015, 8:49 AM

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

rafael updated this revision to Diff 42226.Dec 8 2015, 2:14 PM

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.

tejohnson added inline comments.Dec 8 2015, 6:28 PM
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.

rafael updated this revision to Diff 42302.Dec 9 2015, 8:13 AM
tejohnson added inline comments.Dec 9 2015, 2:12 PM
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?

rafael updated this revision to Diff 42349.Dec 9 2015, 3:09 PM

Rebase and rename function. I went with processGlobalsForThinLTO.

tejohnson accepted this revision.Dec 9 2015, 8:03 PM
tejohnson added a reviewer: tejohnson.

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 revision is now accepted and ready to land.Dec 9 2015, 8:03 PM
tejohnson added inline comments.Dec 9 2015, 8:06 PM
lib/Linker/LinkModules.cpp
70

Ignore this, somehow this one ended up in the wrong place.

127

This was the comment that I intended to say needed an update.

Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in r255254.