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/sext-to-zext.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

46 lines
2.3 KiB
LLVM
Raw Normal View History

[tests] Autogen a few tests for ease of update
2021-02-12 08:51:12 +08: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-17 02:09:47 +08:00
; RUN: opt -analyze -enable-new-pm=0 -scalar-evolution < %s | FileCheck %s
; RUN: opt -disable-output "-passes=print<scalar-evolution>" < %s 2>&1 | FileCheck %s
[SCEV] Be less eager about demoting zexts to sexts After r262438 we can have provably positive NSW SCEV expressions whose zero extensions cannot be simplified (since r262438 makes SCEV better at computing constant ranges). This means demoting sexts of positive add recurrences eagerly can result in an unsimplified zero extension where we could have had a simplified sign extension. This change fixes the issue by teaching SCEV to demote sext of a positive SCEV expression to a zext only if the sext could not be simplified. llvm-svn: 262638
2016-03-04 02:31:23 +08:00
define void @f(i1 %c) {
[tests] Autogen a few tests for ease of update
2021-02-12 08:51:12 +08:00
; CHECK-LABEL: 'f'
; CHECK-NEXT: Classifying expressions for: @f
; CHECK-NEXT: %start = select i1 %c, i32 100, i32 0
[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-20 00:27:46 +08:00
; CHECK-NEXT: --> %start U: [0,101) S: [0,101)
[tests] Autogen a few tests for ease of update
2021-02-12 08:51:12 +08:00
; CHECK-NEXT: %step = select i1 %c, i32 -1, i32 1
; CHECK-NEXT: --> %step U: [1,0) S: [-2,2)
; CHECK-NEXT: %iv = phi i32 [ %start, %entry ], [ %iv.dec, %loop ]
; CHECK-NEXT: --> {%start,+,%step}<nsw><%loop> U: [0,101) S: [0,101) Exits: ((99 * %step)<nsw> + %start) LoopDispositions: { %loop: Computable }
; CHECK-NEXT: %iv.tc = phi i32 [ 0, %entry ], [ %iv.tc.inc, %loop ]
; CHECK-NEXT: --> {0,+,1}<%loop> U: [0,100) S: [0,100) Exits: 99 LoopDispositions: { %loop: Computable }
; CHECK-NEXT: %iv.tc.inc = add i32 %iv.tc, 1
; CHECK-NEXT: --> {1,+,1}<%loop> U: [1,101) S: [1,101) Exits: 100 LoopDispositions: { %loop: Computable }
; CHECK-NEXT: %iv.dec = add nsw i32 %iv, %step
[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-20 00:27:46 +08:00
; CHECK-NEXT: --> {(%step + %start),+,%step}<nw><%loop> U: [-200,201) S: [-200,201) Exits: ((100 * %step)<nsw> + %start) LoopDispositions: { %loop: Computable }
[tests] Autogen a few tests for ease of update
2021-02-12 08:51:12 +08:00
; CHECK-NEXT: %iv.sext = sext i32 %iv to i64
[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-20 00:27:46 +08:00
; CHECK-NEXT: --> {(zext i32 %start to i64),+,(sext i32 %step to i64)}<nsw><%loop> U: [0,101) S: [0,101) Exits: ((zext i32 %start to i64) + (99 * (sext i32 %step to i64))<nsw>) LoopDispositions: { %loop: Computable }
[tests] Autogen a few tests for ease of update
2021-02-12 08:51:12 +08:00
; CHECK-NEXT: Determining loop execution counts for: @f
; CHECK-NEXT: Loop %loop: backedge-taken count is 99
; CHECK-NEXT: Loop %loop: max backedge-taken count is 99
; CHECK-NEXT: Loop %loop: Predicated backedge-taken count is 99
; CHECK-NEXT: Predicates:
; CHECK: Loop %loop: Trip multiple is 100
;
[SCEV] Be less eager about demoting zexts to sexts After r262438 we can have provably positive NSW SCEV expressions whose zero extensions cannot be simplified (since r262438 makes SCEV better at computing constant ranges). This means demoting sexts of positive add recurrences eagerly can result in an unsimplified zero extension where we could have had a simplified sign extension. This change fixes the issue by teaching SCEV to demote sext of a positive SCEV expression to a zext only if the sext could not be simplified. llvm-svn: 262638
2016-03-04 02:31:23 +08:00
entry:
%start = select i1 %c, i32 100, i32 0
%step = select i1 %c, i32 -1, i32 1
br label %loop
loop:
%iv = phi i32 [ %start, %entry ], [ %iv.dec, %loop ]
%iv.tc = phi i32 [ 0, %entry ], [ %iv.tc.inc, %loop ]
%iv.tc.inc = add i32 %iv.tc, 1
%iv.dec = add nsw i32 %iv, %step
%iv.sext = sext i32 %iv to i64
%be = icmp ne i32 %iv.tc.inc, 100
br i1 %be, label %loop, label %leave
leave:
ret void
}