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

[Peter Collingbourne via llvm-dev]

On Fri, 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.
> 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;
>   }
>

Yes, that does seem to make things more complicated than I thought. I
suppose we would have to at least for the moment preserve the global named
metadata node and the global variable list on DISubprogram. In the long
term we could perhaps consider preserving these variables on a global named
metadata node like I was mentioning on the other subthread with David. We'd
still need to have a global metadata node, so maybe it wouldn't be much
better.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160506/5c54d492/attachment.html>