This is a latent bug that's been hanging around for a while. For a loop-invariant
pointer, expandBounds would return the range {Ptr, Ptr}, but this was interpreted
as a half-open range, not a closed range. So we ended up planting incorrect
bounds checks. Even worse, they were tautological, so we ended up incorrectly
executing the optimized loop.
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Analysis/LoopAccessAnalysis.cpp | ||
---|---|---|
1944 | If we're now always calling expandCodeFor(..), is it still worth checking above if NewPtr is in the loop body? |
lib/Analysis/LoopAccessAnalysis.cpp | ||
---|---|---|
1944 | We're only calling expandCodeFor unconditionally on ScPlusOne; I suppose if we're expecting instcombine to clean up from that we should also expect it to clean up expandCodeFor(Sc), but I don't see a need to generate worse code? |
If we're now always calling expandCodeFor(..), is it still worth checking above if NewPtr is in the loop body?