RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:32:44 +01:00
Code Issues Projects Releases Wiki Activity
bedf13b1a7
llvm-mirror/test/Analysis/ScalarEvolution/max-be-count-not-constant.ll

44 lines
2.0 KiB
LLVM
Raw Normal View History

[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; NOTE: Assertions have been autogenerated by utils/update_analyze_test_checks.py
[SCEV] Fix ScalarEvolution tests under NPM Many tests use opt's -analyze feature, which does not translate well to NPM and has better alternatives. The alternative here is to explicitly add a pass that calls ScalarEvolution::print(). The legacy pass manager RUNs aren't changing, but they are now pinned to the legacy pass manager. For each legacy pass manager RUN, I added a corresponding NPM RUN using the 'print<scalar-evolution>' pass. For compatibility with update_analyze_test_checks.py and existing test CHECKs, 'print<scalar-evolution>' now prints what -analyze prints per function. This was generated by the following Python script and failures were manually fixed up: import sys for i in sys.argv: with open(i, 'r') as f: s = f.read() with open(i, 'w') as f: for l in s.splitlines(): if "RUN:" in l and ' -analyze ' in l and '\\' not in l: f.write(l.replace(' -analyze ', ' -analyze -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -analyze ', ' -disable-output ').replace(' -scalar-evolution ', ' "-passes=print<scalar-evolution>" ').replace(" | ", " 2>&1 | ")) f.write('\n') else: f.write(l) There are a couple failures still in ScalarEvolution under NPM, but those are due to other unrelated naming conflicts. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D83798
2020-07-16 20:09:47 +02:00
; RUN: opt < %s -analyze -enable-new-pm=0 -scalar-evolution | FileCheck %s
; RUN: opt < %s -disable-output "-passes=print<scalar-evolution>" 2>&1 | FileCheck %s
[SCEV] Fix an assertion failure in the max backedge taken count Max backedge taken count is always expected to be a constant; and this is usually true by construction -- it is a SCEV expression with constant inputs. However, if the max backedge expression ends up being computed to be a udiv with a constant zero denominator[0], SCEV does not fold the result to a constant since there is no constant it can fold it to (SCEV has no representation for "infinity" or "undef"). However, in computeMaxBECountForLT we already know the denominator is positive, and thus at least 1; and we can use this fact to avoid dividing by zero. [0]: We can end up with a constant zero denominator if the signed range of the stride is more precise than the unsigned range. llvm-svn: 316615
2017-10-25 23:41:00 +02:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Previously in this case the max backedge count would be computed as 1/0, which
; is correct but undesirable. It would also not fold as a constant, tripping
; asserts in SCEV.
define void @pluto(i32 %arg) {
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-LABEL: 'pluto'
; CHECK-NEXT: Classifying expressions for: @pluto
; CHECK-NEXT: %tmp = ashr i32 %arg, 31
[SCEV] Use both known bits and sign bits when computing range of SCEV unknowns When computing a range for a SCEVUnknown, today we use computeKnownBits for unsigned ranges, and computeNumSignBots for signed ranges. This means we miss opportunities to improve range results. One common missed pattern is that we have a signed range of a value which CKB can determine is positive, but CNSB doesn't convey that information. The current range includes the negative part, and is thus double the size. Per the removed comment, the original concern which delayed using both (after some code merging years back) was a compile time concern. CTMark results (provided by Nikita, thanks!) showed a geomean impact of about 0.1%. This doesn't seem large enough to avoid higher quality results. Differential Revision: https://reviews.llvm.org/D96534
2021-02-19 17:27:46 +01:00
; CHECK-NEXT: --> %tmp U: [-1,1) S: [-1,1)
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-NEXT: %tmp1 = add nsw i32 %tmp, 2
[SCEV] Use both known bits and sign bits when computing range of SCEV unknowns When computing a range for a SCEVUnknown, today we use computeKnownBits for unsigned ranges, and computeNumSignBots for signed ranges. This means we miss opportunities to improve range results. One common missed pattern is that we have a signed range of a value which CKB can determine is positive, but CNSB doesn't convey that information. The current range includes the negative part, and is thus double the size. Per the removed comment, the original concern which delayed using both (after some code merging years back) was a compile time concern. CTMark results (provided by Nikita, thanks!) showed a geomean impact of about 0.1%. This doesn't seem large enough to avoid higher quality results. Differential Revision: https://reviews.llvm.org/D96534
2021-02-19 17:27:46 +01:00
; CHECK-NEXT: --> (2 + %tmp)<nsw> U: [1,3) S: [1,3)
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-NEXT: %tmp3 = phi i32 [ 0, %bb ], [ %tmp4, %bb2 ]
[SCEV] Use both known bits and sign bits when computing range of SCEV unknowns When computing a range for a SCEVUnknown, today we use computeKnownBits for unsigned ranges, and computeNumSignBots for signed ranges. This means we miss opportunities to improve range results. One common missed pattern is that we have a signed range of a value which CKB can determine is positive, but CNSB doesn't convey that information. The current range includes the negative part, and is thus double the size. Per the removed comment, the original concern which delayed using both (after some code merging years back) was a compile time concern. CTMark results (provided by Nikita, thanks!) showed a geomean impact of about 0.1%. This doesn't seem large enough to avoid higher quality results. Differential Revision: https://reviews.llvm.org/D96534
2021-02-19 17:27:46 +01:00
; CHECK-NEXT: --> {0,+,(2 + %tmp)<nsw>}<nuw><nsw><%bb2> U: [0,3) S: [0,3) Exits: ((2 + %tmp)<nsw> * (1 /u (2 + %tmp)<nsw>)) LoopDispositions: { %bb2: Computable }
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-NEXT: %tmp4 = add nuw nsw i32 %tmp1, %tmp3
[SCEV] Use both known bits and sign bits when computing range of SCEV unknowns When computing a range for a SCEVUnknown, today we use computeKnownBits for unsigned ranges, and computeNumSignBots for signed ranges. This means we miss opportunities to improve range results. One common missed pattern is that we have a signed range of a value which CKB can determine is positive, but CNSB doesn't convey that information. The current range includes the negative part, and is thus double the size. Per the removed comment, the original concern which delayed using both (after some code merging years back) was a compile time concern. CTMark results (provided by Nikita, thanks!) showed a geomean impact of about 0.1%. This doesn't seem large enough to avoid higher quality results. Differential Revision: https://reviews.llvm.org/D96534
2021-02-19 17:27:46 +01:00
; CHECK-NEXT: --> {(2 + %tmp)<nsw>,+,(2 + %tmp)<nsw>}<nuw><nsw><%bb2> U: [1,5) S: [1,5) Exits: (2 + ((2 + %tmp)<nsw> * (1 /u (2 + %tmp)<nsw>)) + %tmp) LoopDispositions: { %bb2: Computable }
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-NEXT: Determining loop execution counts for: @pluto
; CHECK-NEXT: Loop %bb2: backedge-taken count is (1 /u (2 + %tmp)<nsw>)
[SCEV] Use both known bits and sign bits when computing range of SCEV unknowns When computing a range for a SCEVUnknown, today we use computeKnownBits for unsigned ranges, and computeNumSignBots for signed ranges. This means we miss opportunities to improve range results. One common missed pattern is that we have a signed range of a value which CKB can determine is positive, but CNSB doesn't convey that information. The current range includes the negative part, and is thus double the size. Per the removed comment, the original concern which delayed using both (after some code merging years back) was a compile time concern. CTMark results (provided by Nikita, thanks!) showed a geomean impact of about 0.1%. This doesn't seem large enough to avoid higher quality results. Differential Revision: https://reviews.llvm.org/D96534
2021-02-19 17:27:46 +01:00
; CHECK-NEXT: Loop %bb2: max backedge-taken count is 1
[tests] Autogen a few tests for ease of update
2021-02-12 01:51:12 +01:00
; CHECK-NEXT: Loop %bb2: Predicated backedge-taken count is (1 /u (2 + %tmp)<nsw>)
; CHECK-NEXT: Predicates:
; CHECK: Loop %bb2: Trip multiple is 1
;
[SCEV] Fix an assertion failure in the max backedge taken count Max backedge taken count is always expected to be a constant; and this is usually true by construction -- it is a SCEV expression with constant inputs. However, if the max backedge expression ends up being computed to be a udiv with a constant zero denominator[0], SCEV does not fold the result to a constant since there is no constant it can fold it to (SCEV has no representation for "infinity" or "undef"). However, in computeMaxBECountForLT we already know the denominator is positive, and thus at least 1; and we can use this fact to avoid dividing by zero. [0]: We can end up with a constant zero denominator if the signed range of the stride is more precise than the unsigned range. llvm-svn: 316615
2017-10-25 23:41:00 +02:00
bb:
%tmp = ashr i32 %arg, 31
%tmp1 = add nsw i32 %tmp, 2
br label %bb2
bb2: ; preds = %bb2, %bb
%tmp3 = phi i32 [ 0, %bb ], [ %tmp4, %bb2 ]
%tmp4 = add nuw nsw i32 %tmp1, %tmp3
%tmp5 = icmp ult i32 %tmp4, 2
br i1 %tmp5, label %bb2, label %bb6
bb6: ; preds = %bb2
ret void
}
Reference in New Issue Copy Permalink