maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Analysis/ScalarEvolution/trip-count9.ll

416 lines
12 KiB
LLVM
Raw Normal View History

Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; RUN: opt -analyze -scalar-evolution -S < %s | FileCheck %s
; Every combination of
; - starting at 0, 1, or %x
; - steping by 1 or 2
; - stopping at %n or %n*2
; - using nsw, or not
; Some of these represent missed opportunities.
; CHECK: Determining loop execution counts for: @foo
; CHECK: Loop %loop: backedge-taken count is (-1 + %n)
; CHECK: Loop %loop: max backedge-taken count is 6
define void @foo(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: Unpredictable backedge-taken count.
; CHECK: Loop %loop: Unpredictable max backedge-taken count.
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @step2(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @start1
; CHECK: Loop %loop: backedge-taken count is (-2 + (2 smax %n))
; CHECK: Loop %loop: max backedge-taken count is 5
define void @start1(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @start1_step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: Unpredictable backedge-taken count.
; CHECK: Loop %loop: Unpredictable max backedge-taken count.
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @start1_step2(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @startx
; CHECK: Loop %loop: backedge-taken count is (-1 + (-1 * %x) + ((1 + %x) smax %n))
; CHECK: Loop %loop: max backedge-taken count is -1
define void @startx(i4 %n, i4 %x) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @startx_step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: Unpredictable backedge-taken count.
; CHECK: Loop %loop: Unpredictable max backedge-taken count.
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @startx_step2(i4 %n, i4 %x) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @nsw
; CHECK: Loop %loop: backedge-taken count is (-1 + %n)
; CHECK: Loop %loop: max backedge-taken count is 6
define void @nsw(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; If %n is INT4_MAX, %i.next will wrap. The nsw bit says that the
; result is undefined. Therefore, after the loop's second iteration,
; we are free to assume that the loop exits. This is valid because:
; (a) %i.next is a poison value after the second iteration, which can
; also be considered an undef value.
; (b) the return instruction enacts a side effect that is control
; dependent on the poison value.
;
; CHECK-LABEL: nsw_step2
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; CHECK: Determining loop execution counts for: @nsw_step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-1 + %n) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 2
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @nsw_step2(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK-LABEL: nsw_start1
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; CHECK: Determining loop execution counts for: @nsw_start1
; CHECK: Loop %loop: backedge-taken count is (-2 + (2 smax %n))
; CHECK: Loop %loop: max backedge-taken count is 5
define void @nsw_start1(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @nsw_start1_step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-2 + (3 smax %n)) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 2
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @nsw_start1_step2(i4 %n) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @nsw_startx
; CHECK: Loop %loop: backedge-taken count is (-1 + (-1 * %x) + ((1 + %x) smax %n))
; CHECK: Loop %loop: max backedge-taken count is -1
define void @nsw_startx(i4 %n, i4 %x) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @nsw_startx_step2
SCEV should use NSW to get trip count for positive nonunit stride loops. SCEV currently fails to compute loop counts for nonunit stride loops. This comes up frequently. It prevents loop optimization and forces vectorization to insert extra loop checks. For example: void foo(int n, int *x) { for (int i = 0; i < n; i += 3) { x[i] = i; x[i+1] = i+1; x[i+2] = i+2; } } We need to properly handle the case in which limit > INT_MAX-stride. In the above case: n > INT_MAX-3. In this case the loop counter will step beyond the limit and overflow at the same time. However, knowing that signed integer overlow in undefined, we can assume the loop test behavior is arbitrary after overflow. This obeys both C undefined behavior rules, and the more strict LLVM poison value rules. I'm finally fixing this in response to Hal Finkel's persistence. The most probable reason that we never optimized this before is that we were being careful to handle case where the developer expected a side-effect free infinite loop relying on overflow: for (int i = 0; i < n; i += s) { ++j; } return j; If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might expect an infinite loop. However there are plenty of ways to achieve this effect without relying on undefined behavior of signed overflow. llvm-svn: 193015
2013-10-19 07:43:53 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-1 + (-1 * %x) + ((2 + %x) smax %n)) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 7
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @nsw_startx_step2(i4 %n, i4 %x) {
entry:
%s = icmp sgt i4 %n, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %n
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even
; CHECK: Loop %loop: backedge-taken count is (-1 + (2 * %n))
; CHECK: Loop %loop: max backedge-taken count is 5
define void @even(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_step2
Rewrite SCEV's backedge taken count computation. Patch by Michele Scandale! Rewrite of the functions used to compute the backedge taken count of a loop on LT and GT comparisons. I decided to split the handling of LT and GT cases becasue the trick "a > b == -a < -b" in some cases prevents the trip count computation due to the multiplication by -1 on the two operands of the comparison. This issue comes from the conservative computation of value range of SCEVs: taking the negative SCEV of an expression that have a small positive range (e.g. [0,31]), we would have a SCEV with a fullset as value range. Indeed, in the new rewritten function I tried to better handle the maximum backedge taken count computation when MAX/MIN expression are used to handle the cases where no entry guard is found. Some test have been modified in order to check the new value correctly (I manually check them and reasoning on possible overflow the new values seem correct). I finally added a new test case related to the multiplication by -1 issue on GT comparisons. llvm-svn: 194116
2013-11-06 10:08:26 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-1 + (2 * %n)) /u 2)
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; CHECK: Loop %loop: max backedge-taken count is 2
define void @even_step2(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_start1
; CHECK: Loop %loop: backedge-taken count is (-2 + (2 smax (2 * %n)))
; CHECK: Loop %loop: max backedge-taken count is 4
define void @even_start1(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_start1_step2
Rewrite SCEV's backedge taken count computation. Patch by Michele Scandale! Rewrite of the functions used to compute the backedge taken count of a loop on LT and GT comparisons. I decided to split the handling of LT and GT cases becasue the trick "a > b == -a < -b" in some cases prevents the trip count computation due to the multiplication by -1 on the two operands of the comparison. This issue comes from the conservative computation of value range of SCEVs: taking the negative SCEV of an expression that have a small positive range (e.g. [0,31]), we would have a SCEV with a fullset as value range. Indeed, in the new rewritten function I tried to better handle the maximum backedge taken count computation when MAX/MIN expression are used to handle the cases where no entry guard is found. Some test have been modified in order to check the new value correctly (I manually check them and reasoning on possible overflow the new values seem correct). I finally added a new test case related to the multiplication by -1 issue on GT comparisons. llvm-svn: 194116
2013-11-06 10:08:26 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-2 + (3 smax (2 * %n))) /u 2)
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; CHECK: Loop %loop: max backedge-taken count is 2
define void @even_start1_step2(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_startx
; CHECK: Loop %loop: backedge-taken count is (-1 + (-1 * %x) + ((1 + %x) smax (2 * %n)))
Rewrite SCEV's backedge taken count computation. Patch by Michele Scandale! Rewrite of the functions used to compute the backedge taken count of a loop on LT and GT comparisons. I decided to split the handling of LT and GT cases becasue the trick "a > b == -a < -b" in some cases prevents the trip count computation due to the multiplication by -1 on the two operands of the comparison. This issue comes from the conservative computation of value range of SCEVs: taking the negative SCEV of an expression that have a small positive range (e.g. [0,31]), we would have a SCEV with a fullset as value range. Indeed, in the new rewritten function I tried to better handle the maximum backedge taken count computation when MAX/MIN expression are used to handle the cases where no entry guard is found. Some test have been modified in order to check the new value correctly (I manually check them and reasoning on possible overflow the new values seem correct). I finally added a new test case related to the multiplication by -1 issue on GT comparisons. llvm-svn: 194116
2013-11-06 10:08:26 +08:00
; CHECK: Loop %loop: max backedge-taken count is -2
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @even_startx(i4 %n, i4 %x) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_startx_step2
Rewrite SCEV's backedge taken count computation. Patch by Michele Scandale! Rewrite of the functions used to compute the backedge taken count of a loop on LT and GT comparisons. I decided to split the handling of LT and GT cases becasue the trick "a > b == -a < -b" in some cases prevents the trip count computation due to the multiplication by -1 on the two operands of the comparison. This issue comes from the conservative computation of value range of SCEVs: taking the negative SCEV of an expression that have a small positive range (e.g. [0,31]), we would have a SCEV with a fullset as value range. Indeed, in the new rewritten function I tried to better handle the maximum backedge taken count computation when MAX/MIN expression are used to handle the cases where no entry guard is found. Some test have been modified in order to check the new value correctly (I manually check them and reasoning on possible overflow the new values seem correct). I finally added a new test case related to the multiplication by -1 issue on GT comparisons. llvm-svn: 194116
2013-11-06 10:08:26 +08:00
; CHECK: Loop %loop: backedge-taken count is ((-1 + (-1 * %x) + ((2 + %x) smax (2 * %n))) /u 2)
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
; CHECK: Loop %loop: max backedge-taken count is 7
define void @even_startx_step2(i4 %n, i4 %x) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw
; CHECK: Loop %loop: backedge-taken count is (-1 + (2 * %n))
; CHECK: Loop %loop: max backedge-taken count is 5
define void @even_nsw(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw_step2
; CHECK: Loop %loop: backedge-taken count is ((-1 + (2 * %n)) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 2
define void @even_nsw_step2(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 0, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw_start1
; CHECK: Loop %loop: backedge-taken count is (-2 + (2 smax (2 * %n)))
; CHECK: Loop %loop: max backedge-taken count is 4
define void @even_nsw_start1(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw_start1_step2
; CHECK: Loop %loop: backedge-taken count is ((-2 + (3 smax (2 * %n))) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 2
define void @even_nsw_start1_step2(i4 %n) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ 1, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw_startx
; CHECK: Loop %loop: backedge-taken count is (-1 + (-1 * %x) + ((1 + %x) smax (2 * %n)))
Rewrite SCEV's backedge taken count computation. Patch by Michele Scandale! Rewrite of the functions used to compute the backedge taken count of a loop on LT and GT comparisons. I decided to split the handling of LT and GT cases becasue the trick "a > b == -a < -b" in some cases prevents the trip count computation due to the multiplication by -1 on the two operands of the comparison. This issue comes from the conservative computation of value range of SCEVs: taking the negative SCEV of an expression that have a small positive range (e.g. [0,31]), we would have a SCEV with a fullset as value range. Indeed, in the new rewritten function I tried to better handle the maximum backedge taken count computation when MAX/MIN expression are used to handle the cases where no entry guard is found. Some test have been modified in order to check the new value correctly (I manually check them and reasoning on possible overflow the new values seem correct). I finally added a new test case related to the multiplication by -1 issue on GT comparisons. llvm-svn: 194116
2013-11-06 10:08:26 +08:00
; CHECK: Loop %loop: max backedge-taken count is -2
Fix the the ceiling-division used in computing the MaxBECount so that it doesn't have trouble with an intermediate add overflowing. Also, be more conservative about the case where the induction variable in an SLT loop exit can step past the RHS of the SLT and overflow in a single step. Make getSignedRange more aggressive, to recover for some common cases which the above fixes pessimized. This addresses rdar://7561161. llvm-svn: 94512
2010-01-26 12:40:18 +08:00
define void @even_nsw_startx(i4 %n, i4 %x) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 1
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}
; CHECK: Determining loop execution counts for: @even_nsw_startx_step2
; CHECK: Loop %loop: backedge-taken count is ((-1 + (-1 * %x) + ((2 + %x) smax (2 * %n))) /u 2)
; CHECK: Loop %loop: max backedge-taken count is 7
define void @even_nsw_startx_step2(i4 %n, i4 %x) {
entry:
%m = shl i4 %n, 1
%s = icmp sgt i4 %m, 0
br i1 %s, label %loop, label %exit
loop:
%i = phi i4 [ %x, %entry ], [ %i.next, %loop ]
%i.next = add nsw i4 %i, 2
%t = icmp slt i4 %i.next, %m
br i1 %t, label %loop, label %exit
exit:
ret void
}