This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Clean up stale alias import handling
ClosedPublic

Authored by tejohnson on Aug 29 2017, 10:32 AM.

Details

Summary

Remove some code that was no longer needed. The first FIXME is
stale since we long ago started using the index to drive importing,
rather than doing force importing based on linkage type. And
now with r309278, we no longer import any aliases.

Diff Detail

Repository
rL LLVM

Event Timeline

tejohnson created this revision.Aug 29 2017, 10:32 AM
dblaikie accepted this revision.Aug 29 2017, 11:07 AM

Is it worth having the DEBUG output if no aliases are ever imported?

Could potentially rewrite this whole loop as:

assert(none_of(SrcModule.aliases(), [&](GlobalAlias &GA) { if (!GA.hasName()) return false; return ImportGUIDs.count(GA.getGUID()); }) && "Unexpected alias in import list");

Dunno if that comes out more legible, though.

This revision is now accepted and ready to land.Aug 29 2017, 11:07 AM

Is it worth having the DEBUG output if no aliases are ever imported?

I think it is worthwhile emitting this since we also emit the functions/vars that are not imported.

Could potentially rewrite this whole loop as:

assert(none_of(SrcModule.aliases(), [&](GlobalAlias &GA) { if (!GA.hasName()) return false; return ImportGUIDs.count(GA.getGUID()); }) && "Unexpected alias in import list");

Dunno if that comes out more legible, though.

I was trying to keep it somewhat symmetric with the earlier code handling functions and variables. I'm hoping to start looking at importing these as a copy, which would mean this would go back to a loop anyway. I will change it if you feel strongly that this is better though.

This revision was automatically updated to reflect the committed changes.