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

[Adrian Prantl via llvm-commits]

> On Jan 15, 2016, at 1:51 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Fri, Jan 15, 2016 at 1:42 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> 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?
>> 
>> 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.
> 
> Ah, yeah - if we're going to implement this, I'm not sure turning a global into a local is a sufficiently good user experience to make it an intermediate step towards the end goal, rather than doing the work up front. I'm open to discussing it, though - I can see how it'd be an option, but just seems like a bad user experience..

No I totally agree. This is similar to the imported_entity thing we discussed yesterday. Even if the global variable isn’t available everywhere it may affect name resolution etc. so we should attempt to correctly represent it in DWARF.
> 
> - Dave
>  
> 
> -- 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 <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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160115/54044c78/attachment.html>