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

[Eric Christopher]

On Fri, May 16, 2014 at 11:07 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 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.
>

That's what I recall yes.

> 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).
>

*nod* This is definitely the direction we should go.

> 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.
>

I think Manman's testcase would be the right direction.

-eric

>>
>> -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