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

[David Blaikie via llvm-dev]

On Fri, May 6, 2016 at 3:17 PM, Adrian Prantl via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>

Sure - but there's probably a fair question whether any of that stuff is
relevant if /nothing/ was ever emitted for the CU. Most of those things
should only be used for lookup within the scope of the file they were
defined in, for example - so if there's no function from that CU, no line
table, etc, you can never be "in" that file, etc.

But I haven't thought about it hard - there may be good reasons for CUs
with no live code/data.


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

I've probably made this argument myself - but I wonder how strong it is.
Name lookup's never going to be perfect because some things can be
optimized out (or never code generated in the first place) - for example
functions:

namespace x {
void f();
namespace y {
inline void f() {
}
void g();
}
}

If you're in the definition of g, but no one ever called f (or it got
optimized away), 'f' is going to find x::f, not x::y::f...

But I agree, we could probably make the argument that within a function we
preserve all the names.


>   }
>
> -- adrian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160506/61913ffe/attachment.html>