dwblaikie wrote: > My understanding was that the DIExpression parameter to > DIGlobalVariableExpression was empty for global variables with locations. So > the patch just encodes the constant into that expression if it's otherwise > empty.
I think in theory it can be non-empty (see what happens under a merge globals optimization... I'm not sure of an example of when this optimization fires, or what the debug info we emit looks like - in theory it should look like a global with a non-empty expression that describes offsetting the pointer forward to reach the global inside the merged global) & so then you'd have a hard time telling whether the expression is meant to be used in addition to the location, or as part of evaluating the location. We don't really have a mechanism for encoding a variable in two locations (or a constant and a location) at the same time, I think. We could invent a special opcode to use in the expression to communicate this, or define some special handling if there's two separate expressions providing a location (or a location and a constant in this case) for the same variable (say that they're both valid, and emit them both if we can). @adrian-prantl thoughts? https://github.com/llvm/llvm-project/pull/72730 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
