[PATCH] [SCEV][LoopVectorize] Allow ScalarEvolution to make assumptions about overflows

[Adam Nemet]

Hi Silviu,

Can you please discuss the use-cases?  We all ran into SCEV not always being the right vehicle to prove no-overflow but this proposes a pretty big change, so I want to make sure we can't take more targeted/distributed solutions to the problem.  (My general feeling is similar to what Andy and Sanjoy have already expressed.)

I feel like that in some cases, we can prove no-overflow at *compile* time by further analyzing the IR (like what I am proposing in http://reviews.llvm.org/D10472).  Essentially this is relying on C/C++ signed overflow being undefined.

In other cases we may need prove no-overflow of smaller types so that we can up-level the sign/zero-extensions.  Is this perhaps something that's better done in indvars?  The idea is (maybe flawed) that you can eliminate an extension in the loop by using an overflow check outside the loop.

Anyhow, you collected some testcases so categorizing the issues would probably help the discussion.

I am also in favor of allowing finer level of control along the lines of Sanjoy's comments.  Your approach may work for the vectorizer but in case of the general dependence analysis, we may not need to prove of no-overflow of all pointers.  For example, if a pointer can't alias with any other accesses in the loop, we don't care that we can't get a true affine form for it.

Thanks,
Adam


http://reviews.llvm.org/D10161

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