[PATCH] D16209: Teach GlobalOpt not to drop DebugInfo on the floor when it promotes globals to allocas

[David Blaikie via llvm-commits]

On Fri, Jan 15, 2016 at 1:55 PM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

>
>
> On 1/15/16 2:42 PM, Adrian Prantl wrote:
>
>>
>> On Jan 15, 2016, at 1:29 PM, David Blaikie <dblaikie at gmail.com
>>> <mailto:dblaikie at gmail.com>> wrote:
>>>
>>>
>>>
>>> On Fri, Jan 15, 2016 at 6:54 AM, Jonathan Roelofs via llvm-commits
>>> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>>
>>> wrote:
>>>
>>>     jroelofs added a comment.
>>>
>>>     @Dblaikie Not sure if my explanation was clear: I'm trying to
>>>     convert the DI metadata from the kind that references a global, to
>>>     the kind that references a local.
>>>
>>>
>>> Right
>>>
>>>     To do that, I /think/ I need to add the dbg.declare/value to the
>>>     alloca that gets's created, and delete the one that references the
>>>     soon-to-be-dead global. Does /that/ seem to you to be something
>>>     out of the range of things that the DI metadata scheme can cope with?
>>>
>>>
>>> The problem I'm getting at is that I think you'll end up with DWARF
>>> that doesn't make sense. You'll end up with a local variable instead
>>> of a global. Not just a global described by a local location.
>>>
>>> Does that make sense?
>>>
>>
> Ahh, I see. Thanks for the explanation.
>
>
>>> DWARF:
>>>
>>>   DW_TAG_compile_unit
>>>     DW_TAG_global_variable "foo"
>>>     DW_TAG_subprogram
>>>       DW_TAG_variable "bar"
>>>       ...
>>>
>>> ->
>>>
>>>   DW_TAG_compile_unit
>>>     DW_TAG_subprogram
>>>       DW_TAG_variable "foo"
>>>       DW_TAG_variable "bar"
>>>
>>> Which isn't correct. "foo" should still be a DW_TAG_global_variable in
>>> the CU scope, its location should be a local location.
>>>
>>> I don't think the metadata can describe this currently... - but I
>>> could be wrong.
>>>
>>
>> I don’t think it can, which is why I suggested this hack with the local
>> variable on IRC yesterday. But, of course, it would be better to fix
>> LLVM to support the latter.
>>
>
> Am I understanding correctly that this is a limitation of the IR's
> representation of it, and not of DWARF?
>

That's my understanding, yes. I'd check GCC's DWARF representation for
situations like this, but I imagine it's plausible.

I don't have /great/ ideas about how to do this in LLVM's IR representation
or IRGen, especially if the global is sunk into more than one function (eg:
int i; void f1() {  i = 3; ... } void f2() { i = 7; ... })... won't be
pretty.

- Dave


>
>
> Jon
>
>
>> -- adrian
>>
>>
>>>     If not, do you know how to delete the DIGlobalVariable here? I
>>>     started down this rabbit hole because I've got a bug where the
>>>     debug info emitted into the asm references the global... which no
>>>     longer exists, causing the assembler to barf on it.
>>>
>>>
>>>     http://reviews.llvm.org/D16209
>>>
>>>
>>>
>>>     _______________________________________________
>>>     llvm-commits mailing list
>>>     llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160115/3f868102/attachment.html>