<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 4:14 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Dec 5, 2018, at 3:58 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> Hi Folks,<br>
> <br>
> Looking into some other issues, I came across a couple of oddities with regard to debug info for global variables (PR39900 and PR39899).<br>
> <br>
> But a broader question I was wondering if it was anyone's radar (it's not something I'll be pushing on myself in the near future, but just wanted to see if the idea was already out there, etc):<br>
> <br>
> Why are there DIGlobalVariableExpressions that are both attached as !dbg metadata on llvm::GlobalVariables, and in the globals() list of a DICompileUnit? I would've thought, ideally, a DIGlobalVariableExpression would be mutually exclusively in one place or the other - the only ones in the globals() list of a DICompileUnit would be the constant values, that have no place elsewhere. When the storage for a global is optimized away, it'd be possible to find its DICompileUnit from the scope of the DIGlobalVariable referenced by the DIGlobalVariableExpression given by the !dbg on said GlobalVariable & attach the constant DIGlobalVariableExpression there, perhaps?<br>
<br>
<br>
This duality was something that I originally planned to clean up, but it turned out to be more complicated than worth the effort.<br>
<br>
A couple of constraints are:<br>
- LLVM IR may refer to Metadata, but not vice versa<br>
- llvm::GlobalVariables thus need a !dbg attachment to be bound to a DIGlobalVariableExpression<br>
- An optimized-away global constant needs to live somewhere, hence the DICompileUnit's globals: field.<br>
<br>
You are right in that debug variables don't need to be in both places at the same time, but then we need to teach optimization passes that delete a constant llvm::GlobalVariable to update a DICompileUnit's globals: field. </blockquote><div><br>Fair, I suppose today if an optimization pass deletes a GlobalVariable, the result is that the debug info still describes the global variable - but without any value. (this is inconsistent, though technically better, than we do with functions - which, if totally deleted, aren't emitted at all - but they track through inlining more than a global variable does, so it's not a perfect comparison) - whereas if we avoided having them in the globals() list, we'd /have/ to update that list, even in cases where the optimization didn't have anything useful to say about the value of the global (eg: "hey, this global has lots of different values throughout its lifetime, but none of them are used, I'm going to delete it" - today, it just deletes it and the debug info is correct. But with this change, it'd have to go wire in a null description to ensure the variable wasn't lost entirely)<br><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is messy and may subtly break some assumptions that I haven't thought about yet. Outside of DIBuilder we get through the entire compiler without modifying any MDNodes. </blockquote><div><br></div><div>I guess we only create new ones when it comes to creating complicated dwarf location descriptions/expressions as optimizations change local variables around? So not modification in that case?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That said, DICompileUnit is distinct so calling replaceGlobals() on it is probably safe.<br>
<br>
What would the primary benefit of making this change be?<br></blockquote><div><br>Oh, just noticed as an aside while I was filing the aforementioned bugs - struck me as weird that they were connected in two places is all. No major thing I can think of.<br><br>- Dave </div></div></div>