aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorSanjoy Das <sanjoy@playingwithpointers.com>2017-12-04 19:22:00 +0000
committerSanjoy Das <sanjoy@playingwithpointers.com>2017-12-04 19:22:00 +0000
commit7e36337935ab4d64f947bae93ec0ca0b51d714b1 (patch)
tree1c7d122686e75d290a280aeccf8ec4729e97308f /clang/lib/Frontend/CompilerInvocation.cpp
parentaa92cae14e998670780065f92ae9ed1431d69ff1 (diff)
downloadllvm-7e36337935ab4d64f947bae93ec0ca0b51d714b1.zip
llvm-7e36337935ab4d64f947bae93ec0ca0b51d714b1.tar.gz
llvm-7e36337935ab4d64f947bae93ec0ca0b51d714b1.tar.bz2
[SCEV] A different fix for PR33494
Summary: I don't think rL309080 is the right fix for PR33494 -- caching ExitLimit only hides the problem[0]. The real issue is that because of how we forget SCEV expressions ScalarEvolution::getBackedgeTakenInfo, in the test case for PR33494 computing the backedge for any loop invalidates the trip count for every other loop. This effectively makes the SCEV cache useless. I've instead made the SCEV expression invalidation in ScalarEvolution::getBackedgeTakenInfo less aggressive to fix this issue. [0]: One way to think about this is that rL309080 essentially augmented the backedge-taken-count cache with another equivalent exit-limit cache. The bug went away because we were explicitly not clearing the exit-limit cache in getBackedgeTakenInfo. But instead of doing all of that, we can just avoid clearing the backedge-taken-count cache. Reviewers: mkazantsev, mzolotukhin Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D39361 llvm-svn: 319678
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions