2018-04-06 01:37:35 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=ALL --check-prefix=SSE --check-prefix=SSE2
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse4.1 | FileCheck %s --check-prefix=ALL --check-prefix=SSE --check-prefix=SSE41
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=ALL --check-prefix=AVX --check-prefix=AVX1
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2 | FileCheck %s --check-prefix=ALL --check-prefix=AVX --check-prefix=AVX2
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f,+avx512bw | FileCheck %s --check-prefix=ALL --check-prefix=AVX512 --check-prefix=AVX512BW
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f,+avx512bw,+avx512vl | FileCheck %s --check-prefix=ALL --check-prefix=AVX512 --check-prefix=AVX512VL
|
|
|
|
|
|
|
|
;
|
|
|
|
; vXi64
|
|
|
|
;
|
|
|
|
|
|
|
|
define i64 @test_v2i64(<2 x i64> %a0) {
|
|
|
|
; SSE-LABEL: test_v2i64:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movq %xmm1, %rax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v2i64:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v2i64:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i64 @llvm.experimental.vector.reduce.add.i64.v2i64(<2 x i64> %a0)
|
|
|
|
ret i64 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i64 @test_v4i64(<4 x i64> %a0) {
|
|
|
|
; SSE-LABEL: test_v4i64:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddq %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movq %xmm1, %rax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v4i64:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v4i64:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v4i64:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i64 @llvm.experimental.vector.reduce.add.i64.v4i64(<4 x i64> %a0)
|
|
|
|
ret i64 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i64 @test_v8i64(<8 x i64> %a0) {
|
|
|
|
; SSE-LABEL: test_v8i64:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddq %xmm3, %xmm1
|
|
|
|
; SSE-NEXT: paddq %xmm2, %xmm1
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movq %xmm0, %rax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v8i64:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddq %xmm2, %xmm3, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddq %xmm2, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v8i64:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v8i64:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddq %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddq %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i64 @llvm.experimental.vector.reduce.add.i64.v8i64(<8 x i64> %a0)
|
|
|
|
ret i64 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i64 @test_v16i64(<16 x i64> %a0) {
|
|
|
|
; SSE-LABEL: test_v16i64:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddq %xmm6, %xmm2
|
|
|
|
; SSE-NEXT: paddq %xmm7, %xmm3
|
|
|
|
; SSE-NEXT: paddq %xmm5, %xmm3
|
|
|
|
; SSE-NEXT: paddq %xmm1, %xmm3
|
|
|
|
; SSE-NEXT: paddq %xmm4, %xmm2
|
|
|
|
; SSE-NEXT: paddq %xmm3, %xmm2
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm2
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm2, %xmm0
|
|
|
|
; SSE-NEXT: movq %xmm0, %rax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v16i64:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vpaddq %xmm3, %xmm1, %xmm4
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddq %xmm3, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddq %xmm4, %xmm2, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm2, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v16i64:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddq %ymm3, %ymm1, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm2, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddq %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v16i64:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpaddq %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddq %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddq %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i64 @llvm.experimental.vector.reduce.add.i64.v16i64(<16 x i64> %a0)
|
|
|
|
ret i64 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
;
|
|
|
|
; vXi32
|
|
|
|
;
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
define i32 @test_v2i32(<2 x i32> %a0) {
|
|
|
|
; SSE-LABEL: test_v2i32:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v2i32:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v2i32:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i32 @llvm.experimental.vector.reduce.add.i32.v2i32(<2 x i32> %a0)
|
|
|
|
ret i32 %1
|
|
|
|
}
|
|
|
|
|
2018-04-06 01:37:35 +08:00
|
|
|
define i32 @test_v4i32(<4 x i32> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v4i32:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v4i32:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; 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
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v4i32:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-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
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i32 @llvm.experimental.vector.reduce.add.i32.v4i32(<4 x i32> %a0)
|
|
|
|
ret i32 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_v8i32(<8 x i32> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v8i32:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v8i32:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; 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
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v8i32:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
[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]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v8i32:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
[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
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i32 @llvm.experimental.vector.reduce.add.i32.v8i32(<8 x i32> %a0)
|
|
|
|
ret i32 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_v16i32(<16 x i32> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v16i32:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddd %xmm3, %xmm1
|
|
|
|
; SSE-NEXT: paddd %xmm2, %xmm1
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v16i32:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddd %xmm2, %xmm3, %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
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v16i32:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
[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]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v16i32:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i32 @llvm.experimental.vector.reduce.add.i32.v16i32(<16 x i32> %a0)
|
|
|
|
ret i32 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_v32i32(<32 x i32> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v32i32:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddd %xmm6, %xmm2
|
|
|
|
; SSE-NEXT: paddd %xmm7, %xmm3
|
|
|
|
; SSE-NEXT: paddd %xmm5, %xmm3
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm3
|
|
|
|
; SSE-NEXT: paddd %xmm4, %xmm2
|
|
|
|
; SSE-NEXT: paddd %xmm3, %xmm2
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm2
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddd %xmm2, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v32i32:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vpaddd %xmm3, %xmm1, %xmm4
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddd %xmm3, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddd %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddd %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddd %xmm4, %xmm2, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddd %xmm1, %xmm2, %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
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v32i32:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddd %ymm3, %ymm1, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm2, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddd %ymm1, %ymm0, %ymm0
|
[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]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v32i32:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddd %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i32 @llvm.experimental.vector.reduce.add.i32.v32i32(<32 x i32> %a0)
|
|
|
|
ret i32 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
;
|
|
|
|
; vXi16
|
|
|
|
;
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
define i16 @test_v2i16(<2 x i16> %a0) {
|
|
|
|
; SSE-LABEL: test_v2i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v2i16:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v2i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v2i16(<2 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_v4i16(<4 x i16> %a0) {
|
|
|
|
; SSE-LABEL: test_v4i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v4i16:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; 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: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v4i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v4i16(<4 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
2018-04-06 01:37:35 +08:00
|
|
|
define i16 @test_v8i16(<8 x i16> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v8i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v8i16:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX-NEXT: vpaddw %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: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v8i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddw %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
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v8i16(<8 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_v16i16(<16 x i16> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v16i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v16i16:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddw %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: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v16i16:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
[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: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v16i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
[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
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v16i16(<16 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_v32i16(<32 x i16> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v32i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddw %xmm3, %xmm1
|
|
|
|
; SSE-NEXT: paddw %xmm2, %xmm1
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v32i16:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddw %xmm2, %xmm3, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddw %xmm2, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddw %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: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v32i16:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
[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: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v32i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v32i16(<32 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_v64i16(<64 x i16> %a0) {
|
[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
|
|
|
; SSE-LABEL: test_v64i16:
|
|
|
|
; SSE: # %bb.0:
|
|
|
|
; SSE-NEXT: paddw %xmm6, %xmm2
|
|
|
|
; SSE-NEXT: paddw %xmm7, %xmm3
|
|
|
|
; SSE-NEXT: paddw %xmm5, %xmm3
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm3
|
|
|
|
; SSE-NEXT: paddw %xmm4, %xmm2
|
|
|
|
; SSE-NEXT: paddw %xmm3, %xmm2
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm2
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
|
|
|
|
; SSE-NEXT: paddw %xmm2, %xmm0
|
|
|
|
; SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; SSE-NEXT: retq
|
2018-04-06 01:37:35 +08:00
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v64i16:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vpaddw %xmm3, %xmm1, %xmm4
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm3, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm4, %xmm2, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm2, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddw %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: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v64i16:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddw %ymm3, %ymm1, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm2, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddw %ymm1, %ymm0, %ymm0
|
[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: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v64i16:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddw %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $ax killed $ax killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i16 @llvm.experimental.vector.reduce.add.i16.v64i16(<64 x i16> %a0)
|
|
|
|
ret i16 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
;
|
|
|
|
; vXi8
|
|
|
|
;
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
define i8 @test_v2i8(<2 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v2i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v2i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddq %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm1, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v2i8:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v2i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddq %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v2i8(<2 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_v4i8(<4 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v4i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; 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: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v4i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddd %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddd %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm0, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v4i8:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; 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: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v4i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddd %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v4i8(<4 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_v8i8(<8 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v8i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE2-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE2-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v8i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddw %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE41-NEXT: paddw %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm1, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v8i8:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v8i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddw %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v8i8(<8 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
2018-04-06 01:37:35 +08:00
|
|
|
define i8 @test_v16i8(<16 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v16i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v16i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: psrlw $8, %xmm0
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm0, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX-LABEL: test_v16i8:
|
|
|
|
; AVX: # %bb.0:
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; AVX-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v16i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v16i8(<16 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_v32i8(<32 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v32i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movd %xmm0, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v32i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: psrld $16, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: psrlw $8, %xmm0
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm0, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v32i8:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v32i8:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v32i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v32i8(<32 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_v64i8(<64 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v64i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: paddb %xmm3, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm2, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: psrlw $8, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v64i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: paddb %xmm3, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm2, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: psrlw $8, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm1, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v64i8:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddb %xmm2, %xmm3, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddb %xmm2, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v64i8:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v64i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v64i8(<64 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_v128i8(<128 x i8> %a0) {
|
|
|
|
; SSE2-LABEL: test_v128i8:
|
|
|
|
; SSE2: # %bb.0:
|
|
|
|
; SSE2-NEXT: paddb %xmm6, %xmm2
|
|
|
|
; SSE2-NEXT: paddb %xmm7, %xmm3
|
|
|
|
; SSE2-NEXT: paddb %xmm5, %xmm3
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm3
|
|
|
|
; SSE2-NEXT: paddb %xmm4, %xmm2
|
|
|
|
; SSE2-NEXT: paddb %xmm3, %xmm2
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm2
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
|
|
|
|
; SSE2-NEXT: paddb %xmm2, %xmm0
|
|
|
|
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE2-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: psrlw $8, %xmm1
|
|
|
|
; SSE2-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE2-NEXT: movd %xmm1, %eax
|
|
|
|
; SSE2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; SSE41-LABEL: test_v128i8:
|
|
|
|
; SSE41: # %bb.0:
|
|
|
|
; SSE41-NEXT: paddb %xmm6, %xmm2
|
|
|
|
; SSE41-NEXT: paddb %xmm7, %xmm3
|
|
|
|
; SSE41-NEXT: paddb %xmm5, %xmm3
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm3
|
|
|
|
; SSE41-NEXT: paddb %xmm4, %xmm2
|
|
|
|
; SSE41-NEXT: paddb %xmm3, %xmm2
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm2
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm2[2,3,0,1]
|
|
|
|
; SSE41-NEXT: paddb %xmm2, %xmm0
|
|
|
|
; SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: psrld $16, %xmm0
|
|
|
|
; SSE41-NEXT: paddb %xmm1, %xmm0
|
|
|
|
; SSE41-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: psrlw $8, %xmm1
|
|
|
|
; SSE41-NEXT: paddb %xmm0, %xmm1
|
|
|
|
; SSE41-NEXT: pextrb $0, %xmm1, %eax
|
|
|
|
; SSE41-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; SSE41-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX1-LABEL: test_v128i8:
|
|
|
|
; AVX1: # %bb.0:
|
|
|
|
; AVX1-NEXT: vpaddb %xmm3, %xmm1, %xmm4
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm3, %xmm1, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm3, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm4, %xmm2, %xmm2
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm2, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; AVX1-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
|
|
|
; AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX1-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX1-NEXT: vzeroupper
|
|
|
|
; AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX2-LABEL: test_v128i8:
|
|
|
|
; AVX2: # %bb.0:
|
|
|
|
; AVX2-NEXT: vpaddb %ymm3, %ymm1, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm2, %ymm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX2-NEXT: vpaddb %ymm1, %ymm0, %ymm0
|
|
|
|
; AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX2-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX2-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX2-NEXT: vzeroupper
|
|
|
|
; AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; AVX512-LABEL: test_v128i8:
|
|
|
|
; AVX512: # %bb.0:
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrld $16, %xmm0, %xmm1
|
|
|
|
; AVX512-NEXT: vpaddb %zmm1, %zmm0, %zmm0
|
|
|
|
; AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2018-10-30 22:14:34 +08:00
|
|
|
; AVX512-NEXT: vpaddb %xmm1, %xmm0, %xmm0
|
2018-04-06 01:37:35 +08:00
|
|
|
; AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
|
|
|
; AVX512-NEXT: # kill: def $al killed $al killed $eax
|
|
|
|
; AVX512-NEXT: vzeroupper
|
|
|
|
; AVX512-NEXT: retq
|
|
|
|
%1 = call i8 @llvm.experimental.vector.reduce.add.i8.v128i8(<128 x i8> %a0)
|
|
|
|
ret i8 %1
|
|
|
|
}
|
|
|
|
|
|
|
|
declare i64 @llvm.experimental.vector.reduce.add.i64.v2i64(<2 x i64>)
|
|
|
|
declare i64 @llvm.experimental.vector.reduce.add.i64.v4i64(<4 x i64>)
|
|
|
|
declare i64 @llvm.experimental.vector.reduce.add.i64.v8i64(<8 x i64>)
|
|
|
|
declare i64 @llvm.experimental.vector.reduce.add.i64.v16i64(<16 x i64>)
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
declare i32 @llvm.experimental.vector.reduce.add.i32.v2i32(<2 x i32>)
|
2018-04-06 01:37:35 +08:00
|
|
|
declare i32 @llvm.experimental.vector.reduce.add.i32.v4i32(<4 x i32>)
|
|
|
|
declare i32 @llvm.experimental.vector.reduce.add.i32.v8i32(<8 x i32>)
|
|
|
|
declare i32 @llvm.experimental.vector.reduce.add.i32.v16i32(<16 x i32>)
|
|
|
|
declare i32 @llvm.experimental.vector.reduce.add.i32.v32i32(<32 x i32>)
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v2i16(<2 x i16>)
|
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v4i16(<4 x i16>)
|
2018-04-06 01:37:35 +08:00
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v8i16(<8 x i16>)
|
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v16i16(<16 x i16>)
|
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v32i16(<32 x i16>)
|
|
|
|
declare i16 @llvm.experimental.vector.reduce.add.i16.v64i16(<64 x i16>)
|
|
|
|
|
2018-12-05 14:29:44 +08:00
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v2i8(<2 x i8>)
|
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v4i8(<4 x i8>)
|
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v8i8(<8 x i8>)
|
2018-04-06 01:37:35 +08:00
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v16i8(<16 x i8>)
|
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v32i8(<32 x i8>)
|
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v64i8(<64 x i8>)
|
|
|
|
declare i8 @llvm.experimental.vector.reduce.add.i8.v128i8(<128 x i8>)
|