[PATCH] ScalarEvolution incorrectly assumes that the start of certain add recurrences don't overflow
sanjoy at playingwithpointers.com
Fri Feb 6 19:00:55 PST 2015
> You mentioned that you can replace this with a correct version. I would love to see that!
I initially thought that this optimization was valid if the loop had at most one exiting block; but that is not correct. That one exiting block could be an early exit that leaves the loop before computing the pre-incremented induction variable.
If we make the assumption that a PHI node taking a poison value is UB (big assumption since poison values do not have consistent semantics yet) then I think we can do this optimization as long as we can prove that the backedge will be taken at least once.
> Actually, you could probably break this in theory without an early exit with a recurrence defined by a loop header phi that is not actually used within the loop except for the increment, then only used conditionally outside the loop. I say "in theory" because of the way the poison bit theoretically propagates. In SCEV, we basically assume undefined behavior the moment the value is used in a recurrence. That issue is much bigger than this bit of code though. You would really have to strip NSW/NUW from SCEV to change that assumption.
I agree -- I think SCEV should stick with this stronger notion of nsw/nuw until LLVM's semantics gets a consistent description of what poison does.
More information about the llvm-commits