[llvm-bugs] [Bug 31013] New: [IR] DIGlobalVariable should not hold a DIExpression
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Nov 14 10:51:26 PST 2016
https://llvm.org/bugs/show_bug.cgi?id=31013
Bug ID: 31013
Summary: [IR] DIGlobalVariable should not hold a DIExpression
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedbugs at nondot.org
Reporter: aprantl at apple.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
Currently, DIGlobalVariables holds a DIExpression. This is not the best way to
model this:
(1) The DIGlobalVariable should describe the source level variable, not how to
get to its location.
(2) It makes it unsafe/hard to update the expressions when we call
replaceExpression on the DIGLobalVariable.
(3) It makes it impossible to represent a global variable that is in more than
one location (e.g., a variable with multiple DW_OP_piece-s).
We also moved away from attaching the DIExpression to DILocalVariable for the
same reasons.
A better representation would be to add a DIGlobalVariableExpression(var:
!DIGlobalVariable(...), expr: !DIExpression(...)) that wraps a global variable
and an expression. For example, let's say we have a global symbol g that
doesn't need an expression — this would still be represented as:
@g = global i32 0, !dbg !0
!0 = DIGlobalVariable(name: "g", ...)
Later, after some transformation, this becomes:
@opt_g = global i32 *, !dbg !1
!0 = distinct !DIGlobalVariable(name: "g", ...) ; Identical to !0 above.
!1 = !DIGlobalVariableExpr(var: !0, expr: !2) ; Not distinct.
!2 = !DIExpression(DW_OP_deref, ...)
This allows transformations to just add new mergeable metadata on top of the
existing DIGlobalVariable without blowing up the representation if they aren't
needed.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161114/e161481c/attachment.html>
More information about the llvm-bugs
mailing list