2017-11-06 03:48:24 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+sse2 | FileCheck %s --check-prefix=X86 --check-prefix=X86-SSE --check-prefix=X86-SSE2
|
|
|
|
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+sse4.2 | FileCheck %s --check-prefix=X86 --check-prefix=X86-SSE --check-prefix=X86-SSE42
|
|
|
|
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+avx | FileCheck %s --check-prefix=X86 --check-prefix=X86-AVX --check-prefix=X86-AVX1
|
|
|
|
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+avx2 | FileCheck %s --check-prefix=X86 --check-prefix=X86-AVX --check-prefix=X86-AVX2
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+sse2 | FileCheck %s --check-prefix=X64 --check-prefix=X64-SSE --check-prefix=X64-SSE2
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+sse4.2 | FileCheck %s --check-prefix=X64 --check-prefix=X64-SSE --check-prefix=X64-SSE42
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+avx | FileCheck %s --check-prefix=X64 --check-prefix=X64-AVX --check-prefix=X64-AVX1
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+avx2 | FileCheck %s --check-prefix=X64 --check-prefix=X64-AVX --check-prefix=X64-AVX2
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+avx512f,+avx512bw,+avx512dq,+avx512vl | FileCheck %s --check-prefix=X64 --check-prefix=X64-AVX --check-prefix=X64-AVX512
|
|
|
|
|
|
|
|
;
|
|
|
|
; 128-bit Vectors
|
|
|
|
;
|
|
|
|
|
|
|
|
define i64 @test_reduce_v2i64(<2 x i64> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm3, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm5, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pand %xmm3, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movd %xmm3, %eax
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %edx
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2018-02-28 00:59:10 +08:00
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm2 = xmm0[2,3,0,1]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa {{.*#+}} xmm0 = [0,2147483648,0,2147483648]
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm1, %xmm3
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm0, %xmm3
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm2
|
|
|
|
; X86-SSE42-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE42-NEXT: pextrd $1, %xmm2, %edx
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-LABEL: test_reduce_v2i64:
|
|
|
|
; X86-AVX1: ## %bb.0:
|
|
|
|
; X86-AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX1-NEXT: vmovddup {{.*#+}} xmm2 = [-0.0E+0,-0.0E+0]
|
|
|
|
; X86-AVX1-NEXT: ## xmm2 = mem[0,0]
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm2, %xmm0, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm2, %xmm1, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vblendvpd %xmm2, %xmm0, %xmm1, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX1-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v2i64:
|
|
|
|
; X86-AVX2: ## %bb.0:
|
|
|
|
; X86-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX2-NEXT: vpbroadcastq {{.*#+}} xmm2 = [-0.0E+0,-0.0E+0]
|
|
|
|
; X86-AVX2-NEXT: vpxor %xmm2, %xmm0, %xmm3
|
|
|
|
; X86-AVX2-NEXT: vpxor %xmm2, %xmm1, %xmm2
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %xmm2, %xmm0, %xmm1, %xmm0
|
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX2-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX2-NEXT: retl
|
2017-11-06 03:48:24 +08:00
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-10-10 03:05:50 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [9223372039002259456,9223372039002259456]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm3, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm5, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movq %xmm3, %rax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2018-02-28 00:59:10 +08:00
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm2 = xmm0[2,3,0,1]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa {{.*#+}} xmm0 = [9223372036854775808,9223372036854775808]
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm1, %xmm3
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm0, %xmm3
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm2
|
|
|
|
; X64-SSE42-NEXT: movq %xmm2, %rax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm2, %xmm0, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm2, %xmm1, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vblendvpd %xmm2, %xmm0, %xmm1, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX2-NEXT: vmovdqa {{.*#+}} xmm2 = [9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX2-NEXT: vpxor %xmm2, %xmm0, %xmm3
|
|
|
|
; X64-AVX2-NEXT: vpxor %xmm2, %xmm1, %xmm2
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %xmm2, %xmm0, %xmm1, %xmm0
|
|
|
|
; X64-AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v2i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX512-NEXT: vpminuq %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <2 x i64> %a0, <2 x i64> undef, <2 x i32> <i32 1, i32 undef>
|
|
|
|
%2 = icmp ult <2 x i64> %a0, %1
|
|
|
|
%3 = select <2 x i1> %2, <2 x i64> %a0, <2 x i64> %1
|
|
|
|
%4 = extractelement <2 x i64> %3, i32 0
|
|
|
|
ret i64 %4
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_reduce_v4i32(<4 x i32> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pand %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: por %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X86-AVX-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pand %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: por %xmm4, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX-LABEL: test_reduce_v4i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX-NEXT: retq
|
|
|
|
%1 = shufflevector <4 x i32> %a0, <4 x i32> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <4 x i32> %a0, %1
|
|
|
|
%3 = select <4 x i1> %2, <4 x i32> %a0, <4 x i32> %1
|
|
|
|
%4 = shufflevector <4 x i32> %3, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <4 x i32> %3, %4
|
|
|
|
%6 = select <4 x i1> %5, <4 x i32> %3, <4 x i32> %4
|
|
|
|
%7 = extractelement <4 x i32> %6, i32 0
|
|
|
|
ret i32 %7
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_reduce_v8i16(<8 x i16> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X86-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX: ## %bb.0:
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-AVX-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X64-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX-LABEL: test_reduce_v8i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX: ## %bb.0:
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: retq
|
|
|
|
%1 = shufflevector <8 x i16> %a0, <8 x i16> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <8 x i16> %a0, %1
|
|
|
|
%3 = select <8 x i1> %2, <8 x i16> %a0, <8 x i16> %1
|
|
|
|
%4 = shufflevector <8 x i16> %3, <8 x i16> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <8 x i16> %3, %4
|
|
|
|
%6 = select <8 x i1> %5, <8 x i16> %3, <8 x i16> %4
|
|
|
|
%7 = shufflevector <8 x i16> %6, <8 x i16> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <8 x i16> %6, %7
|
|
|
|
%9 = select <8 x i1> %8, <8 x i16> %6, <8 x i16> %7
|
|
|
|
%10 = extractelement <8 x i16> %9, i32 0
|
|
|
|
ret i16 %10
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_reduce_v16i8(<16 x i8> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X86-AVX-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX-LABEL: test_reduce_v16i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X64-AVX-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX-NEXT: retq
|
|
|
|
%1 = shufflevector <16 x i8> %a0, <16 x i8> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <16 x i8> %a0, %1
|
|
|
|
%3 = select <16 x i1> %2, <16 x i8> %a0, <16 x i8> %1
|
|
|
|
%4 = shufflevector <16 x i8> %3, <16 x i8> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <16 x i8> %3, %4
|
|
|
|
%6 = select <16 x i1> %5, <16 x i8> %3, <16 x i8> %4
|
|
|
|
%7 = shufflevector <16 x i8> %6, <16 x i8> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <16 x i8> %6, %7
|
|
|
|
%9 = select <16 x i1> %8, <16 x i8> %6, <16 x i8> %7
|
|
|
|
%10 = shufflevector <16 x i8> %9, <16 x i8> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <16 x i8> %9, %10
|
|
|
|
%12 = select <16 x i1> %11, <16 x i8> %9, <16 x i8> %10
|
|
|
|
%13 = extractelement <16 x i8> %12, i32 0
|
|
|
|
ret i8 %13
|
|
|
|
}
|
|
|
|
|
|
|
|
;
|
|
|
|
; 256-bit Vectors
|
|
|
|
;
|
|
|
|
|
|
|
|
define i64 @test_reduce_v4i64(<4 x i64> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm4, %xmm5
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm3, %xmm5
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm6, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm3[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm5, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pand %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: por %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %edx
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm2
|
|
|
|
; X86-SSE42-NEXT: movdqa {{.*#+}} xmm3 = [0,2147483648,0,2147483648]
|
2018-02-28 00:59:10 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm4
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pxor %xmm3, %xmm4
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm4, %xmm0
|
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm2, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm2 = xmm1[2,3,0,1]
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm0, %xmm3
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm2
|
|
|
|
; X86-SSE42-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE42-NEXT: pextrd $1, %xmm2, %edx
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-NEXT: vmovddup {{.*#+}} xmm2 = [-0.0E+0,-0.0E+0]
|
|
|
|
; X86-AVX1-NEXT: ## xmm2 = mem[0,0]
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm2, %xmm0, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm2, %xmm1, %xmm4
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm3, %xmm4, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm4, %xmm0, %xmm4
|
|
|
|
; X86-AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm3, %ymm3
|
|
|
|
; X86-AVX1-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX1-NEXT: vxorpd %xmm2, %xmm0, %xmm3
|
2018-09-09 22:13:22 +08:00
|
|
|
; X86-AVX1-NEXT: vxorpd %xmm2, %xmm1, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX1-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX2-NEXT: vpbroadcastq {{.*#+}} ymm2 = [-0.0E+0,-0.0E+0,-0.0E+0,-0.0E+0]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpxor %ymm2, %ymm0, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vpxor %ymm2, %ymm1, %ymm4
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm2
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %ymm3, %ymm2, %ymm2
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX2-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2018-10-10 03:05:50 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [9223372039002259456,9223372039002259456]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm4, %xmm5
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm3, %xmm5
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm6, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm3[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm5, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pand %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: por %xmm4, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movq %xmm2, %rax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm2
|
|
|
|
; X64-SSE42-NEXT: movdqa {{.*#+}} xmm3 = [9223372036854775808,9223372036854775808]
|
2018-02-28 00:59:10 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm4
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pxor %xmm3, %xmm4
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm4, %xmm0
|
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm2, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm2 = xmm1[2,3,0,1]
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm0, %xmm3
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm2
|
|
|
|
; X64-SSE42-NEXT: movq %xmm2, %rax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm2, %xmm0, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm2, %xmm1, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm3, %xmm4, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm4, %xmm0, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm3, %ymm3
|
|
|
|
; X64-AVX1-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX1-NEXT: vxorpd %xmm2, %xmm0, %xmm3
|
2018-09-09 22:13:22 +08:00
|
|
|
; X64-AVX1-NEXT: vxorpd %xmm2, %xmm1, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm3, %xmm2, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX2-NEXT: vpbroadcastq {{.*#+}} ymm2 = [9223372036854775808,9223372036854775808,9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX2-NEXT: vpxor %ymm2, %ymm0, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vpxor %ymm2, %ymm1, %ymm4
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm2
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %ymm3, %ymm2, %ymm2
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v4i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX512-NEXT: vpminuq %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX512-NEXT: vpminuq %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <4 x i64> %a0, <4 x i64> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <4 x i64> %a0, %1
|
|
|
|
%3 = select <4 x i1> %2, <4 x i64> %a0, <4 x i64> %1
|
|
|
|
%4 = shufflevector <4 x i64> %3, <4 x i64> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <4 x i64> %3, %4
|
|
|
|
%6 = select <4 x i1> %5, <4 x i64> %3, <4 x i64> %4
|
|
|
|
%7 = extractelement <4 x i64> %6, i32 0
|
|
|
|
ret i64 %7
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_reduce_v8i32(<8 x i32> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pand %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: por %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pand %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: por %xmm3, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,2147483648,2147483648,2147483648]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pand %xmm4, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pand %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm2
|
|
|
|
; X64-SSE2-NEXT: por %xmm3, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v8i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX512-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX512-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX512-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <8 x i32> %a0, <8 x i32> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <8 x i32> %a0, %1
|
|
|
|
%3 = select <8 x i1> %2, <8 x i32> %a0, <8 x i32> %1
|
|
|
|
%4 = shufflevector <8 x i32> %3, <8 x i32> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <8 x i32> %3, %4
|
|
|
|
%6 = select <8 x i1> %5, <8 x i32> %3, <8 x i32> %4
|
|
|
|
%7 = shufflevector <8 x i32> %6, <8 x i32> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <8 x i32> %6, %7
|
|
|
|
%9 = select <8 x i1> %8, <8 x i32> %6, <8 x i32> %7
|
|
|
|
%10 = extractelement <8 x i32> %9, i32 0
|
|
|
|
ret i32 %10
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_reduce_v16i16(<16 x i16> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm1, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X86-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminuw %xmm1, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX1-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-AVX2-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm2 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm1, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm1, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm2, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X64-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminuw %xmm1, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX1-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX2-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v16i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX512-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX512-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX512-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <16 x i16> %a0, <16 x i16> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <16 x i16> %a0, %1
|
|
|
|
%3 = select <16 x i1> %2, <16 x i16> %a0, <16 x i16> %1
|
|
|
|
%4 = shufflevector <16 x i16> %3, <16 x i16> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <16 x i16> %3, %4
|
|
|
|
%6 = select <16 x i1> %5, <16 x i16> %3, <16 x i16> %4
|
|
|
|
%7 = shufflevector <16 x i16> %6, <16 x i16> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <16 x i16> %6, %7
|
|
|
|
%9 = select <16 x i1> %8, <16 x i16> %6, <16 x i16> %7
|
|
|
|
%10 = shufflevector <16 x i16> %9, <16 x i16> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <16 x i16> %9, %10
|
|
|
|
%12 = select <16 x i1> %11, <16 x i16> %9, <16 x i16> %10
|
|
|
|
%13 = extractelement <16 x i16> %12, i32 0
|
|
|
|
ret i16 %13
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_reduce_v32i8(<32 x i8> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX1-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX1-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v32i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX512-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX512-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX512-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX512-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <32 x i8> %a0, <32 x i8> undef, <32 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <32 x i8> %a0, %1
|
|
|
|
%3 = select <32 x i1> %2, <32 x i8> %a0, <32 x i8> %1
|
|
|
|
%4 = shufflevector <32 x i8> %3, <32 x i8> undef, <32 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <32 x i8> %3, %4
|
|
|
|
%6 = select <32 x i1> %5, <32 x i8> %3, <32 x i8> %4
|
|
|
|
%7 = shufflevector <32 x i8> %6, <32 x i8> undef, <32 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <32 x i8> %6, %7
|
|
|
|
%9 = select <32 x i1> %8, <32 x i8> %6, <32 x i8> %7
|
|
|
|
%10 = shufflevector <32 x i8> %9, <32 x i8> undef, <32 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <32 x i8> %9, %10
|
|
|
|
%12 = select <32 x i1> %11, <32 x i8> %9, <32 x i8> %10
|
|
|
|
%13 = shufflevector <32 x i8> %12, <32 x i8> undef, <32 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%14 = icmp ult <32 x i8> %12, %13
|
|
|
|
%15 = select <32 x i1> %14, <32 x i8> %12, <32 x i8> %13
|
|
|
|
%16 = extractelement <32 x i8> %15, i32 0
|
|
|
|
ret i8 %16
|
|
|
|
}
|
|
|
|
|
|
|
|
;
|
|
|
|
; 512-bit Vectors
|
|
|
|
;
|
|
|
|
|
|
|
|
define i64 @test_reduce_v8i64(<8 x i64> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [2147483648,2147483648,2147483648,2147483648]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm5
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm5
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm6
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm6, %xmm7
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm5, %xmm7
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm5, %xmm6
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm6[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm5, %xmm6
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm6, %xmm5
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pand %xmm5, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm3, %xmm5
|
|
|
|
; X86-SSE2-NEXT: por %xmm1, %xmm5
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm6
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm6
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm6[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm6[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pand %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm2, %xmm1
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm5, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm2, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pand %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pandn %xmm5, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: por %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpeqd %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[0,0,2,2]
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: pand %xmm2, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
|
|
|
|
; X86-SSE2-NEXT: por %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pand %xmm2, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movd %xmm2, %eax
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %edx
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm5
|
|
|
|
; X86-SSE42-NEXT: movdqa {{.*#+}} xmm4 = [0,2147483648,0,2147483648]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm1, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pxor %xmm4, %xmm6
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm4, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm6, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm3
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE42-NEXT: movdqa %xmm5, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm2, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm5, %xmm2
|
|
|
|
; X86-SSE42-NEXT: movapd %xmm2, %xmm1
|
|
|
|
; X86-SSE42-NEXT: xorpd %xmm4, %xmm1
|
|
|
|
; X86-SSE42-NEXT: movapd %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: xorpd %xmm4, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm2, %xmm3
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm3[2,3,0,1]
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pxor %xmm1, %xmm4
|
|
|
|
; X86-SSE42-NEXT: pcmpgtq %xmm0, %xmm4
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm4, %xmm0
|
|
|
|
; X86-SSE42-NEXT: blendvpd %xmm0, %xmm3, %xmm1
|
|
|
|
; X86-SSE42-NEXT: movd %xmm1, %eax
|
|
|
|
; X86-SSE42-NEXT: pextrd $1, %xmm1, %edx
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-NEXT: vmovddup {{.*#+}} xmm3 = [-0.0E+0,-0.0E+0]
|
|
|
|
; X86-AVX1-NEXT: ## xmm3 = mem[0,0]
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm3, %xmm2, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-NEXT: vxorps %xmm3, %xmm4, %xmm4
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm2, %xmm4, %xmm2
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-NEXT: vxorps %xmm3, %xmm0, %xmm4
|
|
|
|
; X86-AVX1-NEXT: vxorps %xmm3, %xmm1, %xmm5
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm4, %xmm5, %xmm4
|
|
|
|
; X86-AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm4, %ymm2
|
|
|
|
; X86-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vxorpd %xmm3, %xmm0, %xmm2
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX1-NEXT: vxorps %xmm3, %xmm1, %xmm4
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm2, %xmm4, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm4, %xmm0, %xmm4
|
|
|
|
; X86-AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm2, %ymm2
|
|
|
|
; X86-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX1-NEXT: vxorpd %xmm3, %xmm0, %xmm2
|
2018-09-09 22:13:22 +08:00
|
|
|
; X86-AVX1-NEXT: vxorpd %xmm3, %xmm1, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vpcmpgtq %xmm2, %xmm3, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX1-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2019-04-17 03:18:53 +08:00
|
|
|
; X86-AVX2-NEXT: vpbroadcastq {{.*#+}} ymm2 = [-0.0E+0,-0.0E+0,-0.0E+0,-0.0E+0]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpxor %ymm2, %ymm0, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vpxor %ymm2, %ymm1, %ymm4
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm4
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X86-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm2
|
|
|
|
; X86-AVX2-NEXT: vpcmpgtq %ymm3, %ymm2, %ymm2
|
|
|
|
; X86-AVX2-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX2-NEXT: vpextrd $1, %xmm0, %edx
|
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2018-10-10 03:05:50 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [9223372039002259456,9223372039002259456]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm5
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm5
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm6, %xmm7
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm5, %xmm7
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm8 = xmm7[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm5, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm6[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm8, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm6, %xmm5
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pand %xmm5, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm3, %xmm5
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm5
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm6[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm3[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm7, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm6[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm5, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm0, %xmm2
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm2[0,0,2,2]
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pand %xmm6, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pand %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm5, %xmm1
|
|
|
|
; X64-SSE2-NEXT: por %xmm3, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm2
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm4, %xmm3
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm2, %xmm3
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm3[0,0,2,2]
|
|
|
|
; X64-SSE2-NEXT: pcmpeqd %xmm2, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm4[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: pand %xmm5, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
|
|
|
|
; X64-SSE2-NEXT: por %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movq %xmm3, %rax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm5
|
|
|
|
; X64-SSE42-NEXT: movdqa {{.*#+}} xmm4 = [9223372036854775808,9223372036854775808]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm1, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pxor %xmm4, %xmm6
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm4, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm6, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm1, %xmm3
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE42-NEXT: movdqa %xmm5, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm2, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm5, %xmm2
|
|
|
|
; X64-SSE42-NEXT: movapd %xmm2, %xmm1
|
|
|
|
; X64-SSE42-NEXT: xorpd %xmm4, %xmm1
|
|
|
|
; X64-SSE42-NEXT: movapd %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: xorpd %xmm4, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm2, %xmm3
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm3[2,3,0,1]
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm3, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pxor %xmm1, %xmm4
|
|
|
|
; X64-SSE42-NEXT: pcmpgtq %xmm0, %xmm4
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm4, %xmm0
|
|
|
|
; X64-SSE42-NEXT: blendvpd %xmm0, %xmm3, %xmm1
|
|
|
|
; X64-SSE42-NEXT: movq %xmm1, %rax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vmovdqa {{.*#+}} xmm3 = [9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm3, %xmm2, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm3, %xmm4, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm2, %xmm4, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm3, %xmm0, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm3, %xmm1, %xmm5
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm4, %xmm5, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm4, %ymm2
|
|
|
|
; X64-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vxorpd %xmm3, %xmm0, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpxor %xmm3, %xmm1, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm2, %xmm4, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm4, %xmm0, %xmm4
|
|
|
|
; X64-AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm2, %ymm2
|
|
|
|
; X64-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX1-NEXT: vxorpd %xmm3, %xmm0, %xmm2
|
2018-09-09 22:13:22 +08:00
|
|
|
; X64-AVX1-NEXT: vxorpd %xmm3, %xmm1, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpcmpgtq %xmm2, %xmm3, %xmm2
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX1-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpbroadcastq {{.*#+}} ymm2 = [9223372036854775808,9223372036854775808,9223372036854775808,9223372036854775808]
|
|
|
|
; X64-AVX2-NEXT: vpxor %ymm2, %ymm0, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vpxor %ymm2, %ymm1, %ymm4
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vextractf128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm4
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %ymm3, %ymm4, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %ymm3, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm0, %ymm3
|
|
|
|
; X64-AVX2-NEXT: vxorpd %ymm2, %ymm1, %ymm2
|
|
|
|
; X64-AVX2-NEXT: vpcmpgtq %ymm3, %ymm2, %ymm2
|
|
|
|
; X64-AVX2-NEXT: vblendvpd %ymm2, %ymm0, %ymm1, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v8i64:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; X64-AVX512-NEXT: vpminuq %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX512-NEXT: vpminuq %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX512-NEXT: vpminuq %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vmovq %xmm0, %rax
|
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <8 x i64> %a0, <8 x i64> undef, <8 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <8 x i64> %a0, %1
|
|
|
|
%3 = select <8 x i1> %2, <8 x i64> %a0, <8 x i64> %1
|
|
|
|
%4 = shufflevector <8 x i64> %3, <8 x i64> undef, <8 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <8 x i64> %3, %4
|
|
|
|
%6 = select <8 x i1> %5, <8 x i64> %3, <8 x i64> %4
|
|
|
|
%7 = shufflevector <8 x i64> %6, <8 x i64> undef, <8 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <8 x i64> %6, %7
|
|
|
|
%9 = select <8 x i1> %8, <8 x i64> %6, <8 x i64> %7
|
|
|
|
%10 = extractelement <8 x i64> %9, i32 0
|
|
|
|
ret i64 %10
|
|
|
|
}
|
|
|
|
|
|
|
|
define i32 @test_reduce_v16i32(<16 x i32> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [2147483648,2147483648,2147483648,2147483648]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm5
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm5
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm6
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm5, %xmm6
|
|
|
|
; X86-SSE2-NEXT: pand %xmm6, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm3, %xmm6
|
|
|
|
; X86-SSE2-NEXT: por %xmm1, %xmm6
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pand %xmm3, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: por %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm6, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pand %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm6, %xmm1
|
|
|
|
; X86-SSE2-NEXT: por %xmm3, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm2, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pand %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm3
|
|
|
|
; X86-SSE2-NEXT: por %xmm1, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm0, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pcmpgtd %xmm1, %xmm4
|
|
|
|
; X86-SSE2-NEXT: pand %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pandn %xmm0, %xmm4
|
|
|
|
; X86-SSE2-NEXT: por %xmm3, %xmm4
|
|
|
|
; X86-SSE2-NEXT: movd %xmm4, %eax
|
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminud %xmm3, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm2, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm2, %xmm3, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm2, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X86-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X86-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [2147483648,2147483648,2147483648,2147483648]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm5
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm5
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm6
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm6
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm5, %xmm6
|
|
|
|
; X64-SSE2-NEXT: pand %xmm6, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm3, %xmm6
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm6
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm0
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm6, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pand %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm6, %xmm1
|
|
|
|
; X64-SSE2-NEXT: por %xmm3, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm2, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pand %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm3
|
|
|
|
; X64-SSE2-NEXT: por %xmm1, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pcmpgtd %xmm1, %xmm4
|
|
|
|
; X64-SSE2-NEXT: pand %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pandn %xmm0, %xmm4
|
|
|
|
; X64-SSE2-NEXT: por %xmm3, %xmm4
|
|
|
|
; X64-SSE2-NEXT: movd %xmm4, %eax
|
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminud %xmm3, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm2, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm0, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE42-NEXT: pminud %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm2, %xmm3, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm2, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX1-NEXT: vpminud %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX2-NEXT: vpminud %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v16i32:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
|
|
|
; X64-AVX512-NEXT: vpminud %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
|
|
|
; X64-AVX512-NEXT: vpminud %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-AVX512-NEXT: vpminud %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
; X64-AVX512-NEXT: vpminud %zmm1, %zmm0, %zmm0
|
|
|
|
; X64-AVX512-NEXT: vmovd %xmm0, %eax
|
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <16 x i32> %a0, <16 x i32> undef, <16 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <16 x i32> %a0, %1
|
|
|
|
%3 = select <16 x i1> %2, <16 x i32> %a0, <16 x i32> %1
|
|
|
|
%4 = shufflevector <16 x i32> %3, <16 x i32> undef, <16 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <16 x i32> %3, %4
|
|
|
|
%6 = select <16 x i1> %5, <16 x i32> %3, <16 x i32> %4
|
|
|
|
%7 = shufflevector <16 x i32> %6, <16 x i32> undef, <16 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <16 x i32> %6, %7
|
|
|
|
%9 = select <16 x i1> %8, <16 x i32> %6, <16 x i32> %7
|
|
|
|
%10 = shufflevector <16 x i32> %9, <16 x i32> undef, <16 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <16 x i32> %9, %10
|
|
|
|
%12 = select <16 x i1> %11, <16 x i32> %9, <16 x i32> %10
|
|
|
|
%13 = extractelement <16 x i32> %12, i32 0
|
|
|
|
ret i32 %13
|
|
|
|
}
|
|
|
|
|
|
|
|
define i16 @test_reduce_v32i16(<32 x i16> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X86-SSE2-NEXT: pminsw %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X86-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminuw %xmm3, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pminuw %xmm2, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pminuw %xmm1, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vpminuw %xmm2, %xmm3, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpminuw %xmm2, %xmm0, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX1-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpminuw %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X86-AVX2-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa {{.*#+}} xmm4 = [32768,32768,32768,32768,32768,32768,32768,32768]
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm3
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm2
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm2, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
|
2018-02-11 18:52:37 +08:00
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm0
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-SSE2-NEXT: pminsw %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pxor %xmm4, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminsw %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movd %xmm1, %eax
|
2019-01-04 05:31:16 +08:00
|
|
|
; X64-SSE2-NEXT: xorl $32768, %eax ## imm = 0x8000
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminuw %xmm3, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pminuw %xmm2, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pminuw %xmm1, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm0, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpminuw %xmm2, %xmm3, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpminuw %xmm2, %xmm0, %xmm0
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX1-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpminuw %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX2-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX2-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v32i16:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX512-NEXT: vpminuw %ymm1, %ymm0, %ymm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-11-23 21:50:27 +08:00
|
|
|
; X64-AVX512-NEXT: vpminuw %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX512-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vmovd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX512-NEXT: ## kill: def $ax killed $ax killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <32 x i16> %a0, <32 x i16> undef, <32 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <32 x i16> %a0, %1
|
|
|
|
%3 = select <32 x i1> %2, <32 x i16> %a0, <32 x i16> %1
|
|
|
|
%4 = shufflevector <32 x i16> %3, <32 x i16> undef, <32 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <32 x i16> %3, %4
|
|
|
|
%6 = select <32 x i1> %5, <32 x i16> %3, <32 x i16> %4
|
|
|
|
%7 = shufflevector <32 x i16> %6, <32 x i16> undef, <32 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <32 x i16> %6, %7
|
|
|
|
%9 = select <32 x i1> %8, <32 x i16> %6, <32 x i16> %7
|
|
|
|
%10 = shufflevector <32 x i16> %9, <32 x i16> undef, <32 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <32 x i16> %9, %10
|
|
|
|
%12 = select <32 x i1> %11, <32 x i16> %9, <32 x i16> %10
|
|
|
|
%13 = shufflevector <32 x i16> %12, <32 x i16> undef, <32 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%14 = icmp ult <32 x i16> %12, %13
|
|
|
|
%15 = select <32 x i1> %14, <32 x i16> %12, <32 x i16> %13
|
|
|
|
%16 = extractelement <32 x i16> %15, i32 0
|
|
|
|
ret i16 %16
|
|
|
|
}
|
|
|
|
|
|
|
|
define i8 @test_reduce_v64i8(<64 x i8> %a0) {
|
|
|
|
; X86-SSE2-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: pminub %xmm3, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm2, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X86-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X86-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-SSE42-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminub %xmm3, %xmm1
|
|
|
|
; X86-SSE42-NEXT: pminub %xmm2, %xmm0
|
|
|
|
; X86-SSE42-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X86-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-SSE42-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX1-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm2, %xmm3, %xmm2
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm2, %xmm0, %xmm0
|
|
|
|
; X86-AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X86-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX1-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX1-NEXT: vzeroupper
|
|
|
|
; X86-AVX1-NEXT: retl
|
|
|
|
;
|
|
|
|
; X86-AVX2-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X86-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpminub %ymm1, %ymm0, %ymm0
|
|
|
|
; X86-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X86-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X86-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X86-AVX2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X86-AVX2-NEXT: vzeroupper
|
|
|
|
; X86-AVX2-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-SSE2-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: pminub %xmm3, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm2, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,2,3]
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: psrld $16, %xmm1
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm0, %xmm1
|
|
|
|
; X64-SSE2-NEXT: movdqa %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: psrlw $8, %xmm0
|
|
|
|
; X64-SSE2-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE2-NEXT: movd %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-SSE42-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-SSE42: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminub %xmm3, %xmm1
|
|
|
|
; X64-SSE42-NEXT: pminub %xmm2, %xmm0
|
|
|
|
; X64-SSE42-NEXT: pminub %xmm1, %xmm0
|
|
|
|
; X64-SSE42-NEXT: movdqa %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: psrlw $8, %xmm1
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pminub %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-SSE42-NEXT: phminposuw %xmm1, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: pextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-SSE42-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-SSE42-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX1-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX1: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm2, %xmm3, %xmm2
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm2, %xmm0, %xmm0
|
|
|
|
; X64-AVX1-NEXT: vpsrlw $8, %xmm0, %xmm1
|
|
|
|
; X64-AVX1-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX1-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX1-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX1-NEXT: vzeroupper
|
|
|
|
; X64-AVX1-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX2-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX2: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpminub %ymm1, %ymm0, %ymm0
|
|
|
|
; X64-AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX2-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX2-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX2-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX2-NEXT: vzeroupper
|
|
|
|
; X64-AVX2-NEXT: retq
|
|
|
|
;
|
|
|
|
; X64-AVX512-LABEL: test_reduce_v64i8:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64-AVX512: ## %bb.0:
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti64x4 $1, %zmm0, %ymm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX512-NEXT: vpminub %ymm1, %ymm0, %ymm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vextracti128 $1, %ymm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX512-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vpsrlw $8, %xmm0, %xmm1
|
2017-12-19 20:02:40 +08:00
|
|
|
; X64-AVX512-NEXT: vpminub %xmm1, %xmm0, %xmm0
|
|
|
|
; X64-AVX512-NEXT: vphminposuw %xmm0, %xmm0
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vpextrb $0, %xmm0, %eax
|
2018-02-01 06:04:26 +08:00
|
|
|
; X64-AVX512-NEXT: ## kill: def $al killed $al killed $eax
|
2017-11-06 03:48:24 +08:00
|
|
|
; X64-AVX512-NEXT: vzeroupper
|
|
|
|
; X64-AVX512-NEXT: retq
|
|
|
|
%1 = shufflevector <64 x i8> %a0, <64 x i8> undef, <64 x i32> <i32 32, i32 33, i32 34, i32 35, i32 36, i32 37, i32 38, i32 39, i32 40, i32 41, i32 42, i32 43, i32 44, i32 45, i32 46, i32 47, i32 48, i32 49, i32 50, i32 51, i32 52, i32 53, i32 54, i32 55, i32 56, i32 57, i32 58, i32 59, i32 60, i32 61, i32 62, i32 63, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%2 = icmp ult <64 x i8> %a0, %1
|
|
|
|
%3 = select <64 x i1> %2, <64 x i8> %a0, <64 x i8> %1
|
|
|
|
%4 = shufflevector <64 x i8> %3, <64 x i8> undef, <64 x i32> <i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%5 = icmp ult <64 x i8> %3, %4
|
|
|
|
%6 = select <64 x i1> %5, <64 x i8> %3, <64 x i8> %4
|
|
|
|
%7 = shufflevector <64 x i8> %6, <64 x i8> undef, <64 x i32> <i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%8 = icmp ult <64 x i8> %6, %7
|
|
|
|
%9 = select <64 x i1> %8, <64 x i8> %6, <64 x i8> %7
|
|
|
|
%10 = shufflevector <64 x i8> %9, <64 x i8> undef, <64 x i32> <i32 4, i32 5, i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%11 = icmp ult <64 x i8> %9, %10
|
|
|
|
%12 = select <64 x i1> %11, <64 x i8> %9, <64 x i8> %10
|
|
|
|
%13 = shufflevector <64 x i8> %12, <64 x i8> undef, <64 x i32> <i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%14 = icmp ult <64 x i8> %12, %13
|
|
|
|
%15 = select <64 x i1> %14, <64 x i8> %12, <64 x i8> %13
|
|
|
|
%16 = shufflevector <64 x i8> %15, <64 x i8> undef, <64 x i32> <i32 1, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
|
|
|
|
%17 = icmp ult <64 x i8> %15, %16
|
|
|
|
%18 = select <64 x i1> %17, <64 x i8> %15, <64 x i8> %16
|
|
|
|
%19 = extractelement <64 x i8> %18, i32 0
|
|
|
|
ret i8 %19
|
|
|
|
}
|