[PATCH] ScalarEvolution incorrectly assumes that the start of certain add recurrences don't overflow

Sanjoy Das 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.


http://reviews.llvm.org/D7331

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list