<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 6, 2016 at 3:17 PM, Adrian Prantl via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 6, 2016, at 1:17 PM, Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for removing the <a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> named metadata node.<br>
<br>
</span>Not to spoil all the fun, but I’m not sure if this will bring us much closer to removing the <a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> node. The reason the <a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> 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.<br></blockquote><div><br></div><div>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.<br><br>But I haven't thought about it hard - there may be good reasons for CUs with no live code/data.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
  int i;<br>
  void f() {<br>
    static int i; // may get optimized away<br>
    // if I’m stopped here, in the debugger, “i” should always refer to the inner i;<br></blockquote><div><br></div><div>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:<br><br>namespace x {<br>void f();<br>namespace y {<br>inline void f() {<br>}<br>void g();</div><div>}<br>}<br><br>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... <br><br>But I agree, we could probably make the argument that within a function we preserve all the names.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  }<br>
<br>
-- adrian<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>