[PATCH] D139934: [IndVars] Apply more optimistic SkipLastIter for AND/OR conditions

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev planned changes to this revision.
mkazantsev added inline comments.


================
Comment at: llvm/lib/Transforms/Scalar/IndVarSimplify.cpp:1490
+      for (size_t j = 0; j < LeafConditions.size(); j++)
+        if (i != j) {
+          auto EL = SE->computeExitLimitFromCond(L, LeafConditions[j], Inverted,
----------------
nikic wrote:
> nikic wrote:
> > mkazantsev wrote:
> > > nikic wrote:
> > > > I don't really get why we need this quadratic-complexity code. It doesn't look like anything inside here depends on the outer `i`?
> > > `OldCond ` depends on outer `i`. The logic here is following: we have `n` conditions joined through `AND`. Currenly we are handing `i`'th condition. If any **other** condition gives exact same exit count as the whole aggregate, it means that the current condition can be handled w/o last iteration. Scanning these other conditions takes linear time (I guess we could cache something if it's a problem, but they can be rewritten, so it's safer not to).
> > > 
> > It should be sufficient to go through all the conditions once, and just remember which ones match the maximum. Then it should be possible to use skip last iter if either a) there is more than one such condition or b) the one such condition is not the one currently processed. Probably, for all practical purposes it's fine to just ignore a) and only store a single index for the condition that matches the max exit count.
> And if we do that, then I don't think we need the MaxJoinedICmpsToAnalyze limit either, because the complexity is linear.
I was thinking about something like this actually. The fact that stopped me is that, after rewriting, the property of "exits on last iteration" will disappear. Imagine `A & B & C`, all three exiting on last iteration. We could replace `A` basing on `B`, `B` basing on `C` and `C` basing on `A`. The simplistic approach I am currently using prevents that, however if we sustain a set of all conditions exiting on last iter, that should work. Let me try it out.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139934/new/

https://reviews.llvm.org/D139934