diff options
| author | Nicolai Haehnle <nhaehnle@gmail.com> | 2016-08-10 18:51:14 +0000 |
|---|---|---|
| committer | Nicolai Haehnle <nhaehnle@gmail.com> | 2016-08-10 18:51:14 +0000 |
| commit | 02d784172c40325a12e481b4ffcb0618dcd13e78 (patch) | |
| tree | 72d191876a5c2ad211d8ea5ab2302fe3ef5a8009 /llvm/lib/Transforms | |
| parent | b10f6876cd7353d1e3fe2b13cf3f0e8171d8335f (diff) | |
| download | bcm5719-llvm-02d784172c40325a12e481b4ffcb0618dcd13e78.tar.gz bcm5719-llvm-02d784172c40325a12e481b4ffcb0618dcd13e78.zip | |
LiveIntervalAnalysis: fix a crash in repairOldRegInRange
Summary:
See the new test case for one that was (non-deterministically) crashing
on trunk and deterministically hit the assertion that I added in D23302.
Basically, the machine function contains a sequence
DS_WRITE_B32 %vreg4, %vreg14:sub0, ...
DS_WRITE_B32 %vreg4, %vreg14:sub0, ...
%vreg14:sub1<def> = COPY %vreg14:sub0
and SILoadStoreOptimizer::mergeWrite2Pair merges the two DS_WRITE_B32
instructions into one before calling repairIntervalsInRange.
Now repairIntervalsInRange wants to repair %vreg14, in particular, and
ends up trying to repair %vreg14:sub1 as well, but that only becomes
active _after_ the range that is to be repaired, hence the crash due
to LR.find(...) == LR.begin() at the start of repairOldRegInRange.
I believe that just skipping those subrange is fine, but again, not too
familiar with that code.
Reviewers: MatzeB, kparzysz, tstellarAMD
Subscribers: llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D23303
llvm-svn: 278268
Diffstat (limited to 'llvm/lib/Transforms')
0 files changed, 0 insertions, 0 deletions
