summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/expression_command/completion/other.cpp
diff options
context:
space:
mode:
authorJeremy Morse <jeremy.morse.llvm@gmail.com>2019-02-13 10:54:53 +0000
committerJeremy Morse <jeremy.morse.llvm@gmail.com>2019-02-13 10:54:53 +0000
commitf10af3f134f2c91b0dcc2bd7fa9e8f700fb05b99 (patch)
treebbd33f980aabb8be4ba7459338d525a6b8e38a65 /lldb/packages/Python/lldbsuite/test/expression_command/completion/other.cpp
parentf8ffb926e206982c57d862d12fe0004a135e014c (diff)
downloadbcm5719-llvm-f10af3f134f2c91b0dcc2bd7fa9e8f700fb05b99.tar.gz
bcm5719-llvm-f10af3f134f2c91b0dcc2bd7fa9e8f700fb05b99.zip
[DebugInfo][InstCombine] Prefer to salvage debuginfo over sinking it
When instcombine sinks an instruction between two basic blocks, it sinks any dbg.value users in the source block with it, to prevent debug use-before-free. However we can do better by attempting to salvage the debug users, which would avoid moving where the variable location changes. If we successfully salvage, still sink a (cloned) dbg.value with the sunk instruction, as the sunk instruction is more likely to be "live" later in the compilation process. If we can't salvage dbg.value users of a sunk instruction, mark the dbg.values in the original block as being undef. This terminates any earlier variable location range, and represents the fact that we've optimized out the variable location for a portion of the program. Differential Revision: https://reviews.llvm.org/D56788 llvm-svn: 353936
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/completion/other.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud