This is an archive of the discontinued LLVM Phabricator instance.

LTO: Include dso-local bit in ThinLTO cache key.
ClosedPublic

Authored by pcc on Jan 30 2018, 3:12 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jan 30 2018, 3:12 PM
tejohnson added inline comments.Jan 31 2018, 7:32 AM
llvm/lib/LTO/LTO.cpp
181 ↗(On Diff #132061)

Is it necessary to do this for all refs, rather than just for each DefinedGlobals summary (like we do for the linkage below)?

llvm/test/LTO/Resolution/X86/cache-dso-local.ll
9 ↗(On Diff #132061)

comment please

pcc updated this revision to Diff 132238.Jan 31 2018, 11:51 AM
  • Address review comment
pcc marked an inline comment as done.Jan 31 2018, 11:51 AM
pcc added inline comments.
llvm/lib/LTO/LTO.cpp
181 ↗(On Diff #132061)

Yes because dso-local generally affects the code generated for references to globals.

tejohnson added inline comments.Feb 1 2018, 8:44 AM
llvm/lib/LTO/LTO.cpp
181 ↗(On Diff #132061)

Perhaps, but in FunctionImportGlobalProcessing::processGlobalForThinLTO we apply this flag to every GV defined in the module. Even if that generally only affects references to those GVs, it seems incomplete not to hash it for all GVs that might have the flag set in the IR. By updating the hash only for references, we will update the hash multiple times for some GVs (those that are in multiple ref lists) and not at all for others (those that don't have any references from within this module). It seems like it would be sufficient and more complete to update the hash for all GVs in the DefinedGlobals set.

pcc added inline comments.Feb 1 2018, 11:34 AM
llvm/lib/LTO/LTO.cpp
181 ↗(On Diff #132061)

But if I understand correctly, globals that are only referenced and not defined by a module will not appear in DefinedGlobals, so the hash would not take into account the dso-local bit for such globals.

If a GV declaration is not referenced from a module (say it is an unreferenced declaration that for some reason wasn't gc'ed) then it wouldn't seem to matter what its dso-local bit is because no code would be generated based on it.

tejohnson accepted this revision.Feb 1 2018, 12:37 PM

LGTM

llvm/lib/LTO/LTO.cpp
181 ↗(On Diff #132061)

But if I understand correctly, globals that are only referenced and not defined by a module will not appear in DefinedGlobals, so the hash would not take into account the dso-local bit for such globals.

Ok, I was thinking about the distributed backend case (where we're not even invoking this caching code), where we only have summaries for things defined in this module or being imported into it, so we wouldn't be able to update the DSOLocal bit in the backend on GVs for refs we don't have the definition for. (Hmm, does that mean we need to enhance the distributed build case to get the full benefit of the DSOLocal optimization? I.e. include summaries for things we reference but aren't importing, and somehow mark them to not be imported, so that we can update their DSO local flag.)

If a GV declaration is not referenced from a module (say it is an unreferenced declaration that for some reason wasn't gc'ed) then it wouldn't seem to matter what its dso-local bit is because no code would be generated based on it.

Again confused myself thinking about the distributed case, here we have the whole index. Nevermind...unless the DSO local flag will in the future ever affect something other than the code gen for references.

This revision is now accepted and ready to land.Feb 1 2018, 12:37 PM
This revision was automatically updated to reflect the committed changes.