maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/InstSimplify/cast-unsigned-icmp-cmp-0.ll

189 lines
5.9 KiB
LLVM
Raw Normal View History

[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
[InstSimplify] [NFC] cast-unsigned-icmp-cmp-0.ll - don't run instcombine As disscussed in post-commit review of D44421, there is simply no reason to run instcombine on this testcase. llvm-svn: 327541
2018-03-15 01:59:12 +08:00
; RUN: opt < %s -instsimplify -S | FileCheck %s
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
; This is related to https://bugs.llvm.org/show_bug.cgi?id=36682
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; All of these can be simplified to a constant true or false value.
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
; * slt i32 %b, 0 -> false
; * sgt i32 %b, -1 -> true
define i1 @i32_cast_cmp_slt_int_0_uitofp_float(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_float(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 false
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to float
%b = bitcast float %f to i32
%cmp = icmp slt i32 %b, 0
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_slt_int_0_uitofp_float_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_float_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x float>
%b = bitcast <2 x float> %f to <2 x i32>
%cmp = icmp slt <2 x i32> %b, <i32 0, i32 0>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_slt_int_0_uitofp_float_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_float_vec_undef(
[PatternMatch] allow undef elements when matching a vector zero This is the last step in getting constant pattern matchers to allow undef elements in constant vectors. I'm adding a dedicated m_ZeroInt() function and building m_Zero() from that. In most cases, calling code can be updated to use m_ZeroInt() directly when there's no need to match pointers, but I'm leaving that efficiency optimization as a follow-up step because it's not always clear when that's ok. There are just enough icmp folds in InstSimplify that can be used for integer or pointer types, that we probably still want a generic m_Zero() for those cases. Otherwise, we could eliminate it (and possibly add a m_NullPtr() as an alias for isa<ConstantPointerNull>()). We're conservatively returning a full zero vector (zeroinitializer) in InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify), but I'm not sure if that's actually necessary in all cases. We may be able to propagate an undef lane instead. One test where this happens is marked with 'TODO'. llvm-svn: 330550
2018-04-23 01:07:44 +08:00
; CHECK-NEXT: ret <3 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x float>
%b = bitcast <3 x float> %f to <3 x i32>
%cmp = icmp slt <3 x i32> %b, <i32 0, i32 undef, i32 0>
ret <3 x i1> %cmp
}
define i1 @i32_cast_cmp_sgt_int_m1_uitofp_float(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_float(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 true
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to float
%b = bitcast float %f to i32
%cmp = icmp sgt i32 %b, -1
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_float_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_float_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> <i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x float>
%b = bitcast <2 x float> %f to <2 x i32>
%cmp = icmp sgt <2 x i32> %b, <i32 -1, i32 -1>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_float_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_float_vec_undef(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <3 x i1> <i1 true, i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x float>
%b = bitcast <3 x float> %f to <3 x i32>
%cmp = icmp sgt <3 x i32> %b, <i32 -1, i32 undef, i32 -1>
ret <3 x i1> %cmp
}
define i1 @i32_cast_cmp_slt_int_0_uitofp_double(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_double(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 false
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to double
%b = bitcast double %f to i64
%cmp = icmp slt i64 %b, 0
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_slt_int_0_uitofp_double_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_double_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x double>
%b = bitcast <2 x double> %f to <2 x i64>
%cmp = icmp slt <2 x i64> %b, <i64 0, i64 0>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_slt_int_0_uitofp_double_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_double_vec_undef(
[PatternMatch] allow undef elements when matching a vector zero This is the last step in getting constant pattern matchers to allow undef elements in constant vectors. I'm adding a dedicated m_ZeroInt() function and building m_Zero() from that. In most cases, calling code can be updated to use m_ZeroInt() directly when there's no need to match pointers, but I'm leaving that efficiency optimization as a follow-up step because it's not always clear when that's ok. There are just enough icmp folds in InstSimplify that can be used for integer or pointer types, that we probably still want a generic m_Zero() for those cases. Otherwise, we could eliminate it (and possibly add a m_NullPtr() as an alias for isa<ConstantPointerNull>()). We're conservatively returning a full zero vector (zeroinitializer) in InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify), but I'm not sure if that's actually necessary in all cases. We may be able to propagate an undef lane instead. One test where this happens is marked with 'TODO'. llvm-svn: 330550
2018-04-23 01:07:44 +08:00
; CHECK-NEXT: ret <3 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x double>
%b = bitcast <3 x double> %f to <3 x i64>
%cmp = icmp slt <3 x i64> %b, <i64 0, i64 undef, i64 0>
ret <3 x i1> %cmp
}
define i1 @i32_cast_cmp_sgt_int_m1_uitofp_double(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_double(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 true
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to double
%b = bitcast double %f to i64
%cmp = icmp sgt i64 %b, -1
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_double_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_double_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> <i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x double>
%b = bitcast <2 x double> %f to <2 x i64>
%cmp = icmp sgt <2 x i64> %b, <i64 -1, i64 -1>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_double_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_double_vec_undef(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <3 x i1> <i1 true, i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x double>
%b = bitcast <3 x double> %f to <3 x i64>
%cmp = icmp sgt <3 x i64> %b, <i64 -1, i64 undef, i64 -1>
ret <3 x i1> %cmp
}
define i1 @i32_cast_cmp_slt_int_0_uitofp_half(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_half(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 false
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to half
%b = bitcast half %f to i16
%cmp = icmp slt i16 %b, 0
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_slt_int_0_uitofp_half_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_half_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x half>
%b = bitcast <2 x half> %f to <2 x i16>
%cmp = icmp slt <2 x i16> %b, <i16 0, i16 0>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_slt_int_0_uitofp_half_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_slt_int_0_uitofp_half_vec_undef(
[PatternMatch] allow undef elements when matching a vector zero This is the last step in getting constant pattern matchers to allow undef elements in constant vectors. I'm adding a dedicated m_ZeroInt() function and building m_Zero() from that. In most cases, calling code can be updated to use m_ZeroInt() directly when there's no need to match pointers, but I'm leaving that efficiency optimization as a follow-up step because it's not always clear when that's ok. There are just enough icmp folds in InstSimplify that can be used for integer or pointer types, that we probably still want a generic m_Zero() for those cases. Otherwise, we could eliminate it (and possibly add a m_NullPtr() as an alias for isa<ConstantPointerNull>()). We're conservatively returning a full zero vector (zeroinitializer) in InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify), but I'm not sure if that's actually necessary in all cases. We may be able to propagate an undef lane instead. One test where this happens is marked with 'TODO'. llvm-svn: 330550
2018-04-23 01:07:44 +08:00
; CHECK-NEXT: ret <3 x i1> zeroinitializer
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x half>
%b = bitcast <3 x half> %f to <3 x i16>
%cmp = icmp slt <3 x i16> %b, <i16 0, i16 undef, i16 0>
ret <3 x i1> %cmp
}
define i1 @i32_cast_cmp_sgt_int_m1_uitofp_half(i32 %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_half(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret i1 true
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp i32 %i to half
%b = bitcast half %f to i16
%cmp = icmp sgt i16 %b, -1
ret i1 %cmp
}
define <2 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_half_vec(<2 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_half_vec(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <2 x i1> <i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <2 x i32> %i to <2 x half>
%b = bitcast <2 x half> %f to <2 x i16>
%cmp = icmp sgt <2 x i16> %b, <i16 -1, i16 -1>
ret <2 x i1> %cmp
}
define <3 x i1> @i32_cast_cmp_sgt_int_m1_uitofp_half_vec_undef(<3 x i32> %i) {
; CHECK-LABEL: @i32_cast_cmp_sgt_int_m1_uitofp_half_vec_undef(
[InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682) This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
2018-03-16 00:17:46 +08:00
; CHECK-NEXT: ret <3 x i1> <i1 true, i1 true, i1 true>
[InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
2018-03-15 01:31:08 +08:00
;
%f = uitofp <3 x i32> %i to <3 x half>
%b = bitcast <3 x half> %f to <3 x i16>
%cmp = icmp sgt <3 x i16> %b, <i16 -1, i16 undef, i16 -1>
ret <3 x i1> %cmp
}