[PATCH] D35010: [IRCE] Recognize loops with ne/eq latch conditions

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev added a comment.

In https://reviews.llvm.org/D35010#802926, @sanjoy wrote:

> Did you consider a somewhat more general trick of using the loop's BE taken count to derive an equivalent BE condition?  E.g. if the loops be taken count is 100, and the post-incremented indvar (the one the BE condition uses) is `{5,+,1}` (everything is `i32`) then the BE taken condition can be `++I s< 105` (and you can derive this without looking at whether the BE condition was expressed using SLT or NE or EQ etc.).


I think we still need to parse the loop structure to be able to duplicate it correctly, but the idea is interesting. I will think around it.



================
Comment at: lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp:810
+    if (Pred == ICmpInst::ICMP_NE && LatchBrExitIdx == 1)
+      // while (++i != len) {         while (++i < len) {
+      //   ...                 --->     ...
----------------
mkazantsev wrote:
> mkazantsev wrote:
> > sanjoy wrote:
> > > I don't think this equivalence holds if the RHS is negative.
> > What's the problem with negative RHS? There is no conceptual difference between
> >   while (++i != 5) ---> while (++i < 5)
> > and
> >   while (++i != -5) ---> while (++i < -5)
> > Maybe what you meant was "if the RHS is less than the IV's initial value"? Such loops get rejected earlier, test_02 exercises this situation. Will add an assert on that.
> Actually not earlier, but under this condition we will bail out on line 842.
Tests 2, 4, 6, 8 check such situations and make sure that the IRCE doesn't apply to them.


https://reviews.llvm.org/D35010