[60281] IV overflow detection: differentiate between limit checked IV and other ivs.

PullRequest: graal/19515

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,62 +620,85 @@ public boolean counterNeverOverflows() {
     }
 
     public boolean ivCanNeverOverflow(InductionVariable iv) {
+        if (iv != getLimitCheckedIV()) {
+            /*
+             * All non-limit checked 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, LoopUtility.tripCountSignedExact(this), 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;
+                }
+            }
+        }
+
+        // BELOW: limitCheckedIV case
+
         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
+           /*
+            * 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();
+        ValueNode strideNode = getLimitCheckedIV().strideNode();
         IntegerStamp strideStamp = (IntegerStamp) strideNode.stamp(NodeView.DEFAULT);
         IntegerHelper integerHelper = getCounterIntegerHelper();
         if (getDirection() == InductionVariable.Direction.Up) {

compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/phases/common/util/LoopUtility.java

@@ -53,6 +53,7 @@
 import jdk.graal.compiler.nodes.cfg.HIRBlock;
 import jdk.graal.compiler.nodes.extended.OpaqueValueNode;
 import jdk.graal.compiler.nodes.loop.BasicInductionVariable;
+import jdk.graal.compiler.nodes.loop.CountedLoopInfo;
 import jdk.graal.compiler.nodes.loop.InductionVariable;
 import jdk.graal.compiler.nodes.loop.Loop;
 import jdk.graal.compiler.nodes.loop.LoopsData;
@@ -61,6 +62,15 @@
 
 public class LoopUtility {
 
+    public static long tripCountSignedExact(CountedLoopInfo loop) {
+        ValueNode maxTripCountNode = loop.maxTripCountNode();
+        final long maxTripCountAsSigned = maxTripCountNode.asJavaConstant().asLong();
+        if (maxTripCountAsSigned < 0) {
+            throw new ArithmeticException("Unsigned value " + maxTripCountAsSigned + " overflows signed range");
+        }
+        return maxTripCountAsSigned;
+    }
+
     public static long addExact(int bits, long a, long b) {
         if (bits == 8) {
             byte ba = NumUtil.safeToByteAE(a);