[llvm-dev] DebugInfo: Global variable expression management

[Adrian Prantl via llvm-dev]

> 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. 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. That said, DICompileUnit is distinct so calling replaceGlobals() on it is probably safe.

What would the primary benefit of making this change be?

-- adrian