summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
diff options
context:
space:
mode:
authorBjorn Pettersson <bjorn.a.pettersson@ericsson.com>2018-09-20 09:00:17 +0000
committerBjorn Pettersson <bjorn.a.pettersson@ericsson.com>2018-09-20 09:00:17 +0000
commitcd53b7f54efb22c6bf52cab1fbf95805033ca018 (patch)
tree4816566361325bafbe968b99655e1dd6d21959ae /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
parenteb7f60201cb348223d3feec20638b3b084804a26 (diff)
downloadbcm5719-llvm-cd53b7f54efb22c6bf52cab1fbf95805033ca018.tar.gz
bcm5719-llvm-cd53b7f54efb22c6bf52cab1fbf95805033ca018.zip
[IPSCCP] Fix a problem with removing labels in a switch with undef condition
Summary: Before removing basic blocks that ipsccp has considered as dead all uses of the basic block label must be removed. That is done by calling ConstantFoldTerminator on the users. An exception is when the branch condition is an undef value. In such scenarios ipsccp is using some internal assumptions regarding which edge in the control flow that should remain, while ConstantFoldTerminator don't know how to fold the terminator. The problem addressed here is related to ConstantFoldTerminator's ability to rewrite a 'switch' into a conditional 'br'. In such situations ConstantFoldTerminator returns true indicating that the terminator has been rewritten. However, ipsccp treated the true value as if the edge to the dead basic block had been removed. So the code for resolving an undef branch condition did not trigger, and we ended up with assertion that there were uses remaining when deleting the basic block. The solution is to resolve indeterminate branches before the call to ConstantFoldTerminator. Reviewers: efriedma, fhahn, davide Reviewed By: fhahn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52232 llvm-svn: 342632
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud