[llvm-dev] RFC: metadata attachments for global variables

[Adrian Prantl via llvm-dev]

> On May 6, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On May 6, 2016, at 3:17 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> 
>> 
>>> On May 6, 2016, at 1:17 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for removing the llvm.dbg.cu named metadata node.
>> 
>> Not to spoil all the fun, but I’m not sure if this will bring us much closer to removing the llvm.dbg.cu node. The reason the llvm.dbg.cu node exits is so we can find all DICompileUnits, because the DICompileUnit holds debug info that is not referenced by any IR. This includes things like DIImportedEntity (think C++ “using”), enums, and macros.
> 
> I understand the fact that DICompileUnit holds debug information that are useful and not referenced directly from the IR.
> 
> What I wonder is, after all edges are pointing from the IR toward the metadata graph, why do you need to keep a compile unit (and the associated retained informations) if nothing in the IR (transitively) points to this compile unit? (i.e. it is unreachable from the IR)

Couple of examples:
- because the compile unit could contain definitions for an enum that is useful during expression evaluation
- because it contains constants that are useful (XNU for example has this version.c file: http://opensource.apple.com/source/xnu/xnu-1456.1.26/config/version.c).
- When clang compiles debug info for a module it compiles an otherwise empty CU with debug info for all types in the module.

-- adrian

> -- 
> Mehdi
> 
> 
>> We will also need a story for preserving DIGlobalVariables that are constants and have their GlobalObject optimized away. We can definitely remove all the global variables that are referenced from GlobalObjects’ !dbg attachments from the DICompileUnit’s list of globals, but we will need to retain all constants. Really, we should also retain all non-constant globals that had their storage optimized away, because they may shadow other variables. For example:
>> 
>> int i;
>> void f() {
>>   static int i; // may get optimized away
>>   // if I’m stopped here, in the debugger, “i” should always refer to the inner i;
>> }
>> 
>> -- adrian
>