diff options
author | Jeremy Morse <jeremy.morse@sony.com> | 2022-02-02 15:04:14 +0000 |
---|---|---|
committer | Jeremy Morse <jeremy.morse@sony.com> | 2022-02-02 15:08:49 +0000 |
commit | 43de305704a50983bf134d8fb916f752a02eb076 (patch) | |
tree | dd725a717917f9e21606aef64e9c9c2b252406ec /llvm/lib/CodeGen/CommandFlags.cpp | |
parent | c5fff9095342a792bf4b9a077fe3c3a83c4e566c (diff) | |
download | llvm-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