tree f5a2445c3787a8c63ad7a772827a18772b6d10e9
parent 64ea45e488996e0371d10ac2b8abfe8079201b96
author Jeremy Morse <jeremy.morse.llvm@gmail.com> 1550075585 +0000
committer Jeremy Morse <jeremy.morse.llvm@gmail.com> 1550075585 +0000

[DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs

In this patch SelectionDAG tries to salvage any dbg.values that are going to be
dropped, in case they can be recovered from Values in the current BB. It also
strengthens SelectionDAGs handling of dangling debug data, so that dbg.values
are *always* emitted (as Undef or otherwise) instead of dangling forever.

The motivation behind this patch exists in the new test case: a memory address
(here a bitcast and GEP) exist in one basic block, and a dbg.value referring to
the address is left in the 'next' block. The base pointer is live across all
basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it
isn't even emitted as an Undef DBG_VALUE.

The change is simply: if we're definitely going to drop a dbg.value, repeatedly
apply salvageDebugInfo to its operand until either we find something that can
be encoded, or we can't salvage any further in which case we produce an Undef
DBG_VALUE. To know when we're "definitely going to drop a dbg.value",
SelectionDAG signals SelectionDAGBuilder when all IR instructions have been
encoded to force salvaging. This ensures that any dbg.value that's dangling
after DAG creation will have a corresponding DBG_VALUE encoded. 

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353954 91177308-0d34-0410-b5e6-96231b3b80d8