[llvm] r192938 - Temporarily revert r192749 as it is causing problems for LTO and

David Blaikie dblaikie at gmail.com
Fri May 16 11:07:21 PDT 2014


On Fri, Oct 18, 2013 at 10:00 AM, Eric Christopher <echristo at gmail.com> wrote:
> Yeah, those two error messages shouldn't be able to happen at the same
> time, yet, here we are.
>
> :\
>
> Anyhow, reverted the rest of it and it should come back now.

For the record, this revert happened in r192985.

Though there's no accompanying test case and the buildbot failure logs
are long since cleaned up, which makes this easy to regress again in
the same way.

I can guess at what happened that would've required that patch to be
reverted: inlining cross-module. In that case there would be no DIE
for the inlined subprogram in the CU that's being inlined into.

What the correct behavior is here is an open question: should we do
cross-CU DIE references? I'm sort of warming to that idea, personally.
This would also make it a bit easier to generalize subprogram creation
and inlining handling - just walk the scope change of the subprogram,
find it's ultimate parental CU, getOrCreateSubprogram there, and defer
doing some of the abstract definition wiring until later (this latter
part is something I'm considering doing to fix some other debug info
inlining issues).

I'll try to create a test case. Any nice way to force cross-module
inling... ? I'll see what I can come up with.

>
> -eric
>
> On Fri, Oct 18, 2013 at 9:55 AM, Adrian Prantl <aprantl at apple.com> wrote:
>> Weird, the buildbot is still red:
>>
>> http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-Rlto/builds/937
>>
>> -- adrian
>>
>> On Oct 17, 2013, at 18:57, Eric Christopher <echristo at gmail.com> wrote:
>>
>>> Author: echristo
>>> Date: Thu Oct 17 20:57:30 2013
>>> New Revision: 192938
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=192938&view=rev
>>> Log:
>>> Temporarily revert r192749 as it is causing problems for LTO and
>>> requires a more in depth change to the IR structure.
>>>
>>> Modified:
>>>    llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
>>>
>>> Modified: llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp?rev=192938&r1=192937&r2=192938&view=diff
>>> ==============================================================================
>>> --- llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (original)
>>> +++ llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Thu Oct 17 20:57:30 2013
>>> @@ -827,7 +827,14 @@ CompileUnit *DwarfDebug::constructCompil
>>>
>>> // Construct subprogram DIE.
>>> void DwarfDebug::constructSubprogramDIE(CompileUnit *TheCU, const MDNode *N) {
>>> -  assert(!SPMap[N] && "Trying to create a subprogram DIE twice!");
>>> +  // FIXME: We should only call this routine once, however, during LTO if a
>>> +  // program is defined in multiple CUs we could end up calling it out of
>>> +  // beginModule as we walk the CUs.
>>> +
>>> +  CompileUnit *&CURef = SPMap[N];
>>> +  if (CURef)
>>> +    return;
>>> +  CURef = TheCU;
>>>
>>>   DISubprogram SP(N);
>>>   if (!SP.isDefinition())
>>> @@ -836,7 +843,6 @@ void DwarfDebug::constructSubprogramDIE(
>>>     return;
>>>
>>>   DIE *SubprogramDie = TheCU->getOrCreateSubprogramDIE(SP);
>>> -  SPMap[N] = TheCU;
>>>
>>>   // Expose as a global name.
>>>   TheCU->addGlobalName(SP.getName(), SubprogramDie, resolve(SP.getContext()));
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



More information about the llvm-commits mailing list