[PATCH] D30887: [ScalarEvolution] Predicate implication from operations

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev marked 6 inline comments as done.
mkazantsev added inline comments.


================
Comment at: lib/Analysis/ScalarEvolution.cpp:8565
+      // Rules for division.
+      auto *Num = getSCEV(Op1);
+      auto *Denum = getSCEV(Op2);
----------------
sanjoy wrote:
> mkazantsev wrote:
> > sanjoy wrote:
> > > Let's avoid creating SCEV expressions here (via `getSCEV` or `getAddExpr`).  One problem is that it may be a compile time hit.  They can also cause use to compute overly conservative trip counts, since this call to `isImpliedViaOperations` may have itself been done during a trip count computation, and invoking `getSCEV` may try to (recursively) compute the trip count of the same loop again which would cache a conservative `SCEVCouldNotCompute` (to avoid recursing infinitely).
> > I have removed the call of "isKnownPredicate" that might request recursive recalculation of the same trip count; now we use more light-weight check that used to be "IsKnownPredicateFull" lambda. So now this problem should have gone.
> > 
> > As for the compile time issue, what is the alternative to using SCEV for Num/Denum/FoundRHS+ 1?
> One possibility would be to put the actual core of the logic in `llvm::isImpliedCondition` (which is in ValueTracking), and then try to call into that helper from there.
> 
> That is, say the antecedent is `(sext i16 %t to i32) s< i32 44` and the consequent is `%s != 400`.  We could then ask ValueTracking `llvm::isImpliedCondition(i16 %t s< i16 44, %s != 400)` [0] and return whatever ValueTracking told us.
> 
> We will probably need to generalize the interface of ValueTracking's `llvm::isImpliedCondition` a bit though, but that should be fine.
> 
> [0] Using the fact that `(sext(A) s< sext(B)) == A s< B`.
I noticed that Num never needs a new SCEV creation in good case, because all we want is to prove that it's SCEV is actually FoundLHS. thus, it and some type conversions have gone.

Now we only have SCEV creation left for Denum-related stuff (such as constructing -Denum and Denum + 1). Here I believe that we cannot get rid of it, because for using implied conditions interfaces we will have to construct those sum and neg in terms of values if not in terms of SCEVs.

To avoid reculsive recalculations in this last case, let's just reduce the scope of the optimization to Denum being a constant. In this case creating Denum+1, -Denum or type extensions will only require constants creation, and there is a very high chance that these contant SCEVs already exist.


https://reviews.llvm.org/D30887