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/madd.ll

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

2913 lines
133 KiB
LLVM
Raw Normal View History

Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
Use PMADDWD to expand reduction in a loop Summary: PMADDWD can help improve 8/16 bit integer mutliply-add operation performance for cases like: for (int i = 0; i < count; i++) a += x[i] * y[i]; Reviewers: wmi, davidxl, hfinkel, RKSimon, zvi, mkuper Reviewed By: mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31679 llvm-svn: 299776
2017-04-07 23:41:52 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=SSE2
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefixes=AVX,AVX1
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2 | FileCheck %s --check-prefixes=AVX,AVX256,AVX2
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f | FileCheck %s --check-prefixes=AVX,AVX256,AVX512,AVX512F
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512bw | FileCheck %s --check-prefixes=AVX,AVX256,AVX512,AVX512BW
Use PMADDWD to expand reduction in a loop Summary: PMADDWD can help improve 8/16 bit integer mutliply-add operation performance for cases like: for (int i = 0; i < count; i++) a += x[i] * y[i]; Reviewers: wmi, davidxl, hfinkel, RKSimon, zvi, mkuper Reviewed By: mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31679 llvm-svn: 299776
2017-04-07 23:41:52 +08:00
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
define i32 @_Z10test_shortPsS_i_128(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z10test_shortPsS_i_128:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0: # %entry
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; SSE2-NEXT: xorl %ecx, %ecx
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB0_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; SSE2-NEXT: movq {{.*#+}} xmm2 = mem[0],zero
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pmulhw %xmm1, %xmm3
; SSE2-NEXT: pmullw %xmm1, %xmm2
; SSE2-NEXT: punpcklwd {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[1],xmm3[1],xmm2[2],xmm3[2],xmm2[3],xmm3[3]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: addq $8, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB0_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: movd %xmm0, %eax
; SSE2-NEXT: retq
;
; AVX-LABEL: _Z10test_shortPsS_i_128:
; AVX: # %bb.0: # %entry
; AVX-NEXT: movl %edx, %eax
; AVX-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX-NEXT: xorl %ecx, %ecx
; AVX-NEXT: .p2align 4, 0x90
; AVX-NEXT: .LBB0_1: # %vector.body
; AVX-NEXT: # =>This Inner Loop Header: Depth=1
; AVX-NEXT: vpmovsxwd (%rdi,%rcx,2), %xmm1
; AVX-NEXT: vpmovsxwd (%rsi,%rcx,2), %xmm2
; AVX-NEXT: vpmulld %xmm1, %xmm2, %xmm1
; AVX-NEXT: vpaddd %xmm0, %xmm1, %xmm0
; AVX-NEXT: addq $8, %rcx
; AVX-NEXT: cmpq %rcx, %rax
; AVX-NEXT: jne .LBB0_1
; AVX-NEXT: # %bb.2: # %middle.block
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <4 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <4 x i16>*
%wide.load = load <4 x i16>, <4 x i16>* %5, align 2
%6 = sext <4 x i16> %wide.load to <4 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <4 x i16>*
%wide.load14 = load <4 x i16>, <4 x i16>* %8, align 2
%9 = sext <4 x i16> %wide.load14 to <4 x i32>
%10 = mul nsw <4 x i32> %9, %6
%11 = add nsw <4 x i32> %10, %vec.phi
%index.next = add i64 %index, 8
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf15 = shufflevector <4 x i32> %11, <4 x i32> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
%bin.rdx16 = add <4 x i32> %11, %rdx.shuf15
%rdx.shuf17 = shufflevector <4 x i32> %bin.rdx16, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <4 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <4 x i32> %bin.rdx18, i32 0
ret i32 %13
}
define i32 @_Z10test_shortPsS_i_256(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z10test_shortPsS_i_256:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm1, %xmm1
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB1_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm2
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm3
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: pmaddwd %xmm2, %xmm3
; SSE2-NEXT: paddd %xmm3, %xmm1
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; SSE2-NEXT: addq $8, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: jne .LBB1_1
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2-NEXT: # %bb.2: # %middle.block
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-LABEL: _Z10test_shortPsS_i_256:
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: .LBB1_1: # %vector.body
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
; AVX1-NEXT: vmovdqu (%rsi,%rcx,2), %xmm1
; AVX1-NEXT: vpmaddwd (%rdi,%rcx,2), %xmm1, %xmm1
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm1
; AVX1-NEXT: vblendps {{.*#+}} ymm0 = ymm1[0,1,2,3],ymm0[4,5,6,7]
; AVX1-NEXT: addq $8, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: jne .LBB1_1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-LABEL: _Z10test_shortPsS_i_256:
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX256: # %bb.0: # %entry
; AVX256-NEXT: movl %edx, %eax
; AVX256-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX256-NEXT: xorl %ecx, %ecx
; AVX256-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: .LBB1_1: # %vector.body
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX256-NEXT: # =>This Inner Loop Header: Depth=1
; AVX256-NEXT: vmovdqu (%rsi,%rcx,2), %xmm1
; AVX256-NEXT: vpmaddwd (%rdi,%rcx,2), %xmm1, %xmm1
; AVX256-NEXT: vpaddd %ymm0, %ymm1, %ymm0
; AVX256-NEXT: addq $8, %rcx
; AVX256-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: jne .LBB1_1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX256-NEXT: # %bb.2: # %middle.block
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX256-NEXT: vmovd %xmm0, %eax
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
Use PMADDWD to expand reduction in a loop Summary: PMADDWD can help improve 8/16 bit integer mutliply-add operation performance for cases like: for (int i = 0; i < count; i++) a += x[i] * y[i]; Reviewers: wmi, davidxl, hfinkel, RKSimon, zvi, mkuper Reviewed By: mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31679 llvm-svn: 299776
2017-04-07 23:41:52 +08:00
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <8 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <8 x i16>*
%wide.load = load <8 x i16>, <8 x i16>* %5, align 2
%6 = sext <8 x i16> %wide.load to <8 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <8 x i16>*
%wide.load14 = load <8 x i16>, <8 x i16>* %8, align 2
%9 = sext <8 x i16> %wide.load14 to <8 x i32>
%10 = mul nsw <8 x i32> %9, %6
%11 = add nsw <8 x i32> %10, %vec.phi
%index.next = add i64 %index, 8
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf = shufflevector <8 x i32> %11, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <8 x i32> %11, %rdx.shuf
%rdx.shuf15 = shufflevector <8 x i32> %bin.rdx, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <8 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <8 x i32> %bin.rdx16, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <8 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <8 x i32> %bin.rdx18, i32 0
ret i32 %13
}
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
define i32 @_Z10test_shortPsS_i_512(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z10test_shortPsS_i_512:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm2, %xmm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm1, %xmm1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: .LBB2_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm3
; SSE2-NEXT: movdqu 16(%rdi,%rcx,2), %xmm4
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm5
; SSE2-NEXT: pmaddwd %xmm3, %xmm5
; SSE2-NEXT: paddd %xmm5, %xmm2
; SSE2-NEXT: movdqu 16(%rsi,%rcx,2), %xmm3
; SSE2-NEXT: pmaddwd %xmm4, %xmm3
; SSE2-NEXT: paddd %xmm3, %xmm1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: jne .LBB2_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm0, %xmm2
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: paddd %xmm0, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm2, %xmm1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: _Z10test_shortPsS_i_512:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX1-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: .LBB2_1: # %vector.body
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vmovdqu (%rsi,%rcx,2), %xmm2
; AVX1-NEXT: vmovdqu 16(%rsi,%rcx,2), %xmm3
; AVX1-NEXT: vpmaddwd 16(%rdi,%rcx,2), %xmm3, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vpaddd %xmm4, %xmm3, %xmm3
; AVX1-NEXT: vpmaddwd (%rdi,%rcx,2), %xmm2, %xmm2
[X86][AVX] combineLoopMAddPattern - support 256-bit cases on AVX1 via SplitBinaryOpsAndApply llvm-svn: 326189
2018-02-27 20:20:37 +08:00
; AVX1-NEXT: vpaddd %xmm1, %xmm2, %xmm1
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: jne .LBB2_1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # %bb.2: # %middle.block
[X86][AVX] combineLoopMAddPattern - support 256-bit cases on AVX1 via SplitBinaryOpsAndApply llvm-svn: 326189
2018-02-27 20:20:37 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpaddd %xmm3, %xmm2, %xmm2
[X86][AVX] combineLoopMAddPattern - support 256-bit cases on AVX1 via SplitBinaryOpsAndApply llvm-svn: 326189
2018-02-27 20:20:37 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-LABEL: _Z10test_shortPsS_i_512:
; AVX2: # %bb.0: # %entry
; AVX2-NEXT: movl %edx, %eax
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX2-NEXT: xorl %ecx, %ecx
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: .LBB2_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
; AVX2-NEXT: vmovdqu (%rsi,%rcx,2), %ymm2
; AVX2-NEXT: vpmaddwd (%rdi,%rcx,2), %ymm2, %ymm2
; AVX2-NEXT: vpaddd %ymm1, %ymm2, %ymm1
; AVX2-NEXT: addq $16, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: jne .LBB2_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: # %bb.2: # %middle.block
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm0
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
; AVX512-LABEL: _Z10test_shortPsS_i_512:
; AVX512: # %bb.0: # %entry
; AVX512-NEXT: movl %edx, %eax
; AVX512-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512-NEXT: xorl %ecx, %ecx
; AVX512-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: .LBB2_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512-NEXT: vmovdqu (%rsi,%rcx,2), %ymm1
; AVX512-NEXT: vpmaddwd (%rdi,%rcx,2), %ymm1, %ymm1
; AVX512-NEXT: vpaddd %zmm0, %zmm1, %zmm0
; AVX512-NEXT: addq $16, %rcx
; AVX512-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: jne .LBB2_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512-NEXT: # %bb.2: # %middle.block
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vzeroupper
; AVX512-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <16 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <16 x i16>*
%wide.load = load <16 x i16>, <16 x i16>* %5, align 2
%6 = sext <16 x i16> %wide.load to <16 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <16 x i16>*
%wide.load14 = load <16 x i16>, <16 x i16>* %8, align 2
%9 = sext <16 x i16> %wide.load14 to <16 x i32>
%10 = mul nsw <16 x i32> %9, %6
%11 = add nsw <16 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf1 = shufflevector <16 x i32> %11, <16 x i32> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx1 = add <16 x i32> %11, %rdx.shuf1
%rdx.shuf = shufflevector <16 x i32> %bin.rdx1, <16 x i32> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <16 x i32> %bin.rdx1, %rdx.shuf
%rdx.shuf15 = shufflevector <16 x i32> %bin.rdx, <16 x i32> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <16 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <16 x i32> %bin.rdx16, <16 x i32> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <16 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <16 x i32> %bin.rdx18, i32 0
ret i32 %13
}
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
define i32 @_Z10test_shortPsS_i_1024(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z10test_shortPsS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm8
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: xorl %ecx, %ecx
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm2, %xmm2
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: pxor %xmm4, %xmm4
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: pxor %xmm1, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm3, %xmm3
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB3_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm5
; SSE2-NEXT: movdqu 16(%rdi,%rcx,2), %xmm6
; SSE2-NEXT: movdqu 32(%rdi,%rcx,2), %xmm7
; SSE2-NEXT: movdqu 48(%rdi,%rcx,2), %xmm9
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm0
; SSE2-NEXT: pmaddwd %xmm5, %xmm0
; SSE2-NEXT: paddd %xmm0, %xmm2
; SSE2-NEXT: movdqu 16(%rsi,%rcx,2), %xmm0
; SSE2-NEXT: pmaddwd %xmm6, %xmm0
; SSE2-NEXT: paddd %xmm0, %xmm4
; SSE2-NEXT: movdqu 32(%rsi,%rcx,2), %xmm0
; SSE2-NEXT: pmaddwd %xmm7, %xmm0
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movdqu 48(%rsi,%rcx,2), %xmm0
; SSE2-NEXT: pmaddwd %xmm9, %xmm0
; SSE2-NEXT: paddd %xmm0, %xmm3
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB3_1
; SSE2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm8, %xmm4
; SSE2-NEXT: paddd %xmm8, %xmm3
; SSE2-NEXT: paddd %xmm4, %xmm3
; SSE2-NEXT: paddd %xmm8, %xmm2
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: paddd %xmm8, %xmm1
; SSE2-NEXT: paddd %xmm3, %xmm1
; SSE2-NEXT: paddd %xmm2, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
[X86] Bring back the MOV64r0 pseudo instruction This patch brings back the MOV64r0 pseudo instruction for zeroing a 64-bit register. This replaces the SUBREG_TO_REG MOV32r0 sequence we use today. Post register allocation we will rewrite the MOV64r0 to a 32-bit xor with an implicit def of the 64-bit register similar to what we do for the various XMM/YMM/ZMM zeroing pseudos. My main motivation is to enable the spill optimization in foldMemoryOperandImpl. As we were seeing some code that repeatedly did "xor eax, eax; store eax;" to spill several registers with a new xor for each store. With this optimization enabled we get a store of a 0 immediate instead of an xor. Though I admit the ideal solution would be one xor where there are multiple spills. I don't believe we have a test case that shows this optimization in here. I'll see if I can try to reduce one from the code were looking at. There's definitely some other machine CSE(and maybe other passes) behavior changes exposed by this patch. So it seems like there might be some other deficiencies in SUBREG_TO_REG handling. Differential Revision: https://reviews.llvm.org/D52757 llvm-svn: 345165
2018-10-25 01:32:09 +08:00
; SSE2-NEXT: paddd %xmm1, %xmm0
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-LABEL: _Z10test_shortPsS_i_1024:
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpxor %xmm2, %xmm2, %xmm2
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: .p2align 4, 0x90
; AVX1-NEXT: .LBB3_1: # %vector.body
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vmovdqu (%rsi,%rcx,2), %xmm3
; AVX1-NEXT: vmovdqu 16(%rsi,%rcx,2), %xmm4
; AVX1-NEXT: vmovdqu 32(%rsi,%rcx,2), %xmm5
; AVX1-NEXT: vmovdqu 48(%rsi,%rcx,2), %xmm6
; AVX1-NEXT: vpmaddwd 48(%rdi,%rcx,2), %xmm6, %xmm6
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm7
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vpaddd %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpmaddwd 32(%rdi,%rcx,2), %xmm5, %xmm5
; AVX1-NEXT: vpaddd %xmm2, %xmm5, %xmm2
; AVX1-NEXT: vinsertf128 $1, %xmm6, %ymm2, %ymm2
; AVX1-NEXT: vpmaddwd 16(%rdi,%rcx,2), %xmm4, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpaddd %xmm5, %xmm4, %xmm4
; AVX1-NEXT: vpmaddwd (%rdi,%rcx,2), %xmm3, %xmm3
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpaddd %xmm1, %xmm3, %xmm1
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm1, %ymm1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
; AVX1-NEXT: jne .LBB3_1
; AVX1-NEXT: # %bb.2: # %middle.block
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vpaddd %xmm0, %xmm2, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm2
[CodeGen] Enhance machine PHIs optimization Summary: Make machine PHIs optimization to work for single value register taken from several different copies. This is the first step to fix PR38917. This change allows to get rid of redundant PHIs (see opt_phis2.mir test) to make the subsequent optimizations (like CSE) possible and simpler. For instance, before this patch the code like this: %b = COPY %z ... %a = PHI %bb1, %a; %bb2, %b could be optimized to: %a = %b but the code like this: %c = COPY %z ... %b = COPY %z ... %a = PHI %bb1, %a; %bb2, %b; %bb3, %c would remain unchanged. With this patch the latter case will be optimized: %a = %z```. Committed on behalf of: Anton Afanasyev anton.a.afanasyev@gmail.com Reviewers: RKSimon, MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54839 llvm-svn: 349271
2018-12-15 22:37:01 +08:00
; AVX1-NEXT: vpaddd %xmm5, %xmm2, %xmm2
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm5, %xmm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm4, %xmm2
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vpaddd %xmm3, %xmm0, %xmm0
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-LABEL: _Z10test_shortPsS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2: # %bb.0: # %entry
; AVX2-NEXT: movl %edx, %eax
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX2-NEXT: xorl %ecx, %ecx
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vpxor %xmm2, %xmm2, %xmm2
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: .p2align 4, 0x90
; AVX2-NEXT: .LBB3_1: # %vector.body
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX2-NEXT: vmovdqu (%rsi,%rcx,2), %ymm3
; AVX2-NEXT: vmovdqu 32(%rsi,%rcx,2), %ymm4
; AVX2-NEXT: vpmaddwd 32(%rdi,%rcx,2), %ymm4, %ymm4
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vpaddd %ymm2, %ymm4, %ymm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX2-NEXT: vpmaddwd (%rdi,%rcx,2), %ymm3, %ymm3
; AVX2-NEXT: vpaddd %ymm1, %ymm3, %ymm1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: addq $16, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
; AVX2-NEXT: jne .LBB3_1
; AVX2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm1
; AVX2-NEXT: vpaddd %ymm0, %ymm2, %ymm0
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-LABEL: _Z10test_shortPsS_i_1024:
; AVX512F: # %bb.0: # %entry
; AVX512F-NEXT: movl %edx, %eax
; AVX512F-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512F-NEXT: xorl %ecx, %ecx
; AVX512F-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: .p2align 4, 0x90
; AVX512F-NEXT: .LBB3_1: # %vector.body
; AVX512F-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX512F-NEXT: vmovdqu (%rsi,%rcx,2), %ymm2
; AVX512F-NEXT: vmovdqu 32(%rsi,%rcx,2), %ymm3
; AVX512F-NEXT: vpmaddwd 32(%rdi,%rcx,2), %ymm3, %ymm3
; AVX512F-NEXT: vpmaddwd (%rdi,%rcx,2), %ymm2, %ymm2
; AVX512F-NEXT: vinserti64x4 $1, %ymm3, %zmm2, %zmm2
; AVX512F-NEXT: vpaddd %zmm1, %zmm2, %zmm1
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: addq $16, %rcx
; AVX512F-NEXT: cmpq %rcx, %rax
; AVX512F-NEXT: jne .LBB3_1
; AVX512F-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX512F-NEXT: vpaddd %zmm0, %zmm1, %zmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512F-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: vmovd %xmm0, %eax
; AVX512F-NEXT: vzeroupper
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: _Z10test_shortPsS_i_1024:
; AVX512BW: # %bb.0: # %entry
; AVX512BW-NEXT: movl %edx, %eax
; AVX512BW-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512BW-NEXT: xorl %ecx, %ecx
; AVX512BW-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX512BW-NEXT: .p2align 4, 0x90
; AVX512BW-NEXT: .LBB3_1: # %vector.body
; AVX512BW-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512BW-NEXT: vmovdqu64 (%rsi,%rcx,2), %zmm2
; AVX512BW-NEXT: vpmaddwd (%rdi,%rcx,2), %zmm2, %zmm2
; AVX512BW-NEXT: vpaddd %zmm1, %zmm2, %zmm1
; AVX512BW-NEXT: addq $16, %rcx
; AVX512BW-NEXT: cmpq %rcx, %rax
; AVX512BW-NEXT: jne .LBB3_1
; AVX512BW-NEXT: # %bb.2: # %middle.block
; AVX512BW-NEXT: vpaddd %zmm0, %zmm1, %zmm0
; AVX512BW-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512BW-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512BW-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-NEXT: vmovd %xmm0, %eax
; AVX512BW-NEXT: vzeroupper
; AVX512BW-NEXT: retq
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
%vec.phi = phi <32 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
%4 = getelementptr inbounds i16, i16* %0, i64 %index
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
%5 = bitcast i16* %4 to <32 x i16>*
%wide.load = load <32 x i16>, <32 x i16>* %5, align 2
%6 = sext <32 x i16> %wide.load to <32 x i32>
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
%7 = getelementptr inbounds i16, i16* %1, i64 %index
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
%8 = bitcast i16* %7 to <32 x i16>*
%wide.load14 = load <32 x i16>, <32 x i16>* %8, align 2
%9 = sext <32 x i16> %wide.load14 to <32 x i32>
%10 = mul nsw <32 x i32> %9, %6
%11 = add nsw <32 x i32> %10, %vec.phi
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
%rdx.shuf2 = shufflevector <32 x i32> %11, <32 x i32> undef, <32 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx2 = add <32 x i32> %11, %rdx.shuf2
%rdx.shuf1 = shufflevector <32 x i32> %bin.rdx2, <32 x i32> undef, <32 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx1 = add <32 x i32> %bin.rdx2, %rdx.shuf1
%rdx.shuf = shufflevector <32 x i32> %bin.rdx1, <32 x i32> undef, <32 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <32 x i32> %bin.rdx1, %rdx.shuf
%rdx.shuf15 = shufflevector <32 x i32> %bin.rdx, <32 x i32> undef, <32 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <32 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <32 x i32> %bin.rdx16, <32 x i32> undef, <32 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <32 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <32 x i32> %bin.rdx18, i32 0
ret i32 %13
}
define i32 @_Z9test_charPcS_i_128(i8* nocapture readonly, i8* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z9test_charPcS_i_128:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB4_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movd {{.*#+}} xmm1 = mem[0],zero,zero,zero
; SSE2-NEXT: punpcklbw {{.*#+}} xmm1 = xmm1[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: movd {{.*#+}} xmm2 = mem[0],zero,zero,zero
; SSE2-NEXT: punpcklbw {{.*#+}} xmm2 = xmm2[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: psraw $8, %xmm1
; SSE2-NEXT: psraw $8, %xmm2
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: pmullw %xmm1, %xmm2
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: punpcklwd {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1],xmm1[2],xmm2[2],xmm1[3],xmm2[3]
; SSE2-NEXT: psrad $16, %xmm1
; SSE2-NEXT: paddd %xmm1, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB4_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: movd %xmm0, %eax
; SSE2-NEXT: retq
;
; AVX-LABEL: _Z9test_charPcS_i_128:
; AVX: # %bb.0: # %entry
; AVX-NEXT: movl %edx, %eax
; AVX-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX-NEXT: xorl %ecx, %ecx
; AVX-NEXT: .p2align 4, 0x90
; AVX-NEXT: .LBB4_1: # %vector.body
; AVX-NEXT: # =>This Inner Loop Header: Depth=1
; AVX-NEXT: vpmovsxbd (%rdi,%rcx), %xmm1
; AVX-NEXT: vpmovsxbd (%rsi,%rcx), %xmm2
; AVX-NEXT: vpmulld %xmm1, %xmm2, %xmm1
; AVX-NEXT: vpaddd %xmm0, %xmm1, %xmm0
; AVX-NEXT: addq $16, %rcx
; AVX-NEXT: cmpq %rcx, %rax
; AVX-NEXT: jne .LBB4_1
; AVX-NEXT: # %bb.2: # %middle.block
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <4 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i8, i8* %0, i64 %index
%5 = bitcast i8* %4 to <4 x i8>*
%wide.load = load <4 x i8>, <4 x i8>* %5, align 1
%6 = sext <4 x i8> %wide.load to <4 x i32>
%7 = getelementptr inbounds i8, i8* %1, i64 %index
%8 = bitcast i8* %7 to <4 x i8>*
%wide.load14 = load <4 x i8>, <4 x i8>* %8, align 1
%9 = sext <4 x i8> %wide.load14 to <4 x i32>
%10 = mul nsw <4 x i32> %9, %6
%11 = add nsw <4 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf17 = shufflevector <4 x i32> %11, <4 x i32> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
%bin.rdx18 = add <4 x i32> %11, %rdx.shuf17
%rdx.shuf19 = shufflevector <4 x i32> %bin.rdx18, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
%bin.rdx20 = add <4 x i32> %bin.rdx18, %rdx.shuf19
%13 = extractelement <4 x i32> %bin.rdx20, i32 0
ret i32 %13
}
define i32 @_Z9test_charPcS_i_256(i8* nocapture readonly, i8* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z9test_charPcS_i_256:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm1, %xmm1
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB5_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movq {{.*#+}} xmm2 = mem[0],zero
; SSE2-NEXT: punpcklbw {{.*#+}} xmm2 = xmm2[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: movq {{.*#+}} xmm3 = mem[0],zero
; SSE2-NEXT: punpcklbw {{.*#+}} xmm3 = xmm3[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: psraw $8, %xmm2
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: psraw $8, %xmm3
; SSE2-NEXT: pmaddwd %xmm2, %xmm3
; SSE2-NEXT: paddd %xmm3, %xmm1
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB5_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
; AVX1-LABEL: _Z9test_charPcS_i_256:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: .p2align 4, 0x90
; AVX1-NEXT: .LBB5_1: # %vector.body
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
; AVX1-NEXT: vpmovsxbw (%rdi,%rcx), %xmm1
; AVX1-NEXT: vpmovsxbw (%rsi,%rcx), %xmm2
; AVX1-NEXT: vpmaddwd %xmm1, %xmm2, %xmm1
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm1
; AVX1-NEXT: vblendps {{.*#+}} ymm0 = ymm1[0,1,2,3],ymm0[4,5,6,7]
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
; AVX1-NEXT: jne .LBB5_1
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX256-LABEL: _Z9test_charPcS_i_256:
; AVX256: # %bb.0: # %entry
; AVX256-NEXT: movl %edx, %eax
; AVX256-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX256-NEXT: xorl %ecx, %ecx
; AVX256-NEXT: .p2align 4, 0x90
; AVX256-NEXT: .LBB5_1: # %vector.body
; AVX256-NEXT: # =>This Inner Loop Header: Depth=1
; AVX256-NEXT: vpmovsxbw (%rdi,%rcx), %xmm1
; AVX256-NEXT: vpmovsxbw (%rsi,%rcx), %xmm2
; AVX256-NEXT: vpmaddwd %xmm1, %xmm2, %xmm1
; AVX256-NEXT: vpaddd %ymm0, %ymm1, %ymm0
; AVX256-NEXT: addq $16, %rcx
; AVX256-NEXT: cmpq %rcx, %rax
; AVX256-NEXT: jne .LBB5_1
; AVX256-NEXT: # %bb.2: # %middle.block
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: vmovd %xmm0, %eax
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <8 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i8, i8* %0, i64 %index
%5 = bitcast i8* %4 to <8 x i8>*
%wide.load = load <8 x i8>, <8 x i8>* %5, align 1
%6 = sext <8 x i8> %wide.load to <8 x i32>
%7 = getelementptr inbounds i8, i8* %1, i64 %index
%8 = bitcast i8* %7 to <8 x i8>*
%wide.load14 = load <8 x i8>, <8 x i8>* %8, align 1
%9 = sext <8 x i8> %wide.load14 to <8 x i32>
%10 = mul nsw <8 x i32> %9, %6
%11 = add nsw <8 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf15 = shufflevector <8 x i32> %11, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <8 x i32> %11, %rdx.shuf15
%rdx.shuf17 = shufflevector <8 x i32> %bin.rdx16, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <8 x i32> %bin.rdx16, %rdx.shuf17
%rdx.shuf19 = shufflevector <8 x i32> %bin.rdx18, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx20 = add <8 x i32> %bin.rdx18, %rdx.shuf19
%13 = extractelement <8 x i32> %bin.rdx20, i32 0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
ret i32 %13
}
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
define i32 @_Z9test_charPcS_i_512(i8* nocapture readonly, i8* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z9test_charPcS_i_512:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0: # %entry
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; SSE2-NEXT: xorl %ecx, %ecx
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: pxor %xmm2, %xmm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm1, %xmm1
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: .LBB6_1: # %vector.body
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: movdqu (%rdi,%rcx), %xmm3
; SSE2-NEXT: movdqu (%rsi,%rcx), %xmm4
; SSE2-NEXT: punpckhbw {{.*#+}} xmm5 = xmm5[8],xmm3[8],xmm5[9],xmm3[9],xmm5[10],xmm3[10],xmm5[11],xmm3[11],xmm5[12],xmm3[12],xmm5[13],xmm3[13],xmm5[14],xmm3[14],xmm5[15],xmm3[15]
; SSE2-NEXT: psraw $8, %xmm5
; SSE2-NEXT: punpckhbw {{.*#+}} xmm6 = xmm6[8],xmm4[8],xmm6[9],xmm4[9],xmm6[10],xmm4[10],xmm6[11],xmm4[11],xmm6[12],xmm4[12],xmm6[13],xmm4[13],xmm6[14],xmm4[14],xmm6[15],xmm4[15]
; SSE2-NEXT: psraw $8, %xmm6
; SSE2-NEXT: pmaddwd %xmm5, %xmm6
; SSE2-NEXT: paddd %xmm6, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: punpcklbw {{.*#+}} xmm3 = xmm3[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: psraw $8, %xmm3
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: punpcklbw {{.*#+}} xmm4 = xmm4[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: psraw $8, %xmm4
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: pmaddwd %xmm3, %xmm4
; SSE2-NEXT: paddd %xmm4, %xmm2
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: jne .LBB6_1
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm0, %xmm2
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: paddd %xmm0, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm2, %xmm1
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-LABEL: _Z9test_charPcS_i_512:
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX1-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: .LBB6_1: # %vector.body
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
[DAGCombiner] Change the SDLoc on split extloads (2/N) In DAGCombiner, we try to simplify this pattern: ([s|z]ext (load ...)) Conceptually, a new extload which is created while splitting the load should have the same debug location as the load. Making this change affects the IROrder of the new load, causing some test case churn. In practice, the new location is never different from the location of the [s|z]ext, at least not during check-llvm or a stage2 build. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46156 llvm-svn: 331301
2018-05-02 03:29:15 +08:00
; AVX1-NEXT: vpmovsxbw (%rdi,%rcx), %xmm2
; AVX1-NEXT: vpmovsxbw 8(%rdi,%rcx), %xmm3
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmovsxbw (%rsi,%rcx), %xmm4
[DAGCombiner] Change the SDLoc on split extloads (2/N) In DAGCombiner, we try to simplify this pattern: ([s|z]ext (load ...)) Conceptually, a new extload which is created while splitting the load should have the same debug location as the load. Making this change affects the IROrder of the new load, causing some test case churn. In practice, the new location is never different from the location of the [s|z]ext, at least not during check-llvm or a stage2 build. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46156 llvm-svn: 331301
2018-05-02 03:29:15 +08:00
; AVX1-NEXT: vpmaddwd %xmm2, %xmm4, %xmm2
; AVX1-NEXT: vpmovsxbw 8(%rsi,%rcx), %xmm4
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmaddwd %xmm3, %xmm4, %xmm3
[DAGCombiner] Change the SDLoc on split extloads (2/N) In DAGCombiner, we try to simplify this pattern: ([s|z]ext (load ...)) Conceptually, a new extload which is created while splitting the load should have the same debug location as the load. Making this change affects the IROrder of the new load, causing some test case churn. In practice, the new location is never different from the location of the [s|z]ext, at least not during check-llvm or a stage2 build. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46156 llvm-svn: 331301
2018-05-02 03:29:15 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vpaddd %xmm4, %xmm3, %xmm3
; AVX1-NEXT: vpaddd %xmm1, %xmm2, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: jne .LBB6_1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # %bb.2: # %middle.block
[X86][AVX] combineLoopMAddPattern - support 256-bit cases on AVX1 via SplitBinaryOpsAndApply llvm-svn: 326189
2018-02-27 20:20:37 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpaddd %xmm3, %xmm2, %xmm2
[X86][AVX] combineLoopMAddPattern - support 256-bit cases on AVX1 via SplitBinaryOpsAndApply llvm-svn: 326189
2018-02-27 20:20:37 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-LABEL: _Z9test_charPcS_i_512:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0: # %entry
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: movl %edx, %eax
[X86] SET0 to use XMM registers where possible PR26018 PR32862 Differential Revision: https://reviews.llvm.org/D35839 llvm-svn: 309298
2017-07-28 01:47:01 +08:00
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; AVX2-NEXT: xorl %ecx, %ecx
[X86] SET0 to use XMM registers where possible PR26018 PR32862 Differential Revision: https://reviews.llvm.org/D35839 llvm-svn: 309298
2017-07-28 01:47:01 +08:00
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: .LBB6_1: # %vector.body
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; AVX2-NEXT: vpmovsxbw (%rdi,%rcx), %ymm2
; AVX2-NEXT: vpmovsxbw (%rsi,%rcx), %ymm3
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: vpmaddwd %ymm2, %ymm3, %ymm2
; AVX2-NEXT: vpaddd %ymm1, %ymm2, %ymm1
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; AVX2-NEXT: addq $16, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: jne .LBB6_1
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2-NEXT: # %bb.2: # %middle.block
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm0
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-LABEL: _Z9test_charPcS_i_512:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0: # %entry
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX512-NEXT: movl %edx, %eax
[X86] SET0 to use XMM registers where possible PR26018 PR32862 Differential Revision: https://reviews.llvm.org/D35965 llvm-svn: 309926
2017-08-03 16:50:18 +08:00
; AVX512-NEXT: vpxor %xmm0, %xmm0, %xmm0
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; AVX512-NEXT: xorl %ecx, %ecx
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX512-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: .LBB6_1: # %vector.body
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX512-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Add patterns to turn an insert into lower subvector of a zero vector into a move instruction which will implicitly zero the upper elements. Ideally we'd be able to emit the SUBREG_TO_REG without the explicit register->register move, but we'd need to be sure the producing operation would select something that guaranteed the upper bits were already zeroed. llvm-svn: 312450
2017-09-04 01:52:25 +08:00
; AVX512-NEXT: vpmovsxbw (%rdi,%rcx), %ymm1
; AVX512-NEXT: vpmovsxbw (%rsi,%rcx), %ymm2
; AVX512-NEXT: vpmaddwd %ymm1, %ymm2, %ymm1
; AVX512-NEXT: vpaddd %zmm0, %zmm1, %zmm0
Reapply fix PR23384 (part 3 of 3) r304824 (was reverted in r305720). The root cause of reverting was fixed - PR33514. Summary: The patch makes instruction count the highest priority for LSR solution for X86 (previously registers had highest priority). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D30562 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310289
2017-08-08 03:56:34 +08:00
; AVX512-NEXT: addq $16, %rcx
; AVX512-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: jne .LBB6_1
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512-NEXT: # %bb.2: # %middle.block
[X86] Add patterns to turn an insert into lower subvector of a zero vector into a move instruction which will implicitly zero the upper elements. Ideally we'd be able to emit the SUBREG_TO_REG without the explicit register->register move, but we'd need to be sure the producing operation would select something that guaranteed the upper bits were already zeroed. llvm-svn: 312450
2017-09-04 01:52:25 +08:00
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
[x86] Enable some support for lowerVectorShuffleWithUndefHalf with AVX-512 Summary: This teaches 512-bit shuffles to detect unused halfs in order to reduce shuffle size. We may need to refine the 512-bit exit point. I couldn't remember if we had good cross lane shuffles for 8/16 bit with AVX-512 or not. I believe this is step towards being able to handle D36454 without a special case. From here we need to improve our ability to combine extract_subvector with insert_subvector and other extract_subvectors. And we need to support narrowing binary operations where we don't demand all elements. This may be improvements to DAGCombiner::narrowExtractedVectorBinOp(by recognizing an insert_subvector in addition to concat) or we may need a target specific combiner. Reviewers: RKSimon, zvi, delena, jbhateja Reviewed By: RKSimon, jbhateja Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36601 llvm-svn: 310724
2017-08-12 00:20:05 +08:00
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] Enable some support for lowerVectorShuffleWithUndefHalf with AVX-512 Summary: This teaches 512-bit shuffles to detect unused halfs in order to reduce shuffle size. We may need to refine the 512-bit exit point. I couldn't remember if we had good cross lane shuffles for 8/16 bit with AVX-512 or not. I believe this is step towards being able to handle D36454 without a special case. From here we need to improve our ability to combine extract_subvector with insert_subvector and other extract_subvectors. And we need to support narrowing binary operations where we don't demand all elements. This may be improvements to DAGCombiner::narrowExtractedVectorBinOp(by recognizing an insert_subvector in addition to concat) or we may need a target specific combiner. Reviewers: RKSimon, zvi, delena, jbhateja Reviewed By: RKSimon, jbhateja Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36601 llvm-svn: 310724
2017-08-12 00:20:05 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] Enable some support for lowerVectorShuffleWithUndefHalf with AVX-512 Summary: This teaches 512-bit shuffles to detect unused halfs in order to reduce shuffle size. We may need to refine the 512-bit exit point. I couldn't remember if we had good cross lane shuffles for 8/16 bit with AVX-512 or not. I believe this is step towards being able to handle D36454 without a special case. From here we need to improve our ability to combine extract_subvector with insert_subvector and other extract_subvectors. And we need to support narrowing binary operations where we don't demand all elements. This may be improvements to DAGCombiner::narrowExtractedVectorBinOp(by recognizing an insert_subvector in addition to concat) or we may need a target specific combiner. Reviewers: RKSimon, zvi, delena, jbhateja Reviewed By: RKSimon, jbhateja Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36601 llvm-svn: 310724
2017-08-12 00:20:05 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
Update the madd.ll test with utils/update_llc_test_checks.py (NFC) llvm-svn: 300740
2017-04-20 04:08:14 +08:00
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vzeroupper
; AVX512-NEXT: retq
Use PMADDWD to expand reduction in a loop Summary: PMADDWD can help improve 8/16 bit integer mutliply-add operation performance for cases like: for (int i = 0; i < count; i++) a += x[i] * y[i]; Reviewers: wmi, davidxl, hfinkel, RKSimon, zvi, mkuper Reviewed By: mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31679 llvm-svn: 299776
2017-04-07 23:41:52 +08:00
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <16 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i8, i8* %0, i64 %index
%5 = bitcast i8* %4 to <16 x i8>*
%wide.load = load <16 x i8>, <16 x i8>* %5, align 1
%6 = sext <16 x i8> %wide.load to <16 x i32>
%7 = getelementptr inbounds i8, i8* %1, i64 %index
%8 = bitcast i8* %7 to <16 x i8>*
%wide.load14 = load <16 x i8>, <16 x i8>* %8, align 1
%9 = sext <16 x i8> %wide.load14 to <16 x i32>
%10 = mul nsw <16 x i32> %9, %6
%11 = add nsw <16 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf = shufflevector <16 x i32> %11, <16 x i32> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <16 x i32> %11, %rdx.shuf
%rdx.shuf15 = shufflevector <16 x i32> %bin.rdx, <16 x i32> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <16 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <16 x i32> %bin.rdx16, <16 x i32> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <16 x i32> %bin.rdx16, %rdx.shuf17
%rdx.shuf19 = shufflevector <16 x i32> %bin.rdx18, <16 x i32> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx20 = add <16 x i32> %bin.rdx18, %rdx.shuf19
%13 = extractelement <16 x i32> %bin.rdx20, i32 0
ret i32 %13
}
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
define i32 @_Z9test_charPcS_i_1024(i8* nocapture readonly, i8* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: _Z9test_charPcS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm8, %xmm8
; SSE2-NEXT: xorl %ecx, %ecx
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: pxor %xmm2, %xmm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm4, %xmm4
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: pxor %xmm1, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: pxor %xmm3, %xmm3
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: .LBB7_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: movdqu (%rdi,%rcx), %xmm10
; SSE2-NEXT: movdqu 16(%rdi,%rcx), %xmm7
; SSE2-NEXT: movdqu (%rsi,%rcx), %xmm9
; SSE2-NEXT: movdqu 16(%rsi,%rcx), %xmm0
; SSE2-NEXT: punpckhbw {{.*#+}} xmm5 = xmm5[8],xmm7[8],xmm5[9],xmm7[9],xmm5[10],xmm7[10],xmm5[11],xmm7[11],xmm5[12],xmm7[12],xmm5[13],xmm7[13],xmm5[14],xmm7[14],xmm5[15],xmm7[15]
[X86] Preserve undef information when creating a punpckl/hbw from a v16i8 where all the even or odd elements are undef. Previously if V2 was unused we ended up using V1 for both inputs as part of the code that follows the new code. By using lowerVectorShuffleWithUNPCK we keep the undef nature of V2 in the output. As near as I can tell this makes v16i8 behavior consistent with every other VT now. This does mean that we give the register allocator freedom to fill in random registers now and create false dependencies. But like I said we're already doing that for other types. llvm-svn: 347296
2018-11-20 17:04:01 +08:00
; SSE2-NEXT: psraw $8, %xmm5
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: punpckhbw {{.*#+}} xmm6 = xmm6[8],xmm0[8],xmm6[9],xmm0[9],xmm6[10],xmm0[10],xmm6[11],xmm0[11],xmm6[12],xmm0[12],xmm6[13],xmm0[13],xmm6[14],xmm0[14],xmm6[15],xmm0[15]
[X86] Preserve undef information when creating a punpckl/hbw from a v16i8 where all the even or odd elements are undef. Previously if V2 was unused we ended up using V1 for both inputs as part of the code that follows the new code. By using lowerVectorShuffleWithUNPCK we keep the undef nature of V2 in the output. As near as I can tell this makes v16i8 behavior consistent with every other VT now. This does mean that we give the register allocator freedom to fill in random registers now and create false dependencies. But like I said we're already doing that for other types. llvm-svn: 347296
2018-11-20 17:04:01 +08:00
; SSE2-NEXT: psraw $8, %xmm6
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: pmaddwd %xmm5, %xmm6
; SSE2-NEXT: paddd %xmm6, %xmm3
; SSE2-NEXT: punpcklbw {{.*#+}} xmm5 = xmm5[0],xmm7[0],xmm5[1],xmm7[1],xmm5[2],xmm7[2],xmm5[3],xmm7[3],xmm5[4],xmm7[4],xmm5[5],xmm7[5],xmm5[6],xmm7[6],xmm5[7],xmm7[7]
; SSE2-NEXT: psraw $8, %xmm5
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: psraw $8, %xmm0
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: pmaddwd %xmm5, %xmm0
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: punpckhbw {{.*#+}} xmm0 = xmm0[8],xmm10[8],xmm0[9],xmm10[9],xmm0[10],xmm10[10],xmm0[11],xmm10[11],xmm0[12],xmm10[12],xmm0[13],xmm10[13],xmm0[14],xmm10[14],xmm0[15],xmm10[15]
; SSE2-NEXT: psraw $8, %xmm0
; SSE2-NEXT: punpckhbw {{.*#+}} xmm5 = xmm5[8],xmm9[8],xmm5[9],xmm9[9],xmm5[10],xmm9[10],xmm5[11],xmm9[11],xmm5[12],xmm9[12],xmm5[13],xmm9[13],xmm5[14],xmm9[14],xmm5[15],xmm9[15]
; SSE2-NEXT: psraw $8, %xmm5
; SSE2-NEXT: pmaddwd %xmm0, %xmm5
; SSE2-NEXT: paddd %xmm5, %xmm4
; SSE2-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0],xmm10[0],xmm0[1],xmm10[1],xmm0[2],xmm10[2],xmm0[3],xmm10[3],xmm0[4],xmm10[4],xmm0[5],xmm10[5],xmm0[6],xmm10[6],xmm0[7],xmm10[7]
; SSE2-NEXT: psraw $8, %xmm0
; SSE2-NEXT: punpcklbw {{.*#+}} xmm5 = xmm5[0],xmm9[0],xmm5[1],xmm9[1],xmm5[2],xmm9[2],xmm5[3],xmm9[3],xmm5[4],xmm9[4],xmm5[5],xmm9[5],xmm5[6],xmm9[6],xmm5[7],xmm9[7]
; SSE2-NEXT: psraw $8, %xmm5
; SSE2-NEXT: pmaddwd %xmm0, %xmm5
; SSE2-NEXT: paddd %xmm5, %xmm2
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: addq $32, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; SSE2-NEXT: jne .LBB7_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; SSE2-NEXT: paddd %xmm8, %xmm4
; SSE2-NEXT: paddd %xmm8, %xmm3
; SSE2-NEXT: paddd %xmm4, %xmm3
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: paddd %xmm8, %xmm2
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: paddd %xmm8, %xmm1
; SSE2-NEXT: paddd %xmm3, %xmm1
[X86] Don't mark SEXTLOAD from v4i8/v4i16/v8i8 as Custom on pre-sse4.1. This seems to be getting in the way more than its helping. This does mean we stop scalarizing some cases, but I'm not convinced the scalarization was really better. Some of the changes to vsel-cmp-load.ll are a regression but D56156 should fix it. llvm-svn: 350159
2018-12-30 11:05:07 +08:00
; SSE2-NEXT: paddd %xmm2, %xmm1
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
[X86] Bring back the MOV64r0 pseudo instruction This patch brings back the MOV64r0 pseudo instruction for zeroing a 64-bit register. This replaces the SUBREG_TO_REG MOV32r0 sequence we use today. Post register allocation we will rewrite the MOV64r0 to a 32-bit xor with an implicit def of the 64-bit register similar to what we do for the various XMM/YMM/ZMM zeroing pseudos. My main motivation is to enable the spill optimization in foldMemoryOperandImpl. As we were seeing some code that repeatedly did "xor eax, eax; store eax;" to spill several registers with a new xor for each store. With this optimization enabled we get a store of a 0 immediate instead of an xor. Though I admit the ideal solution would be one xor where there are multiple spills. I don't believe we have a test case that shows this optimization in here. I'll see if I can try to reduce one from the code were looking at. There's definitely some other machine CSE(and maybe other passes) behavior changes exposed by this patch. So it seems like there might be some other deficiencies in SUBREG_TO_REG handling. Differential Revision: https://reviews.llvm.org/D52757 llvm-svn: 345165
2018-10-25 01:32:09 +08:00
; SSE2-NEXT: paddd %xmm1, %xmm0
Revert r345165 "[X86] Bring back the MOV64r0 pseudo instruction" Google is reporting regressions on some benchmarks. llvm-svn: 345785
2018-11-01 05:53:24 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; SSE2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-LABEL: _Z9test_charPcS_i_1024:
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpxor %xmm2, %xmm2, %xmm2
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: .LBB7_1: # %vector.body
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpmovsxbw (%rdi,%rcx), %xmm3
; AVX1-NEXT: vpmovsxbw 8(%rdi,%rcx), %xmm4
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmovsxbw 16(%rdi,%rcx), %xmm5
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpmovsxbw 24(%rdi,%rcx), %xmm6
; AVX1-NEXT: vpmovsxbw (%rsi,%rcx), %xmm7
; AVX1-NEXT: vpmaddwd %xmm3, %xmm7, %xmm3
; AVX1-NEXT: vpmovsxbw 8(%rsi,%rcx), %xmm7
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmaddwd %xmm4, %xmm7, %xmm4
; AVX1-NEXT: vpmovsxbw 16(%rsi,%rcx), %xmm7
; AVX1-NEXT: vpmaddwd %xmm5, %xmm7, %xmm5
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpmovsxbw 24(%rsi,%rcx), %xmm7
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmaddwd %xmm6, %xmm7, %xmm6
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm7
; AVX1-NEXT: vpaddd %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpaddd %xmm2, %xmm5, %xmm2
; AVX1-NEXT: vinsertf128 $1, %xmm6, %ymm2, %ymm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpaddd %xmm5, %xmm4, %xmm4
; AVX1-NEXT: vpaddd %xmm1, %xmm3, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm1, %ymm1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: addq $32, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: jne .LBB7_1
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpaddd %xmm0, %xmm2, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm2
[CodeGen] Enhance machine PHIs optimization Summary: Make machine PHIs optimization to work for single value register taken from several different copies. This is the first step to fix PR38917. This change allows to get rid of redundant PHIs (see opt_phis2.mir test) to make the subsequent optimizations (like CSE) possible and simpler. For instance, before this patch the code like this: %b = COPY %z ... %a = PHI %bb1, %a; %bb2, %b could be optimized to: %a = %b but the code like this: %c = COPY %z ... %b = COPY %z ... %a = PHI %bb1, %a; %bb2, %b; %bb3, %c would remain unchanged. With this patch the latter case will be optimized: %a = %z```. Committed on behalf of: Anton Afanasyev anton.a.afanasyev@gmail.com Reviewers: RKSimon, MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54839 llvm-svn: 349271
2018-12-15 22:37:01 +08:00
; AVX1-NEXT: vpaddd %xmm5, %xmm2, %xmm2
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm5, %xmm2
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX1-NEXT: vpaddd %xmm2, %xmm4, %xmm2
; AVX1-NEXT: vpaddd %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-LABEL: _Z9test_charPcS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2: # %bb.0: # %entry
; AVX2-NEXT: movl %edx, %eax
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX2-NEXT: xorl %ecx, %ecx
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vpxor %xmm2, %xmm2, %xmm2
; AVX2-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: .LBB7_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX2-NEXT: vpmovsxbw (%rdi,%rcx), %ymm3
; AVX2-NEXT: vpmovsxbw 16(%rdi,%rcx), %ymm4
; AVX2-NEXT: vpmovsxbw (%rsi,%rcx), %ymm5
; AVX2-NEXT: vpmaddwd %ymm3, %ymm5, %ymm3
; AVX2-NEXT: vpaddd %ymm1, %ymm3, %ymm1
; AVX2-NEXT: vpmovsxbw 16(%rsi,%rcx), %ymm3
; AVX2-NEXT: vpmaddwd %ymm4, %ymm3, %ymm3
; AVX2-NEXT: vpaddd %ymm2, %ymm3, %ymm2
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: addq $32, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: jne .LBB7_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm1
; AVX2-NEXT: vpaddd %ymm0, %ymm2, %ymm0
; AVX2-NEXT: vpaddd %ymm0, %ymm1, %ymm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-LABEL: _Z9test_charPcS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F: # %bb.0: # %entry
; AVX512F-NEXT: movl %edx, %eax
; AVX512F-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512F-NEXT: xorl %ecx, %ecx
; AVX512F-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: .LBB7_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512F-NEXT: vpmovsxbw (%rdi,%rcx), %ymm2
; AVX512F-NEXT: vpmovsxbw 16(%rdi,%rcx), %ymm3
; AVX512F-NEXT: vpmovsxbw (%rsi,%rcx), %ymm4
; AVX512F-NEXT: vpmaddwd %ymm2, %ymm4, %ymm2
; AVX512F-NEXT: vpmovsxbw 16(%rsi,%rcx), %ymm4
; AVX512F-NEXT: vpmaddwd %ymm3, %ymm4, %ymm3
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX512F-NEXT: vinserti64x4 $1, %ymm3, %zmm2, %zmm2
; AVX512F-NEXT: vpaddd %zmm1, %zmm2, %zmm1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: addq $32, %rcx
; AVX512F-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512F-NEXT: jne .LBB7_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: # %bb.2: # %middle.block
[X86] Remove the max vector width restriction from combineLoopMAddPattern and rely splitOpsAndApply to handle splitting. This seems to be a net improvement. There's still an issue under avx512f where we have a 512-bit vpaddd, but not vpmaddwd so we end up doing two 256-bit vpmaddwds and inserting the results before a 512-bit vpaddd. It might be better to do two 512-bits paddds with zeros in the upper half. Same number of instructions, but breaks a dependency. llvm-svn: 337656
2018-07-23 03:44:35 +08:00
; AVX512F-NEXT: vpaddd %zmm0, %zmm1, %zmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512F-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512F-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512F-NEXT: vmovd %xmm0, %eax
; AVX512F-NEXT: vzeroupper
; AVX512F-NEXT: retq
;
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-LABEL: _Z9test_charPcS_i_1024:
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW: # %bb.0: # %entry
; AVX512BW-NEXT: movl %edx, %eax
; AVX512BW-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512BW-NEXT: xorl %ecx, %ecx
; AVX512BW-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX512BW-NEXT: .p2align 4, 0x90
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-NEXT: .LBB7_1: # %vector.body
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512BW-NEXT: vpmovsxbw (%rdi,%rcx), %zmm2
; AVX512BW-NEXT: vpmovsxbw (%rsi,%rcx), %zmm3
; AVX512BW-NEXT: vpmaddwd %zmm2, %zmm3, %zmm2
; AVX512BW-NEXT: vpaddd %zmm1, %zmm2, %zmm1
; AVX512BW-NEXT: addq $32, %rcx
; AVX512BW-NEXT: cmpq %rcx, %rax
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512BW-NEXT: jne .LBB7_1
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW-NEXT: # %bb.2: # %middle.block
; AVX512BW-NEXT: vpaddd %zmm0, %zmm1, %zmm0
; AVX512BW-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512BW-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512BW-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512BW-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more madd reduction tests with wider vectors. We had no test case exercising 512-bit vpmaddwd usage. llvm-svn: 323840
2018-01-31 08:30:32 +08:00
; AVX512BW-NEXT: vmovd %xmm0, %eax
; AVX512BW-NEXT: vzeroupper
; AVX512BW-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <32 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i8, i8* %0, i64 %index
%5 = bitcast i8* %4 to <32 x i8>*
%wide.load = load <32 x i8>, <32 x i8>* %5, align 1
%6 = sext <32 x i8> %wide.load to <32 x i32>
%7 = getelementptr inbounds i8, i8* %1, i64 %index
%8 = bitcast i8* %7 to <32 x i8>*
%wide.load14 = load <32 x i8>, <32 x i8>* %8, align 1
%9 = sext <32 x i8> %wide.load14 to <32 x i32>
%10 = mul nsw <32 x i32> %9, %6
%11 = add nsw <32 x i32> %10, %vec.phi
%index.next = add i64 %index, 32
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf1 = shufflevector <32 x i32> %11, <32 x i32> undef, <32 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx1 = add <32 x i32> %11, %rdx.shuf1
%rdx.shuf = shufflevector <32 x i32> %bin.rdx1, <32 x i32> undef, <32 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <32 x i32> %bin.rdx1, %rdx.shuf
%rdx.shuf15 = shufflevector <32 x i32> %bin.rdx, <32 x i32> undef, <32 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx32 = add <32 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <32 x i32> %bin.rdx32, <32 x i32> undef, <32 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <32 x i32> %bin.rdx32, %rdx.shuf17
%rdx.shuf19 = shufflevector <32 x i32> %bin.rdx18, <32 x i32> undef, <32 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx20 = add <32 x i32> %bin.rdx18, %rdx.shuf19
%13 = extractelement <32 x i32> %bin.rdx20, i32 0
ret i32 %13
}
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
define i32 @test_unsigned_short_128(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: test_unsigned_short_128:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB8_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movq {{.*#+}} xmm1 = mem[0],zero
; SSE2-NEXT: movq {{.*#+}} xmm2 = mem[0],zero
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pmulhuw %xmm1, %xmm3
; SSE2-NEXT: pmullw %xmm1, %xmm2
; SSE2-NEXT: punpcklwd {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[1],xmm3[1],xmm2[2],xmm3[2],xmm2[3],xmm3[3]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB8_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: movd %xmm0, %eax
; SSE2-NEXT: retq
;
; AVX-LABEL: test_unsigned_short_128:
; AVX: # %bb.0: # %entry
; AVX-NEXT: movl %edx, %eax
; AVX-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX-NEXT: xorl %ecx, %ecx
; AVX-NEXT: .p2align 4, 0x90
; AVX-NEXT: .LBB8_1: # %vector.body
; AVX-NEXT: # =>This Inner Loop Header: Depth=1
; AVX-NEXT: vpmovzxwd {{.*#+}} xmm1 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX-NEXT: vpmovzxwd {{.*#+}} xmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX-NEXT: vpmulld %xmm1, %xmm2, %xmm1
; AVX-NEXT: vpaddd %xmm0, %xmm1, %xmm0
; AVX-NEXT: addq $16, %rcx
; AVX-NEXT: cmpq %rcx, %rax
; AVX-NEXT: jne .LBB8_1
; AVX-NEXT: # %bb.2: # %middle.block
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <4 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <4 x i16>*
%wide.load = load <4 x i16>, <4 x i16>* %5, align 2
%6 = zext <4 x i16> %wide.load to <4 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <4 x i16>*
%wide.load14 = load <4 x i16>, <4 x i16>* %8, align 2
%9 = zext <4 x i16> %wide.load14 to <4 x i32>
%10 = mul nsw <4 x i32> %9, %6
%11 = add nsw <4 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf15 = shufflevector <4 x i32> %11, <4 x i32> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
%bin.rdx16 = add <4 x i32> %11, %rdx.shuf15
%rdx.shuf17 = shufflevector <4 x i32> %bin.rdx16, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <4 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <4 x i32> %bin.rdx18, i32 0
ret i32 %13
}
define i32 @test_unsigned_short_256(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: test_unsigned_short_256:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm1, %xmm1
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB9_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm2
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm4
; SSE2-NEXT: pmulhuw %xmm2, %xmm4
; SSE2-NEXT: pmullw %xmm2, %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm2
; SSE2-NEXT: punpcklwd {{.*#+}} xmm2 = xmm2[0],xmm4[0],xmm2[1],xmm4[1],xmm2[2],xmm4[2],xmm2[3],xmm4[3]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: punpckhwd {{.*#+}} xmm3 = xmm3[4],xmm4[4],xmm3[5],xmm4[5],xmm3[6],xmm4[6],xmm3[7],xmm4[7]
; SSE2-NEXT: paddd %xmm3, %xmm1
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB9_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: movd %xmm0, %eax
; SSE2-NEXT: retq
;
; AVX1-LABEL: test_unsigned_short_256:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: .p2align 4, 0x90
; AVX1-NEXT: .LBB9_1: # %vector.body
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm1 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm3 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm1, %xmm3, %xmm1
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm3 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpaddd %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vpaddd %xmm0, %xmm2, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
; AVX1-NEXT: jne .LBB9_1
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX256-LABEL: test_unsigned_short_256:
; AVX256: # %bb.0: # %entry
; AVX256-NEXT: movl %edx, %eax
; AVX256-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX256-NEXT: xorl %ecx, %ecx
; AVX256-NEXT: .p2align 4, 0x90
; AVX256-NEXT: .LBB9_1: # %vector.body
; AVX256-NEXT: # =>This Inner Loop Header: Depth=1
; AVX256-NEXT: vpmovzxwd {{.*#+}} ymm1 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX256-NEXT: vpmovzxwd {{.*#+}} ymm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX256-NEXT: vpmulld %ymm1, %ymm2, %ymm1
; AVX256-NEXT: vpaddd %ymm0, %ymm1, %ymm0
; AVX256-NEXT: addq $16, %rcx
; AVX256-NEXT: cmpq %rcx, %rax
; AVX256-NEXT: jne .LBB9_1
; AVX256-NEXT: # %bb.2: # %middle.block
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX256-NEXT: vmovd %xmm0, %eax
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <8 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <8 x i16>*
%wide.load = load <8 x i16>, <8 x i16>* %5, align 2
%6 = zext <8 x i16> %wide.load to <8 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <8 x i16>*
%wide.load14 = load <8 x i16>, <8 x i16>* %8, align 2
%9 = zext <8 x i16> %wide.load14 to <8 x i32>
%10 = mul nsw <8 x i32> %9, %6
%11 = add nsw <8 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf = shufflevector <8 x i32> %11, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <8 x i32> %11, %rdx.shuf
%rdx.shuf15 = shufflevector <8 x i32> %bin.rdx, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <8 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <8 x i32> %bin.rdx16, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <8 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <8 x i32> %bin.rdx18, i32 0
ret i32 %13
}
define i32 @test_unsigned_short_512(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: test_unsigned_short_512:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm1, %xmm1
; SSE2-NEXT: pxor %xmm3, %xmm3
; SSE2-NEXT: pxor %xmm2, %xmm2
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB10_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm4
; SSE2-NEXT: movdqu 16(%rdi,%rcx,2), %xmm8
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm6
; SSE2-NEXT: movdqu 16(%rsi,%rcx,2), %xmm7
; SSE2-NEXT: movdqa %xmm6, %xmm5
; SSE2-NEXT: pmulhuw %xmm4, %xmm5
; SSE2-NEXT: pmullw %xmm4, %xmm6
; SSE2-NEXT: movdqa %xmm6, %xmm4
; SSE2-NEXT: punpcklwd {{.*#+}} xmm4 = xmm4[0],xmm5[0],xmm4[1],xmm5[1],xmm4[2],xmm5[2],xmm4[3],xmm5[3]
; SSE2-NEXT: paddd %xmm4, %xmm0
; SSE2-NEXT: punpckhwd {{.*#+}} xmm6 = xmm6[4],xmm5[4],xmm6[5],xmm5[5],xmm6[6],xmm5[6],xmm6[7],xmm5[7]
; SSE2-NEXT: paddd %xmm6, %xmm1
; SSE2-NEXT: movdqa %xmm7, %xmm4
; SSE2-NEXT: pmulhuw %xmm8, %xmm4
; SSE2-NEXT: pmullw %xmm8, %xmm7
; SSE2-NEXT: movdqa %xmm7, %xmm5
; SSE2-NEXT: punpcklwd {{.*#+}} xmm5 = xmm5[0],xmm4[0],xmm5[1],xmm4[1],xmm5[2],xmm4[2],xmm5[3],xmm4[3]
; SSE2-NEXT: paddd %xmm5, %xmm3
; SSE2-NEXT: punpckhwd {{.*#+}} xmm7 = xmm7[4],xmm4[4],xmm7[5],xmm4[5],xmm7[6],xmm4[6],xmm7[7],xmm4[7]
; SSE2-NEXT: paddd %xmm7, %xmm2
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB10_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: paddd %xmm3, %xmm0
; SSE2-NEXT: paddd %xmm2, %xmm1
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
; AVX1-LABEL: test_unsigned_short_512:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX1-NEXT: .p2align 4, 0x90
; AVX1-NEXT: .LBB10_1: # %vector.body
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm3 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm5 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm2, %xmm6, %xmm2
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm3, %xmm6, %xmm3
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm4, %xmm6, %xmm4
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm5, %xmm6, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm6
; AVX1-NEXT: vpaddd %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vpaddd %xmm1, %xmm3, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm1, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vpaddd %xmm2, %xmm4, %xmm2
; AVX1-NEXT: vpaddd %xmm0, %xmm5, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
; AVX1-NEXT: jne .LBB10_1
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpaddd %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpaddd %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_unsigned_short_512:
; AVX2: # %bb.0: # %entry
; AVX2-NEXT: movl %edx, %eax
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX2-NEXT: xorl %ecx, %ecx
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX2-NEXT: .p2align 4, 0x90
; AVX2-NEXT: .LBB10_1: # %vector.body
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm3 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm2, %ymm4, %ymm2
; AVX2-NEXT: vpaddd %ymm1, %ymm2, %ymm1
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpaddd %ymm0, %ymm2, %ymm0
; AVX2-NEXT: addq $16, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
; AVX2-NEXT: jne .LBB10_1
; AVX2-NEXT: # %bb.2: # %middle.block
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
; AVX512-LABEL: test_unsigned_short_512:
; AVX512: # %bb.0: # %entry
; AVX512-NEXT: movl %edx, %eax
; AVX512-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512-NEXT: xorl %ecx, %ecx
; AVX512-NEXT: .p2align 4, 0x90
; AVX512-NEXT: .LBB10_1: # %vector.body
; AVX512-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm1 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmulld %zmm1, %zmm2, %zmm1
; AVX512-NEXT: vpaddd %zmm0, %zmm1, %zmm0
; AVX512-NEXT: addq $16, %rcx
; AVX512-NEXT: cmpq %rcx, %rax
; AVX512-NEXT: jne .LBB10_1
; AVX512-NEXT: # %bb.2: # %middle.block
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vzeroupper
; AVX512-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <16 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <16 x i16>*
%wide.load = load <16 x i16>, <16 x i16>* %5, align 2
%6 = zext <16 x i16> %wide.load to <16 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <16 x i16>*
%wide.load14 = load <16 x i16>, <16 x i16>* %8, align 2
%9 = zext <16 x i16> %wide.load14 to <16 x i32>
%10 = mul nsw <16 x i32> %9, %6
%11 = add nsw <16 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf1 = shufflevector <16 x i32> %11, <16 x i32> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx1 = add <16 x i32> %11, %rdx.shuf1
%rdx.shuf = shufflevector <16 x i32> %bin.rdx1, <16 x i32> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <16 x i32> %bin.rdx1, %rdx.shuf
%rdx.shuf15 = shufflevector <16 x i32> %bin.rdx, <16 x i32> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <16 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <16 x i32> %bin.rdx16, <16 x i32> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <16 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <16 x i32> %bin.rdx18, i32 0
ret i32 %13
}
define i32 @test_unsigned_short_1024(i16* nocapture readonly, i16* nocapture readonly, i32) local_unnamed_addr #0 {
; SSE2-LABEL: test_unsigned_short_1024:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %edx, %eax
; SSE2-NEXT: pxor %xmm8, %xmm8
; SSE2-NEXT: xorl %ecx, %ecx
; SSE2-NEXT: pxor %xmm3, %xmm3
; SSE2-NEXT: pxor %xmm9, %xmm9
; SSE2-NEXT: pxor %xmm10, %xmm10
; SSE2-NEXT: pxor %xmm4, %xmm4
; SSE2-NEXT: pxor %xmm6, %xmm6
; SSE2-NEXT: pxor %xmm5, %xmm5
; SSE2-NEXT: pxor %xmm7, %xmm7
; SSE2-NEXT: .p2align 4, 0x90
; SSE2-NEXT: .LBB11_1: # %vector.body
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movdqu 48(%rdi,%rcx,2), %xmm0
; SSE2-NEXT: movdqu 48(%rsi,%rcx,2), %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm2
; SSE2-NEXT: pmulhuw %xmm0, %xmm2
; SSE2-NEXT: pmullw %xmm0, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm0
; SSE2-NEXT: punpckhwd {{.*#+}} xmm0 = xmm0[4],xmm2[4],xmm0[5],xmm2[5],xmm0[6],xmm2[6],xmm0[7],xmm2[7]
; SSE2-NEXT: paddd %xmm0, %xmm7
; SSE2-NEXT: movdqu 32(%rdi,%rcx,2), %xmm0
; SSE2-NEXT: punpcklwd {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1],xmm1[2],xmm2[2],xmm1[3],xmm2[3]
; SSE2-NEXT: movdqu 32(%rsi,%rcx,2), %xmm2
; SSE2-NEXT: paddd %xmm1, %xmm5
; SSE2-NEXT: movdqa %xmm2, %xmm1
; SSE2-NEXT: pmulhuw %xmm0, %xmm1
; SSE2-NEXT: pmullw %xmm0, %xmm2
; SSE2-NEXT: movdqa %xmm2, %xmm0
; SSE2-NEXT: punpckhwd {{.*#+}} xmm0 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
; SSE2-NEXT: paddd %xmm0, %xmm6
; SSE2-NEXT: movdqu (%rdi,%rcx,2), %xmm0
; SSE2-NEXT: punpcklwd {{.*#+}} xmm2 = xmm2[0],xmm1[0],xmm2[1],xmm1[1],xmm2[2],xmm1[2],xmm2[3],xmm1[3]
; SSE2-NEXT: movdqu (%rsi,%rcx,2), %xmm1
; SSE2-NEXT: paddd %xmm2, %xmm4
; SSE2-NEXT: movdqa %xmm1, %xmm2
; SSE2-NEXT: pmulhuw %xmm0, %xmm2
; SSE2-NEXT: pmullw %xmm0, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm0
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0],xmm2[0],xmm0[1],xmm2[1],xmm0[2],xmm2[2],xmm0[3],xmm2[3]
; SSE2-NEXT: paddd %xmm0, %xmm8
; SSE2-NEXT: movdqu 16(%rdi,%rcx,2), %xmm0
; SSE2-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4],xmm2[4],xmm1[5],xmm2[5],xmm1[6],xmm2[6],xmm1[7],xmm2[7]
; SSE2-NEXT: movdqu 16(%rsi,%rcx,2), %xmm2
; SSE2-NEXT: paddd %xmm1, %xmm3
; SSE2-NEXT: movdqa %xmm2, %xmm1
; SSE2-NEXT: pmulhuw %xmm0, %xmm1
; SSE2-NEXT: pmullw %xmm0, %xmm2
; SSE2-NEXT: movdqa %xmm2, %xmm0
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; SSE2-NEXT: paddd %xmm0, %xmm9
; SSE2-NEXT: punpckhwd {{.*#+}} xmm2 = xmm2[4],xmm1[4],xmm2[5],xmm1[5],xmm2[6],xmm1[6],xmm2[7],xmm1[7]
; SSE2-NEXT: paddd %xmm2, %xmm10
; SSE2-NEXT: addq $16, %rcx
; SSE2-NEXT: cmpq %rcx, %rax
; SSE2-NEXT: jne .LBB11_1
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: paddd %xmm6, %xmm3
; SSE2-NEXT: paddd %xmm7, %xmm10
; SSE2-NEXT: paddd %xmm3, %xmm10
; SSE2-NEXT: paddd %xmm4, %xmm8
; SSE2-NEXT: paddd %xmm5, %xmm9
; SSE2-NEXT: paddd %xmm10, %xmm9
; SSE2-NEXT: paddd %xmm8, %xmm9
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm9[2,3,0,1]
; SSE2-NEXT: paddd %xmm9, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
; AVX1-LABEL: test_unsigned_short_1024:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %edx, %eax
; AVX1-NEXT: vpxor %xmm8, %xmm8, %xmm8
; AVX1-NEXT: xorl %ecx, %ecx
; AVX1-NEXT: vpxor %xmm2, %xmm2, %xmm2
; AVX1-NEXT: vpxor %xmm9, %xmm9, %xmm9
; AVX1-NEXT: vpxor %xmm3, %xmm3, %xmm3
; AVX1-NEXT: .p2align 4, 0x90
; AVX1-NEXT: .LBB11_1: # %vector.body
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm5 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm7 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm0 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm12 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm10 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm11 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm1 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm4, %xmm1, %xmm1
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm5, %xmm4, %xmm4
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm5 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm6, %xmm5, %xmm5
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm7 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm0, %xmm7, %xmm13
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm7 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm12, %xmm7, %xmm7
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm0 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm10, %xmm0, %xmm10
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm0 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
; AVX1-NEXT: vpmulld %xmm11, %xmm0, %xmm11
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm1, %xmm0
; AVX1-NEXT: vpaddd %xmm2, %xmm4, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm2
; AVX1-NEXT: vextractf128 $1, %ymm8, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm5, %xmm0
[X86] Teach X86MCInstLower to swap operands of commutable instructions to enable 2-byte VEX encoding. Summary: The 2 source operands commutable instructions are encoded in the VEX.VVVV field and the r/m field of the MODRM byte plus the VEX.B field. The VEX.B field is missing from the 2-byte VEX encoding. If the VEX.VVVV source is 0-7 and the other register is 8-15 we can swap them to avoid needing the VEX.B field. This works as long as the VEX.W, VEX.mmmmm, and VEX.X fields are also not needed. Fixes PR36706. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68550
2019-11-05 11:58:53 +08:00
; AVX1-NEXT: vpaddd %xmm6, %xmm8, %xmm1
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm8
; AVX1-NEXT: vextractf128 $1, %ymm9, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm13, %xmm0
[X86] Teach X86MCInstLower to swap operands of commutable instructions to enable 2-byte VEX encoding. Summary: The 2 source operands commutable instructions are encoded in the VEX.VVVV field and the r/m field of the MODRM byte plus the VEX.B field. The VEX.B field is missing from the 2-byte VEX encoding. If the VEX.VVVV source is 0-7 and the other register is 8-15 we can swap them to avoid needing the VEX.B field. This works as long as the VEX.W, VEX.mmmmm, and VEX.X fields are also not needed. Fixes PR36706. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68550
2019-11-05 11:58:53 +08:00
; AVX1-NEXT: vpaddd %xmm7, %xmm9, %xmm1
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm9
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm10, %xmm0
; AVX1-NEXT: vpaddd %xmm3, %xmm11, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm3
; AVX1-NEXT: addq $16, %rcx
; AVX1-NEXT: cmpq %rcx, %rax
; AVX1-NEXT: jne .LBB11_1
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vpaddd %xmm3, %xmm2, %xmm0
; AVX1-NEXT: vextractf128 $1, %ymm8, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm9, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
; AVX1-NEXT: vpaddd %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpaddd %xmm2, %xmm4, %xmm2
; AVX1-NEXT: vpaddd %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpaddd %xmm0, %xmm9, %xmm0
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpaddd %xmm0, %xmm8, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_unsigned_short_1024:
; AVX2: # %bb.0: # %entry
; AVX2-NEXT: movl %edx, %eax
; AVX2-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX2-NEXT: xorl %ecx, %ecx
; AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vpxor %xmm2, %xmm2, %xmm2
; AVX2-NEXT: vpxor %xmm3, %xmm3, %xmm3
; AVX2-NEXT: .p2align 4, 0x90
; AVX2-NEXT: .LBB11_1: # %vector.body
; AVX2-NEXT: # =>This Inner Loop Header: Depth=1
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm5 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm6 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm7 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm8 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm4, %ymm8, %ymm4
; AVX2-NEXT: vpaddd %ymm2, %ymm4, %ymm2
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm5, %ymm4, %ymm4
; AVX2-NEXT: vpaddd %ymm1, %ymm4, %ymm1
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm6, %ymm4, %ymm4
; AVX2-NEXT: vpaddd %ymm0, %ymm4, %ymm0
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
; AVX2-NEXT: vpmulld %ymm7, %ymm4, %ymm4
; AVX2-NEXT: vpaddd %ymm3, %ymm4, %ymm3
; AVX2-NEXT: addq $16, %rcx
; AVX2-NEXT: cmpq %rcx, %rax
; AVX2-NEXT: jne .LBB11_1
; AVX2-NEXT: # %bb.2: # %middle.block
; AVX2-NEXT: vpaddd %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpaddd %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[x86] narrow a shuffle that doesn't use or set any high elements This isn't the final fix for our reduction/horizontal codegen, but it takes care of a lot of the problems. After we narrow the shuffle, existing combines for insert/extract and binops kick in, and we end up with cheaper 128-bit ops. The avg and mul reduction tests show an existing shuffle lowering hole for AVX2/AVX512. I think in its most minimal form this is: https://bugs.llvm.org/show_bug.cgi?id=40434 ...but we might need multiple fixes to get it right. Differential Revision: https://reviews.llvm.org/D57156 llvm-svn: 352209
2019-01-25 23:37:42 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[x86] add and use fast horizontal vector math subtarget feature This is the planned follow-up to D52997. Here we are reducing horizontal vector math codegen by default. AMD Jaguar (btver2) should have no difference with this patch because it has fast-hops. (If we want to set that bit for other CPUs, let me know.) The code changes are small, but there are many test diffs. For files that are specifically testing for hops, I added RUNs to distinguish fast/slow, so we can see the consequences side-by-side. For files that are primarily concerned with codegen other than hops, I just updated the CHECK lines to reflect the new default codegen. To recap the recent horizontal op story: 1. Before rL343727, we were producing hops for all subtargets for a variety of patterns. Hops were likely not optimal for all targets though. 2. The IR improvement in r343727 exposed a hole in the backend hop pattern matching, so we reduced hop codegen for all subtargets. That was bad for Jaguar (PR39195). 3. We restored the hop codegen for all targets with rL344141. Good for Jaguar, but probably bad for other CPUs. 4. This patch allows us to distinguish when we want to produce hops, so everyone can be happy. I'm not sure if we have the best predicate here, but the intent is to undo the extra hop-iness that was enabled by r344141. Differential Revision: https://reviews.llvm.org/D53095 llvm-svn: 344361
2018-10-13 00:41:02 +08:00
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
; AVX512-LABEL: test_unsigned_short_1024:
; AVX512: # %bb.0: # %entry
; AVX512-NEXT: movl %edx, %eax
; AVX512-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX512-NEXT: xorl %ecx, %ecx
; AVX512-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX512-NEXT: .p2align 4, 0x90
; AVX512-NEXT: .LBB11_1: # %vector.body
; AVX512-NEXT: # =>This Inner Loop Header: Depth=1
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm3 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm4 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmulld %zmm2, %zmm4, %zmm2
; AVX512-NEXT: vpaddd %zmm1, %zmm2, %zmm1
; AVX512-NEXT: vpmovzxwd {{.*#+}} zmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero,mem[8],zero,mem[9],zero,mem[10],zero,mem[11],zero,mem[12],zero,mem[13],zero,mem[14],zero,mem[15],zero
; AVX512-NEXT: vpmulld %zmm3, %zmm2, %zmm2
; AVX512-NEXT: vpaddd %zmm0, %zmm2, %zmm0
; AVX512-NEXT: addq $16, %rcx
; AVX512-NEXT: cmpq %rcx, %rax
; AVX512-NEXT: jne .LBB11_1
; AVX512-NEXT: # %bb.2: # %middle.block
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
[DAGCombiner] fold extract_subvector of extract_subvector This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
2019-01-30 03:13:39 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
[DAGCombiner] narrow vector binops when extraction is cheap Narrowing vector binops came up in the demanded bits discussion in D52912. I don't think we're going to be able to do this transform in IR as a canonicalization because of the risk of creating unsupported widths for vector ops, but we already have a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap(). This is currently enabled for x86, ARM, and AArch64 (although only x86 has existing regression test diffs). This is artificially limited to not look through bitcasts because there are so many test diffs already, but that's marked with a TODO and is a small follow-up. Differential Revision: https://reviews.llvm.org/D53784 llvm-svn: 345602
2018-10-30 22:14:34 +08:00
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[X86] Add more MADD recurrence test cases with larger and narrower vector widths. llvm-svn: 337650
2018-07-22 13:16:47 +08:00
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vzeroupper
; AVX512-NEXT: retq
entry:
%3 = zext i32 %2 to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <32 x i32> [ %11, %vector.body ], [ zeroinitializer, %entry ]
%4 = getelementptr inbounds i16, i16* %0, i64 %index
%5 = bitcast i16* %4 to <32 x i16>*
%wide.load = load <32 x i16>, <32 x i16>* %5, align 2
%6 = zext <32 x i16> %wide.load to <32 x i32>
%7 = getelementptr inbounds i16, i16* %1, i64 %index
%8 = bitcast i16* %7 to <32 x i16>*
%wide.load14 = load <32 x i16>, <32 x i16>* %8, align 2
%9 = zext <32 x i16> %wide.load14 to <32 x i32>
%10 = mul nsw <32 x i32> %9, %6
%11 = add nsw <32 x i32> %10, %vec.phi
%index.next = add i64 %index, 16
%12 = icmp eq i64 %index.next, %3
br i1 %12, label %middle.block, label %vector.body
middle.block:
%rdx.shuf2 = shufflevector <32 x i32> %11, <32 x i32> undef, <32 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx2 = add <32 x i32> %11, %rdx.shuf2
%rdx.shuf1 = shufflevector <32 x i32> %bin.rdx2, <32 x i32> undef, <32 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx1 = add <32 x i32> %bin.rdx2, %rdx.shuf1
%rdx.shuf = shufflevector <32 x i32> %bin.rdx1, <32 x i32> undef, <32 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <32 x i32> %bin.rdx1, %rdx.shuf
%rdx.shuf15 = shufflevector <32 x i32> %bin.rdx, <32 x i32> undef, <32 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx16 = add <32 x i32> %bin.rdx, %rdx.shuf15
%rdx.shuf17 = shufflevector <32 x i32> %bin.rdx16, <32 x i32> undef, <32 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx18 = add <32 x i32> %bin.rdx16, %rdx.shuf17
%13 = extractelement <32 x i32> %bin.rdx18, i32 0
ret i32 %13
}
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
define <4 x i32> @pmaddwd_8(<8 x i16> %A, <8 x i16> %B) {
; SSE2-LABEL: pmaddwd_8:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm1, %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_8:
; AVX: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX-NEXT: retq
%a = sext <8 x i16> %A to <8 x i32>
%b = sext <8 x i16> %B to <8 x i32>
%m = mul nsw <8 x i32> %a, %b
%odd = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %odd, %even
ret <4 x i32> %ret
}
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
define <4 x i32> @pmaddwd_8_swapped(<8 x i16> %A, <8 x i16> %B) {
; SSE2-LABEL: pmaddwd_8_swapped:
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm1, %xmm0
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_8_swapped:
; AVX: # %bb.0:
; AVX-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
; AVX-NEXT: retq
%a = sext <8 x i16> %A to <8 x i32>
%b = sext <8 x i16> %B to <8 x i32>
%m = mul nsw <8 x i32> %a, %b
%odd = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %even, %odd
ret <4 x i32> %ret
}
define <4 x i32> @larger_mul(<16 x i16> %A, <16 x i16> %B) {
; SSE2-LABEL: larger_mul:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: pmulhw %xmm2, %xmm1
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: pmullw %xmm2, %xmm0
; SSE2-NEXT: movdqa %xmm0, %xmm2
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: punpckhwd {{.*#+}} xmm2 = xmm2[4],xmm1[4],xmm2[5],xmm1[5],xmm2[6],xmm1[6],xmm2[7],xmm1[7]
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,2],xmm2[0,2]
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,3],xmm2[1,3]
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: paddd %xmm1, %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: larger_mul:
; AVX1: # %bb.0:
; AVX1-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX2-LABEL: larger_mul:
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX2-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
; AVX2-NEXT: vzeroupper
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX2-NEXT: retq
;
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512-LABEL: larger_mul:
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX512: # %bb.0:
; AVX512-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512-NEXT: vpmulld %zmm1, %zmm0, %zmm0
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512-NEXT: vpextrd $2, %xmm0, %eax
; AVX512-NEXT: vpinsrd $1, %eax, %xmm0, %xmm1
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm2
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vpinsrd $2, %eax, %xmm1, %xmm1
; AVX512-NEXT: vpextrd $2, %xmm2, %eax
; AVX512-NEXT: vpinsrd $3, %eax, %xmm1, %xmm1
[DAGCombiner] (insert_vector_elt (vector_shuffle X, Y), (extract_vector_elt X, N), IdxC) -> (vector_shuffle X, Y) Summary: This is beneficial when the shuffle is only used once and end up being generated in a few places when some node is combined into a shuffle. Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66718 llvm-svn: 370326
2019-08-29 18:35:51 +08:00
; AVX512-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[1,3,2,3]
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512-NEXT: vpextrd $1, %xmm2, %eax
; AVX512-NEXT: vpinsrd $2, %eax, %xmm0, %xmm0
; AVX512-NEXT: vpextrd $3, %xmm2, %eax
; AVX512-NEXT: vpinsrd $3, %eax, %xmm0, %xmm0
; AVX512-NEXT: vpaddd %xmm0, %xmm1, %xmm0
; AVX512-NEXT: vzeroupper
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX512-NEXT: retq
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
%a = sext <16 x i16> %A to <16 x i32>
%b = sext <16 x i16> %B to <16 x i32>
%m = mul nsw <16 x i32> %a, %b
%odd = shufflevector <16 x i32> %m, <16 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <16 x i32> %m, <16 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %odd, %even
ret <4 x i32> %ret
}
define <8 x i32> @pmaddwd_16(<16 x i16> %A, <16 x i16> %B) {
; SSE2-LABEL: pmaddwd_16:
; SSE2: # %bb.0:
; SSE2-NEXT: pmaddwd %xmm2, %xmm0
; SSE2-NEXT: pmaddwd %xmm3, %xmm1
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: pmaddwd_16:
; AVX1: # %bb.0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpmaddwd %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX256-LABEL: pmaddwd_16:
; AVX256: # %bb.0:
; AVX256-NEXT: vpmaddwd %ymm1, %ymm0, %ymm0
; AVX256-NEXT: retq
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
%a = sext <16 x i16> %A to <16 x i32>
%b = sext <16 x i16> %B to <16 x i32>
%m = mul nsw <16 x i32> %a, %b
%odd = shufflevector <16 x i32> %m, <16 x i32> undef, <8 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14>
%even = shufflevector <16 x i32> %m, <16 x i32> undef, <8 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>
%ret = add <8 x i32> %odd, %even
ret <8 x i32> %ret
}
define <16 x i32> @pmaddwd_32(<32 x i16> %A, <32 x i16> %B) {
; SSE2-LABEL: pmaddwd_32:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm4, %xmm0
; SSE2-NEXT: pmaddwd %xmm5, %xmm1
; SSE2-NEXT: pmaddwd %xmm6, %xmm2
; SSE2-NEXT: pmaddwd %xmm7, %xmm3
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: pmaddwd_32:
; AVX1: # %bb.0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm6
; AVX1-NEXT: vpmaddwd %xmm6, %xmm4, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm6
; AVX1-NEXT: vpmaddwd %xmm6, %xmm5, %xmm5
; AVX1-NEXT: vpmaddwd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm5, %ymm0, %ymm0
; AVX1-NEXT: vpmaddwd %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm1, %ymm1
; AVX1-NEXT: retq
;
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX2-LABEL: pmaddwd_32:
; AVX2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX2-NEXT: vpmaddwd %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpmaddwd %ymm3, %ymm1, %ymm1
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX2-NEXT: retq
;
; AVX512F-LABEL: pmaddwd_32:
; AVX512F: # %bb.0:
[X86] Pass v32i16/v64i8 in zmm registers on KNL target. gcc and icc pass these types in zmm registers in zmm registers. This patch implements a quick hack to override the register type before calling convention handling to one that is legal. Longer term we might want to do something similar to 256-bit integer registers on AVX1 where we just split all the operations. Fixes PR42957 Differential Revision: https://reviews.llvm.org/D66708 llvm-svn: 370495
2019-08-31 01:35:08 +08:00
; AVX512F-NEXT: vextracti64x4 $1, %zmm1, %ymm2
; AVX512F-NEXT: vextracti64x4 $1, %zmm0, %ymm3
; AVX512F-NEXT: vpmaddwd %ymm2, %ymm3, %ymm2
; AVX512F-NEXT: vpmaddwd %ymm1, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: pmaddwd_32:
; AVX512BW: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512BW-NEXT: vpmaddwd %zmm1, %zmm0, %zmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX512BW-NEXT: retq
%a = sext <32 x i16> %A to <32 x i32>
%b = sext <32 x i16> %B to <32 x i32>
%m = mul nsw <32 x i32> %a, %b
%odd = shufflevector <32 x i32> %m, <32 x i32> undef, <16 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14, i32 16, i32 18, i32 20, i32 22, i32 24, i32 26, i32 28, i32 30>
%even = shufflevector <32 x i32> %m, <32 x i32> undef, <16 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 17, i32 19, i32 21, i32 23, i32 25, i32 27, i32 29, i32 31>
%ret = add <16 x i32> %odd, %even
ret <16 x i32> %ret
}
define <4 x i32> @pmaddwd_const(<8 x i16> %A) {
; SSE2-LABEL: pmaddwd_const:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd {{.*}}(%rip), %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_const:
; AVX: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX-NEXT: vpmaddwd {{.*}}(%rip), %xmm0, %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; AVX-NEXT: retq
%a = sext <8 x i16> %A to <8 x i32>
%m = mul nsw <8 x i32> %a, <i32 32767, i32 -32768, i32 0, i32 0, i32 1, i32 7, i32 42, i32 32>
%odd = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %odd, %even
ret <4 x i32> %ret
}
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; Do not select unsigned i16 multiplication
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
define <4 x i32> @pmaddwd_negative1(<8 x i16> %A, <8 x i16> %B) {
; SSE2-LABEL: pmaddwd_negative1:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa %xmm0, %xmm2
; SSE2-NEXT: pmulhuw %xmm1, %xmm2
; SSE2-NEXT: pmullw %xmm1, %xmm0
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4],xmm2[4],xmm1[5],xmm2[5],xmm1[6],xmm2[6],xmm1[7],xmm2[7]
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0],xmm2[0],xmm0[1],xmm2[1],xmm0[2],xmm2[2],xmm0[3],xmm2[3]
; SSE2-NEXT: movdqa %xmm0, %xmm2
; SSE2-NEXT: shufps {{.*#+}} xmm2 = xmm2[0,2],xmm1[0,2]
; SSE2-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,3],xmm1[1,3]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: pmaddwd_negative1:
; AVX1: # %bb.0:
[X86] Don't emit *_extend_vector_inreg nodes when both the input and output types are legal with AVX1 We already have custom lowering for the AVX case in LegalizeVectorOps. So its better to keep the regular extend op around as long as possible. I had to qualify one place in DAG combine that created illegal vector extending load operations. This change by itself had no effect on any tests which is why its included here. I've made a few cleanups to the custom lowering. The sign extend code no longer creates an identity shuffle with undef elements. The zero extend code now emits a zero_extend_vector_inreg instead of an unpckl with a zero vector. For the high half of the custom lowering of zero_extend/any_extend, we're now using an unpckh with a zero vector or undef. Previously we used used a pshufd to move the upper 64-bits to the lower 64-bits and then used a zero_extend_vector_inreg. I think the zero vector should require less execution resources and be smaller code size. Differential Revision: https://reviews.llvm.org/D54024 llvm-svn: 346043
2018-11-03 05:09:49 +08:00
; AVX1-NEXT: vpxor %xmm2, %xmm2, %xmm2
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm3 = xmm0[4],xmm2[4],xmm0[5],xmm2[5],xmm0[6],xmm2[6],xmm0[7],xmm2[7]
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero
[X86] Don't emit *_extend_vector_inreg nodes when both the input and output types are legal with AVX1 We already have custom lowering for the AVX case in LegalizeVectorOps. So its better to keep the regular extend op around as long as possible. I had to qualify one place in DAG combine that created illegal vector extending load operations. This change by itself had no effect on any tests which is why its included here. I've made a few cleanups to the custom lowering. The sign extend code no longer creates an identity shuffle with undef elements. The zero extend code now emits a zero_extend_vector_inreg instead of an unpckl with a zero vector. For the high half of the custom lowering of zero_extend/any_extend, we're now using an unpckh with a zero vector or undef. Previously we used used a pshufd to move the upper 64-bits to the lower 64-bits and then used a zero_extend_vector_inreg. I think the zero vector should require less execution resources and be smaller code size. Differential Revision: https://reviews.llvm.org/D54024 llvm-svn: 346043
2018-11-03 05:09:49 +08:00
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm2 = xmm1[4],xmm2[4],xmm1[5],xmm2[5],xmm1[6],xmm2[6],xmm1[7],xmm2[7]
; AVX1-NEXT: vpmulld %xmm2, %xmm3, %xmm2
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm1 = xmm1[0],zero,xmm1[1],zero,xmm1[2],zero,xmm1[3],zero
; AVX1-NEXT: vpmulld %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vphaddd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: retq
;
; AVX256-LABEL: pmaddwd_negative1:
; AVX256: # %bb.0:
; AVX256-NEXT: vpmovzxwd {{.*#+}} ymm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero,xmm0[4],zero,xmm0[5],zero,xmm0[6],zero,xmm0[7],zero
; AVX256-NEXT: vpmovzxwd {{.*#+}} ymm1 = xmm1[0],zero,xmm1[1],zero,xmm1[2],zero,xmm1[3],zero,xmm1[4],zero,xmm1[5],zero,xmm1[6],zero,xmm1[7],zero
; AVX256-NEXT: vpmulld %ymm1, %ymm0, %ymm0
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX256-NEXT: vphaddd %xmm1, %xmm0, %xmm0
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
%a = zext <8 x i16> %A to <8 x i32>
%b = zext <8 x i16> %B to <8 x i32>
%m = mul nuw <8 x i32> %a, %b
%odd = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %odd, %even
ret <4 x i32> %ret
}
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; Do not select if constant is too large
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
define <4 x i32> @pmaddwd_negative2(<8 x i16> %A) {
; SSE2-LABEL: pmaddwd_negative2:
; SSE2: # %bb.0:
; SSE2-NEXT: punpcklwd {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
; SSE2-NEXT: psrad $16, %xmm1
; SSE2-NEXT: punpckhwd {{.*#+}} xmm0 = xmm0[4,4,5,5,6,6,7,7]
; SSE2-NEXT: psrad $16, %xmm0
[X86][SSE] Combine (some) target shuffles with multiple uses As discussed on D41794, we have many cases where we fail to combine shuffles as the input operands have other uses. This patch permits these shuffles to be combined as long as they don't introduce additional variable shuffle masks, which should reduce instruction dependencies and allow the total number of shuffles to still drop without increasing the constant pool. However, this may mean that some memory folds may no longer occur, and on pre-AVX require the occasional extra register move. This also exposes some poor PMULDQ/PMULUDQ codegen which was doing unnecessary upper/lower calculations which will in fact fold to zero/undef - the fix will be added in a followup commit. Differential Revision: https://reviews.llvm.org/D50328 llvm-svn: 339335
2018-08-09 20:30:02 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,1,3,3]
; SSE2-NEXT: movdqa {{.*#+}} xmm3 = [1,7,42,32]
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm3[1,1,3,3]
; SSE2-NEXT: pmuludq %xmm2, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm1[1,1,3,3]
; SSE2-NEXT: movdqa {{.*#+}} xmm5 = [32768,4294934528,0,0]
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[1,1,3,3]
; SSE2-NEXT: pmuludq %xmm2, %xmm6
; SSE2-NEXT: shufps {{.*#+}} xmm6 = xmm6[0,2],xmm4[0,2]
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: pmuludq %xmm3, %xmm0
[X86][SSE] Combine (some) target shuffles with multiple uses As discussed on D41794, we have many cases where we fail to combine shuffles as the input operands have other uses. This patch permits these shuffles to be combined as long as they don't introduce additional variable shuffle masks, which should reduce instruction dependencies and allow the total number of shuffles to still drop without increasing the constant pool. However, this may mean that some memory folds may no longer occur, and on pre-AVX require the occasional extra register move. This also exposes some poor PMULDQ/PMULUDQ codegen which was doing unnecessary upper/lower calculations which will in fact fold to zero/undef - the fix will be added in a followup commit. Differential Revision: https://reviews.llvm.org/D50328 llvm-svn: 339335
2018-08-09 20:30:02 +08:00
; SSE2-NEXT: pmuludq %xmm5, %xmm1
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,2],xmm0[0,2]
; SSE2-NEXT: paddd %xmm6, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm0
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: pmaddwd_negative2:
; AVX1: # %bb.0:
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpmovsxwd %xmm1, %xmm1
; AVX1-NEXT: vpmovsxwd %xmm0, %xmm0
; AVX1-NEXT: vpmulld {{.*}}(%rip), %xmm0, %xmm0
; AVX1-NEXT: vpmulld {{.*}}(%rip), %xmm1, %xmm1
; AVX1-NEXT: vphaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: retq
;
; AVX256-LABEL: pmaddwd_negative2:
; AVX256: # %bb.0:
; AVX256-NEXT: vpmovsxwd %xmm0, %ymm0
; AVX256-NEXT: vpmulld {{.*}}(%rip), %ymm0, %ymm0
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX256-NEXT: vphaddd %xmm1, %xmm0, %xmm0
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
X86 Tests: Add Tests for PMADDWD selection. NFC. Support for ISel to be added. llvm-svn: 321970
2018-01-08 04:21:10 +08:00
%a = sext <8 x i16> %A to <8 x i32>
%m = mul nsw <8 x i32> %a, <i32 32768, i32 -32768, i32 0, i32 0, i32 1, i32 7, i32 42, i32 32>
%odd = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%even = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%ret = add <4 x i32> %odd, %even
ret <4 x i32> %ret
}
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
define <4 x i32> @jumbled_indices4(<8 x i16> %A, <8 x i16> %B) {
; SSE2-LABEL: jumbled_indices4:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm1, %xmm0
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; SSE2-NEXT: retq
;
; AVX-LABEL: jumbled_indices4:
; AVX: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX-NEXT: retq
%exta = sext <8 x i16> %A to <8 x i32>
%extb = sext <8 x i16> %B to <8 x i32>
%m = mul <8 x i32> %exta, %extb
%sa = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 3, i32 1, i32 5, i32 6>
%sb = shufflevector <8 x i32> %m, <8 x i32> undef, <4 x i32> <i32 2, i32 0, i32 4, i32 7>
%a = add <4 x i32> %sa, %sb
ret <4 x i32> %a
}
define <8 x i32> @jumbled_indices8(<16 x i16> %A, <16 x i16> %B) {
; SSE2-LABEL: jumbled_indices8:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm2, %xmm0
; SSE2-NEXT: pmaddwd %xmm3, %xmm1
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: jumbled_indices8:
; AVX1: # %bb.0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpmaddwd %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpmaddwd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX256-LABEL: jumbled_indices8:
; AVX256: # %bb.0:
; AVX256-NEXT: vpmaddwd %ymm1, %ymm0, %ymm0
; AVX256-NEXT: retq
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
%exta = sext <16 x i16> %A to <16 x i32>
%extb = sext <16 x i16> %B to <16 x i32>
%m = mul <16 x i32> %exta, %extb
%sa = shufflevector <16 x i32> %m, <16 x i32> undef, <8 x i32> <i32 0, i32 2, i32 7, i32 4, i32 11, i32 8, i32 15, i32 12>
%sb = shufflevector <16 x i32> %m, <16 x i32> undef, <8 x i32> <i32 1, i32 3, i32 6, i32 5, i32 10, i32 9, i32 14, i32 13>
%a = add <8 x i32> %sa, %sb
ret <8 x i32> %a
}
define <16 x i32> @jumbled_indices16(<32 x i16> %A, <32 x i16> %B) {
; SSE2-LABEL: jumbled_indices16:
; SSE2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd %xmm4, %xmm0
; SSE2-NEXT: pmaddwd %xmm5, %xmm1
; SSE2-NEXT: pmaddwd %xmm6, %xmm2
; SSE2-NEXT: pmaddwd %xmm7, %xmm3
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: jumbled_indices16:
; AVX1: # %bb.0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm6
; AVX1-NEXT: vpmaddwd %xmm6, %xmm4, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm6
; AVX1-NEXT: vpmaddwd %xmm6, %xmm5, %xmm5
; AVX1-NEXT: vpmaddwd %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm5, %ymm0, %ymm0
; AVX1-NEXT: vpmaddwd %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm1, %ymm1
; AVX1-NEXT: retq
;
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX2-LABEL: jumbled_indices16:
; AVX2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX2-NEXT: vpmaddwd %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpmaddwd %ymm3, %ymm1, %ymm1
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX2-NEXT: retq
;
; AVX512F-LABEL: jumbled_indices16:
; AVX512F: # %bb.0:
[X86] Pass v32i16/v64i8 in zmm registers on KNL target. gcc and icc pass these types in zmm registers in zmm registers. This patch implements a quick hack to override the register type before calling convention handling to one that is legal. Longer term we might want to do something similar to 256-bit integer registers on AVX1 where we just split all the operations. Fixes PR42957 Differential Revision: https://reviews.llvm.org/D66708 llvm-svn: 370495
2019-08-31 01:35:08 +08:00
; AVX512F-NEXT: vextracti64x4 $1, %zmm1, %ymm2
; AVX512F-NEXT: vextracti64x4 $1, %zmm0, %ymm3
; AVX512F-NEXT: vpmaddwd %ymm2, %ymm3, %ymm2
; AVX512F-NEXT: vpmaddwd %ymm1, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: jumbled_indices16:
; AVX512BW: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512BW-NEXT: vpmaddwd %zmm1, %zmm0, %zmm0
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX512BW-NEXT: retq
%exta = sext <32 x i16> %A to <32 x i32>
%extb = sext <32 x i16> %B to <32 x i32>
%m = mul <32 x i32> %exta, %extb
%sa = shufflevector <32 x i32> %m, <32 x i32> undef, <16 x i32> <i32 2, i32 0, i32 5, i32 6, i32 11, i32 9, i32 15, i32 12, i32 17, i32 18, i32 20, i32 23, i32 27, i32 24, i32 31, i32 29>
%sb = shufflevector <32 x i32> %m, <32 x i32> undef, <16 x i32> <i32 3, i32 1, i32 4, i32 7, i32 10, i32 8, i32 14, i32 13, i32 16, i32 19, i32 21, i32 22, i32 26, i32 25, i32 30, i32 28>
%a = add <16 x i32> %sa, %sb
ret <16 x i32> %a
}
define <32 x i32> @jumbled_indices32(<64 x i16> %A, <64 x i16> %B) {
; SSE2-LABEL: jumbled_indices32:
; SSE2: # %bb.0:
[X86] Handle COPYs of physregs better (regalloc hints) Enable enableMultipleCopyHints() on X86. Original Patch by @jonpa: While enabling the mischeduler for SystemZ, it was discovered that for some reason a test needed one extra seemingly needless COPY (test/CodeGen/SystemZ/call-03.ll). The handling for that is resulted in this patch, which improves the register coalescing by providing not just one copy hint, but a sorted list of copy hints. On SystemZ, this gives ~12500 less register moves on SPEC, as well as marginally less spilling. Instead of improving just the SystemZ backend, the improvement has been implemented in common-code (calculateSpillWeightAndHint(). This gives a lot of test failures, but since this should be a general improvement I hope that the involved targets will help and review the test updates. Differential Revision: https://reviews.llvm.org/D38128 llvm-svn: 342578
2018-09-20 02:59:08 +08:00
; SSE2-NEXT: movq %rdi, %rax
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: pmaddwd {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: movdqa %xmm7, 112(%rdi)
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; SSE2-NEXT: movdqa %xmm6, 96(%rdi)
; SSE2-NEXT: movdqa %xmm5, 80(%rdi)
; SSE2-NEXT: movdqa %xmm4, 64(%rdi)
; SSE2-NEXT: movdqa %xmm3, 48(%rdi)
; SSE2-NEXT: movdqa %xmm2, 32(%rdi)
; SSE2-NEXT: movdqa %xmm1, 16(%rdi)
; SSE2-NEXT: movdqa %xmm0, (%rdi)
; SSE2-NEXT: retq
;
[X86] Add avx1 command line to madd.ll to show splitting and concatenating 256-bit operations. llvm-svn: 326068
2018-02-26 15:48:17 +08:00
; AVX1-LABEL: jumbled_indices32:
; AVX1: # %bb.0:
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm9
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm10
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm11
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm12
; AVX1-NEXT: vpmaddwd %xmm12, %xmm8, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm12
; AVX1-NEXT: vpmaddwd %xmm12, %xmm9, %xmm9
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm12
; AVX1-NEXT: vpmaddwd %xmm12, %xmm10, %xmm10
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm12
; AVX1-NEXT: vpmaddwd %xmm12, %xmm11, %xmm11
; AVX1-NEXT: vpmaddwd %xmm4, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm11, %ymm0, %ymm0
; AVX1-NEXT: vpmaddwd %xmm5, %xmm1, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm10, %ymm1, %ymm1
; AVX1-NEXT: vpmaddwd %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vinsertf128 $1, %xmm9, %ymm2, %ymm2
; AVX1-NEXT: vpmaddwd %xmm7, %xmm3, %xmm3
; AVX1-NEXT: vinsertf128 $1, %xmm8, %ymm3, %ymm3
; AVX1-NEXT: retq
;
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX2-LABEL: jumbled_indices32:
; AVX2: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX2-NEXT: vpmaddwd %ymm4, %ymm0, %ymm0
; AVX2-NEXT: vpmaddwd %ymm5, %ymm1, %ymm1
; AVX2-NEXT: vpmaddwd %ymm6, %ymm2, %ymm2
; AVX2-NEXT: vpmaddwd %ymm7, %ymm3, %ymm3
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX2-NEXT: retq
;
; AVX512F-LABEL: jumbled_indices32:
; AVX512F: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512F-NEXT: vpmaddwd %ymm5, %ymm1, %ymm1
; AVX512F-NEXT: vpmaddwd %ymm4, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmaddwd %ymm7, %ymm3, %ymm1
; AVX512F-NEXT: vpmaddwd %ymm6, %ymm2, %ymm2
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm2, %zmm1
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: jumbled_indices32:
; AVX512BW: # %bb.0:
X86: Add pattern matching for PMADDWD In addition to the existing match as part of a loop-reduction, add a straightforward pattern match for DAG-contained patterns. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D41811 llvm-svn: 322446
2018-01-14 01:42:19 +08:00
; AVX512BW-NEXT: vpmaddwd %zmm2, %zmm0, %zmm0
; AVX512BW-NEXT: vpmaddwd %zmm3, %zmm1, %zmm1
X86 Tests: add more pamddwd cases. NFC Improve coverage of D41811 llvm-svn: 322434
2018-01-13 16:21:29 +08:00
; AVX512BW-NEXT: retq
%exta = sext <64 x i16> %A to <64 x i32>
%extb = sext <64 x i16> %B to <64 x i32>
%m = mul <64 x i32> %exta, %extb
%sa = shufflevector <64 x i32> %m, <64 x i32> undef, <32 x i32> <i32 1, i32 2, i32 6, i32 5, i32 10, i32 8, i32 14, i32 12, i32 19, i32 17, i32 22, i32 20, i32 25, i32 27, i32 30, i32 28, i32 32, i32 34, i32 37, i32 38, i32 41, i32 43, i32 45, i32 47, i32 50, i32 48, i32 52, i32 54, i32 59, i32 56, i32 61, i32 63>
%sb = shufflevector <64 x i32> %m, <64 x i32> undef, <32 x i32> <i32 0, i32 3, i32 7, i32 4, i32 11, i32 9, i32 15, i32 13, i32 18, i32 16, i32 23, i32 21, i32 24, i32 26, i32 31, i32 29, i32 33, i32 35, i32 36, i32 39, i32 40, i32 42, i32 44, i32 46, i32 51, i32 49, i32 53, i32 55, i32 58, i32 57, i32 60, i32 62>
%a = add <32 x i32> %sa, %sb
ret <32 x i32> %a
}
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; NOTE: We're testing with loads because ABI lowering creates a concat_vectors that extract_vector_elt creation can see through.
; This would require the combine to recreate the concat_vectors.
define <4 x i32> @pmaddwd_128(<8 x i16>* %Aptr, <8 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_128:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: pmaddwd (%rsi), %xmm0
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_128:
; AVX: # %bb.0:
; AVX-NEXT: vmovdqa (%rdi), %xmm0
; AVX-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX-NEXT: retq
%A = load <8 x i16>, <8 x i16>* %Aptr
%B = load <8 x i16>, <8 x i16>* %Bptr
%A_even = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%A_odd = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%B_even = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%B_odd = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%A_even_ext = sext <4 x i16> %A_even to <4 x i32>
%B_even_ext = sext <4 x i16> %B_even to <4 x i32>
%A_odd_ext = sext <4 x i16> %A_odd to <4 x i32>
%B_odd_ext = sext <4 x i16> %B_odd to <4 x i32>
%even_mul = mul <4 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <4 x i32> %A_odd_ext, %B_odd_ext
%add = add <4 x i32> %even_mul, %odd_mul
ret <4 x i32> %add
}
define <8 x i32> @pmaddwd_256(<16 x i16>* %Aptr, <16 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_256:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: movdqa 16(%rdi), %xmm1
; SSE2-NEXT: pmaddwd (%rsi), %xmm0
; SSE2-NEXT: pmaddwd 16(%rsi), %xmm1
; SSE2-NEXT: retq
;
; AVX1-LABEL: pmaddwd_256:
; AVX1: # %bb.0:
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vmovdqa (%rdi), %xmm0
; AVX1-NEXT: vmovdqa 16(%rdi), %xmm1
; AVX1-NEXT: vpmaddwd 16(%rsi), %xmm1, %xmm1
; AVX1-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; AVX1-NEXT: retq
;
; AVX256-LABEL: pmaddwd_256:
; AVX256: # %bb.0:
; AVX256-NEXT: vmovdqa (%rdi), %ymm0
; AVX256-NEXT: vpmaddwd (%rsi), %ymm0, %ymm0
; AVX256-NEXT: retq
%A = load <16 x i16>, <16 x i16>* %Aptr
%B = load <16 x i16>, <16 x i16>* %Bptr
%A_even = shufflevector <16 x i16> %A, <16 x i16> undef, <8 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14>
%A_odd = shufflevector <16 x i16> %A, <16 x i16> undef, <8 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>
%B_even = shufflevector <16 x i16> %B, <16 x i16> undef, <8 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14>
%B_odd = shufflevector <16 x i16> %B, <16 x i16> undef, <8 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>
%A_even_ext = sext <8 x i16> %A_even to <8 x i32>
%B_even_ext = sext <8 x i16> %B_even to <8 x i32>
%A_odd_ext = sext <8 x i16> %A_odd to <8 x i32>
%B_odd_ext = sext <8 x i16> %B_odd to <8 x i32>
%even_mul = mul <8 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <8 x i32> %A_odd_ext, %B_odd_ext
%add = add <8 x i32> %even_mul, %odd_mul
ret <8 x i32> %add
}
define <16 x i32> @pmaddwd_512(<32 x i16>* %Aptr, <32 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_512:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: movdqa 16(%rdi), %xmm1
; SSE2-NEXT: movdqa 32(%rdi), %xmm2
; SSE2-NEXT: movdqa 48(%rdi), %xmm3
; SSE2-NEXT: pmaddwd (%rsi), %xmm0
; SSE2-NEXT: pmaddwd 16(%rsi), %xmm1
; SSE2-NEXT: pmaddwd 32(%rsi), %xmm2
; SSE2-NEXT: pmaddwd 48(%rsi), %xmm3
; SSE2-NEXT: retq
;
; AVX1-LABEL: pmaddwd_512:
; AVX1: # %bb.0:
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vmovdqa (%rdi), %xmm0
; AVX1-NEXT: vmovdqa 16(%rdi), %xmm1
; AVX1-NEXT: vmovdqa 32(%rdi), %xmm2
; AVX1-NEXT: vmovdqa 48(%rdi), %xmm3
; AVX1-NEXT: vpmaddwd 16(%rsi), %xmm1, %xmm1
; AVX1-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: vpmaddwd 48(%rsi), %xmm3, %xmm1
; AVX1-NEXT: vpmaddwd 32(%rsi), %xmm2, %xmm2
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: pmaddwd_512:
; AVX2: # %bb.0:
; AVX2-NEXT: vmovdqa (%rdi), %ymm0
; AVX2-NEXT: vmovdqa 32(%rdi), %ymm1
; AVX2-NEXT: vpmaddwd (%rsi), %ymm0, %ymm0
; AVX2-NEXT: vpmaddwd 32(%rsi), %ymm1, %ymm1
; AVX2-NEXT: retq
;
; AVX512F-LABEL: pmaddwd_512:
; AVX512F: # %bb.0:
; AVX512F-NEXT: vmovdqa (%rdi), %ymm0
; AVX512F-NEXT: vmovdqa 32(%rdi), %ymm1
; AVX512F-NEXT: vpmaddwd 32(%rsi), %ymm1, %ymm1
; AVX512F-NEXT: vpmaddwd (%rsi), %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: pmaddwd_512:
; AVX512BW: # %bb.0:
; AVX512BW-NEXT: vmovdqa64 (%rdi), %zmm0
; AVX512BW-NEXT: vpmaddwd (%rsi), %zmm0, %zmm0
; AVX512BW-NEXT: retq
%A = load <32 x i16>, <32 x i16>* %Aptr
%B = load <32 x i16>, <32 x i16>* %Bptr
%A_even = shufflevector <32 x i16> %A, <32 x i16> undef, <16 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14, i32 16, i32 18, i32 20, i32 22, i32 24, i32 26, i32 28, i32 30>
%A_odd = shufflevector <32 x i16> %A, <32 x i16> undef, <16 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 17, i32 19, i32 21, i32 23, i32 25, i32 27, i32 29, i32 31>
%B_even = shufflevector <32 x i16> %B, <32 x i16> undef, <16 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14, i32 16, i32 18, i32 20, i32 22, i32 24, i32 26, i32 28, i32 30>
%B_odd = shufflevector <32 x i16> %B, <32 x i16> undef, <16 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 17, i32 19, i32 21, i32 23, i32 25, i32 27, i32 29, i32 31>
%A_even_ext = sext <16 x i16> %A_even to <16 x i32>
%B_even_ext = sext <16 x i16> %B_even to <16 x i32>
%A_odd_ext = sext <16 x i16> %A_odd to <16 x i32>
%B_odd_ext = sext <16 x i16> %B_odd to <16 x i32>
%even_mul = mul <16 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <16 x i32> %A_odd_ext, %B_odd_ext
%add = add <16 x i32> %even_mul, %odd_mul
ret <16 x i32> %add
}
define <32 x i32> @pmaddwd_1024(<64 x i16>* %Aptr, <64 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_1024:
; SSE2: # %bb.0:
[X86] Handle COPYs of physregs better (regalloc hints) Enable enableMultipleCopyHints() on X86. Original Patch by @jonpa: While enabling the mischeduler for SystemZ, it was discovered that for some reason a test needed one extra seemingly needless COPY (test/CodeGen/SystemZ/call-03.ll). The handling for that is resulted in this patch, which improves the register coalescing by providing not just one copy hint, but a sorted list of copy hints. On SystemZ, this gives ~12500 less register moves on SPEC, as well as marginally less spilling. Instead of improving just the SystemZ backend, the improvement has been implemented in common-code (calculateSpillWeightAndHint(). This gives a lot of test failures, but since this should be a general improvement I hope that the involved targets will help and review the test updates. Differential Revision: https://reviews.llvm.org/D38128 llvm-svn: 342578
2018-09-20 02:59:08 +08:00
; SSE2-NEXT: movq %rdi, %rax
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; SSE2-NEXT: movdqa (%rsi), %xmm0
; SSE2-NEXT: movdqa 16(%rsi), %xmm1
; SSE2-NEXT: movdqa 32(%rsi), %xmm2
; SSE2-NEXT: movdqa 48(%rsi), %xmm3
; SSE2-NEXT: pmaddwd (%rdx), %xmm0
; SSE2-NEXT: pmaddwd 16(%rdx), %xmm1
; SSE2-NEXT: pmaddwd 32(%rdx), %xmm2
; SSE2-NEXT: pmaddwd 48(%rdx), %xmm3
; SSE2-NEXT: movdqa 64(%rsi), %xmm4
; SSE2-NEXT: pmaddwd 64(%rdx), %xmm4
; SSE2-NEXT: movdqa 80(%rsi), %xmm5
; SSE2-NEXT: pmaddwd 80(%rdx), %xmm5
; SSE2-NEXT: movdqa 96(%rsi), %xmm6
; SSE2-NEXT: pmaddwd 96(%rdx), %xmm6
; SSE2-NEXT: movdqa 112(%rsi), %xmm7
; SSE2-NEXT: pmaddwd 112(%rdx), %xmm7
; SSE2-NEXT: movdqa %xmm7, 112(%rdi)
; SSE2-NEXT: movdqa %xmm6, 96(%rdi)
; SSE2-NEXT: movdqa %xmm5, 80(%rdi)
; SSE2-NEXT: movdqa %xmm4, 64(%rdi)
; SSE2-NEXT: movdqa %xmm3, 48(%rdi)
; SSE2-NEXT: movdqa %xmm2, 32(%rdi)
; SSE2-NEXT: movdqa %xmm1, 16(%rdi)
; SSE2-NEXT: movdqa %xmm0, (%rdi)
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: retq
;
; AVX1-LABEL: pmaddwd_1024:
; AVX1: # %bb.0:
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; AVX1-NEXT: vmovdqa (%rdi), %xmm0
; AVX1-NEXT: vmovdqa 16(%rdi), %xmm1
; AVX1-NEXT: vmovdqa 32(%rdi), %xmm2
; AVX1-NEXT: vmovdqa 48(%rdi), %xmm3
; AVX1-NEXT: vpmaddwd 16(%rsi), %xmm1, %xmm1
; AVX1-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: vpmaddwd 48(%rsi), %xmm3, %xmm1
; AVX1-NEXT: vpmaddwd 32(%rsi), %xmm2, %xmm2
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX1-NEXT: vmovdqa 80(%rdi), %xmm2
; AVX1-NEXT: vpmaddwd 80(%rsi), %xmm2, %xmm2
; AVX1-NEXT: vmovdqa 64(%rdi), %xmm3
; AVX1-NEXT: vpmaddwd 64(%rsi), %xmm3, %xmm3
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm3, %ymm2
; AVX1-NEXT: vmovdqa 112(%rdi), %xmm3
; AVX1-NEXT: vpmaddwd 112(%rsi), %xmm3, %xmm3
; AVX1-NEXT: vmovdqa 96(%rdi), %xmm4
; AVX1-NEXT: vpmaddwd 96(%rsi), %xmm4, %xmm4
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm4, %ymm3
; AVX1-NEXT: retq
;
; AVX2-LABEL: pmaddwd_1024:
; AVX2: # %bb.0:
; AVX2-NEXT: vmovdqa (%rdi), %ymm0
; AVX2-NEXT: vmovdqa 32(%rdi), %ymm1
; AVX2-NEXT: vmovdqa 64(%rdi), %ymm2
; AVX2-NEXT: vmovdqa 96(%rdi), %ymm3
; AVX2-NEXT: vpmaddwd (%rsi), %ymm0, %ymm0
; AVX2-NEXT: vpmaddwd 32(%rsi), %ymm1, %ymm1
; AVX2-NEXT: vpmaddwd 64(%rsi), %ymm2, %ymm2
; AVX2-NEXT: vpmaddwd 96(%rsi), %ymm3, %ymm3
; AVX2-NEXT: retq
;
; AVX512F-LABEL: pmaddwd_1024:
; AVX512F: # %bb.0:
; AVX512F-NEXT: vmovdqa (%rdi), %ymm0
; AVX512F-NEXT: vmovdqa 32(%rdi), %ymm1
; AVX512F-NEXT: vmovdqa 64(%rdi), %ymm2
; AVX512F-NEXT: vmovdqa 96(%rdi), %ymm3
; AVX512F-NEXT: vpmaddwd 32(%rsi), %ymm1, %ymm1
; AVX512F-NEXT: vpmaddwd (%rsi), %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmaddwd 96(%rsi), %ymm3, %ymm1
; AVX512F-NEXT: vpmaddwd 64(%rsi), %ymm2, %ymm2
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm2, %zmm1
; AVX512F-NEXT: retq
;
; AVX512BW-LABEL: pmaddwd_1024:
; AVX512BW: # %bb.0:
; AVX512BW-NEXT: vmovdqa64 (%rdi), %zmm0
; AVX512BW-NEXT: vmovdqa64 64(%rdi), %zmm1
; AVX512BW-NEXT: vpmaddwd (%rsi), %zmm0, %zmm0
; AVX512BW-NEXT: vpmaddwd 64(%rsi), %zmm1, %zmm1
; AVX512BW-NEXT: retq
%A = load <64 x i16>, <64 x i16>* %Aptr
%B = load <64 x i16>, <64 x i16>* %Bptr
%A_even = shufflevector <64 x i16> %A, <64 x i16> undef, <32 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14, i32 16, i32 18, i32 20, i32 22, i32 24, i32 26, i32 28, i32 30, i32 32, i32 34, i32 36, i32 38, i32 40, i32 42, i32 44, i32 46, i32 48, i32 50, i32 52, i32 54, i32 56, i32 58, i32 60, i32 62>
%A_odd = shufflevector <64 x i16> %A, <64 x i16> undef, <32 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 17, i32 19, i32 21, i32 23, i32 25, i32 27, i32 29, i32 31, i32 33, i32 35, i32 37, i32 39, i32 41, i32 43, i32 45, i32 47, i32 49, i32 51, i32 53, i32 55, i32 57, i32 59, i32 61, i32 63>
%B_even = shufflevector <64 x i16> %B, <64 x i16> undef, <32 x i32> <i32 0, i32 2, i32 4, i32 6, i32 8, i32 10, i32 12, i32 14, i32 16, i32 18, i32 20, i32 22, i32 24, i32 26, i32 28, i32 30, i32 32, i32 34, i32 36, i32 38, i32 40, i32 42, i32 44, i32 46, i32 48, i32 50, i32 52, i32 54, i32 56, i32 58, i32 60, i32 62>
%B_odd = shufflevector <64 x i16> %B, <64 x i16> undef, <32 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 17, i32 19, i32 21, i32 23, i32 25, i32 27, i32 29, i32 31, i32 33, i32 35, i32 37, i32 39, i32 41, i32 43, i32 45, i32 47, i32 49, i32 51, i32 53, i32 55, i32 57, i32 59, i32 61, i32 63>
%A_even_ext = sext <32 x i16> %A_even to <32 x i32>
%B_even_ext = sext <32 x i16> %B_even to <32 x i32>
%A_odd_ext = sext <32 x i16> %A_odd to <32 x i32>
%B_odd_ext = sext <32 x i16> %B_odd to <32 x i32>
%even_mul = mul <32 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <32 x i32> %A_odd_ext, %B_odd_ext
%add = add <32 x i32> %even_mul, %odd_mul
ret <32 x i32> %add
}
define <4 x i32> @pmaddwd_commuted_mul(<8 x i16>* %Aptr, <8 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_commuted_mul:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: pmaddwd (%rsi), %xmm0
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_commuted_mul:
; AVX: # %bb.0:
; AVX-NEXT: vmovdqa (%rdi), %xmm0
; AVX-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX-NEXT: retq
%A = load <8 x i16>, <8 x i16>* %Aptr
%B = load <8 x i16>, <8 x i16>* %Bptr
%A_even = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%A_odd = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%B_even = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%B_odd = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
%A_even_ext = sext <4 x i16> %A_even to <4 x i32>
%B_even_ext = sext <4 x i16> %B_even to <4 x i32>
%A_odd_ext = sext <4 x i16> %A_odd to <4 x i32>
%B_odd_ext = sext <4 x i16> %B_odd to <4 x i32>
%even_mul = mul <4 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <4 x i32> %B_odd_ext, %A_odd_ext ; Different order than previous mul
%add = add <4 x i32> %even_mul, %odd_mul
ret <4 x i32> %add
}
define <4 x i32> @pmaddwd_swapped_indices(<8 x i16>* %Aptr, <8 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_swapped_indices:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: pmaddwd (%rsi), %xmm0
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_swapped_indices:
; AVX: # %bb.0:
; AVX-NEXT: vmovdqa (%rdi), %xmm0
; AVX-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX-NEXT: retq
%A = load <8 x i16>, <8 x i16>* %Aptr
%B = load <8 x i16>, <8 x i16>* %Bptr
%A_even = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 1, i32 2, i32 5, i32 6> ; indices aren't all even
%A_odd = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 0, i32 3, i32 4, i32 7> ; indices aren't all odd
%B_even = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 1, i32 2, i32 5, i32 6> ; same indices as A
%B_odd = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 0, i32 3, i32 4, i32 7> ; same indices as A
%A_even_ext = sext <4 x i16> %A_even to <4 x i32>
%B_even_ext = sext <4 x i16> %B_even to <4 x i32>
%A_odd_ext = sext <4 x i16> %A_odd to <4 x i32>
%B_odd_ext = sext <4 x i16> %B_odd to <4 x i32>
%even_mul = mul <4 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <4 x i32> %A_odd_ext, %B_odd_ext
%add = add <4 x i32> %even_mul, %odd_mul
ret <4 x i32> %add
}
; Negative test were indices aren't paired properly
define <4 x i32> @pmaddwd_bad_indices(<8 x i16>* %Aptr, <8 x i16>* %Bptr) {
; SSE2-LABEL: pmaddwd_bad_indices:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqa (%rdi), %xmm0
; SSE2-NEXT: movdqa (%rsi), %xmm1
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm0[2,1,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,6,5,6,7]
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm2[1,0,3,2,4,5,6,7]
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm0[0,3,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,7,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; SSE2-NEXT: pshuflw {{.*#+}} xmm3 = xmm1[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm3 = xmm3[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,2,2,3]
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm1[3,1,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,7,5,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm1[1,0,3,2,4,5,6,7]
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; SSE2-NEXT: movdqa %xmm2, %xmm4
; SSE2-NEXT: pmulhw %xmm3, %xmm4
; SSE2-NEXT: pmullw %xmm3, %xmm2
; SSE2-NEXT: punpcklwd {{.*#+}} xmm2 = xmm2[0],xmm4[0],xmm2[1],xmm4[1],xmm2[2],xmm4[2],xmm2[3],xmm4[3]
; SSE2-NEXT: movdqa %xmm0, %xmm3
; SSE2-NEXT: pmulhw %xmm1, %xmm3
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: pmullw %xmm1, %xmm0
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0],xmm3[0],xmm0[1],xmm3[1],xmm0[2],xmm3[2],xmm0[3],xmm3[3]
; SSE2-NEXT: paddd %xmm2, %xmm0
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; SSE2-NEXT: retq
;
; AVX-LABEL: pmaddwd_bad_indices:
; AVX: # %bb.0:
; AVX-NEXT: vmovdqa (%rdi), %xmm0
; AVX-NEXT: vmovdqa (%rsi), %xmm1
; AVX-NEXT: vpshufb {{.*#+}} xmm2 = xmm0[2,3,4,5,10,11,12,13,12,13,10,11,12,13,14,15]
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; AVX-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,6,7,8,9,14,15,8,9,14,15,12,13,14,15]
Revert "[X86] Enable -x86-experimental-vector-widening-legalization by default." This reverts commit 3de33245d2c992c9e0af60372043540b60f3a810. This commit broke the MSan buildbots. See https://reviews.llvm.org/rL367901 for more information. llvm-svn: 368107
2019-08-07 07:00:43 +08:00
; AVX-NEXT: vpshufb {{.*#+}} xmm3 = xmm1[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
Recommit r367901 "[X86] Enable -x86-experimental-vector-widening-legalization by default." The assert that caused this to be reverted should be fixed now. Original commit message: This patch changes our defualt legalization behavior for 16, 32, and 64 bit vectors with i8/i16/i32/i64 scalar types from promotion to widening. For example, v8i8 will now be widened to v16i8 instead of promoted to v8i16. This keeps the elements widths the same and pads with undef elements. We believe this is a better legalization strategy. But it carries some issues due to the fragmented vector ISA. For example, i8 shifts and multiplies get widened and then later have to be promoted/split into vXi16 vectors. This has the potential to cause regressions so we wanted to get it in early in the 10.0 cycle so we have plenty of time to address them. Next steps will be to merge tests that explicitly test the command line option. And then we can remove the option and its associated code. llvm-svn: 368183
2019-08-08 00:24:26 +08:00
; AVX-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[2,3,6,7,10,11,14,15,14,15,10,11,12,13,14,15]
; AVX-NEXT: vpmovsxwd %xmm2, %xmm2
[X86] Add matching for another pattern of PMADDWD. Summary: This is the pattern you get from the loop vectorizer for something like this int16_t A[1024]; int16_t B[1024]; int32_t C[512]; void pmaddwd() { for (int i = 0; i != 512; ++i) C[i] = (A[2*i]*B[2*i]) + (A[2*i+1]*B[2*i+1]); } In this case we will have (add (mul (build_vector), (build_vector)), (mul (build_vector), (build_vector))). This is different than the pattern we currently match which has the build_vectors between an add and a single multiply. I'm not sure what C code would get you that pattern. Reviewers: RKSimon, spatel, zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49636 llvm-svn: 338097
2018-07-27 12:29:10 +08:00
; AVX-NEXT: vpmovsxwd %xmm3, %xmm3
; AVX-NEXT: vpmulld %xmm3, %xmm2, %xmm2
; AVX-NEXT: vpmovsxwd %xmm0, %xmm0
; AVX-NEXT: vpmovsxwd %xmm1, %xmm1
; AVX-NEXT: vpmulld %xmm1, %xmm0, %xmm0
; AVX-NEXT: vpaddd %xmm0, %xmm2, %xmm0
; AVX-NEXT: retq
%A = load <8 x i16>, <8 x i16>* %Aptr
%B = load <8 x i16>, <8 x i16>* %Bptr
%A_even = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 1, i32 2, i32 5, i32 6>
%A_odd = shufflevector <8 x i16> %A, <8 x i16> undef, <4 x i32> <i32 0, i32 3, i32 4, i32 7>
%B_even = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6> ; different indices than A
%B_odd = shufflevector <8 x i16> %B, <8 x i16> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7> ; different indices than A
%A_even_ext = sext <4 x i16> %A_even to <4 x i32>
%B_even_ext = sext <4 x i16> %B_even to <4 x i32>
%A_odd_ext = sext <4 x i16> %A_odd to <4 x i32>
%B_odd_ext = sext <4 x i16> %B_odd to <4 x i32>
%even_mul = mul <4 x i32> %A_even_ext, %B_even_ext
%odd_mul = mul <4 x i32> %A_odd_ext, %B_odd_ext
%add = add <4 x i32> %even_mul, %odd_mul
ret <4 x i32> %add
}
[X86] Add test case for D50868. NFC llvm-svn: 340630
2018-08-25 02:05:02 +08:00
; This test contains two multiplies joined by an add. The result of that add is then reduced to a single element.
; SelectionDAGBuilder should tag the joining add as a vector reduction. We need to recognize that both sides can use pmaddwd
define i32 @madd_double_reduction(<8 x i16>* %arg, <8 x i16>* %arg1, <8 x i16>* %arg2, <8 x i16>* %arg3) {
; SSE2-LABEL: madd_double_reduction:
; SSE2: # %bb.0:
; SSE2-NEXT: movdqu (%rdi), %xmm0
; SSE2-NEXT: movdqu (%rsi), %xmm1
[X86] Teach combineLoopMAddPattern to handle cases where there is no loop and the add has two multiply inputs Differential Revision: https://reviews.llvm.org/D50868 llvm-svn: 340631
2018-08-25 02:05:04 +08:00
; SSE2-NEXT: pmaddwd %xmm0, %xmm1
; SSE2-NEXT: movdqu (%rdx), %xmm0
[X86] Add test case for D50868. NFC llvm-svn: 340630
2018-08-25 02:05:02 +08:00
; SSE2-NEXT: movdqu (%rcx), %xmm2
[X86] Teach combineLoopMAddPattern to handle cases where there is no loop and the add has two multiply inputs Differential Revision: https://reviews.llvm.org/D50868 llvm-svn: 340631
2018-08-25 02:05:04 +08:00
; SSE2-NEXT: pmaddwd %xmm0, %xmm2
; SSE2-NEXT: paddd %xmm1, %xmm2
[X86] Add test case for D50868. NFC llvm-svn: 340630
2018-08-25 02:05:02 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
[DAGCombiner] try to move bitcast after extract_subvector I noticed that we were failing to narrow an x86 ymm math op in a case similar to the 'madd' test diff. That is because a bitcast is sitting between the math and the extract subvector and thwarting our pattern matching for narrowing: t56: v8i32 = add t59, t58 t68: v4i64 = bitcast t56 t73: v2i64 = extract_subvector t68, Constant:i64<2> t96: v4i32 = bitcast t73 There are a few wins and neutral diffs in the other tests. Differential Revision: https://reviews.llvm.org/D61806 llvm-svn: 360541
2019-05-12 22:43:20 +08:00
; AVX-LABEL: madd_double_reduction:
; AVX: # %bb.0:
; AVX-NEXT: vmovdqu (%rdi), %xmm0
; AVX-NEXT: vmovdqu (%rdx), %xmm1
; AVX-NEXT: vpmaddwd (%rcx), %xmm1, %xmm1
[X86] In combineLoopMAddPattern and combineLoopSADPattern, preserve the vector reduction flag on the final add. Handle unrolled loops by letting DAG combine revisit. This reverts r340478 and r340631 and replaces them with a simpler method of just letting DAG combine revisit the nodes to handle the other operand. llvm-svn: 367195
2019-07-29 02:45:42 +08:00
; AVX-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
[DAGCombiner] try to move bitcast after extract_subvector I noticed that we were failing to narrow an x86 ymm math op in a case similar to the 'madd' test diff. That is because a bitcast is sitting between the math and the extract subvector and thwarting our pattern matching for narrowing: t56: v8i32 = add t59, t58 t68: v4i64 = bitcast t56 t73: v2i64 = extract_subvector t68, Constant:i64<2> t96: v4i32 = bitcast t73 There are a few wins and neutral diffs in the other tests. Differential Revision: https://reviews.llvm.org/D61806 llvm-svn: 360541
2019-05-12 22:43:20 +08:00
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
[X86] Add test case for D50868. NFC llvm-svn: 340630
2018-08-25 02:05:02 +08:00
%tmp = load <8 x i16>, <8 x i16>* %arg, align 1
%tmp6 = load <8 x i16>, <8 x i16>* %arg1, align 1
%tmp7 = sext <8 x i16> %tmp to <8 x i32>
%tmp17 = sext <8 x i16> %tmp6 to <8 x i32>
%tmp19 = mul nsw <8 x i32> %tmp7, %tmp17
%tmp20 = load <8 x i16>, <8 x i16>* %arg2, align 1
%tmp21 = load <8 x i16>, <8 x i16>* %arg3, align 1
%tmp22 = sext <8 x i16> %tmp20 to <8 x i32>
%tmp23 = sext <8 x i16> %tmp21 to <8 x i32>
%tmp25 = mul nsw <8 x i32> %tmp22, %tmp23
%tmp26 = add nuw nsw <8 x i32> %tmp25, %tmp19
%tmp29 = shufflevector <8 x i32> %tmp26, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp30 = add <8 x i32> %tmp26, %tmp29
%tmp31 = shufflevector <8 x i32> %tmp30, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp32 = add <8 x i32> %tmp30, %tmp31
%tmp33 = shufflevector <8 x i32> %tmp32, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp34 = add <8 x i32> %tmp32, %tmp33
%tmp35 = extractelement <8 x i32> %tmp34, i64 0
ret i32 %tmp35
}
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
define i32 @madd_quad_reduction(<8 x i16>* %arg, <8 x i16>* %arg1, <8 x i16>* %arg2, <8 x i16>* %arg3, <8 x i16>* %arg4, <8 x i16>* %arg5, <8 x i16>* %arg6, <8 x i16>* %arg7) {
; SSE2-LABEL: madd_quad_reduction:
; SSE2: # %bb.0:
; SSE2-NEXT: movq {{[0-9]+}}(%rsp), %r10
; SSE2-NEXT: movq {{[0-9]+}}(%rsp), %rax
; SSE2-NEXT: movdqu (%rdi), %xmm0
; SSE2-NEXT: movdqu (%rsi), %xmm1
; SSE2-NEXT: pmaddwd %xmm0, %xmm1
; SSE2-NEXT: movdqu (%rdx), %xmm0
; SSE2-NEXT: movdqu (%rcx), %xmm2
; SSE2-NEXT: pmaddwd %xmm0, %xmm2
; SSE2-NEXT: movdqu (%r8), %xmm0
; SSE2-NEXT: movdqu (%r9), %xmm3
; SSE2-NEXT: pmaddwd %xmm0, %xmm3
; SSE2-NEXT: paddd %xmm2, %xmm3
; SSE2-NEXT: movdqu (%rax), %xmm0
; SSE2-NEXT: movdqu (%r10), %xmm2
; SSE2-NEXT: pmaddwd %xmm0, %xmm2
; SSE2-NEXT: paddd %xmm3, %xmm2
; SSE2-NEXT: paddd %xmm1, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
; SSE2-NEXT: paddd %xmm2, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
[DAGCombiner][X86] Teach SimplifyVBinOp to fold VBinOp (concat X, undef/constant), (concat Y, undef/constant) -> concat (VBinOp X, Y), VecC This improves the combine I included in D66504 to handle constants in the upper operands of the concat. If we can constant fold them away we can pull the concat after the bin op. This helps with chains of madd reductions on X86 from loop unrolling. The loop madd reduction pattern creates pmaddwd with half the width of the add that follows it using zeroes to fill the upper bits. If we have two of these added together we can pull the zeroes through the accumulating add and then shrink it. Differential Revision: https://reviews.llvm.org/D66680 llvm-svn: 369937
2019-08-27 01:59:11 +08:00
; AVX-LABEL: madd_quad_reduction:
; AVX: # %bb.0:
; AVX-NEXT: movq {{[0-9]+}}(%rsp), %r10
; AVX-NEXT: movq {{[0-9]+}}(%rsp), %rax
; AVX-NEXT: vmovdqu (%rdi), %xmm0
; AVX-NEXT: vmovdqu (%rdx), %xmm1
; AVX-NEXT: vpmaddwd (%rcx), %xmm1, %xmm1
; AVX-NEXT: vpmaddwd (%rsi), %xmm0, %xmm0
; AVX-NEXT: vmovdqu (%r8), %xmm2
; AVX-NEXT: vpmaddwd (%r9), %xmm2, %xmm2
; AVX-NEXT: vpaddd %xmm2, %xmm1, %xmm1
; AVX-NEXT: vmovdqu (%rax), %xmm2
; AVX-NEXT: vpmaddwd (%r10), %xmm2, %xmm2
; AVX-NEXT: vpaddd %xmm2, %xmm1, %xmm1
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
%tmp = load <8 x i16>, <8 x i16>* %arg, align 1
%tmp6 = load <8 x i16>, <8 x i16>* %arg1, align 1
%tmp7 = sext <8 x i16> %tmp to <8 x i32>
%tmp17 = sext <8 x i16> %tmp6 to <8 x i32>
%tmp19 = mul nsw <8 x i32> %tmp7, %tmp17
%tmp20 = load <8 x i16>, <8 x i16>* %arg2, align 1
%tmp21 = load <8 x i16>, <8 x i16>* %arg3, align 1
%tmp22 = sext <8 x i16> %tmp20 to <8 x i32>
%tmp23 = sext <8 x i16> %tmp21 to <8 x i32>
%tmp25 = mul nsw <8 x i32> %tmp22, %tmp23
%tmp26 = add nuw nsw <8 x i32> %tmp25, %tmp19
%tmp40 = load <8 x i16>, <8 x i16>* %arg4, align 1
%tmp41 = load <8 x i16>, <8 x i16>* %arg5, align 1
%tmp42 = sext <8 x i16> %tmp40 to <8 x i32>
%tmp43 = sext <8 x i16> %tmp41 to <8 x i32>
%tmp45 = mul nsw <8 x i32> %tmp42, %tmp43
%tmp56 = add nuw nsw <8 x i32> %tmp26, %tmp45
%tmp50 = load <8 x i16>, <8 x i16>* %arg6, align 1
%tmp51 = load <8 x i16>, <8 x i16>* %arg7, align 1
%tmp52 = sext <8 x i16> %tmp50 to <8 x i32>
%tmp53 = sext <8 x i16> %tmp51 to <8 x i32>
%tmp55 = mul nsw <8 x i32> %tmp52, %tmp53
%tmp57 = add nuw nsw <8 x i32> %tmp55, %tmp56
%tmp29 = shufflevector <8 x i32> %tmp57, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp30 = add <8 x i32> %tmp57, %tmp29
%tmp31 = shufflevector <8 x i32> %tmp30, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp32 = add <8 x i32> %tmp30, %tmp31
%tmp33 = shufflevector <8 x i32> %tmp32, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%tmp34 = add <8 x i32> %tmp32, %tmp33
%tmp35 = extractelement <8 x i32> %tmp34, i64 0
ret i32 %tmp35
}
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
define i64 @sum_and_sum_of_squares(i8* %a, i32 %n) {
; SSE2-LABEL: sum_and_sum_of_squares:
; SSE2: # %bb.0: # %entry
; SSE2-NEXT: movl %esi, %eax
; SSE2-NEXT: pxor %xmm0, %xmm0
; SSE2-NEXT: pxor %xmm1, %xmm1
; SSE2-NEXT: pxor %xmm2, %xmm2
; SSE2-NEXT: pxor %xmm3, %xmm3
; SSE2-NEXT: .p2align 4, 0x90
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; SSE2-NEXT: .LBB33_1: # %vector.body
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; SSE2-NEXT: # =>This Inner Loop Header: Depth=1
; SSE2-NEXT: movq {{.*#+}} xmm4 = mem[0],zero
; SSE2-NEXT: punpcklbw {{.*#+}} xmm4 = xmm4[0],xmm0[0],xmm4[1],xmm0[1],xmm4[2],xmm0[2],xmm4[3],xmm0[3],xmm4[4],xmm0[4],xmm4[5],xmm0[5],xmm4[6],xmm0[6],xmm4[7],xmm0[7]
; SSE2-NEXT: movdqa %xmm4, %xmm5
; SSE2-NEXT: punpcklwd {{.*#+}} xmm5 = xmm5[0],xmm0[0],xmm5[1],xmm0[1],xmm5[2],xmm0[2],xmm5[3],xmm0[3]
; SSE2-NEXT: paddd %xmm5, %xmm2
; SSE2-NEXT: movdqa %xmm4, %xmm5
; SSE2-NEXT: punpckhwd {{.*#+}} xmm5 = xmm5[4],xmm0[4],xmm5[5],xmm0[5],xmm5[6],xmm0[6],xmm5[7],xmm0[7]
; SSE2-NEXT: paddd %xmm5, %xmm3
; SSE2-NEXT: pmaddwd %xmm4, %xmm4
; SSE2-NEXT: paddd %xmm4, %xmm1
; SSE2-NEXT: addq $8, %rdi
; SSE2-NEXT: addq $-8, %rax
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; SSE2-NEXT: jne .LBB33_1
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; SSE2-NEXT: # %bb.2: # %middle.block
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: paddd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; SSE2-NEXT: paddd %xmm0, %xmm1
; SSE2-NEXT: movd %xmm1, %eax
; SSE2-NEXT: retq
;
; AVX1-LABEL: sum_and_sum_of_squares:
; AVX1: # %bb.0: # %entry
; AVX1-NEXT: movl %esi, %eax
; AVX1-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX1-NEXT: .p2align 4, 0x90
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; AVX1-NEXT: .LBB33_1: # %vector.body
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX1-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Don't use PMADDWD for vector add reductions of multiplies if the mul inputs have an additional user. The pmaddwd inserts a truncate, if that truncate would end up creating additional instructions instead of making a zext narrower, then we shouldn't do it. I've restricted this to only sse4.1 targets since on prior targets the zext will be done in stages. So the truncate will probably not create additional instructions. Might need some more investigation of mul shrinking and the other pmaddwd transform to be sure this is the right decision. There might be a slight regression on AVX1 targets due to add splitting. Hard to say for sure. Maybe we need to look into using the vector reduction flag to use 2 narrow loads and a blend instead of extracting and inserting. llvm-svn: 367198
2019-07-29 09:36:58 +08:00
; AVX1-NEXT: vpmovzxbd {{.*#+}} xmm2 = mem[0],zero,zero,zero,mem[1],zero,zero,zero,mem[2],zero,zero,zero,mem[3],zero,zero,zero
; AVX1-NEXT: vpmovzxbd {{.*#+}} xmm3 = mem[0],zero,zero,zero,mem[1],zero,zero,zero,mem[2],zero,zero,zero,mem[3],zero,zero,zero
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
; AVX1-NEXT: vpaddd %xmm4, %xmm3, %xmm4
; AVX1-NEXT: vpaddd %xmm1, %xmm2, %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm1, %ymm1
; AVX1-NEXT: vpmaddwd %xmm2, %xmm2, %xmm2
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX1-NEXT: vpmaddwd %xmm3, %xmm3, %xmm3
[X86] Don't use PMADDWD for vector add reductions of multiplies if the mul inputs have an additional user. The pmaddwd inserts a truncate, if that truncate would end up creating additional instructions instead of making a zext narrower, then we shouldn't do it. I've restricted this to only sse4.1 targets since on prior targets the zext will be done in stages. So the truncate will probably not create additional instructions. Might need some more investigation of mul shrinking and the other pmaddwd transform to be sure this is the right decision. There might be a slight regression on AVX1 targets due to add splitting. Hard to say for sure. Maybe we need to look into using the vector reduction flag to use 2 narrow loads and a blend instead of extracting and inserting. llvm-svn: 367198
2019-07-29 09:36:58 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm4
; AVX1-NEXT: vpaddd %xmm4, %xmm3, %xmm3
; AVX1-NEXT: vpaddd %xmm0, %xmm2, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm0, %ymm0
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX1-NEXT: addq $8, %rdi
; AVX1-NEXT: addq $-8, %rax
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; AVX1-NEXT: jne .LBB33_1
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX1-NEXT: # %bb.2: # %middle.block
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX1-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX256-LABEL: sum_and_sum_of_squares:
; AVX256: # %bb.0: # %entry
; AVX256-NEXT: movl %esi, %eax
; AVX256-NEXT: vpxor %xmm0, %xmm0, %xmm0
; AVX256-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX256-NEXT: .p2align 4, 0x90
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; AVX256-NEXT: .LBB33_1: # %vector.body
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX256-NEXT: # =>This Inner Loop Header: Depth=1
[X86] Don't use PMADDWD for vector add reductions of multiplies if the mul inputs have an additional user. The pmaddwd inserts a truncate, if that truncate would end up creating additional instructions instead of making a zext narrower, then we shouldn't do it. I've restricted this to only sse4.1 targets since on prior targets the zext will be done in stages. So the truncate will probably not create additional instructions. Might need some more investigation of mul shrinking and the other pmaddwd transform to be sure this is the right decision. There might be a slight regression on AVX1 targets due to add splitting. Hard to say for sure. Maybe we need to look into using the vector reduction flag to use 2 narrow loads and a blend instead of extracting and inserting. llvm-svn: 367198
2019-07-29 09:36:58 +08:00
; AVX256-NEXT: vpmovzxbd {{.*#+}} ymm2 = mem[0],zero,zero,zero,mem[1],zero,zero,zero,mem[2],zero,zero,zero,mem[3],zero,zero,zero,mem[4],zero,zero,zero,mem[5],zero,zero,zero,mem[6],zero,zero,zero,mem[7],zero,zero,zero
; AVX256-NEXT: vpaddd %ymm1, %ymm2, %ymm1
; AVX256-NEXT: vpmaddwd %ymm2, %ymm2, %ymm2
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX256-NEXT: vpaddd %ymm0, %ymm2, %ymm0
; AVX256-NEXT: addq $8, %rdi
; AVX256-NEXT: addq $-8, %rax
[X86] Add a further unrolled madd reduction test case that shows several deficiencies. The AVX2 check lines show two issues. An ADD that became an OR because we knew the input was disjoint, but really it was zero so we should have just removed the ADD/OR all together. Relatedly we use 128-bit VPMADDWD instructions followed by 256-bit VPADDD operations. We should be able to narrow these VPADDDs. llvm-svn: 369736
2019-08-23 15:38:25 +08:00
; AVX256-NEXT: jne .LBB33_1
[X86] Add test cases to show missing one use check in combineLoopMAddPattern. llvm-svn: 367197
2019-07-29 09:36:54 +08:00
; AVX256-NEXT: # %bb.2: # %middle.block
; AVX256-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX256-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
; AVX256-NEXT: vpaddd %xmm1, %xmm0, %xmm0
; AVX256-NEXT: vmovd %xmm0, %eax
; AVX256-NEXT: vzeroupper
; AVX256-NEXT: retq
entry:
%0 = zext i32 %n to i64
br label %vector.body
vector.body:
%index = phi i64 [ %index.next, %vector.body ], [ 0, %entry ]
%vec.phi = phi <8 x i32> [ %6, %vector.body ], [ zeroinitializer, %entry ]
%sum.phi = phi <8 x i32> [ %4, %vector.body ], [ zeroinitializer, %entry ]
%1 = getelementptr inbounds i8, i8* %a, i64 %index
%2 = bitcast i8* %1 to <8 x i8>*
%wide.load = load <8 x i8>, <8 x i8>* %2, align 1
%3 = zext <8 x i8> %wide.load to <8 x i32>
%4 = add nsw <8 x i32> %3, %sum.phi
%5 = mul nsw <8 x i32> %3, %3
%6 = add nsw <8 x i32> %5, %vec.phi
%index.next = add i64 %index, 8
%7 = icmp eq i64 %index.next, %0
br i1 %7, label %middle.block, label %vector.body
middle.block:
%rdx.shuf35 = shufflevector <8 x i32> %4, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx36 = add <8 x i32> %4, %rdx.shuf35
%rdx.shuf37 = shufflevector <8 x i32> %bin.rdx36, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx38 = add <8 x i32> %bin.rdx36, %rdx.shuf37
%rdx.shuf39 = shufflevector <8 x i32> %bin.rdx38, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx40 = add <8 x i32> %bin.rdx38, %rdx.shuf39
%8 = extractelement <8 x i32> %bin.rdx40, i32 0
%rdx.shuf = shufflevector <8 x i32> %6, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx = add <8 x i32> %6, %rdx.shuf
%rdx.shuf31 = shufflevector <8 x i32> %bin.rdx, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx32 = add <8 x i32> %bin.rdx, %rdx.shuf31
%rdx.shuf33 = shufflevector <8 x i32> %bin.rdx32, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%bin.rdx34 = add <8 x i32> %bin.rdx32, %rdx.shuf33
%9 = extractelement <8 x i32> %bin.rdx34, i32 0
%tmp = zext i32 %8 to i64
%tmp28 = shl nuw i64 %tmp, 32
%tmp29 = zext i32 %9 to i64
ret i64 %tmp29
}