<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 12:28 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"><div><div class="h5">On Tue, May 10, 2016 at 11:45 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</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"><div><div>On Mon, May 9, 2016 at 4:42 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"><div><div><br><div class="gmail_quote">On Mon, May 9, 2016 at 4:26 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, May 9, 2016 at 3:38 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 9, 2016 at 3:17 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 9, 2016 at 2:33 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 9, 2016 at 1:53 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, May 6, 2016 at 2:10 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, May 6, 2016 at 2:09 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, May 6, 2016 at 1:55 PM, Peter Collingbourne 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, May 6, 2016 at 1:21 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
> On 2016-May-06, at 13:17, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I'd like to add support for metadata attachments for global variables in the same way as we did for functions.<br>
><br>
> Syntax would be pretty simple:<br>
> @foo = global i32 0, !foo !0, !bar !1<br>
> (the extra commas are required to disambiguate from a named metadata on the next line)<br>
<br>
</span>SGTM.<br>
<span><br>
> Benefits:<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>A little harder than it sounds (need to somehow support a GlobalVariable that is RAUW'ed with a ConstantInt), but I think this is important to do.<br></blockquote><div><br></div></span><div>How can a GlobalVariable be replaced with a ConstantInt? Wouldn't that just be an absolute address?</div></div></div></div></blockquote><div><br></div></span><div>If the global variable has a known constant value & the address is never needed, then we might optimize away the storage and still want debug info describing the constant. </div></div></div></div></blockquote><div><br></div></span><div>I'm not sure under what conditions, if any, that currently works - so this may be more of a "nice to have" or "be good to think about how any future design wouldn't preclude fixing this gap" sort of thing.</div></div></div></div></blockquote><div><br></div></span><div>It looks like this is how debug info for static data members used to look until r172591 landed back in 2013.</div></div></div></div></blockquote><div><br></div></span><div>Could you explain more what you mean by "<this> is how it worked until" - 'this' being how it used to work and how you're proposing to make it work? I'm not quite following.</div></div></div></div></blockquote><div><br></div></span><div>Sorry, I meant that prior to r172591 we would represent a static data member with something that looked like what a DIGlobalVariable looks like today, but with a ConstantInt representing the initializer in the variable field (which is where the GlobalVariable is normally stored). The change moved the initializer to an associated "static member type" (yes, it's not really a type), which as a side effect caused us to (as far as I can tell) no longer store ConstantInts in the variable field.</div></div></div></div></blockquote><div><br></div></span><div>Actually this isn't accurate, we still produce a ConstantInt in the variable field of DIGlobalVariable for constants in the global scope (e.g. test/CodeGen/2010-08-10-DbgConstant.c in clang). I'll have to think more about what the right representation is for that then.</div></div></div></div></blockquote><div><br></div></div></div><div>Looks like this might be broken/have regressed at some point:<br><br>static const int x = 3;</div><div>void f1(int);<br>void f2(int*);</div><div>void f3() {<br>  f1(x);<br>  f2(&x);</div><div>}<br><br>Now we generate two global variables named 'x', one with a constant value, the other with an address.<br><br>We probably only want the one with the address. (but, then again, we probably want to turn the one with an address to having a constant value if its storage gets optimized away)</div></div></div></div>
</blockquote></div><br></div></div>Thanks David. I was thinking about this representational change for DIGlobalVariable:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) replace the Variable field with a Value field of type ConstantData, and use it exclusively for constant initializers</div><div class="gmail_extra">2) change the logic in the debug info emitter (DwarfCompileUnit::getOrCreateGlobalVariableDIE) to look like this:</div><div class="gmail_extra"><br></div><div class="gmail_extra">if (the DIGlobalVariable was attached to a GlobalVariable) {</div><div class="gmail_extra">  // add a location to the variable DIE</div><div class="gmail_extra">} else if (the DIGlobalVariable has an associated value) {</div><div class="gmail_extra">  // add a constant to the variable DIE</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">It seems that this way we would be able to do "emit an address, or a constant if optimized away" if we modify clang to emit a single DIGlobalVariable for constant globals with an appropriate initializer, and add it to the list of globals in the DICompileUnit.</div></div></blockquote><div><br></div></div></div><div>Something like that sounds plausible.<br><br>Though it seems a minor pity if we have to carry the value (albeit null) in all the non-optimized cases.<br></div></div></div></div></blockquote><div><br></div></div></div><div>Yes, though I suppose that if it mattered we could change globaldce to pull the initializer out of the constant when it removes a constant.</div></div></div></div></blockquote><div><br></div><div>Not quite following there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Also when optimized away to a constant we might still want to keep the link inverted so we don't re-emit the same constant global variable into every CU that uses it (nor have to import it multiple times, etc). So we could have a separate named metadata node that just lists all the constant globals and they point back to their respective CU and that list can be uniqued when linking.<br><br>But I don't know how much any of it matters, how much work it'd be, etc.<br></div></div></div></div></blockquote><div><br></div></span><div>Yes, this is essentially what I was mentioning in my mail yesterday to Adrian. I think that as a first step we can keep the globals list on the CU and move it to separate named metadata if it makes sense/is sufficiently beneficial.<br></div></div></div></div></blockquote><div><br></div><div>Yeah, probably not a bad place to start/incremental progress, etc.<br><br>- Dave</div></div></div></div>