[llvm-dev] [ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp

[Taewook Oh via llvm-dev]

Encountered “assert(GS != DefinedGlobals.end())” failure while running ThinLTO. The assertion statement is in MustPreserveGV lambda function in llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp).

It seems that the assertion fails because it fails to recover the "original name" of the global value. ModuleSummaryIndex::getOriginalNameBeforePromote attempts to get the original name by stripping .llvm.{HASH}, but what I observe is that ".1" is still appended to the expected original name.

Then where this extra ".1" comes from? It is appended when the global value is materialized. IRLinker::materialize function calls IRLinker::linkGlobalValueProto function, and inside that function if DGV is nullptr or ShouldLink is true then IRLinker::copyGlobalValueProto function is called to create a global variable in the destination module that corresponds to SGV. I found that newly created global variable has the extra ".1" added to the name of the SGV.

When this happens? I don't have a complete understanding but I observed that the same global value is materialized twice during the single invocation of IRLinker::run, once with GlobalValueMaterializer and once with LocalValueMaterializer. First, the global value

; Materializable
; Function Attrs: nounwind uwtable
define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {}
(I renamed the function and comdat)

is materialized with GlobalValueMaterializer, (so the IRLinker::materialize function is called with ForAlias == false), and the materialized value is

; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2

Then, later, the same value is materialized again with LocalValueMaterializer (so ForAlias == true for IRLinker::materialize), and the materialized value is

; Function Attrs: nounwind uwtable
define internal void @foo.1(%"type 0x7efb6ee89d80"*) unnamed_addr #2 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 !dbg !12345 {
  // function definition
}
(here, “type 0x7efb6ee89d80” is not “type1” )

So for me it seems that we need a mechanism to retrieve the original name of the global value even when it is renamed during the materialization. I submitted the bug report as well (https://llvm.org/bugs/show_bug.cgi?id=28760).

Thanks,
Taewook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/296d3c53/attachment.html>