[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +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 -S -analyze -enable-new-pm=0 -scalar-evolution < %s | FileCheck %s
|
|
|
|
; RUN: opt -S -disable-output "-passes=print<scalar-evolution>" < %s 2>&1 | FileCheck %s
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
|
|
|
|
; The obvious case.
|
|
|
|
define i32 @udiv_biggerLshr(i32 %val) nounwind {
|
|
|
|
; CHECK-LABEL: 'udiv_biggerLshr'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @udiv_biggerLshr
|
|
|
|
; CHECK-NEXT: %tmp1 = udiv i32 %val, 64
|
|
|
|
; CHECK-NEXT: --> (%val /u 64) U: [0,67108864) S: [0,67108864)
|
|
|
|
; CHECK-NEXT: %tmp2 = mul i32 %tmp1, 16
|
2018-07-14 07:58:46 +08:00
|
|
|
; CHECK-NEXT: --> (16 * (%val /u 64))<nuw><nsw> U: [0,1073741809) S: [0,1073741809)
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @udiv_biggerLshr
|
|
|
|
;
|
|
|
|
%tmp1 = udiv i32 %val, 64
|
|
|
|
%tmp2 = mul i32 %tmp1, 16
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @udiv_biggerShl(i32 %val) nounwind {
|
|
|
|
; CHECK-LABEL: 'udiv_biggerShl'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @udiv_biggerShl
|
|
|
|
; CHECK-NEXT: %tmp1 = udiv i32 %val, 16
|
|
|
|
; CHECK-NEXT: --> (%val /u 16) U: [0,268435456) S: [0,268435456)
|
|
|
|
; CHECK-NEXT: %tmp2 = mul i32 %tmp1, 64
|
|
|
|
; CHECK-NEXT: --> (64 * (%val /u 16)) U: [0,-63) S: [-2147483648,2147483585)
|
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @udiv_biggerShl
|
|
|
|
;
|
|
|
|
%tmp1 = udiv i32 %val, 16
|
|
|
|
%tmp2 = mul i32 %tmp1, 64
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
; Or, it could have been transformed to shifts
|
|
|
|
|
|
|
|
define i32 @shifty_biggerLshr(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'shifty_biggerLshr'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @shifty_biggerLshr
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr i32 %val, 6
|
|
|
|
; CHECK-NEXT: --> (%val /u 64) U: [0,67108864) S: [0,67108864)
|
|
|
|
; CHECK-NEXT: %tmp2 = shl i32 %tmp1, 4
|
2018-07-14 07:58:46 +08:00
|
|
|
; CHECK-NEXT: --> (16 * (%val /u 64))<nuw><nsw> U: [0,1073741809) S: [0,1073741809)
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @shifty_biggerLshr
|
|
|
|
;
|
|
|
|
%tmp1 = lshr i32 %val, 6
|
|
|
|
%tmp2 = shl i32 %tmp1, 4
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @shifty_biggerLshr_lshrexact(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'shifty_biggerLshr_lshrexact'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @shifty_biggerLshr_lshrexact
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr exact i32 %val, 6
|
|
|
|
; CHECK-NEXT: --> (%val /u 64) U: [0,67108864) S: [0,67108864)
|
|
|
|
; CHECK-NEXT: %tmp2 = shl i32 %tmp1, 4
|
2018-07-14 07:58:46 +08:00
|
|
|
; CHECK-NEXT: --> (16 * (%val /u 64))<nuw><nsw> U: [0,1073741809) S: [0,1073741809)
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @shifty_biggerLshr_lshrexact
|
|
|
|
;
|
|
|
|
%tmp1 = lshr exact i32 %val, 6
|
|
|
|
%tmp2 = shl i32 %tmp1, 4
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @shifty_biggerShr(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'shifty_biggerShr'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @shifty_biggerShr
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr i32 %val, 4
|
|
|
|
; CHECK-NEXT: --> (%val /u 16) U: [0,268435456) S: [0,268435456)
|
|
|
|
; CHECK-NEXT: %tmp2 = shl i32 %tmp1, 6
|
|
|
|
; CHECK-NEXT: --> (64 * (%val /u 16)) U: [0,-63) S: [-2147483648,2147483585)
|
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @shifty_biggerShr
|
|
|
|
;
|
|
|
|
%tmp1 = lshr i32 %val, 4
|
|
|
|
%tmp2 = shl i32 %tmp1, 6
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @shifty_biggerShr_lshrexact(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'shifty_biggerShr_lshrexact'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @shifty_biggerShr_lshrexact
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr exact i32 %val, 4
|
|
|
|
; CHECK-NEXT: --> (%val /u 16) U: [0,268435456) S: [0,268435456)
|
|
|
|
; CHECK-NEXT: %tmp2 = shl i32 %tmp1, 6
|
|
|
|
; CHECK-NEXT: --> (64 * (%val /u 16)) U: [0,-63) S: [-2147483648,2147483585)
|
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @shifty_biggerShr_lshrexact
|
|
|
|
;
|
|
|
|
%tmp1 = lshr exact i32 %val, 4
|
|
|
|
%tmp2 = shl i32 %tmp1, 6
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
; Or, further folded into mask variant.
|
|
|
|
|
|
|
|
define i32 @masky_biggerLshr(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'masky_biggerLshr'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @masky_biggerLshr
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr i32 %val, 2
|
|
|
|
; CHECK-NEXT: --> (%val /u 4) U: [0,1073741824) S: [0,1073741824)
|
|
|
|
; CHECK-NEXT: %tmp2 = and i32 %tmp1, -16
|
2018-07-14 07:58:46 +08:00
|
|
|
; CHECK-NEXT: --> (16 * (%val /u 64))<nuw><nsw> U: [0,1073741809) S: [0,1073741809)
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @masky_biggerLshr
|
|
|
|
;
|
|
|
|
%tmp1 = lshr i32 %val, 2
|
|
|
|
%tmp2 = and i32 %tmp1, -16
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @masky_biggerLshr_lshrexact(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'masky_biggerLshr_lshrexact'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @masky_biggerLshr_lshrexact
|
|
|
|
; CHECK-NEXT: %tmp1 = lshr exact i32 %val, 2
|
|
|
|
; CHECK-NEXT: --> (%val /u 4) U: [0,1073741824) S: [0,1073741824)
|
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @masky_biggerLshr_lshrexact
|
|
|
|
;
|
|
|
|
%tmp1 = lshr exact i32 %val, 2
|
|
|
|
ret i32 %tmp1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @masky_biggerShr(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'masky_biggerShr'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @masky_biggerShr
|
|
|
|
; CHECK-NEXT: %tmp1 = shl i32 %val, 2
|
|
|
|
; CHECK-NEXT: --> (4 * %val) U: [0,-3) S: [-2147483648,2147483645)
|
|
|
|
; CHECK-NEXT: %tmp2 = and i32 %tmp1, -64
|
2019-06-15 17:15:52 +08:00
|
|
|
; CHECK-NEXT: --> (64 * (zext i26 (trunc i32 (%val /u 16) to i26) to i32))<nuw> U: [0,-63) S: [-2147483648,2147483585)
|
[NFC][SCEV] Add tests related to bit masking (PR37793)
Summary:
Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287
We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc
But it is currently restricted by rL155136 / rL155362, which says:
```
// This is a constant shift of a constant shift. Be careful about hiding
// shl instructions behind bit masks. They are used to represent multiplies
// by a constant, and it is important that simple arithmetic expressions
// are still recognizable by scalar evolution.
//
// The transforms applied to shl are very similar to the transforms applied
// to mul by constant. We can be more aggressive about optimizing right
// shifts.
//
// Combinations of right and left shifts will still be optimized in
// DAGCombine where scalar evolution no longer applies.
```
I think these tests show that for *constants*, SCEV has no issues with that canonicalization.
Reviewers: mkazantsev, spatel, efriedma, sanjoy
Reviewed By: mkazantsev
Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia
Differential Revision: https://reviews.llvm.org/D48229
llvm-svn: 335101
2018-06-20 15:54:11 +08:00
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @masky_biggerShr
|
|
|
|
;
|
|
|
|
%tmp1 = shl i32 %val, 2
|
|
|
|
%tmp2 = and i32 %tmp1, -64
|
|
|
|
ret i32 %tmp2
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @masky_biggerShr_lshrexact(i32 %val) {
|
|
|
|
; CHECK-LABEL: 'masky_biggerShr_lshrexact'
|
|
|
|
; CHECK-NEXT: Classifying expressions for: @masky_biggerShr_lshrexact
|
|
|
|
; CHECK-NEXT: %tmp1 = shl i32 %val, 2
|
|
|
|
; CHECK-NEXT: --> (4 * %val) U: [0,-3) S: [-2147483648,2147483645)
|
|
|
|
; CHECK-NEXT: Determining loop execution counts for: @masky_biggerShr_lshrexact
|
|
|
|
;
|
|
|
|
%tmp1 = shl i32 %val, 2
|
|
|
|
ret i32 %tmp1
|
|
|
|
}
|