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

[Mehdi Amini via llvm-dev]

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

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