maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/haddsub-3.ll

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

137 lines
5.6 KiB
LLVM
Raw Normal View History

[X86][SSE] Add PR26491 horizontal add test llvm-svn: 323973
2018-02-01 23:30:02 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[X86][SSE] LowerUINT_TO_FP_i64 - only use HADDPD for size/fast-hops We were always generating a single source HADDPD, but really we should only do this if shouldUseHorizontalOp says its a good idea. Differential Revision: https://reviews.llvm.org/D69175 llvm-svn: 375341
2019-10-19 19:53:48 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+sse2 | FileCheck %s --check-prefixes=SSE,SSE2
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+ssse3 | FileCheck %s --check-prefixes=SSE,SSSE3,SSSE3-SLOW
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+ssse3,fast-hops | FileCheck %s --check-prefixes=SSE,SSSE3,SSSE3-FAST
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx | FileCheck %s --check-prefixes=AVX,AVX1,AVX1-SLOW
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx,fast-hops | FileCheck %s --check-prefixes=AVX,AVX1,AVX1-FAST
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx2 | FileCheck %s --check-prefixes=AVX,AVX2
[X86][SSE] Add PR26491 horizontal add test llvm-svn: 323973
2018-02-01 23:30:02 +08:00
define float @pr26491(<4 x float> %a0) {
; SSE2-LABEL: pr26491:
; SSE2: # %bb.0:
; SSE2-NEXT: movaps %xmm0, %xmm1
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[3,3]
[X86][SSE] Add PR26491 horizontal add test llvm-svn: 323973
2018-02-01 23:30:02 +08:00
; SSE2-NEXT: addps %xmm0, %xmm1
; SSE2-NEXT: movaps %xmm1, %xmm0
[X86] Prefer unpckhpd over movhlps in isel for fake unary cases In r337348, I changed lowering to prefer X86ISD::UNPCKL/UNPCKH opcodes over MOVLHPS/MOVHLPS for v2f64 {0,0} and {1,1} shuffles when we have SSE2. This enabled the removal of a bunch of weirdly bitcasted isel patterns in r337349. To avoid changing the tests I placed a gross hack in isel to still emit movhlps instructions for fake unary unpckh nodes. A similar hack was not needed for unpckl and movlhps because we do execution domain switching for those. But unpckh and movhlps have swapped operand order. This patch removes the hack. This is a code size increase since unpckhpd requires a 0x66 prefix and movhlps does not. But if that's a big concern we should be using movhlps for all unpckhpd opcodes and let commuteInstruction turnit into unpckhpd when its an advantage. Differential Revision: https://reviews.llvm.org/D49499 llvm-svn: 341973
2018-09-12 01:57:27 +08:00
; SSE2-NEXT: unpckhpd {{.*#+}} xmm0 = xmm0[1],xmm1[1]
[X86][SSE] Add PR26491 horizontal add test llvm-svn: 323973
2018-02-01 23:30:02 +08:00
; SSE2-NEXT: addss %xmm1, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: pr26491:
; SSSE3: # %bb.0:
; SSSE3-NEXT: movshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; SSSE3-NEXT: addps %xmm0, %xmm1
; SSSE3-NEXT: movaps %xmm1, %xmm0
[X86] Prefer unpckhpd over movhlps in isel for fake unary cases In r337348, I changed lowering to prefer X86ISD::UNPCKL/UNPCKH opcodes over MOVLHPS/MOVHLPS for v2f64 {0,0} and {1,1} shuffles when we have SSE2. This enabled the removal of a bunch of weirdly bitcasted isel patterns in r337349. To avoid changing the tests I placed a gross hack in isel to still emit movhlps instructions for fake unary unpckh nodes. A similar hack was not needed for unpckl and movlhps because we do execution domain switching for those. But unpckh and movhlps have swapped operand order. This patch removes the hack. This is a code size increase since unpckhpd requires a 0x66 prefix and movhlps does not. But if that's a big concern we should be using movhlps for all unpckhpd opcodes and let commuteInstruction turnit into unpckhpd when its an advantage. Differential Revision: https://reviews.llvm.org/D49499 llvm-svn: 341973
2018-09-12 01:57:27 +08:00
; SSSE3-NEXT: unpckhpd {{.*#+}} xmm0 = xmm0[1],xmm1[1]
[X86][SSE] Add PR26491 horizontal add test llvm-svn: 323973
2018-02-01 23:30:02 +08:00
; SSSE3-NEXT: addss %xmm1, %xmm0
; SSSE3-NEXT: retq
;
; AVX-LABEL: pr26491:
; AVX: # %bb.0:
; AVX-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX-NEXT: vaddps %xmm0, %xmm1, %xmm0
; AVX-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; AVX-NEXT: vaddss %xmm0, %xmm1, %xmm0
; AVX-NEXT: retq
%1 = shufflevector <4 x float> %a0, <4 x float> undef, <4 x i32> <i32 1, i32 1, i32 3, i32 3>
%2 = fadd <4 x float> %1, %a0
%3 = extractelement <4 x float> %2, i32 2
%4 = extractelement <4 x float> %2, i32 0
%5 = fadd float %3, %4
ret float %5
}
[x86] make sure horizontal op and broadcast types match to simplify (PR41414) If the types don't match, we can't just remove the shuffle. There may be some other opportunity for optimization here, but this should prevent the crashing seen in: https://bugs.llvm.org/show_bug.cgi?id=41414 llvm-svn: 359095
2019-04-24 22:05:08 +08:00
; When simplifying away a splat (broadcast), the hop type must match the shuffle type.
define <4 x double> @PR41414(i64 %x, <4 x double> %y) {
; SSE2-LABEL: PR41414:
; SSE2: # %bb.0:
; SSE2-NEXT: movq %rdi, %xmm2
; SSE2-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],mem[0],xmm2[1],mem[1]
; SSE2-NEXT: subpd {{.*}}(%rip), %xmm2
; SSE2-NEXT: movapd %xmm2, %xmm3
; SSE2-NEXT: unpckhpd {{.*#+}} xmm3 = xmm3[1],xmm2[1]
; SSE2-NEXT: addpd %xmm2, %xmm3
; SSE2-NEXT: unpcklpd {{.*#+}} xmm3 = xmm3[0,0]
; SSE2-NEXT: divpd %xmm3, %xmm1
; SSE2-NEXT: divpd %xmm3, %xmm0
; SSE2-NEXT: xorpd %xmm2, %xmm2
; SSE2-NEXT: addpd %xmm2, %xmm0
; SSE2-NEXT: addpd %xmm2, %xmm1
; SSE2-NEXT: retq
;
[X86][SSE] LowerUINT_TO_FP_i64 - only use HADDPD for size/fast-hops We were always generating a single source HADDPD, but really we should only do this if shouldUseHorizontalOp says its a good idea. Differential Revision: https://reviews.llvm.org/D69175 llvm-svn: 375341
2019-10-19 19:53:48 +08:00
; SSSE3-SLOW-LABEL: PR41414:
; SSSE3-SLOW: # %bb.0:
; SSSE3-SLOW-NEXT: movq %rdi, %xmm2
; SSSE3-SLOW-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],mem[0],xmm2[1],mem[1]
; SSSE3-SLOW-NEXT: subpd {{.*}}(%rip), %xmm2
; SSSE3-SLOW-NEXT: movapd %xmm2, %xmm3
; SSSE3-SLOW-NEXT: unpckhpd {{.*#+}} xmm3 = xmm3[1],xmm2[1]
; SSSE3-SLOW-NEXT: addpd %xmm2, %xmm3
; SSSE3-SLOW-NEXT: movddup {{.*#+}} xmm2 = xmm3[0,0]
; SSSE3-SLOW-NEXT: divpd %xmm2, %xmm1
; SSSE3-SLOW-NEXT: divpd %xmm2, %xmm0
; SSSE3-SLOW-NEXT: xorpd %xmm2, %xmm2
; SSSE3-SLOW-NEXT: addpd %xmm2, %xmm0
; SSSE3-SLOW-NEXT: addpd %xmm2, %xmm1
; SSSE3-SLOW-NEXT: retq
;
; SSSE3-FAST-LABEL: PR41414:
; SSSE3-FAST: # %bb.0:
; SSSE3-FAST-NEXT: movq %rdi, %xmm2
; SSSE3-FAST-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],mem[0],xmm2[1],mem[1]
; SSSE3-FAST-NEXT: subpd {{.*}}(%rip), %xmm2
; SSSE3-FAST-NEXT: haddpd %xmm2, %xmm2
; SSSE3-FAST-NEXT: divpd %xmm2, %xmm1
; SSSE3-FAST-NEXT: divpd %xmm2, %xmm0
; SSSE3-FAST-NEXT: xorpd %xmm2, %xmm2
; SSSE3-FAST-NEXT: addpd %xmm2, %xmm0
; SSSE3-FAST-NEXT: addpd %xmm2, %xmm1
; SSSE3-FAST-NEXT: retq
;
; AVX1-SLOW-LABEL: PR41414:
; AVX1-SLOW: # %bb.0:
; AVX1-SLOW-NEXT: vmovq %rdi, %xmm1
; AVX1-SLOW-NEXT: vpunpckldq {{.*#+}} xmm1 = xmm1[0],mem[0],xmm1[1],mem[1]
; AVX1-SLOW-NEXT: vsubpd {{.*}}(%rip), %xmm1, %xmm1
; AVX1-SLOW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; AVX1-SLOW-NEXT: vaddpd %xmm1, %xmm2, %xmm1
; AVX1-SLOW-NEXT: vmovddup {{.*#+}} xmm1 = xmm1[0,0]
; AVX1-SLOW-NEXT: vinsertf128 $1, %xmm1, %ymm1, %ymm1
; AVX1-SLOW-NEXT: vdivpd %ymm1, %ymm0, %ymm0
; AVX1-SLOW-NEXT: vxorpd %xmm1, %xmm1, %xmm1
; AVX1-SLOW-NEXT: vaddpd %ymm1, %ymm0, %ymm0
; AVX1-SLOW-NEXT: retq
[x86] make sure horizontal op and broadcast types match to simplify (PR41414) If the types don't match, we can't just remove the shuffle. There may be some other opportunity for optimization here, but this should prevent the crashing seen in: https://bugs.llvm.org/show_bug.cgi?id=41414 llvm-svn: 359095
2019-04-24 22:05:08 +08:00
;
[X86][SSE] LowerUINT_TO_FP_i64 - only use HADDPD for size/fast-hops We were always generating a single source HADDPD, but really we should only do this if shouldUseHorizontalOp says its a good idea. Differential Revision: https://reviews.llvm.org/D69175 llvm-svn: 375341
2019-10-19 19:53:48 +08:00
; AVX1-FAST-LABEL: PR41414:
; AVX1-FAST: # %bb.0:
; AVX1-FAST-NEXT: vmovq %rdi, %xmm1
; AVX1-FAST-NEXT: vpunpckldq {{.*#+}} xmm1 = xmm1[0],mem[0],xmm1[1],mem[1]
; AVX1-FAST-NEXT: vsubpd {{.*}}(%rip), %xmm1, %xmm1
; AVX1-FAST-NEXT: vhaddpd %xmm1, %xmm1, %xmm1
; AVX1-FAST-NEXT: vinsertf128 $1, %xmm1, %ymm1, %ymm1
; AVX1-FAST-NEXT: vdivpd %ymm1, %ymm0, %ymm0
; AVX1-FAST-NEXT: vxorpd %xmm1, %xmm1, %xmm1
; AVX1-FAST-NEXT: vaddpd %ymm1, %ymm0, %ymm0
; AVX1-FAST-NEXT: retq
[x86] make sure horizontal op and broadcast types match to simplify (PR41414) If the types don't match, we can't just remove the shuffle. There may be some other opportunity for optimization here, but this should prevent the crashing seen in: https://bugs.llvm.org/show_bug.cgi?id=41414 llvm-svn: 359095
2019-04-24 22:05:08 +08:00
;
; AVX2-LABEL: PR41414:
; AVX2: # %bb.0:
; AVX2-NEXT: vmovq %rdi, %xmm1
; AVX2-NEXT: vpunpckldq {{.*#+}} xmm1 = xmm1[0],mem[0],xmm1[1],mem[1]
; AVX2-NEXT: vsubpd {{.*}}(%rip), %xmm1, %xmm1
[X86][SSE] LowerUINT_TO_FP_i64 - only use HADDPD for size/fast-hops We were always generating a single source HADDPD, but really we should only do this if shouldUseHorizontalOp says its a good idea. Differential Revision: https://reviews.llvm.org/D69175 llvm-svn: 375341
2019-10-19 19:53:48 +08:00
; AVX2-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; AVX2-NEXT: vaddsd %xmm1, %xmm2, %xmm1
[x86] make sure horizontal op and broadcast types match to simplify (PR41414) If the types don't match, we can't just remove the shuffle. There may be some other opportunity for optimization here, but this should prevent the crashing seen in: https://bugs.llvm.org/show_bug.cgi?id=41414 llvm-svn: 359095
2019-04-24 22:05:08 +08:00
; AVX2-NEXT: vbroadcastsd %xmm1, %ymm1
; AVX2-NEXT: vdivpd %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vxorpd %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vaddpd %ymm1, %ymm0, %ymm0
; AVX2-NEXT: retq
%conv = uitofp i64 %x to double
%t0 = insertelement <4 x double> undef, double %conv, i32 0
%t1 = shufflevector <4 x double> %t0, <4 x double> undef, <4 x i32> zeroinitializer
%t2 = fdiv <4 x double> %y, %t1
%t3 = fadd <4 x double> zeroinitializer, %t2
ret <4 x double> %t3
}