<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 6, 2016 at 3:17 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</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>
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>
  }<br></blockquote><div><br></div><div>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.<br></div></div><div class="gmail_extra"><br></div>Thanks,<br>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>