[llvm-dev] DebugInfo: Global variable expression management

[David Blaikie via llvm-dev]

On Wed, Dec 5, 2018 at 4:14 PM Adrian Prantl <aprantl at apple.com> wrote:

>
>
> > On Dec 5, 2018, at 3:58 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Hi Folks,
> >
> > Looking into some other issues, I came across a couple of oddities with
> regard to debug info for global variables (PR39900 and PR39899).
> >
> > 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):
> >
> > 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?
>
>
> This duality was something that I originally planned to clean up, but it
> turned out to be more complicated than worth the effort.
>
> A couple of constraints are:
> - LLVM IR may refer to Metadata, but not vice versa
> - llvm::GlobalVariables thus need a !dbg attachment to be bound to a
> DIGlobalVariableExpression
> - An optimized-away global constant needs to live somewhere, hence the
> DICompileUnit's globals: field.
>
> 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.


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)




> 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.


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?


> That said, DICompileUnit is distinct so calling replaceGlobals() on it is
> probably safe.
>
> What would the primary benefit of making this change be?
>

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.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181205/692dd30d/attachment.html>