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/vector-idiv-v2i32.ll

1229 lines
44 KiB
LLVM
Raw Normal View History

[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 -x86-experimental-vector-widening-legalization | FileCheck %s --check-prefix=X64_WIDEN
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=+sse2 -x86-experimental-vector-widening-legalization | FileCheck %s --check-prefix=X86_WIDEN
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
define void @test_udiv7_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_udiv7_v2i32:
; X64: # %bb.0:
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm1, %eax
; X64-NEXT: imulq $613566757, %rax, %rcx # imm = 0x24924925
; X64-NEXT: shrq $32, %rcx
; X64-NEXT: subl %ecx, %eax
; X64-NEXT: shrl %eax
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: shrl $2, %eax
; X64-NEXT: movd %xmm0, %ecx
; X64-NEXT: imulq $613566757, %rcx, %rdx # imm = 0x24924925
; X64-NEXT: shrq $32, %rdx
; X64-NEXT: subl %edx, %ecx
; X64-NEXT: shrl %ecx
; X64-NEXT: addl %edx, %ecx
; X64-NEXT: shrl $2, %ecx
; X64-NEXT: movd %ecx, %xmm0
; X64-NEXT: movd %eax, %xmm1
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_udiv7_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %xmm0, %esi
; X86-NEXT: movl $613566757, %ebx # imm = 0x24924925
; X86-NEXT: movl %esi, %eax
; X86-NEXT: mull %ebx
; X86-NEXT: subl %edx, %esi
; X86-NEXT: shrl %esi
; X86-NEXT: addl %edx, %esi
; X86-NEXT: shrl $2, %esi
; X86-NEXT: movl %ecx, %eax
; X86-NEXT: mull %ebx
; X86-NEXT: subl %edx, %ecx
; X86-NEXT: shrl %ecx
; X86-NEXT: addl %edx, %ecx
; X86-NEXT: shrl $2, %ecx
; X86-NEXT: movd %ecx, %xmm0
; X86-NEXT: movd %esi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%edi)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_udiv7_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: imulq $613566757, %rax, %rcx # imm = 0x24924925
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: subl %ecx, %eax
; X64_WIDEN-NEXT: shrl %eax
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: shrl $2, %eax
; X64_WIDEN-NEXT: movd %eax, %xmm1
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: imulq $613566757, %rax, %rcx # imm = 0x24924925
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: subl %ecx, %eax
; X64_WIDEN-NEXT: shrl %eax
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: shrl $2, %eax
; X64_WIDEN-NEXT: movd %eax, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm1, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_udiv7_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %esi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: movl $613566757, %edi # imm = 0x24924925
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: mull %edi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: subl %edx, %ecx
; X86_WIDEN-NEXT: shrl %ecx
; X86_WIDEN-NEXT: addl %edx, %ecx
; X86_WIDEN-NEXT: shrl $2, %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movd %ecx, %xmm1
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: mull %edi
; X86_WIDEN-NEXT: subl %edx, %ecx
; X86_WIDEN-NEXT: shrl %ecx
; X86_WIDEN-NEXT: addl %edx, %ecx
; X86_WIDEN-NEXT: shrl $2, %ecx
; X86_WIDEN-NEXT: movd %ecx, %xmm0
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%esi)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = udiv <2 x i32> %a, <i32 7, i32 7>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_urem7_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_urem7_v2i32:
; X64: # %bb.0:
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm1, %ecx
; X64-NEXT: imulq $613566757, %rcx, %rdx # imm = 0x24924925
; X64-NEXT: shrq $32, %rdx
; X64-NEXT: movl %ecx, %eax
; X64-NEXT: subl %edx, %eax
; X64-NEXT: shrl %eax
; X64-NEXT: addl %edx, %eax
; X64-NEXT: shrl $2, %eax
; X64-NEXT: leal (,%rax,8), %edx
; X64-NEXT: subl %edx, %eax
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: movd %xmm0, %ecx
; X64-NEXT: imulq $613566757, %rcx, %rdx # imm = 0x24924925
; X64-NEXT: shrq $32, %rdx
; X64-NEXT: movl %ecx, %edi
; X64-NEXT: subl %edx, %edi
; X64-NEXT: shrl %edi
; X64-NEXT: addl %edx, %edi
; X64-NEXT: shrl $2, %edi
; X64-NEXT: leal (,%rdi,8), %edx
; X64-NEXT: subl %edx, %edi
; X64-NEXT: addl %ecx, %edi
; X64-NEXT: movd %edi, %xmm0
; X64-NEXT: movd %eax, %xmm1
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_urem7_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebp
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pushl %esi
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %xmm0, %esi
; X86-NEXT: movl $613566757, %edi # imm = 0x24924925
; X86-NEXT: movl %esi, %eax
; X86-NEXT: mull %edi
; X86-NEXT: movl %esi, %ebx
; X86-NEXT: subl %edx, %ebx
; X86-NEXT: shrl %ebx
; X86-NEXT: addl %edx, %ebx
; X86-NEXT: shrl $2, %ebx
; X86-NEXT: leal (,%ebx,8), %eax
; X86-NEXT: subl %eax, %ebx
; X86-NEXT: movl {{[0-9]+}}(%esp), %ebp
; X86-NEXT: addl %esi, %ebx
; X86-NEXT: movl %ecx, %eax
; X86-NEXT: mull %edi
; X86-NEXT: movl %ecx, %eax
; X86-NEXT: subl %edx, %eax
; X86-NEXT: shrl %eax
; X86-NEXT: addl %edx, %eax
; X86-NEXT: shrl $2, %eax
; X86-NEXT: leal (,%eax,8), %edx
; X86-NEXT: subl %edx, %eax
; X86-NEXT: addl %ecx, %eax
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movd %eax, %xmm0
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %ebx, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%ebp)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
; X86-NEXT: popl %ebp
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_urem7_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: imulq $613566757, %rax, %rcx # imm = 0x24924925
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: movl %eax, %edx
; X64_WIDEN-NEXT: subl %ecx, %edx
; X64_WIDEN-NEXT: shrl %edx
; X64_WIDEN-NEXT: addl %ecx, %edx
; X64_WIDEN-NEXT: shrl $2, %edx
; X64_WIDEN-NEXT: leal (,%rdx,8), %ecx
; X64_WIDEN-NEXT: subl %ecx, %edx
; X64_WIDEN-NEXT: addl %eax, %edx
; X64_WIDEN-NEXT: movd %edx, %xmm1
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: imulq $613566757, %rax, %rcx # imm = 0x24924925
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: movl %eax, %edx
; X64_WIDEN-NEXT: subl %ecx, %edx
; X64_WIDEN-NEXT: shrl %edx
; X64_WIDEN-NEXT: addl %ecx, %edx
; X64_WIDEN-NEXT: shrl $2, %edx
; X64_WIDEN-NEXT: leal (,%rdx,8), %ecx
; X64_WIDEN-NEXT: subl %ecx, %edx
; X64_WIDEN-NEXT: addl %eax, %edx
; X64_WIDEN-NEXT: movd %edx, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm1, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_urem7_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %esi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: movl $613566757, %edi # imm = 0x24924925
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: mull %edi
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: subl %edx, %eax
; X86_WIDEN-NEXT: shrl %eax
; X86_WIDEN-NEXT: addl %edx, %eax
; X86_WIDEN-NEXT: shrl $2, %eax
; X86_WIDEN-NEXT: leal (,%eax,8), %edx
; X86_WIDEN-NEXT: subl %edx, %eax
; X86_WIDEN-NEXT: addl %ecx, %eax
; X86_WIDEN-NEXT: movd %eax, %xmm1
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %ecx
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: mull %edi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: subl %edx, %eax
; X86_WIDEN-NEXT: shrl %eax
; X86_WIDEN-NEXT: addl %edx, %eax
; X86_WIDEN-NEXT: shrl $2, %eax
; X86_WIDEN-NEXT: leal (,%eax,8), %edx
; X86_WIDEN-NEXT: subl %edx, %eax
; X86_WIDEN-NEXT: addl %ecx, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movd %eax, %xmm0
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%esi)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = urem <2 x i32> %a, <i32 7, i32 7>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_sdiv7_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_sdiv7_v2i32:
; X64: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm1, %eax
; X64-NEXT: cltq
; X64-NEXT: imulq $-1840700269, %rax, %rcx # imm = 0x92492493
; X64-NEXT: shrq $32, %rcx
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: movl %eax, %ecx
; X64-NEXT: shrl $31, %ecx
; X64-NEXT: sarl $2, %eax
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: movd %xmm0, %ecx
; X64-NEXT: movslq %ecx, %rcx
; X64-NEXT: imulq $-1840700269, %rcx, %rdx # imm = 0x92492493
; X64-NEXT: shrq $32, %rdx
; X64-NEXT: addl %edx, %ecx
; X64-NEXT: movl %ecx, %edx
; X64-NEXT: shrl $31, %edx
; X64-NEXT: sarl $2, %ecx
; X64-NEXT: addl %edx, %ecx
; X64-NEXT: movd %ecx, %xmm0
; X64-NEXT: movd %eax, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_sdiv7_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebp
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %ebx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %esi
; X86-NEXT: movl $-1840700269, %ebp # imm = 0x92492493
; X86-NEXT: movl %esi, %eax
; X86-NEXT: imull %ebp
; X86-NEXT: movl %edx, %edi
; X86-NEXT: addl %esi, %edi
; X86-NEXT: movl %edi, %eax
; X86-NEXT: shrl $31, %eax
; X86-NEXT: sarl $2, %edi
; X86-NEXT: addl %eax, %edi
; X86-NEXT: movl %ecx, %eax
; X86-NEXT: imull %ebp
; X86-NEXT: addl %ecx, %edx
; X86-NEXT: movl %edx, %eax
; X86-NEXT: shrl $31, %eax
; X86-NEXT: sarl $2, %edx
; X86-NEXT: addl %eax, %edx
; X86-NEXT: movd %edx, %xmm0
; X86-NEXT: movd %edi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%ebx)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %ebp
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_sdiv7_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: cltq
; X64_WIDEN-NEXT: imulq $-1840700269, %rax, %rcx # imm = 0x92492493
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: movl %eax, %ecx
; X64_WIDEN-NEXT: shrl $31, %ecx
; X64_WIDEN-NEXT: sarl $2, %eax
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: movd %eax, %xmm1
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: cltq
; X64_WIDEN-NEXT: imulq $-1840700269, %rax, %rcx # imm = 0x92492493
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: movl %eax, %ecx
; X64_WIDEN-NEXT: shrl $31, %ecx
; X64_WIDEN-NEXT: sarl $2, %eax
; X64_WIDEN-NEXT: addl %ecx, %eax
; X64_WIDEN-NEXT: movd %eax, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm1, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_sdiv7_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %ebx
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %esi
; X86_WIDEN-NEXT: movl $-1840700269, %ebx # imm = 0x92492493
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %esi, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: imull %ebx
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: addl %esi, %edx
; X86_WIDEN-NEXT: movl %edx, %eax
; X86_WIDEN-NEXT: shrl $31, %eax
; X86_WIDEN-NEXT: sarl $2, %edx
; X86_WIDEN-NEXT: addl %eax, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movd %edx, %xmm0
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: imull %ebx
; X86_WIDEN-NEXT: addl %ecx, %edx
; X86_WIDEN-NEXT: movl %edx, %eax
; X86_WIDEN-NEXT: shrl $31, %eax
; X86_WIDEN-NEXT: sarl $2, %edx
; X86_WIDEN-NEXT: addl %eax, %edx
; X86_WIDEN-NEXT: movd %edx, %xmm1
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%edi)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: popl %ebx
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = sdiv <2 x i32> %a, <i32 7, i32 7>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_srem7_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_srem7_v2i32:
; X64: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm1, %eax
; X64-NEXT: movslq %eax, %rcx
; X64-NEXT: imulq $-1840700269, %rcx, %rax # imm = 0x92492493
; X64-NEXT: shrq $32, %rax
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: movl %eax, %edx
; X64-NEXT: shrl $31, %edx
; X64-NEXT: sarl $2, %eax
; X64-NEXT: addl %edx, %eax
; X64-NEXT: leal (,%rax,8), %edx
; X64-NEXT: subl %edx, %eax
; X64-NEXT: addl %ecx, %eax
; X64-NEXT: movd %xmm0, %ecx
; X64-NEXT: movslq %ecx, %rcx
; X64-NEXT: imulq $-1840700269, %rcx, %rdx # imm = 0x92492493
; X64-NEXT: shrq $32, %rdx
; X64-NEXT: addl %ecx, %edx
; X64-NEXT: movl %edx, %edi
; X64-NEXT: shrl $31, %edi
; X64-NEXT: sarl $2, %edx
; X64-NEXT: addl %edi, %edx
; X64-NEXT: leal (,%rdx,8), %edi
; X64-NEXT: subl %edi, %edx
; X64-NEXT: addl %ecx, %edx
; X64-NEXT: movd %edx, %xmm0
; X64-NEXT: movd %eax, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_srem7_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebp
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
; X86-NEXT: pushl %esi
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %esi
; X86-NEXT: movl $-1840700269, %ebx # imm = 0x92492493
; X86-NEXT: movl %esi, %eax
; X86-NEXT: imull %ebx
; X86-NEXT: movl %edx, %edi
; X86-NEXT: addl %esi, %edi
; X86-NEXT: movl %edi, %eax
; X86-NEXT: shrl $31, %eax
; X86-NEXT: sarl $2, %edi
; X86-NEXT: addl %eax, %edi
; X86-NEXT: leal (,%edi,8), %eax
; X86-NEXT: subl %eax, %edi
; X86-NEXT: movl {{[0-9]+}}(%esp), %ebp
; X86-NEXT: addl %esi, %edi
; X86-NEXT: movl %ecx, %eax
; X86-NEXT: imull %ebx
; X86-NEXT: addl %ecx, %edx
; X86-NEXT: movl %edx, %eax
; X86-NEXT: shrl $31, %eax
; X86-NEXT: sarl $2, %edx
; X86-NEXT: addl %eax, %edx
; X86-NEXT: leal (,%edx,8), %eax
; X86-NEXT: subl %eax, %edx
; X86-NEXT: addl %ecx, %edx
; X86-NEXT: movd %edx, %xmm0
; X86-NEXT: movd %edi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%ebp)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %ebp
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_srem7_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: cltq
; X64_WIDEN-NEXT: imulq $-1840700269, %rax, %rcx # imm = 0x92492493
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: addl %eax, %ecx
; X64_WIDEN-NEXT: movl %ecx, %edx
; X64_WIDEN-NEXT: shrl $31, %edx
; X64_WIDEN-NEXT: sarl $2, %ecx
; X64_WIDEN-NEXT: addl %edx, %ecx
; X64_WIDEN-NEXT: leal (,%rcx,8), %edx
; X64_WIDEN-NEXT: subl %edx, %ecx
; X64_WIDEN-NEXT: addl %eax, %ecx
; X64_WIDEN-NEXT: movd %ecx, %xmm1
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: cltq
; X64_WIDEN-NEXT: imulq $-1840700269, %rax, %rcx # imm = 0x92492493
; X64_WIDEN-NEXT: shrq $32, %rcx
; X64_WIDEN-NEXT: addl %eax, %ecx
; X64_WIDEN-NEXT: movl %ecx, %edx
; X64_WIDEN-NEXT: shrl $31, %edx
; X64_WIDEN-NEXT: sarl $2, %ecx
; X64_WIDEN-NEXT: addl %edx, %ecx
; X64_WIDEN-NEXT: leal (,%rcx,8), %edx
; X64_WIDEN-NEXT: subl %edx, %ecx
; X64_WIDEN-NEXT: addl %eax, %ecx
; X64_WIDEN-NEXT: movd %ecx, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm1, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_srem7_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %ebx
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %esi
; X86_WIDEN-NEXT: movl $-1840700269, %edi # imm = 0x92492493
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %esi, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: imull %edi
; X86_WIDEN-NEXT: addl %esi, %edx
; X86_WIDEN-NEXT: movl %edx, %eax
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: shrl $31, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: sarl $2, %edx
; X86_WIDEN-NEXT: addl %eax, %edx
; X86_WIDEN-NEXT: leal (,%edx,8), %eax
; X86_WIDEN-NEXT: subl %eax, %edx
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ebx
; X86_WIDEN-NEXT: addl %esi, %edx
; X86_WIDEN-NEXT: movd %edx, %xmm0
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: imull %edi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: addl %ecx, %edx
; X86_WIDEN-NEXT: movl %edx, %eax
; X86_WIDEN-NEXT: shrl $31, %eax
; X86_WIDEN-NEXT: sarl $2, %edx
; X86_WIDEN-NEXT: addl %eax, %edx
; X86_WIDEN-NEXT: leal (,%edx,8), %eax
; X86_WIDEN-NEXT: subl %eax, %edx
; X86_WIDEN-NEXT: addl %ecx, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movd %edx, %xmm1
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%ebx)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: popl %ebx
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = srem <2 x i32> %a, <i32 7, i32 7>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_udiv_pow2_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_udiv_pow2_v2i32:
; X64: # %bb.0:
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: pxor %xmm1, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: psrlq $3, %xmm0
; X64-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_udiv_pow2_v2i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: pxor %xmm1, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: psrlq $3, %xmm0
; X86-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; X86-NEXT: movq %xmm0, (%eax)
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_udiv_pow2_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: psrld $3, %xmm0
; X64_WIDEN-NEXT: movq %xmm0, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_udiv_pow2_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: psrld $3, %xmm0
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq %xmm0, (%eax)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = udiv <2 x i32> %a, <i32 8, i32 8>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_urem_pow2_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_urem_pow2_v2i32:
; X64: # %bb.0:
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movl (%rdi), %eax
; X64-NEXT: movl 4(%rdi), %ecx
; X64-NEXT: movq %rcx, %xmm0
; X64-NEXT: movq %rax, %xmm1
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
; X64-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: pand {{.*}}(%rip), %xmm1
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
; X64-NEXT: pshufd {{.*#+}} xmm0 = xmm1[0,2,2,3]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_urem_pow2_v2i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
[SelectionDAG] Add SimplifyDemandedBits to SimplifyDemandedVectorElts simplification This patch enables SimplifyDemandedBits to call SimplifyDemandedVectorElts in cases where the demanded bits mask covers entire elements of a bitcasted source vector. There are a couple of cases here where simplification at a deeper level (such as through bitcasts) prevents further simplification - CommitTargetLoweringOpt only adds immediate uses/users back to the worklist when we might want to combine the original caller again to see what else it can simplify. As well as that I had to disable handling of bool vector until SimplifyDemandedVectorElts better supports some of their opcodes (SETCC, shifts etc.). Fixes PR39178 Differential Revision: https://reviews.llvm.org/D52935 llvm-svn: 343913
2018-10-06 18:20:04 +08:00
; X86-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,1,1,3]
; X86-NEXT: andps {{\.LCPI.*}}, %xmm0
; X86-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movq %xmm0, (%eax)
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_urem_pow2_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: andps {{.*}}(%rip), %xmm0
; X64_WIDEN-NEXT: movlps %xmm0, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_urem_pow2_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: andps {{\.LCPI.*}}, %xmm0
; X86_WIDEN-NEXT: movlps %xmm0, (%eax)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = urem <2 x i32> %a, <i32 8, i32 8>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_sdiv_pow2_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_sdiv_pow2_v2i32:
; X64: # %bb.0:
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: pxor %xmm1, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64-NEXT: psrad $31, %xmm1
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,3,2,3]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm0[0,1,1,3]
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: psrlq $31, %xmm0
; X64-NEXT: pand {{.*}}(%rip), %xmm0
; X64-NEXT: psrlq $29, %xmm0
; X64-NEXT: paddq %xmm2, %xmm0
; X64-NEXT: psllq $32, %xmm0
; X64-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,3,2,3]
; X64-NEXT: psrad $31, %xmm0
; X64-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,3,2,3]
; X64-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X64-NEXT: psrlq $3, %xmm1
; X64-NEXT: pshufd {{.*#+}} xmm0 = xmm1[0,2,2,3]
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_sdiv_pow2_v2i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: pxor %xmm1, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86-NEXT: psrad $31, %xmm1
; X86-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,3,2,3]
; X86-NEXT: movdqa %xmm0, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,1,1,3]
Recommit r344877 "[X86] Stop promoting integer loads to vXi64" I've included a fix to DAGCombiner::ForwardStoreValueToDirectLoad that I believe will prevent the previous miscompile. Original commit message: Theoretically this was done to simplify the amount of isel patterns that were needed. But it also meant a substantial number of our isel patterns have to match an explicit bitcast. By making the vXi32/vXi16/vXi8 types legal for loads, DAG combiner should be able to change the load type to rem I had to add some additional plain load instruction patterns and a few other special cases, but overall the isel table has reduced in size by ~12000 bytes. So it looks like this promotion was hurting us more than helping. I still have one crash in vector-trunc.ll that I'm hoping @RKSimon can help with. It seems to relate to using getTargetConstantFromNode on a load that was shrunk due to an extract_subvector combine after the constant pool entry was created. So we end up decoding more mask elements than the lo I'm hoping this patch will simplify the number of patterns needed to remove the and/or/xor promotion. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits, RKSimon Differential Revision: https://reviews.llvm.org/D53306 llvm-svn: 344965
2018-10-23 06:14:05 +08:00
; X86-NEXT: movdqa {{.*#+}} xmm2 = [31,0,31,0]
; X86-NEXT: movdqa {{.*#+}} xmm3 = [0,2147483648,0,2147483648]
; X86-NEXT: movdqa %xmm3, %xmm4
; X86-NEXT: psrlq %xmm2, %xmm4
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl $31, %ecx
; X86-NEXT: movd %ecx, %xmm5
Recommit r344877 "[X86] Stop promoting integer loads to vXi64" I've included a fix to DAGCombiner::ForwardStoreValueToDirectLoad that I believe will prevent the previous miscompile. Original commit message: Theoretically this was done to simplify the amount of isel patterns that were needed. But it also meant a substantial number of our isel patterns have to match an explicit bitcast. By making the vXi32/vXi16/vXi8 types legal for loads, DAG combiner should be able to change the load type to rem I had to add some additional plain load instruction patterns and a few other special cases, but overall the isel table has reduced in size by ~12000 bytes. So it looks like this promotion was hurting us more than helping. I still have one crash in vector-trunc.ll that I'm hoping @RKSimon can help with. It seems to relate to using getTargetConstantFromNode on a load that was shrunk due to an extract_subvector combine after the constant pool entry was created. So we end up decoding more mask elements than the lo I'm hoping this patch will simplify the number of patterns needed to remove the and/or/xor promotion. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits, RKSimon Differential Revision: https://reviews.llvm.org/D53306 llvm-svn: 344965
2018-10-23 06:14:05 +08:00
; X86-NEXT: psrlq %xmm5, %xmm3
; X86-NEXT: movsd {{.*#+}} xmm3 = xmm4[0],xmm3[1]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movdqa %xmm1, %xmm4
Recommit r344877 "[X86] Stop promoting integer loads to vXi64" I've included a fix to DAGCombiner::ForwardStoreValueToDirectLoad that I believe will prevent the previous miscompile. Original commit message: Theoretically this was done to simplify the amount of isel patterns that were needed. But it also meant a substantial number of our isel patterns have to match an explicit bitcast. By making the vXi32/vXi16/vXi8 types legal for loads, DAG combiner should be able to change the load type to rem I had to add some additional plain load instruction patterns and a few other special cases, but overall the isel table has reduced in size by ~12000 bytes. So it looks like this promotion was hurting us more than helping. I still have one crash in vector-trunc.ll that I'm hoping @RKSimon can help with. It seems to relate to using getTargetConstantFromNode on a load that was shrunk due to an extract_subvector combine after the constant pool entry was created. So we end up decoding more mask elements than the lo I'm hoping this patch will simplify the number of patterns needed to remove the and/or/xor promotion. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits, RKSimon Differential Revision: https://reviews.llvm.org/D53306 llvm-svn: 344965
2018-10-23 06:14:05 +08:00
; X86-NEXT: psrlq %xmm2, %xmm4
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: psrlq %xmm5, %xmm1
; X86-NEXT: movsd {{.*#+}} xmm1 = xmm4[0],xmm1[1]
Recommit r344877 "[X86] Stop promoting integer loads to vXi64" I've included a fix to DAGCombiner::ForwardStoreValueToDirectLoad that I believe will prevent the previous miscompile. Original commit message: Theoretically this was done to simplify the amount of isel patterns that were needed. But it also meant a substantial number of our isel patterns have to match an explicit bitcast. By making the vXi32/vXi16/vXi8 types legal for loads, DAG combiner should be able to change the load type to rem I had to add some additional plain load instruction patterns and a few other special cases, but overall the isel table has reduced in size by ~12000 bytes. So it looks like this promotion was hurting us more than helping. I still have one crash in vector-trunc.ll that I'm hoping @RKSimon can help with. It seems to relate to using getTargetConstantFromNode on a load that was shrunk due to an extract_subvector combine after the constant pool entry was created. So we end up decoding more mask elements than the lo I'm hoping this patch will simplify the number of patterns needed to remove the and/or/xor promotion. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits, RKSimon Differential Revision: https://reviews.llvm.org/D53306 llvm-svn: 344965
2018-10-23 06:14:05 +08:00
; X86-NEXT: xorpd %xmm3, %xmm1
; X86-NEXT: psubq %xmm3, %xmm1
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pand {{\.LCPI.*}}, %xmm1
; X86-NEXT: psrlq $29, %xmm1
; X86-NEXT: paddq %xmm0, %xmm1
; X86-NEXT: psllq $32, %xmm1
; X86-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,3,2,3]
; X86-NEXT: psrad $31, %xmm1
; X86-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,3,2,3]
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: psrlq $3, %xmm0
; X86-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; X86-NEXT: movq %xmm0, (%eax)
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_sdiv_pow2_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movdqa %xmm0, %xmm1
; X64_WIDEN-NEXT: psrad $31, %xmm1
; X64_WIDEN-NEXT: psrld $29, %xmm1
; X64_WIDEN-NEXT: paddd %xmm0, %xmm1
; X64_WIDEN-NEXT: psrad $3, %xmm1
; X64_WIDEN-NEXT: movq %xmm1, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_sdiv_pow2_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movdqa %xmm0, %xmm1
; X86_WIDEN-NEXT: psrad $31, %xmm1
; X86_WIDEN-NEXT: psrld $29, %xmm1
; X86_WIDEN-NEXT: paddd %xmm0, %xmm1
; X86_WIDEN-NEXT: psrad $3, %xmm1
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq %xmm1, (%eax)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = sdiv <2 x i32> %a, <i32 8, i32 8>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
define void @test_srem_pow2_v2i32(<2 x i32>* %x, <2 x i32>* %y) nounwind {
; X64-LABEL: test_srem_pow2_v2i32:
; X64: # %bb.0:
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: pxor %xmm1, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: psrlq $3, %xmm0
; X64-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rsi)
; X64-NEXT: retq
;
; X86-LABEL: test_srem_pow2_v2i32:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: pxor %xmm1, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: psrlq $3, %xmm0
; X86-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; X86-NEXT: movq %xmm0, (%eax)
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_srem_pow2_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: psrld $3, %xmm0
; X64_WIDEN-NEXT: movq %xmm0, (%rsi)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_srem_pow2_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: psrld $3, %xmm0
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq %xmm0, (%eax)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = udiv <2 x i32> %a, <i32 8, i32 8>
store <2 x i32> %b, <2 x i32>* %y
ret void
}
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
define void @test_udiv_v2i32(<2 x i32>* %x, <2 x i32>* %y, <2 x i32>* %z) nounwind {
; X64-LABEL: test_udiv_v2i32:
; X64: # %bb.0:
; X64-NEXT: movq %rdx, %rcx
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm2, %eax
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,3,0,1]
; X64-NEXT: movd %xmm2, %esi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X64-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: divl %esi
; X64-NEXT: movl %eax, %esi
; X64-NEXT: movd %xmm0, %eax
; X64-NEXT: movd %xmm1, %edi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X64-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: divl %edi
; X64-NEXT: movd %eax, %xmm0
; X64-NEXT: movd %esi, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X64-NEXT: movq %xmm0, (%rcx)
; X64-NEXT: retq
;
; X86-LABEL: test_udiv_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %eax
; X86-NEXT: movd %xmm1, %ebx
; X86-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1,0,1]
; X86-NEXT: movd %xmm1, %esi
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: divl %esi
; X86-NEXT: movl %eax, %esi
; X86-NEXT: movl %ecx, %eax
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X86-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: divl %ebx
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movd %eax, %xmm0
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %esi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%edi)
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: popl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_udiv_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq %rdx, %rcx
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: movd %xmm1, %esi
; X64_WIDEN-NEXT: xorl %edx, %edx
; X64_WIDEN-NEXT: divl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm2
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %esi
; X64_WIDEN-NEXT: xorl %edx, %edx
; X64_WIDEN-NEXT: divl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm2, (%rcx)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_udiv_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %esi
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %edx
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: movd %xmm1, %esi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: xorl %edx, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: divl %esi
; X86_WIDEN-NEXT: movd %eax, %xmm2
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[2,3]
; X86_WIDEN-NEXT: movd %xmm1, %esi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X86_WIDEN-NEXT: xorl %edx, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: divl %esi
; X86_WIDEN-NEXT: movd %eax, %xmm0
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm2, (%ecx)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: retl
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
%a = load <2 x i32>, <2 x i32>* %x
%b = load <2 x i32>, <2 x i32>* %y
%c = udiv <2 x i32> %a, %b
store <2 x i32> %c, <2 x i32>* %z
ret void
}
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
define void @test_urem_v2i32(<2 x i32>* %x, <2 x i32>* %y, <2 x i32>* %z) nounwind {
; X64-LABEL: test_urem_v2i32:
; X64: # %bb.0:
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %rdx, %rcx
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm2, %eax
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,3,0,1]
; X64-NEXT: movd %xmm2, %esi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: divl %esi
; X64-NEXT: movl %edx, %esi
; X64-NEXT: movd %xmm0, %eax
; X64-NEXT: movd %xmm1, %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: divl %edi
; X64-NEXT: movd %edx, %xmm0
; X64-NEXT: movd %esi, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: movq %xmm0, (%rcx)
; X64-NEXT: retq
;
; X86-LABEL: test_urem_v2i32:
; X86: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %eax
; X86-NEXT: movd %xmm1, %ebx
; X86-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1,0,1]
; X86-NEXT: movd %xmm1, %esi
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: divl %esi
; X86-NEXT: movl %edx, %esi
; X86-NEXT: movl %ecx, %eax
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X86-NEXT: xorl %edx, %edx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: divl %ebx
; X86-NEXT: movd %edx, %xmm0
; X86-NEXT: movd %esi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%edi)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_urem_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq %rdx, %rcx
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: movd %xmm1, %esi
; X64_WIDEN-NEXT: xorl %edx, %edx
; X64_WIDEN-NEXT: divl %esi
; X64_WIDEN-NEXT: movd %edx, %xmm2
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %esi
; X64_WIDEN-NEXT: xorl %edx, %edx
; X64_WIDEN-NEXT: divl %esi
; X64_WIDEN-NEXT: movd %edx, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm2, (%rcx)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_urem_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %esi
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %edx
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: movd %xmm1, %esi
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: xorl %edx, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: divl %esi
; X86_WIDEN-NEXT: movd %edx, %xmm2
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[2,3]
; X86_WIDEN-NEXT: movd %xmm1, %esi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X86_WIDEN-NEXT: xorl %edx, %edx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: divl %esi
; X86_WIDEN-NEXT: movd %edx, %xmm0
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm2, (%ecx)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
%b = load <2 x i32>, <2 x i32>* %y
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%c = urem <2 x i32> %a, %b
store <2 x i32> %c, <2 x i32>* %z
ret void
}
define void @test_sdiv_v2i32(<2 x i32>* %x, <2 x i32>* %y, <2 x i32>* %z) nounwind {
; X64-LABEL: test_sdiv_v2i32:
; X64: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq %rdx, %rcx
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm2, %eax
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,3,0,1]
; X64-NEXT: movd %xmm2, %esi
; X64-NEXT: cltd
; X64-NEXT: idivl %esi
; X64-NEXT: movl %eax, %esi
; X64-NEXT: movd %xmm0, %eax
; X64-NEXT: movd %xmm1, %edi
; X64-NEXT: cltd
; X64-NEXT: idivl %edi
; X64-NEXT: movd %eax, %xmm0
; X64-NEXT: movd %esi, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: movq %xmm0, (%rcx)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: retq
;
; X86-LABEL: test_sdiv_v2i32:
; X86: # %bb.0:
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %eax
; X86-NEXT: movd %xmm1, %ebx
; X86-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1,0,1]
; X86-NEXT: movd %xmm1, %esi
; X86-NEXT: cltd
; X86-NEXT: idivl %esi
; X86-NEXT: movl %eax, %esi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl %ecx, %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: cltd
; X86-NEXT: idivl %ebx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movd %eax, %xmm0
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %esi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%edi)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_sdiv_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq %rdx, %rcx
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: movd %xmm1, %esi
; X64_WIDEN-NEXT: cltd
; X64_WIDEN-NEXT: idivl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm2
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %esi
; X64_WIDEN-NEXT: cltd
; X64_WIDEN-NEXT: idivl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm2, (%rcx)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_sdiv_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %ebx
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %esi
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: movd %xmm1, %edi
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[2,3]
; X86_WIDEN-NEXT: movd %xmm1, %ebx
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: cltd
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: idivl %ebx
; X86_WIDEN-NEXT: movd %eax, %xmm0
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: cltd
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: idivl %edi
; X86_WIDEN-NEXT: movd %eax, %xmm1
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%esi)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: popl %ebx
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
%b = load <2 x i32>, <2 x i32>* %y
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%c = sdiv <2 x i32> %a, %b
store <2 x i32> %c, <2 x i32>* %z
ret void
}
define void @test_srem_v2i32(<2 x i32>* %x, <2 x i32>* %y, <2 x i32>* %z) nounwind {
; X64-LABEL: test_srem_v2i32:
; X64: # %bb.0:
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X64-NEXT: movq %rdx, %rcx
; X64-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,3,0,1]
; X64-NEXT: movd %xmm2, %eax
; X64-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,3,0,1]
; X64-NEXT: movd %xmm2, %esi
; X64-NEXT: cltd
; X64-NEXT: idivl %esi
; X64-NEXT: movl %eax, %esi
; X64-NEXT: movd %xmm0, %eax
; X64-NEXT: movd %xmm1, %edi
; X64-NEXT: cltd
; X64-NEXT: idivl %edi
; X64-NEXT: movd %eax, %xmm0
; X64-NEXT: movd %esi, %xmm1
; X64-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X64-NEXT: movq %xmm0, (%rcx)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X64-NEXT: retq
;
; X86-LABEL: test_srem_v2i32:
; X86: # %bb.0:
; X86-NEXT: pushl %ebx
; X86-NEXT: pushl %edi
; X86-NEXT: pushl %esi
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %edi
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86-NEXT: movd %xmm0, %ecx
; X86-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,0,1]
; X86-NEXT: movd %xmm0, %eax
; X86-NEXT: movd %xmm1, %ebx
; X86-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1,0,1]
; X86-NEXT: movd %xmm1, %esi
; X86-NEXT: cltd
; X86-NEXT: idivl %esi
; X86-NEXT: movl %eax, %esi
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
; X86-NEXT: movl %ecx, %eax
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: cltd
; X86-NEXT: idivl %ebx
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: movd %eax, %xmm0
[X86] Type legalize v2i32 div/rem by scalarizing rather than promoting Summary: Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall. This patch switches type legalization to do the scalarizing itself using i32. It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support. Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides. Reviewers: RKSimon, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51325 llvm-svn: 342114
2018-09-13 14:13:37 +08:00
; X86-NEXT: movd %esi, %xmm1
; X86-NEXT: punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; X86-NEXT: movq %xmm0, (%edi)
[X86] Reverse the check prefixes in the test added in r340774. The 32-bit and 64-bit checks were reversed. llvm-svn: 340775
2018-08-28 05:34:37 +08:00
; X86-NEXT: popl %esi
; X86-NEXT: popl %edi
; X86-NEXT: popl %ebx
; X86-NEXT: retl
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
;
; X64_WIDEN-LABEL: test_srem_v2i32:
; X64_WIDEN: # %bb.0:
; X64_WIDEN-NEXT: movq %rdx, %rcx
; X64_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X64_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: movd %xmm1, %esi
; X64_WIDEN-NEXT: cltd
; X64_WIDEN-NEXT: idivl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm2
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %eax
; X64_WIDEN-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; X64_WIDEN-NEXT: movd %xmm0, %esi
; X64_WIDEN-NEXT: cltd
; X64_WIDEN-NEXT: idivl %esi
; X64_WIDEN-NEXT: movd %eax, %xmm0
; X64_WIDEN-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; X64_WIDEN-NEXT: movq %xmm2, (%rcx)
; X64_WIDEN-NEXT: retq
;
; X86_WIDEN-LABEL: test_srem_v2i32:
; X86_WIDEN: # %bb.0:
; X86_WIDEN-NEXT: pushl %ebx
; X86_WIDEN-NEXT: pushl %edi
; X86_WIDEN-NEXT: pushl %esi
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %esi
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %eax
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl {{[0-9]+}}(%esp), %ecx
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: movq {{.*#+}} xmm0 = mem[0],zero
; X86_WIDEN-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; X86_WIDEN-NEXT: movd %xmm0, %ecx
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; X86_WIDEN-NEXT: movd %xmm0, %eax
; X86_WIDEN-NEXT: movd %xmm1, %edi
; X86_WIDEN-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[2,3]
; X86_WIDEN-NEXT: movd %xmm1, %ebx
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: cltd
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: idivl %ebx
; X86_WIDEN-NEXT: movd %eax, %xmm0
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: movl %ecx, %eax
; X86_WIDEN-NEXT: cltd
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; X86_WIDEN-NEXT: idivl %edi
; X86_WIDEN-NEXT: movd %eax, %xmm1
; X86_WIDEN-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; X86_WIDEN-NEXT: movq %xmm1, (%esi)
[X86] Add -x86-experimental-vector-widening-legalization command lines to vector-idiv-v2i32.ll If we're legalizing via widening already, then the type legalizer will scalarize the divs/rems as i32. llvm-svn: 341108
2018-08-31 04:10:10 +08:00
; X86_WIDEN-NEXT: popl %esi
; X86_WIDEN-NEXT: popl %edi
; X86_WIDEN-NEXT: popl %ebx
; X86_WIDEN-NEXT: retl
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%a = load <2 x i32>, <2 x i32>* %x
[X86] Fix copy paste mistake in vector-idiv-v2i32.ll. Add missing test case. Some of the test cases contained the same load twice instead of a different load. llvm-svn: 340833
2018-08-28 23:24:12 +08:00
%b = load <2 x i32>, <2 x i32>* %y
[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes In particular this shows that we end up using libcalls in 32-bit mode even for division by constant. llvm-svn: 340774
2018-08-28 05:13:07 +08:00
%c = sdiv <2 x i32> %a, %b
store <2 x i32> %c, <2 x i32>* %z
ret void
}