diff options
| author | Ahmed Bougacha <ahmed.bougacha@gmail.com> | 2017-03-07 20:53:06 +0000 |
|---|---|---|
| committer | Ahmed Bougacha <ahmed.bougacha@gmail.com> | 2017-03-07 20:53:06 +0000 |
| commit | 5c7924fca51e0580bba5d9103b43558889a149bb (patch) | |
| tree | ac3c65be657ec17fc673ef94a64061cb4e02a425 /lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py | |
| parent | 38455ea8a61f18d2c6824b22faad49d9a8d5cd28 (diff) | |
| download | bcm5719-llvm-5c7924fca51e0580bba5d9103b43558889a149bb.tar.gz bcm5719-llvm-5c7924fca51e0580bba5d9103b43558889a149bb.zip | |
[GlobalISel] Avoid invalidating ValToVReg when translating no-op bitcast.
When we translate a no-op (same type) bitcast, we try to be clever and
only emit a COPY if we already assigned a vreg to the defined value.
However, when we didn't, we tried to assign to a reference into the
ValToVReg DenseMap, even though the RHS of the assignment
(getOrCreateVReg) could potentially grow that DenseMap, invalidating the
reference.
Avoid that by getting the source vreg first.
I audited the rest of the translator; this is the only tricky case.
The test is quite unwieldy, as the problem is caused by the DenseMap
growing, which happens after the 47th mapped value.
llvm-svn: 297208
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py')
0 files changed, 0 insertions, 0 deletions
