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-count13.ll

82 lines
2.5 KiB
LLVM
Raw Normal View History

[SCEV] Fix incorrect trip count computation The way we elide max expressions when computing trip counts is incorrect -- it breaks cases like this: ``` static int wrapping_add(int a, int b) { return (int)((unsigned)a + (unsigned)b); } void test() { volatile int end_buf = 2147483548; // INT_MIN - 100 int end = end_buf; unsigned counter = 0; for (int start = wrapping_add(end, 200); start < end; start++) counter++; print(counter); } ``` Note: the `NoWrap` variable that was being tested has little to do with the values flowing into the max expression; it is a property of the induction variable. test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test functionality I'm reverting in this change, so I've deleted the test fully. llvm-svn: 273079
2016-06-18 12:38:31 +08:00
; RUN: opt -S -analyze -scalar-evolution < %s | FileCheck %s
define void @u_0(i8 %rhs) {
; E.g.: %rhs = 255, %start = 99, backedge taken 156 times
entry:
%start = add i8 %rhs, 100
br label %loop
loop:
%iv = phi i8 [ %start, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nuw i8 %iv, 1 ;; Note: this never unsigned-wraps
%iv.cmp = icmp ult i8 %iv, %rhs
br i1 %iv.cmp, label %loop, label %leave
; CHECK-LABEL: Determining loop execution counts for: @u_0
; CHECK-NEXT: Loop %loop: backedge-taken count is (-100 + (-1 * %rhs) + ((100 + %rhs) umax %rhs))
[LoopUnroll] Keep the loop test only on the first iteration of max-or-zero loops When we have a loop with a known upper bound on the number of iterations, and furthermore know that either the number of iterations will be either exactly that upper bound or zero, then we can fully unroll up to that upper bound keeping only the first loop test to check for the zero iteration case. Most of the work here is in plumbing this 'max-or-zero' information from the part of scalar evolution where it's detected through to loop unrolling. I've also gone for the safe default of 'false' everywhere but howManyLessThans which could probably be improved. Differential Revision: https://reviews.llvm.org/D25682 llvm-svn: 284818
2016-10-21 19:08:48 +08:00
; CHECK-NEXT: Loop %loop: max backedge-taken count is -100, actual taken count either this or zero.
[SCEV] Fix incorrect trip count computation The way we elide max expressions when computing trip counts is incorrect -- it breaks cases like this: ``` static int wrapping_add(int a, int b) { return (int)((unsigned)a + (unsigned)b); } void test() { volatile int end_buf = 2147483548; // INT_MIN - 100 int end = end_buf; unsigned counter = 0; for (int start = wrapping_add(end, 200); start < end; start++) counter++; print(counter); } ``` Note: the `NoWrap` variable that was being tested has little to do with the values flowing into the max expression; it is a property of the induction variable. test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test functionality I'm reverting in this change, so I've deleted the test fully. llvm-svn: 273079
2016-06-18 12:38:31 +08:00
leave:
ret void
}
define void @u_1(i8 %start) {
entry:
; E.g.: %start = 99, %rhs = 255, backedge taken 156 times
%rhs = add i8 %start, -100
br label %loop
loop:
%iv = phi i8 [ %start, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nuw i8 %iv, 1 ;; Note: this never unsigned-wraps
%iv.cmp = icmp ult i8 %iv, %rhs
br i1 %iv.cmp, label %loop, label %leave
; CHECK-LABEL: Determining loop execution counts for: @u_1
; CHECK-NEXT: Loop %loop: backedge-taken count is ((-1 * %start) + ((-100 + %start) umax %start))
[LoopUnroll] Keep the loop test only on the first iteration of max-or-zero loops When we have a loop with a known upper bound on the number of iterations, and furthermore know that either the number of iterations will be either exactly that upper bound or zero, then we can fully unroll up to that upper bound keeping only the first loop test to check for the zero iteration case. Most of the work here is in plumbing this 'max-or-zero' information from the part of scalar evolution where it's detected through to loop unrolling. I've also gone for the safe default of 'false' everywhere but howManyLessThans which could probably be improved. Differential Revision: https://reviews.llvm.org/D25682 llvm-svn: 284818
2016-10-21 19:08:48 +08:00
; CHECK-NEXT: Loop %loop: max backedge-taken count is -100, actual taken count either this or zero.
[SCEV] Fix incorrect trip count computation The way we elide max expressions when computing trip counts is incorrect -- it breaks cases like this: ``` static int wrapping_add(int a, int b) { return (int)((unsigned)a + (unsigned)b); } void test() { volatile int end_buf = 2147483548; // INT_MIN - 100 int end = end_buf; unsigned counter = 0; for (int start = wrapping_add(end, 200); start < end; start++) counter++; print(counter); } ``` Note: the `NoWrap` variable that was being tested has little to do with the values flowing into the max expression; it is a property of the induction variable. test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test functionality I'm reverting in this change, so I've deleted the test fully. llvm-svn: 273079
2016-06-18 12:38:31 +08:00
leave:
ret void
}
define void @s_0(i8 %rhs) {
entry:
; E.g.: %rhs = 127, %start = -29, backedge taken 156 times
%start = add i8 %rhs, 100
br label %loop
loop:
%iv = phi i8 [ %start, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nsw i8 %iv, 1 ;; Note: this never signed-wraps
%iv.cmp = icmp slt i8 %iv, %rhs
br i1 %iv.cmp, label %loop, label %leave
; CHECK-LABEL: Determining loop execution counts for: @s_0
; CHECK-NEXT: Loop %loop: backedge-taken count is (-100 + (-1 * %rhs) + ((100 + %rhs) smax %rhs))
[LoopUnroll] Keep the loop test only on the first iteration of max-or-zero loops When we have a loop with a known upper bound on the number of iterations, and furthermore know that either the number of iterations will be either exactly that upper bound or zero, then we can fully unroll up to that upper bound keeping only the first loop test to check for the zero iteration case. Most of the work here is in plumbing this 'max-or-zero' information from the part of scalar evolution where it's detected through to loop unrolling. I've also gone for the safe default of 'false' everywhere but howManyLessThans which could probably be improved. Differential Revision: https://reviews.llvm.org/D25682 llvm-svn: 284818
2016-10-21 19:08:48 +08:00
; CHECK-NEXT: Loop %loop: max backedge-taken count is -100, actual taken count either this or zero.
[SCEV] Fix incorrect trip count computation The way we elide max expressions when computing trip counts is incorrect -- it breaks cases like this: ``` static int wrapping_add(int a, int b) { return (int)((unsigned)a + (unsigned)b); } void test() { volatile int end_buf = 2147483548; // INT_MIN - 100 int end = end_buf; unsigned counter = 0; for (int start = wrapping_add(end, 200); start < end; start++) counter++; print(counter); } ``` Note: the `NoWrap` variable that was being tested has little to do with the values flowing into the max expression; it is a property of the induction variable. test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test functionality I'm reverting in this change, so I've deleted the test fully. llvm-svn: 273079
2016-06-18 12:38:31 +08:00
leave:
ret void
}
define void @s_1(i8 %start) {
entry:
; E.g.: start = -29, %rhs = 127, %backedge taken 156 times
%rhs = add i8 %start, -100
br label %loop
loop:
%iv = phi i8 [ %start, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nsw i8 %iv, 1
%iv.cmp = icmp slt i8 %iv, %rhs
br i1 %iv.cmp, label %loop, label %leave
; CHECK-LABEL: Determining loop execution counts for: @s_1
; CHECK-NEXT: Loop %loop: backedge-taken count is ((-1 * %start) + ((-100 + %start) smax %start))
[LoopUnroll] Keep the loop test only on the first iteration of max-or-zero loops When we have a loop with a known upper bound on the number of iterations, and furthermore know that either the number of iterations will be either exactly that upper bound or zero, then we can fully unroll up to that upper bound keeping only the first loop test to check for the zero iteration case. Most of the work here is in plumbing this 'max-or-zero' information from the part of scalar evolution where it's detected through to loop unrolling. I've also gone for the safe default of 'false' everywhere but howManyLessThans which could probably be improved. Differential Revision: https://reviews.llvm.org/D25682 llvm-svn: 284818
2016-10-21 19:08:48 +08:00
; CHECK-NEXT: Loop %loop: max backedge-taken count is -100, actual taken count either this or zero.
[SCEV] Fix incorrect trip count computation The way we elide max expressions when computing trip counts is incorrect -- it breaks cases like this: ``` static int wrapping_add(int a, int b) { return (int)((unsigned)a + (unsigned)b); } void test() { volatile int end_buf = 2147483548; // INT_MIN - 100 int end = end_buf; unsigned counter = 0; for (int start = wrapping_add(end, 200); start < end; start++) counter++; print(counter); } ``` Note: the `NoWrap` variable that was being tested has little to do with the values flowing into the max expression; it is a property of the induction variable. test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test functionality I'm reverting in this change, so I've deleted the test fully. llvm-svn: 273079
2016-06-18 12:38:31 +08:00
leave:
ret void
}