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

[silviu.baranga at arm.com]

Hi Hal,

Thanks for having a look! I've only replied to comments related to the design for now. I think we can get the others after we've converged on some conclusion.

Thanks,
Silviu


================
Comment at: include/llvm/Analysis/ScalarEvolution.h:613
@@ +612,3 @@
+
+    virtual const SCEV *getZeroExtendExpr(const SCEV *Op, Type *Ty);
+    virtual const SCEV *getSignExtendExpr(const SCEV *Op, Type *Ty);
----------------
hfinkel wrote:
> Are these two methods special in theory, in this context, or in the future would overrides for more methods be useful?
> 
I think they are special because these expressions cannot fold sext/zext expressions. As far as I can see all the others can, so these seem like they are the only expressions that are stopping us for getting AddRecExprs as results?

For example if we have  (add (sext({x, + , 1}), y). Getting rid of the sext gets us {x + y, +, 1}.

However, there are other methods which might be useful to override, but not related to expression folding. For example SimplifyICmpOperands when taking an ULE predicate can only canonicalize the comparison if it knows that it can add one to the right operand without overflowing (the operand is loop invariant and could possibly be checked). This issue appears mostly when trying to get the number of backedges taken.

http://reviews.llvm.org/D10161

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