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

silviu.baranga at arm.com silviu.baranga at arm.com
Tue Jun 23 08:49:56 PDT 2015

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.


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.



More information about the llvm-commits mailing list