summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
diff options
context:
space:
mode:
authorJeremy Morse <jeremy.morse@sony.com>2019-12-06 11:21:27 +0000
committerJeremy Morse <jeremy.morse@sony.com>2019-12-06 11:27:19 +0000
commitc93a9b15ce885f7a4d90b0f9ff2928fc7e2cd74a (patch)
treea732ac7f7d6f8eb95e52d68e761a0c834cbe88d2 /lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
parentb3009edcf3342c312a26416cca531bd4a29756de (diff)
downloadbcm5719-llvm-c93a9b15ce885f7a4d90b0f9ff2928fc7e2cd74a.tar.gz
bcm5719-llvm-c93a9b15ce885f7a4d90b0f9ff2928fc7e2cd74a.zip
[DebugInfo][CGP] Update dbg.values when sinking address computations
One of CodeGenPrepare's optimizations is to duplicate address calculations into basic blocks, so that as much information as possible can be folded into memory addressing operands. This is great -- but the dbg.value variable location intrinsics are not updated in the same way. This can lead to dbg.values referring to address computations in other blocks that will never be encoded into the DAG, while duplicate address computations are performed locally that could be used by the dbg.value. Some of these (such as non-constant-offset GEPs) can't be salvaged past. Fix this by, whenever we duplicate an address computation into a block, looking for dbg.value users of the original memory address in the same block, and redirecting those to the local computation. Differential Revision: https://reviews.llvm.org/D58403
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud