diff options
| author | Philip Reames <listmail@philipreames.com> | 2016-12-13 01:21:15 +0000 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2016-12-13 01:21:15 +0000 |
| commit | 51387a8c28ca43ceadd29aa58fde8fe1103f9a2a (patch) | |
| tree | c264a35a267d224bddfc60b8afe69603ea571ac6 /llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp | |
| parent | df80572d1f66cee3d50ee3aa2040b4eb47c22244 (diff) | |
| download | bcm5719-llvm-51387a8c28ca43ceadd29aa58fde8fe1103f9a2a.tar.gz bcm5719-llvm-51387a8c28ca43ceadd29aa58fde8fe1103f9a2a.zip | |
[Statepoints] Reuse stack slots more than once within a basic block
The stack slot reuse code had a really amusing bug. We ended up only reusing a stack slot exact once (initial use + reuse) within a basic block. If we had a third statepoint to process, we ended up allocating a new set of stack slots. If we crossed a basic block boundary, the set got cleared. As a result, code which is invoke heavy doesn't see the problem, but multiple calls within a basic block does. Net result: as we optimize invokes into calls, lowering gets worse.
The root error here is that the bitmap uses by the custom allocator wasn't kept in sync. The result was that we ended up resizing the bitmap on the next statepoint (to handle the cross block case), reset the bit once, but then never reset it again.
Differential Revision: https://reviews.llvm.org/D25243
llvm-svn: 289509
Diffstat (limited to 'llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp')
0 files changed, 0 insertions, 0 deletions
