This is an archive of the discontinued LLVM Phabricator instance.

ThinLTO: Correctly follow aliasee references when dead stripping.
ClosedPublic

Authored by pcc on Sep 12 2017, 8:39 PM.

Details

Summary

We were previously handling aliases during dead stripping by adding
the aliased global's "original name" GUID to the worklist. This will
lead to incorrect behaviour if the global has local linkage because
the original name GUID will not correspond to the global's GUID in
the summary.

Because an alias is just another name for the global that it
references, there is no need to mark the referenced global as used,
or to follow references from any other copies of the global. So all
we need to do is to follow references from the aliasee's summary
instead of the alias.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Sep 12 2017, 8:39 PM
tejohnson accepted this revision.Sep 13 2017, 8:17 AM

LGTM, not sure how we didn't hit this before!

This got me thinking - AliasSummary shouldn't have any refs, and in fact while the constructor takes a list of refs, we always pass in an empty list. Short of restructuring the class hierarchy so that AliasSummary doesn't have the refs member, I should at least remove that parameter from the constructor, and probably add an assert in the base class constructor that we don't have a non-empty list for an alias summary type. I'll go ahead and do that in a separate patch...

This revision is now accepted and ready to land.Sep 13 2017, 8:17 AM
pcc added a comment.Sep 13 2017, 9:55 AM

LGTM, not sure how we didn't hit this before!

Short of restructuring the class hierarchy so that AliasSummary doesn't have the refs member

Alternatively, represent alias summaries using a copy of the aliasee's FunctionSummary or GlobalVariableSummary, and remove the AliasSummary class altogether.

I should at least remove that parameter from the constructor, and probably add an assert in the base class constructor that we don't have a non-empty list for an alias summary type. I'll go ahead and do that in a separate patch...

OK, sounds good.

This revision was automatically updated to reflect the committed changes.