<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 6, 2016 at 3:41 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><br>
> On May 6, 2016, at 1:17 PM, Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></span><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></div></blockquote><div><br></div><div>After thinking a little more about this, I suppose that one benefit of attaching entities such as unreferenced globals and macros to a named metadata node is that in something like a ThinLTO scenario we could reduce the amount of work required to import entities into a module by somehow arranging to only load the named metadata node when compiling the module itself, and not when we import it into other modules.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>