[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