This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Add correctness check for RO/WO variable import
ClosedPublic

Authored by evgeny777 on Nov 12 2019, 8:45 AM.

Details

Summary

This was suggested in D70006. The check is a bit expensive so is put under NDEBUG

Diff Detail

Event Timeline

evgeny777 created this revision.Nov 12 2019, 8:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2019, 8:45 AM

Thanks for doing this. I have some ideas on how to reduce the overhead of this checking below.

llvm/lib/Transforms/IPO/FunctionImport.cpp
653

There's presumably a number of duplicates across the various per module import lists, so I'm thinking it would be more efficient to flatten these sets first into a single set of imported GUIDs. Also, it should be more efficient to change the algorithm here to do something like:

Flatten ImportLists -> FlattenedImports
Change loop that walks Export lists to first check if each exported GUID is in the Flattened Imports, and only if not check if it IsReadOrWriteOnlyVar.

The advantage of this is that this avoids doing a hash table lookup for each exported GUID (looking it up in the index), so that we only do so for those that are potentially problematic (because they are not imported anywhere).

An alternative would be to compute the ReadOrWriteOnlyVars exported GUID set as the export lists are built during importing, but only under !NDEBUG. I'm not sure if that is necessary though after the restructuring I suggest above, which should hopefully streamline this so that it is reasonable in debug builds.

This also makes me think it might be a good idea to consider changing the ExportLists to hold the ValueInfos rather than GUIDs (not suggesting you do that here, more a note to self for future). After poking around at the uses of the export lists it seems very doable, and would avoid the need for index hash table lookups to locate the associated summaries here and anywhere else in the future...

evgeny777 updated this revision to Diff 229040.Nov 13 2019, 2:30 AM

Addressed

This also makes me think it might be a good idea to consider changing the ExportLists to hold the ValueInfos rather than GUIDs

Makes sense, I've done it for this patch as well.

tejohnson accepted this revision.Nov 13 2019, 8:45 AM

Thanks for doing this! A minor suggestion and a spelling correction on the variable below, but otherwise lgtm. Please commit the ExportList type change as a separate prior NFC commit and the new assertion checking after as a distinct commit.

llvm/lib/LTO/LTO.cpp
424

Just do Index.getValueInfo(I)

llvm/lib/Transforms/IPO/FunctionImport.cpp
635

s/Flattended/Flattened/

639

I think this loop could be simplified to just:

FlattenedImports.insert(ExportPerModule.second.begin(), ExportPerModule.second.end());
This revision is now accepted and ready to land.Nov 13 2019, 8:45 AM
This revision was automatically updated to reflect the committed changes.