aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/CommandFlags.cpp
diff options
context:
space:
mode:
authorJeremy Morse <jeremy.morse@sony.com>2022-02-02 15:04:14 +0000
committerJeremy Morse <jeremy.morse@sony.com>2022-02-02 15:08:49 +0000
commit43de305704a50983bf134d8fb916f752a02eb076 (patch)
treedd725a717917f9e21606aef64e9c9c2b252406ec /llvm/lib/CodeGen/CommandFlags.cpp
parentc5fff9095342a792bf4b9a077fe3c3a83c4e566c (diff)
downloadllvm-43de305704a50983bf134d8fb916f752a02eb076.zip
llvm-43de305704a50983bf134d8fb916f752a02eb076.tar.gz
llvm-43de305704a50983bf134d8fb916f752a02eb076.tar.bz2
[DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877
This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg, or DBG_INSTR_REFs where no value can be found, are represented by a DbgValue object with Kind "Undef", explicitly meaning "there is no value". In D117877 I added a special-case to some assignment accounting faster, without considering this scenario. It causes variables to be given the value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The DenseMap asserts, because EmptyValue is the tombstone key. Fix this by handling the assign-undef scenario in the special case, to match what happens in the general case: the variable has no value if it's only ever assigned $noreg / undef. Differential Revision: https://reviews.llvm.org/D118715
Diffstat (limited to 'llvm/lib/CodeGen/CommandFlags.cpp')
0 files changed, 0 insertions, 0 deletions