Commit Graph

8 Commits

Author SHA1 Message Date
Adrian Prantl 05782218ab Canonicalize the representation of empty an expression in DIGlobalVariableExpression
This change simplifies code that has to deal with
DIGlobalVariableExpression and mirrors how we treat DIExpressions in
debug info intrinsics. Before this change there were two ways of
representing empty expressions on globals, a nullptr and an empty
!DIExpression().

If someone needs to upgrade out-of-tree testcases:
  perl -pi -e 's/(!DIGlobalVariableExpression\(var: ![0-9]*)\)/\1, expr: !DIExpression())/g' <MYTEST.ll>
will catch 95%.

llvm-svn: 312144
2017-08-30 18:06:51 +00:00
Reid Kleckner 6d353348e5 Parse and print DIExpressions inline to ease IR and MIR testing
Summary:
Most DIExpressions are empty or very simple. When they are complex, they
tend to be unique, so checking them inline is reasonable.

This also avoids the need for CodeGen passes to append to the
llvm.dbg.mir named md node.

See also PR22780, for making DIExpression not be an MDNode.

Reviewers: aprantl, dexonsmith, dblaikie

Subscribers: qcolombet, javed.absar, eraman, hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D37075

llvm-svn: 311594
2017-08-23 20:31:27 +00:00
Adrian Prantl 83ca4fc7bc Update LiveDebugValues to generate DIExpressions for spill offsets
instead of using the deprecated offset field of DBG_VALUE.

This has no observable effect on the generated DWARF, but the
assembler comments will look different.

rdar://problem/33580047

llvm-svn: 309773
2017-08-02 00:16:56 +00:00
Wolfgang Pieb 399dcfaa2a Reapply r294532, reverted in r294787.
Store instructions can have more than one memory operand as a result
of optimizations that fold different stores into one.
When we identify spill instructions to generate DBG_VALUE instructions
to record the spilling of a variable, we disregard stores with 
multiple memory operands for now. We may miss some relevant spills but
the handling is a bit more complex, so we'll do it in a different patch.

This fixes PR31935.

llvm-svn: 295093
2017-02-14 19:08:45 +00:00
Nico Weber ee0b0ec935 Revert r294532, it caused PR31935
llvm-svn: 294787
2017-02-10 21:57:30 +00:00
Wolfgang Pieb 458b4e7c46 Reapply r294356 ("Keep track of spilled variables in LiveDebugValues").
Was reverted with r294447 due to undefined behavior with negative offsets
in DBG_VALUE instructions.

llvm-svn: 294532
2017-02-08 23:46:59 +00:00
NAKAMURA Takumi a3bc043caa Revert r294356, "DebugInfo: Track spilled variables in LiveDebugValues"
It caused undefined behavior in VarLoc. As far as I investigated,

  - VarLoc::VarLoc() treats negative offset value as InvalidKind.
    Consider the case that (int64_t)MI.getOperand(1).getImm() is negative and whether it satisfies ((uint64_t)Offset < (1ULL << 32)).

  - Comparison operators in VarLoc behave undefined since VarLoc::Loc.Hash is uninitialized in case of InvalidKind.

I guess Offset (in VarLoc) could be made aware of signed, but I am not sure.
So I have reverted it for now.

llvm-svn: 294447
2017-02-08 13:49:28 +00:00
Wolfgang Pieb 02f329370f DebugInfo: Track spilled variables in LiveDebugValues
When variables are spilled to the stack by the register allocator, keep track of their
debug locations in LiveDebugValues and insert DBG_VALUE instructions at the appropriate
place. Ensure that the locations are propagated down the dominator tree via the existing 
mechanisms.

Reviewer: aprantl

Differential Revision: https://reviews.llvm.org/D29500

llvm-svn: 294356
2017-02-07 21:23:15 +00:00