maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/lack-of-signed-truncation-c...

649 lines
18 KiB
LLVM
Raw Normal View History

[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc -mtriple=i686-unknown-linux-gnu < %s | FileCheck %s --check-prefixes=CHECK,X86,NOBMI2,X86-NOBMI2,FALLBACK0,X86-FALLBACK0
; RUN: llc -mtriple=x86_64-unknown-linux-gnu < %s | FileCheck %s --check-prefixes=CHECK,X64,NOBMI2,X64-NOBMI2,FALLBACK0,X64-FALLBACK0
; https://bugs.llvm.org/show_bug.cgi?id=38149
; We are truncating from wider width, and then sign-extending
; back to the original width. Then we inequality-comparing orig and src.
; If they don't match, then we had signed truncation during truncation.
; This can be expressed in a several ways in IR:
; trunc + sext + icmp ne <- not canonical
; shl + ashr + icmp ne
[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern.[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern. llvm-svn: 341188
2018-08-31 16:52:03 +08:00
; add + icmp ult/ule
[NFC][X86][AArch64][DAGCombine] More tests for optimizeSetCCOfSignedTruncationCheck() At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyh llvm-svn: 337400
2018-07-19 00:19:06 +08:00
; add + icmp uge/ugt
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; However only the simplest form (with two shifts) gets lowered best.
; ---------------------------------------------------------------------------- ;
; shl + ashr + icmp ne
; ---------------------------------------------------------------------------- ;
define i1 @shifts_necmp_i16_i8(i16 %x) nounwind {
; X86-LABEL: shifts_necmp_i16_i8:
; X86: # %bb.0:
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpw %ax, %cx
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i16_i8:
; X64: # %bb.0:
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpw %di, %ax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i16 %x, 8 ; 16-8
%tmp1 = ashr exact i16 %tmp0, 8 ; 16-8
%tmp2 = icmp ne i16 %tmp1, %x
ret i1 %tmp2
}
define i1 @shifts_necmp_i32_i16(i32 %x) nounwind {
; X86-LABEL: shifts_necmp_i32_i16:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i32_i16:
; X64: # %bb.0:
; X64-NEXT: movswl %di, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i32 %x, 16 ; 32-16
%tmp1 = ashr exact i32 %tmp0, 16 ; 32-16
%tmp2 = icmp ne i32 %tmp1, %x
ret i1 %tmp2
}
define i1 @shifts_necmp_i32_i8(i32 %x) nounwind {
; X86-LABEL: shifts_necmp_i32_i8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i32_i8:
; X64: # %bb.0:
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i32 %x, 24 ; 32-8
%tmp1 = ashr exact i32 %tmp0, 24 ; 32-8
%tmp2 = icmp ne i32 %tmp1, %x
ret i1 %tmp2
}
define i1 @shifts_necmp_i64_i32(i64 %x) nounwind {
; X86-LABEL: shifts_necmp_i64_i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: sarl $31, %eax
; X86-NEXT: xorl {{[0-9]+}}(%esp), %eax
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i64_i32:
; X64: # %bb.0:
; X64-NEXT: movslq %edi, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i64 %x, 32 ; 64-32
%tmp1 = ashr exact i64 %tmp0, 32 ; 64-32
%tmp2 = icmp ne i64 %tmp1, %x
ret i1 %tmp2
}
define i1 @shifts_necmp_i64_i16(i64 %x) nounwind {
; X86-LABEL: shifts_necmp_i64_i16:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: movl %ecx, %edx
; X86-NEXT: sarl $31, %edx
; X86-NEXT: xorl %eax, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %edx
; X86-NEXT: orl %ecx, %edx
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i64_i16:
; X64: # %bb.0:
; X64-NEXT: movswq %di, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i64 %x, 48 ; 64-16
%tmp1 = ashr exact i64 %tmp0, 48 ; 64-16
%tmp2 = icmp ne i64 %tmp1, %x
ret i1 %tmp2
}
define i1 @shifts_necmp_i64_i8(i64 %x) nounwind {
; X86-LABEL: shifts_necmp_i64_i8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: movl %ecx, %edx
; X86-NEXT: sarl $31, %edx
; X86-NEXT: xorl %eax, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %edx
; X86-NEXT: orl %ecx, %edx
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: shifts_necmp_i64_i8:
; X64: # %bb.0:
; X64-NEXT: movsbq %dil, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = shl i64 %x, 56 ; 64-8
%tmp1 = ashr exact i64 %tmp0, 56 ; 64-8
%tmp2 = icmp ne i64 %tmp1, %x
ret i1 %tmp2
}
; ---------------------------------------------------------------------------- ;
; add + icmp ult
; ---------------------------------------------------------------------------- ;
define i1 @add_ultcmp_i16_i8(i16 %x) nounwind {
; X86-LABEL: add_ultcmp_i16_i8:
; X86: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpw %ax, %cx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i16_i8:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpw %di, %ax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i16 %x, -128 ; ~0U << (8-1)
%tmp1 = icmp ult i16 %tmp0, -256 ; ~0U << 8
ret i1 %tmp1
}
define i1 @add_ultcmp_i32_i16(i32 %x) nounwind {
; X86-LABEL: add_ultcmp_i32_i16:
; X86: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i32_i16:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movswl %di, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i32 %x, -32768 ; ~0U << (16-1)
%tmp1 = icmp ult i32 %tmp0, -65536 ; ~0U << 16
ret i1 %tmp1
}
define i1 @add_ultcmp_i32_i8(i32 %x) nounwind {
; X86-LABEL: add_ultcmp_i32_i8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i32_i8:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i32 %x, -128 ; ~0U << (8-1)
%tmp1 = icmp ult i32 %tmp0, -256 ; ~0U << 8
ret i1 %tmp1
}
define i1 @add_ultcmp_i64_i32(i64 %x) nounwind {
; X86-LABEL: add_ultcmp_i64_i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: sarl $31, %eax
; X86-NEXT: xorl {{[0-9]+}}(%esp), %eax
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i64_i32:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movslq %edi, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i64 %x, -2147483648 ; ~0U << (32-1)
%tmp1 = icmp ult i64 %tmp0, -4294967296 ; ~0U << 32
ret i1 %tmp1
}
define i1 @add_ultcmp_i64_i16(i64 %x) nounwind {
; X86-LABEL: add_ultcmp_i64_i16:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: xorl %ecx, %eax
; X86-NEXT: sarl $31, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: orl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i64_i16:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movswq %di, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i64 %x, -32768 ; ~0U << (16-1)
%tmp1 = icmp ult i64 %tmp0, -65536 ; ~0U << 16
ret i1 %tmp1
}
define i1 @add_ultcmp_i64_i8(i64 %x) nounwind {
; X86-LABEL: add_ultcmp_i64_i8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: xorl %ecx, %eax
; X86-NEXT: sarl $31, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: orl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ultcmp_i64_i8:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movsbq %dil, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i64 %x, -128 ; ~0U << (8-1)
%tmp1 = icmp ult i64 %tmp0, -256 ; ~0U << 8
ret i1 %tmp1
}
[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern.[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern. llvm-svn: 341188
2018-08-31 16:52:03 +08:00
; Slightly more canonical variant
define i1 @add_ulecmp_i16_i8(i16 %x) nounwind {
; X86-LABEL: add_ulecmp_i16_i8:
; X86: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpw %ax, %cx
; X86-NEXT: setne %al
[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern.[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern. llvm-svn: 341188
2018-08-31 16:52:03 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ulecmp_i16_i8:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle inverted pattern Summary: A follow-up for D49266 / rL337166 + D49497 / rL338044. This is still the same pattern to check for the [lack of] signed truncation, but in this case the constants and the predicate are negated. https://rise4fun.com/Alive/BDV https://rise4fun.com/Alive/n7Z Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma, dmgreen Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51532 llvm-svn: 341287
2018-09-02 21:56:22 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpw %di, %ax
; X64-NEXT: setne %al
[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern.[NFC][X86][AArch64] A few more patterns for [lack of] signed truncation check pattern. llvm-svn: 341188
2018-08-31 16:52:03 +08:00
; X64-NEXT: retq
%tmp0 = add i16 %x, -128 ; ~0U << (8-1)
%tmp1 = icmp ule i16 %tmp0, -257 ; ~0U << 8 - 1
ret i1 %tmp1
}
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; ---------------------------------------------------------------------------- ;
; add + icmp uge
; ---------------------------------------------------------------------------- ;
define i1 @add_ugecmp_i16_i8(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_i16_i8:
; X86: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpw %ax, %cx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i16_i8:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpw %di, %ax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i16 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
define i1 @add_ugecmp_i32_i16(i32 %x) nounwind {
; X86-LABEL: add_ugecmp_i32_i16:
; X86: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i32_i16:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movswl %di, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i32 %x, 32768 ; 1U << (16-1)
%tmp1 = icmp uge i32 %tmp0, 65536 ; 1U << 16
ret i1 %tmp1
}
define i1 @add_ugecmp_i32_i8(i32 %x) nounwind {
; X86-LABEL: add_ugecmp_i32_i8:
; X86: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i32_i8:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpl %edi, %eax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i32 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i32 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
define i1 @add_ugecmp_i64_i32(i64 %x) nounwind {
; X86-LABEL: add_ugecmp_i64_i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: sarl $31, %eax
; X86-NEXT: xorl {{[0-9]+}}(%esp), %eax
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: setne %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i64_i32:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movslq %edi, %rax
; X64-NEXT: cmpq %rdi, %rax
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: setne %al
; X64-NEXT: retq
%tmp0 = add i64 %x, 2147483648 ; 1U << (32-1)
%tmp1 = icmp uge i64 %tmp0, 4294967296 ; 1U << 32
ret i1 %tmp1
}
define i1 @add_ugecmp_i64_i16(i64 %x) nounwind {
; X86-LABEL: add_ugecmp_i64_i16:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: movswl %ax, %ecx
; X86-NEXT: xorl %ecx, %eax
; X86-NEXT: sarl $31, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: orl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i64_i16:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movswq %di, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i64 %x, 32768 ; 1U << (16-1)
%tmp1 = icmp uge i64 %tmp0, 65536 ; 1U << 16
ret i1 %tmp1
}
define i1 @add_ugecmp_i64_i8(i64 %x) nounwind {
; X86-LABEL: add_ugecmp_i64_i8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: xorl %ecx, %eax
; X86-NEXT: sarl $31, %ecx
; X86-NEXT: xorl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: orl %eax, %ecx
; X86-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_i64_i8:
; X64: # %bb.0:
[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
2018-07-16 20:44:10 +08:00
; X64-NEXT: movsbq %dil, %rax
; X64-NEXT: cmpq %rdi, %rax
; X64-NEXT: setne %al
[NFC][X86][AArch64] Add tests for the 'check for [no] signed truncation' pattern Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But as it looks from these tests, i think we want to revert at least some cases in DAGCombine. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49247 llvm-svn: 336917
2018-07-13 01:00:11 +08:00
; X64-NEXT: retq
%tmp0 = add i64 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i64 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
[NFC][X86][AArch64][DAGCombine] More tests for optimizeSetCCOfSignedTruncationCheck() At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyh llvm-svn: 337400
2018-07-19 00:19:06 +08:00
; Slightly more canonical variant
define i1 @add_ugtcmp_i16_i8(i16 %x) nounwind {
; X86-LABEL: add_ugtcmp_i16_i8:
; X86: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle ule,ugt CondCodes. Summary: A follow-up for D49266 / rL337166. At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyhZZ We won't get to these cases with I1 being -1, as that will be constant-folded to true or false. I'm also not sure we actually hit the 'ule' case, but i think the worst think that could happen is that being dead code. Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49497 llvm-svn: 338044
2018-07-27 01:34:28 +08:00
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movsbl %al, %ecx
; X86-NEXT: cmpw %ax, %cx
; X86-NEXT: setne %al
[NFC][X86][AArch64][DAGCombine] More tests for optimizeSetCCOfSignedTruncationCheck() At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyh llvm-svn: 337400
2018-07-19 00:19:06 +08:00
; X86-NEXT: retl
;
; X64-LABEL: add_ugtcmp_i16_i8:
; X64: # %bb.0:
[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle ule,ugt CondCodes. Summary: A follow-up for D49266 / rL337166. At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyhZZ We won't get to these cases with I1 being -1, as that will be constant-folded to true or false. I'm also not sure we actually hit the 'ule' case, but i think the worst think that could happen is that being dead code. Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49497 llvm-svn: 338044
2018-07-27 01:34:28 +08:00
; X64-NEXT: movsbl %dil, %eax
; X64-NEXT: cmpw %di, %ax
; X64-NEXT: setne %al
[NFC][X86][AArch64][DAGCombine] More tests for optimizeSetCCOfSignedTruncationCheck() At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyh llvm-svn: 337400
2018-07-19 00:19:06 +08:00
; X64-NEXT: retq
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp ugt i16 %tmp0, 255 ; (1U << 8) - 1
ret i1 %tmp1
}
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
; Negative tests
; ---------------------------------------------------------------------------- ;
; Adding not a constant
define i1 @add_ugecmp_bad_i16_i8_add(i16 %x, i16 %y) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i8_add:
; X86: # %bb.0:
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: addw {{[0-9]+}}(%esp), %ax
; X86-NEXT: movzwl %ax, %eax
; X86-NEXT: cmpl $255, %eax
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i8_add:
; X64: # %bb.0:
; X64-NEXT: addl %esi, %edi
; X64-NEXT: movzwl %di, %eax
; X64-NEXT: cmpl $255, %eax
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, %y
%tmp1 = icmp uge i16 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
; Comparing not with a constant
define i1 @add_ugecmp_bad_i16_i8_cmp(i16 %x, i16 %y) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i8_cmp:
; X86: # %bb.0:
; X86-NEXT: movl $128, %eax
; X86-NEXT: addl {{[0-9]+}}(%esp), %eax
; X86-NEXT: cmpw {{[0-9]+}}(%esp), %ax
; X86-NEXT: setae %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i8_cmp:
; X64: # %bb.0:
; X64-NEXT: subl $-128, %edi
; X64-NEXT: cmpw %si, %di
; X64-NEXT: setae %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i16 %tmp0, %y
ret i1 %tmp1
}
; Second constant is not larger than the first one
define i1 @add_ugecmp_bad_i8_i16(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i8_i16:
; X86: # %bb.0:
; X86-NEXT: movl $128, %eax
; X86-NEXT: addl {{[0-9]+}}(%esp), %eax
[X86] Don't promote i16 compares to i32 if the immediate will fit in 8 bits. The comments in this code say we were trying to avoid 16-bit immediates, but if the immediate fits in 8-bits this isn't an issue. This avoids creating a zero extend that probably won't go away. The movmskb related changes are interesting. The movmskb instruction writes a 32-bit result, but fills the upper bits with 0. So the zero_extend we were previously emitting was free, but we turned a -1 immediate that would fit in 8-bits into a 32-bit immediate so it was still bad. llvm-svn: 343871
2018-10-06 02:13:36 +08:00
; X86-NEXT: cmpw $127, %ax
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i8_i16:
; X64: # %bb.0:
; X64-NEXT: subl $-128, %edi
[X86] Don't promote i16 compares to i32 if the immediate will fit in 8 bits. The comments in this code say we were trying to avoid 16-bit immediates, but if the immediate fits in 8-bits this isn't an issue. This avoids creating a zero extend that probably won't go away. The movmskb related changes are interesting. The movmskb instruction writes a 32-bit result, but fills the upper bits with 0. So the zero_extend we were previously emitting was free, but we turned a -1 immediate that would fit in 8-bits into a 32-bit immediate so it was still bad. llvm-svn: 343871
2018-10-06 02:13:36 +08:00
; X64-NEXT: cmpw $127, %di
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i16 %tmp0, 128 ; 1U << (8-1)
ret i1 %tmp1
}
; First constant is not power of two
define i1 @add_ugecmp_bad_i16_i8_c0notpoweroftwo(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i8_c0notpoweroftwo:
; X86: # %bb.0:
; X86-NEXT: movl $192, %eax
; X86-NEXT: addl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movzwl %ax, %eax
; X86-NEXT: cmpl $255, %eax
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i8_c0notpoweroftwo:
; X64: # %bb.0:
; X64-NEXT: addl $192, %edi
; X64-NEXT: movzwl %di, %eax
; X64-NEXT: cmpl $255, %eax
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 192 ; (1U << (8-1)) + (1U << (8-1-1))
%tmp1 = icmp uge i16 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
; Second constant is not power of two
define i1 @add_ugecmp_bad_i16_i8_c1notpoweroftwo(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i8_c1notpoweroftwo:
; X86: # %bb.0:
; X86-NEXT: movl $128, %eax
; X86-NEXT: addl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movzwl %ax, %eax
; X86-NEXT: cmpl $767, %eax # imm = 0x2FF
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i8_c1notpoweroftwo:
; X64: # %bb.0:
; X64-NEXT: subl $-128, %edi
; X64-NEXT: movzwl %di, %eax
; X64-NEXT: cmpl $767, %eax # imm = 0x2FF
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i16 %tmp0, 768 ; (1U << 8)) + (1U << (8+1))
ret i1 %tmp1
}
; Magic check fails, 64 << 1 != 256
define i1 @add_ugecmp_bad_i16_i8_magic(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i8_magic:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: addl $64, %eax
; X86-NEXT: movzwl %ax, %eax
; X86-NEXT: cmpl $255, %eax
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i8_magic:
; X64: # %bb.0:
; X64-NEXT: addl $64, %edi
; X64-NEXT: movzwl %di, %eax
; X64-NEXT: cmpl $255, %eax
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 64 ; 1U << (8-1-1)
%tmp1 = icmp uge i16 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
; Bad 'destination type'
define i1 @add_ugecmp_bad_i16_i4(i16 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i16_i4:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: addl $8, %eax
[X86] Don't promote i16 compares to i32 if the immediate will fit in 8 bits. The comments in this code say we were trying to avoid 16-bit immediates, but if the immediate fits in 8-bits this isn't an issue. This avoids creating a zero extend that probably won't go away. The movmskb related changes are interesting. The movmskb instruction writes a 32-bit result, but fills the upper bits with 0. So the zero_extend we were previously emitting was free, but we turned a -1 immediate that would fit in 8-bits into a 32-bit immediate so it was still bad. llvm-svn: 343871
2018-10-06 02:13:36 +08:00
; X86-NEXT: cmpw $15, %ax
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i16_i4:
; X64: # %bb.0:
; X64-NEXT: addl $8, %edi
[X86] Don't promote i16 compares to i32 if the immediate will fit in 8 bits. The comments in this code say we were trying to avoid 16-bit immediates, but if the immediate fits in 8-bits this isn't an issue. This avoids creating a zero extend that probably won't go away. The movmskb related changes are interesting. The movmskb instruction writes a 32-bit result, but fills the upper bits with 0. So the zero_extend we were previously emitting was free, but we turned a -1 immediate that would fit in 8-bits into a 32-bit immediate so it was still bad. llvm-svn: 343871
2018-10-06 02:13:36 +08:00
; X64-NEXT: cmpw $15, %di
[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern See D49247, D49266 I'm only adding the sane negative tests, and not adding the one-use tests yet. Also, not adding negative tests for the second pattern with inverted operands yet, since it's handling will be added in later differential. llvm-svn: 337014
2018-07-14 00:14:37 +08:00
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i16 %x, 8 ; 1U << (4-1)
%tmp1 = icmp uge i16 %tmp0, 16 ; 1U << 4
ret i1 %tmp1
}
; Bad storage type
define i1 @add_ugecmp_bad_i24_i8(i24 %x) nounwind {
; X86-LABEL: add_ugecmp_bad_i24_i8:
; X86: # %bb.0:
; X86-NEXT: movl $128, %eax
; X86-NEXT: addl {{[0-9]+}}(%esp), %eax
; X86-NEXT: andl $16777215, %eax # imm = 0xFFFFFF
; X86-NEXT: cmpl $255, %eax
; X86-NEXT: seta %al
; X86-NEXT: retl
;
; X64-LABEL: add_ugecmp_bad_i24_i8:
; X64: # %bb.0:
; X64-NEXT: subl $-128, %edi
; X64-NEXT: andl $16777215, %edi # imm = 0xFFFFFF
; X64-NEXT: cmpl $255, %edi
; X64-NEXT: seta %al
; X64-NEXT: retq
%tmp0 = add i24 %x, 128 ; 1U << (8-1)
%tmp1 = icmp uge i24 %tmp0, 256 ; 1U << 8
ret i1 %tmp1
}
[NFC][X86][AArch64][DAGCombine] More tests for optimizeSetCCOfSignedTruncationCheck() At least one of these cases is more canonical, so we really do have to handle it. https://godbolt.org/g/pkzP3X https://rise4fun.com/Alive/pQyh llvm-svn: 337400
2018-07-19 00:19:06 +08:00
; Slightly more canonical variant
define i1 @add_ugtcmp_bad_i16_i8(i16 %x) nounwind {
; CHECK-LABEL: add_ugtcmp_bad_i16_i8:
; CHECK: # %bb.0:
; CHECK-NEXT: xorl %eax, %eax
; CHECK-NEXT: ret{{[l|q]}}
%tmp0 = add i16 %x, 128 ; 1U << (8-1)
%tmp1 = icmp ugt i16 %tmp0, -1 ; when we +1 it, it will wrap to 0
ret i1 %tmp1
}