iv overflow detection: differentiate between limit checked IV and other

ivs

Author: davleopo

compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/nodes/loop/CountedLoopInfo.java

@@ -55,6 +55,7 @@
 import jdk.graal.compiler.nodes.util.IntegerHelper;
 import jdk.graal.compiler.nodes.util.SignedIntegerHelper;
 import jdk.graal.compiler.nodes.util.UnsignedIntegerHelper;
+import jdk.graal.compiler.phases.common.util.LoopUtility;
 import jdk.vm.ci.meta.DeoptimizationAction;
 import jdk.vm.ci.meta.DeoptimizationReason;
 import jdk.vm.ci.meta.JavaKind;
@@ -619,70 +620,92 @@ public boolean counterNeverOverflows() {
     }
 
     public boolean ivCanNeverOverflow(InductionVariable iv) {
-        if (!isLimitIncluded && iv.isConstantStride() && Loop.absStrideIsOne(iv)) {
-            return true;
-        }
-        if (loop.loopBegin().isProtectedNonOverflowingUnsigned()) {
-            return true;
-        }
-        // @formatter:off
-        /*
-         * Following comment reasons about the simplest possible loop form:
-         *
-         *              for(i = 0;i < end;i += stride)
-         *
-         * The problem is we want to create an overflow guard for the loop that can be hoisted
-         * before the loop, i.e., the overflow guard must not have loop variant inputs else it must
-         * be scheduled inside the loop. This means we cannot refer explicitly to the induction
-         * variable's phi but must establish a relation between end, stride and max (max integer
-         * range for a given loop) that is sufficient for most cases.
-         *
-         * We know that a head counted loop with a stride > 1 may overflow if the stride is big
-         * enough that end + stride will be > MAX, i.e. it overflows into negative value range.
-         *
-         * It is important that "end" in this context is the checked value of the loop condition:
-         * i.e., an arbitrary value. There is no relation between end and MAX established except
-         * that based on the integer representation we know that end <= MAX.
-         *
-         * A loop can overflow if the last checked value of the iv allows an overflow in the next
-         * iteration: the value range for which an overflow can happen is [MAX-(stride-1),MAX] e.g.
-         *
-         * MAX=10, stride = 3, overflow if number > 10
-         *  end = MAX -> 10 -> 10 + 3 = 13 -> overflow
-         *  end = MAX-1 -> 9 -> 9 + 3 = 12 -> overflow
-         *  end = MAX-2 -> 8 -> 8 + 3 = 11 -> overflow
-         *  end = MAX-3 -> 7 -> 7 + 3 = 10 -> No overflow at MAX - stride
-         *
-         * Note that this guard is pessimistic, i.e., it marks loops as potentially overflowing that
-         * are actually not overflowing. Consider the following loop:
-         *
-         * <pre>
-         *    for(i = MAX-56; i < MAX, i += 8)
-         * </pre>
-         *
-         *  where i in last loop body visit = MAX - 8, i after = MAX, no overflow
-         *
-         * which is wrongly detected as overflowing since "end" is element of [MAX-(stride-1),MAX]
-         * which is [MAX-7,MAX] and end is MAX. We handle such cases with a speculation and disable
-         * counted loop detection on subsequent compilations. We can only avoid such false positive
-         * detections by actually computing the number of iterations with a division, however we try
-         * to avoid that since that may be part of the fast path.
-         *
-         * And additional backup strategy could be to actually emit the precise guard inside the
-         * loop if the deopt already failed, but we refrain from this for now for simplicity
-         * reasons.
-         */
-        // @formatter:on
-        IntegerStamp endStamp = (IntegerStamp) getTripCountLimit().stamp(NodeView.DEFAULT);
-        ValueNode strideNode = iv.strideNode();
-        IntegerStamp strideStamp = (IntegerStamp) strideNode.stamp(NodeView.DEFAULT);
-        IntegerHelper integerHelper = getCounterIntegerHelper();
-        if (getDirection() == InductionVariable.Direction.Up) {
-            long max = integerHelper.maxValue();
-            return integerHelper.compare(endStamp.upperBound(), max - (strideStamp.upperBound() - 1) - (isLimitIncluded ? 1 : 0)) <= 0;
-        } else if (getDirection() == InductionVariable.Direction.Down) {
-            long min = integerHelper.minValue();
-            return integerHelper.compare(min + (1 - strideStamp.lowerBound()) + (isLimitIncluded ? 1 : 0), endStamp.lowerBound()) <= 0;
+        if (iv == getLimitCheckedIV()) {
+            if (!isLimitIncluded && iv.isConstantStride() && Loop.absStrideIsOne(iv)) {
+                return true;
+            }
+            if (loop.loopBegin().isProtectedNonOverflowingUnsigned()) {
+                return true;
+            }
+           // @formatter:off
+           /*
+            * Following comment reasons about the simplest possible loop form:
+            *
+            *              for(i = 0;i < end;i += stride)
+            *
+            * The problem is we want to create an overflow guard for the loop that can be hoisted
+            * before the loop, i.e., the overflow guard must not have loop variant inputs else it must
+            * be scheduled inside the loop. This means we cannot refer explicitly to the induction
+            * variable's phi but must establish a relation between end, stride and max (max integer
+            * range for a given loop) that is sufficient for most cases.
+            *
+            * We know that a head counted loop with a stride > 1 may overflow if the stride is big
+            * enough that end + stride will be > MAX, i.e. it overflows into negative value range.
+            *
+            * It is important that "end" in this context is the checked value of the loop condition:
+            * i.e., an arbitrary value. There is no relation between end and MAX established except
+            * that based on the integer representation we know that end <= MAX.
+            *
+            * A loop can overflow if the last checked value of the iv allows an overflow in the next
+            * iteration: the value range for which an overflow can happen is [MAX-(stride-1),MAX] e.g.
+            *
+            * MAX=10, stride = 3, overflow if number > 10
+            *  end = MAX -> 10 -> 10 + 3 = 13 -> overflow
+            *  end = MAX-1 -> 9 -> 9 + 3 = 12 -> overflow
+            *  end = MAX-2 -> 8 -> 8 + 3 = 11 -> overflow
+            *  end = MAX-3 -> 7 -> 7 + 3 = 10 -> No overflow at MAX - stride
+            *
+            * Note that this guard is pessimistic, i.e., it marks loops as potentially overflowing that
+            * are actually not overflowing. Consider the following loop:
+            *
+            * <pre>
+            *    for(i = MAX-56; i < MAX, i += 8)
+            * </pre>
+            *
+            *  where i in last loop body visit = MAX - 8, i after = MAX, no overflow
+            *
+            * which is wrongly detected as overflowing since "end" is element of [MAX-(stride-1),MAX]
+            * which is [MAX-7,MAX] and end is MAX. We handle such cases with a speculation and disable
+            * counted loop detection on subsequent compilations. We can only avoid such false positive
+            * detections by actually computing the number of iterations with a division, however we try
+            * to avoid that since that may be part of the fast path.
+            *
+            * And additional backup strategy could be to actually emit the precise guard inside the
+            * loop if the deopt already failed, but we refrain from this for now for simplicity
+            * reasons.
+            */
+           // @formatter:on
+            IntegerStamp endStamp = (IntegerStamp) getTripCountLimit().stamp(NodeView.DEFAULT);
+            ValueNode strideNode = getLimitCheckedIV().strideNode();
+            IntegerStamp strideStamp = (IntegerStamp) strideNode.stamp(NodeView.DEFAULT);
+            IntegerHelper integerHelper = getCounterIntegerHelper();
+            if (getDirection() == InductionVariable.Direction.Up) {
+                long max = integerHelper.maxValue();
+                return integerHelper.compare(endStamp.upperBound(), max - (strideStamp.upperBound() - 1) - (isLimitIncluded ? 1 : 0)) <= 0;
+            } else if (getDirection() == InductionVariable.Direction.Down) {
+                long min = integerHelper.minValue();
+                return integerHelper.compare(min + (1 - strideStamp.lowerBound()) + (isLimitIncluded ? 1 : 0), endStamp.lowerBound()) <= 0;
+            }
+            return false;
+        } else {
+            /*
+             * All over IVs: This IV is not compared against limit and thus we cannot play the trick
+             * comparing against the end stamp. We have to compute (if possible) the extremum value
+             * and use that.
+             */
+            if (iv.isConstantInit() && isConstantMaxTripCount() && iv.isConstantStride()) {
+                try {
+                    final int bits = IntegerStamp.getBits(iv.valueNode().stamp(NodeView.DEFAULT));
+                    long tripCountMinus1 = LoopUtility.subtractExact(bits, maxTripCountNode().asJavaConstant().asLong(), 1);
+                    long stripTimesTripCount = LoopUtility.multiplyExact(bits, iv.constantStride(), tripCountMinus1);
+                    @SuppressWarnings("unused")
+                    long extremum = LoopUtility.addExact(bits, stripTimesTripCount, iv.initNode().asJavaConstant().asLong());
+                    return true;
+                } catch (ArithmeticException e) {
+                    // overflow
+                    return false;
+                }
+            }
         }
         return false;
     }