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/PowerPC/vsx.ll

644 lines
14 KiB
LLVM
Raw Normal View History

[PowerPC] Initial support for the VSX instruction set VSX is an ISA extension supported on the POWER7 and later cores that enhances floating-point vector and scalar capabilities. Among other things, this adds <2 x double> support and generally helps to reduce register pressure. The interesting part of this ISA feature is the register configuration: there are 64 new 128-bit vector registers, the 32 of which are super-registers of the existing 32 scalar floating-point registers, and the second 32 of which overlap with the 32 Altivec vector registers. This makes things like vector insertion and extraction tricky: this can be free but only if we force a restriction to the right register subclass when needed. A new "minipass" PPCVSXCopy takes care of this (although it could do a more-optimal job of it; see the comment about unnecessary copies below). Please note that, currently, VSX is not enabled by default when targeting anything because it is not yet ready for that. The assembler and disassembler are fully implemented and tested. However: - CodeGen support causes miscompiles; test-suite runtime failures: MultiSource/Benchmarks/FreeBench/distray/distray MultiSource/Benchmarks/McCat/08-main/main MultiSource/Benchmarks/Olden/voronoi/voronoi MultiSource/Benchmarks/mafft/pairlocalalign MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 SingleSource/Benchmarks/CoyoteBench/almabench SingleSource/Benchmarks/Misc/matmul_f64_4x4 - The lowering currently falls back to using Altivec instructions far more than it should. Worse, there are some things that are scalarized through the stack that shouldn't be. - A lot of unnecessary copies make it past the optimizers, and this needs to be fixed. - Many more regression tests are needed. Normally, I'd fix these things prior to committing, but there are some students and other contributors who would like to work this, and so it makes sense to move this development process upstream where it can be subject to the regular code-review procedures. llvm-svn: 203768
2014-03-13 15:58:58 +08:00
; RUN: llc -mcpu=pwr7 -mattr=+vsx < %s | FileCheck %s
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define double @test1(double %a, double %b) {
entry:
%v = fmul double %a, %b
ret double %v
; CHECK-LABEL: @test1
; CHECK: xsmuldp 1, 1, 2
; CHECK: blr
}
define double @test2(double %a, double %b) {
entry:
%v = fdiv double %a, %b
ret double %v
; CHECK-LABEL: @test2
; CHECK: xsdivdp 1, 1, 2
; CHECK: blr
}
define double @test3(double %a, double %b) {
entry:
%v = fadd double %a, %b
ret double %v
; CHECK-LABEL: @test3
; CHECK: xsadddp 1, 1, 2
; CHECK: blr
}
define <2 x double> @test4(<2 x double> %a, <2 x double> %b) {
entry:
%v = fadd <2 x double> %a, %b
ret <2 x double> %v
; CHECK-LABEL: @test4
[PowerPC] Fix the VSX v2f64 return register v2f64 values, like other 128-bit values, are returned under VSX in register vs34 (Altivec register v2). llvm-svn: 204543
2014-03-23 02:24:43 +08:00
; CHECK: xvadddp 34, 34, 35
[PowerPC] Initial support for the VSX instruction set VSX is an ISA extension supported on the POWER7 and later cores that enhances floating-point vector and scalar capabilities. Among other things, this adds <2 x double> support and generally helps to reduce register pressure. The interesting part of this ISA feature is the register configuration: there are 64 new 128-bit vector registers, the 32 of which are super-registers of the existing 32 scalar floating-point registers, and the second 32 of which overlap with the 32 Altivec vector registers. This makes things like vector insertion and extraction tricky: this can be free but only if we force a restriction to the right register subclass when needed. A new "minipass" PPCVSXCopy takes care of this (although it could do a more-optimal job of it; see the comment about unnecessary copies below). Please note that, currently, VSX is not enabled by default when targeting anything because it is not yet ready for that. The assembler and disassembler are fully implemented and tested. However: - CodeGen support causes miscompiles; test-suite runtime failures: MultiSource/Benchmarks/FreeBench/distray/distray MultiSource/Benchmarks/McCat/08-main/main MultiSource/Benchmarks/Olden/voronoi/voronoi MultiSource/Benchmarks/mafft/pairlocalalign MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 SingleSource/Benchmarks/CoyoteBench/almabench SingleSource/Benchmarks/Misc/matmul_f64_4x4 - The lowering currently falls back to using Altivec instructions far more than it should. Worse, there are some things that are scalarized through the stack that shouldn't be. - A lot of unnecessary copies make it past the optimizers, and this needs to be fixed. - Many more regression tests are needed. Normally, I'd fix these things prior to committing, but there are some students and other contributors who would like to work this, and so it makes sense to move this development process upstream where it can be subject to the regular code-review procedures. llvm-svn: 203768
2014-03-13 15:58:58 +08:00
; CHECK: blr
}
[PowerPC] Generate logical vector VSX instructions These instructions are essentially the same as their Altivec counterparts, but have access to the larger VSX register file. llvm-svn: 204782
2014-03-26 12:55:40 +08:00
define <4 x i32> @test5(<4 x i32> %a, <4 x i32> %b) {
entry:
%v = xor <4 x i32> %a, %b
ret <4 x i32> %v
; CHECK-LABEL: @test5
; CHECK: xxlxor 34, 34, 35
; CHECK: blr
}
define <8 x i16> @test6(<8 x i16> %a, <8 x i16> %b) {
entry:
%v = xor <8 x i16> %a, %b
ret <8 x i16> %v
; CHECK-LABEL: @test6
; CHECK: xxlxor 34, 34, 35
; CHECK: blr
}
define <16 x i8> @test7(<16 x i8> %a, <16 x i8> %b) {
entry:
%v = xor <16 x i8> %a, %b
ret <16 x i8> %v
; CHECK-LABEL: @test7
; CHECK: xxlxor 34, 34, 35
; CHECK: blr
}
define <4 x i32> @test8(<4 x i32> %a, <4 x i32> %b) {
entry:
%v = or <4 x i32> %a, %b
ret <4 x i32> %v
; CHECK-LABEL: @test8
; CHECK: xxlor 34, 34, 35
; CHECK: blr
}
define <8 x i16> @test9(<8 x i16> %a, <8 x i16> %b) {
entry:
%v = or <8 x i16> %a, %b
ret <8 x i16> %v
; CHECK-LABEL: @test9
; CHECK: xxlor 34, 34, 35
; CHECK: blr
}
define <16 x i8> @test10(<16 x i8> %a, <16 x i8> %b) {
entry:
%v = or <16 x i8> %a, %b
ret <16 x i8> %v
; CHECK-LABEL: @test10
; CHECK: xxlor 34, 34, 35
; CHECK: blr
}
define <4 x i32> @test11(<4 x i32> %a, <4 x i32> %b) {
entry:
%v = and <4 x i32> %a, %b
ret <4 x i32> %v
; CHECK-LABEL: @test11
; CHECK: xxland 34, 34, 35
; CHECK: blr
}
define <8 x i16> @test12(<8 x i16> %a, <8 x i16> %b) {
entry:
%v = and <8 x i16> %a, %b
ret <8 x i16> %v
; CHECK-LABEL: @test12
; CHECK: xxland 34, 34, 35
; CHECK: blr
}
define <16 x i8> @test13(<16 x i8> %a, <16 x i8> %b) {
entry:
%v = and <16 x i8> %a, %b
ret <16 x i8> %v
; CHECK-LABEL: @test13
; CHECK: xxland 34, 34, 35
; CHECK: blr
}
define <4 x i32> @test14(<4 x i32> %a, <4 x i32> %b) {
entry:
%v = or <4 x i32> %a, %b
%w = xor <4 x i32> %v, <i32 -1, i32 -1, i32 -1, i32 -1>
ret <4 x i32> %w
; CHECK-LABEL: @test14
; CHECK: xxlnor 34, 34, 35
; CHECK: blr
}
define <8 x i16> @test15(<8 x i16> %a, <8 x i16> %b) {
entry:
%v = or <8 x i16> %a, %b
%w = xor <8 x i16> %v, <i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1>
ret <8 x i16> %w
; CHECK-LABEL: @test15
; CHECK: xxlnor 34, 34, 35
; CHECK: blr
}
define <16 x i8> @test16(<16 x i8> %a, <16 x i8> %b) {
entry:
%v = or <16 x i8> %a, %b
%w = xor <16 x i8> %v, <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>
ret <16 x i8> %w
; CHECK-LABEL: @test16
; CHECK: xxlnor 34, 34, 35
; CHECK: blr
}
define <4 x i32> @test17(<4 x i32> %a, <4 x i32> %b) {
entry:
%w = xor <4 x i32> %b, <i32 -1, i32 -1, i32 -1, i32 -1>
%v = and <4 x i32> %a, %w
ret <4 x i32> %v
; CHECK-LABEL: @test17
; CHECK: xxlandc 34, 34, 35
; CHECK: blr
}
define <8 x i16> @test18(<8 x i16> %a, <8 x i16> %b) {
entry:
%w = xor <8 x i16> %b, <i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1>
%v = and <8 x i16> %a, %w
ret <8 x i16> %v
; CHECK-LABEL: @test18
; CHECK: xxlandc 34, 34, 35
; CHECK: blr
}
define <16 x i8> @test19(<16 x i8> %a, <16 x i8> %b) {
entry:
%w = xor <16 x i8> %b, <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>
%v = and <16 x i8> %a, %w
ret <16 x i8> %v
; CHECK-LABEL: @test19
; CHECK: xxlandc 34, 34, 35
; CHECK: blr
}
[PowerPC] Lower VSELECT using xxsel when VSX is available With VSX there is a real vector select instruction, and so we should use it. Note that VSELECT will still scalarize for v2f64 because the corresponding SetCC result type (v2i64) is not currently a legal type. llvm-svn: 204801
2014-03-26 20:49:28 +08:00
define <4 x i32> @test20(<4 x i32> %a, <4 x i32> %b, <4 x i32> %c, <4 x i32> %d) {
entry:
%m = icmp eq <4 x i32> %c, %d
%v = select <4 x i1> %m, <4 x i32> %a, <4 x i32> %b
ret <4 x i32> %v
; CHECK-LABEL: @test20
; CHECK: vcmpequw {{[0-9]+}}, 4, 5
; CHECK: xxsel 34, 35, 34, {{[0-9]+}}
; CHECK: blr
}
define <4 x float> @test21(<4 x float> %a, <4 x float> %b, <4 x float> %c, <4 x float> %d) {
entry:
%m = fcmp oeq <4 x float> %c, %d
%v = select <4 x i1> %m, <4 x float> %a, <4 x float> %b
ret <4 x float> %v
; CHECK-LABEL: @test21
; CHECK: xvcmpeqsp [[V1:[0-9]+]], 36, 37
; CHECK: xxsel 34, 35, 34, [[V1]]
; CHECK: blr
}
define <4 x float> @test22(<4 x float> %a, <4 x float> %b, <4 x float> %c, <4 x float> %d) {
entry:
%m = fcmp ueq <4 x float> %c, %d
%v = select <4 x i1> %m, <4 x float> %a, <4 x float> %b
ret <4 x float> %v
; CHECK-LABEL: @test22
; CHECK-DAG: xvcmpeqsp {{[0-9]+}}, 37, 37
; CHECK-DAG: xvcmpeqsp {{[0-9]+}}, 36, 36
; CHECK-DAG: xvcmpeqsp {{[0-9]+}}, 36, 37
; CHECK-DAG: xxlnor
; CHECK-DAG: xxlnor
; CHECK-DAG: xxlor
; CHECK-DAG: xxlor
; CHECK: xxsel 34, 35, 34, {{[0-9]+}}
; CHECK: blr
}
define <8 x i16> @test23(<8 x i16> %a, <8 x i16> %b, <8 x i16> %c, <8 x i16> %d) {
entry:
%m = icmp eq <8 x i16> %c, %d
%v = select <8 x i1> %m, <8 x i16> %a, <8 x i16> %b
ret <8 x i16> %v
; CHECK-LABEL: @test23
; CHECK: vcmpequh {{[0-9]+}}, 4, 5
; CHECK: xxsel 34, 35, 34, {{[0-9]+}}
; CHECK: blr
}
define <16 x i8> @test24(<16 x i8> %a, <16 x i8> %b, <16 x i8> %c, <16 x i8> %d) {
entry:
%m = icmp eq <16 x i8> %c, %d
%v = select <16 x i1> %m, <16 x i8> %a, <16 x i8> %b
ret <16 x i8> %v
; CHECK-LABEL: @test24
; CHECK: vcmpequb {{[0-9]+}}, 4, 5
; CHECK: xxsel 34, 35, 34, {{[0-9]+}}
; CHECK: blr
}
define <2 x double> @test25(<2 x double> %a, <2 x double> %b, <2 x double> %c, <2 x double> %d) {
entry:
%m = fcmp oeq <2 x double> %c, %d
%v = select <2 x i1> %m, <2 x double> %a, <2 x double> %b
ret <2 x double> %v
; CHECK-LABEL: @test25
[PowerPC] Add v2i64 as a legal VSX type v2i64 needs to be a legal VSX type because it is the SetCC result type from v2f64 comparisons. We need to expand all non-arithmetic v2i64 operations. This fixes the lowering for v2f64 VSELECT. llvm-svn: 204828
2014-03-27 00:12:58 +08:00
; CHECK: xvcmpeqdp [[V1:[0-9]+]], 36, 37
; CHECK: xxsel 34, 35, 34, [[V1]]
; CHECK: blr
}
define <2 x i64> @test26(<2 x i64> %a, <2 x i64> %b) {
%v = add <2 x i64> %a, %b
ret <2 x i64> %v
; CHECK-LABEL: @test26
Make use of previously generated stores in SelectionDAGLegalize::ExpandExtractFromVectorThroughStack When expanding EXTRACT_VECTOR_ELT and EXTRACT_SUBVECTOR using SelectionDAGLegalize::ExpandExtractFromVectorThroughStack, we store the entire vector and then load the piece we want. This is fine in isolation, but generating a new store (and corresponding stack slot) for each extraction ends up producing code of poor quality. When we scalarize a vector operation (using SelectionDAG::UnrollVectorOp for example) we generate one EXTRACT_VECTOR_ELT for each element in the vector. This used to generate one stored copy of the vector for each element in the vector. Now we search the uses of the vector for a suitable store before generating a new one, which results in much more efficient scalarization code. llvm-svn: 205153
2014-03-30 23:10:18 +08:00
; Make sure we use only two stores (one for each operand).
; CHECK: stxvd2x 35,
; CHECK: stxvd2x 34,
; CHECK-NOT: stxvd2x
[PowerPC] Add v2i64 as a legal VSX type v2i64 needs to be a legal VSX type because it is the SetCC result type from v2f64 comparisons. We need to expand all non-arithmetic v2i64 operations. This fixes the lowering for v2f64 VSELECT. llvm-svn: 204828
2014-03-27 00:12:58 +08:00
; FIXME: The code quality here is not good; just make sure we do something for now.
; CHECK: add
; CHECK: add
; CHECK: blr
}
define <2 x i64> @test27(<2 x i64> %a, <2 x i64> %b) {
%v = and <2 x i64> %a, %b
ret <2 x i64> %v
; CHECK-LABEL: @test27
; CHECK: xxland 34, 34, 35
[PowerPC] Lower VSELECT using xxsel when VSX is available With VSX there is a real vector select instruction, and so we should use it. Note that VSELECT will still scalarize for v2f64 because the corresponding SetCC result type (v2i64) is not currently a legal type. llvm-svn: 204801
2014-03-26 20:49:28 +08:00
; CHECK: blr
}
[PowerPC] Use VSX vector load/stores for v2[fi]64 These instructions have access to the complete VSX register file. In addition, they "swap" the order of the elements so that element 0 (the scalar part) comes first in memory and element 1 follows at a higher address. llvm-svn: 204838
2014-03-27 02:26:30 +08:00
define <2 x double> @test28(<2 x double>* %a) {
%v = load <2 x double>* %a, align 16
ret <2 x double> %v
; CHECK-LABEL: @test28
; CHECK: lxvd2x 34, 0, 3
; CHECK: blr
}
define void @test29(<2 x double>* %a, <2 x double> %b) {
store <2 x double> %b, <2 x double>* %a, align 16
ret void
; CHECK-LABEL: @test29
; CHECK: stxvd2x 34, 0, 3
; CHECK: blr
}
[PowerPC] VSX loads and stores support unaligned access I've not yet updated PPCTTI because I'm not sure what the actual relative cost is compared to the aligned uses. llvm-svn: 204848
2014-03-27 03:39:09 +08:00
define <2 x double> @test28u(<2 x double>* %a) {
%v = load <2 x double>* %a, align 8
ret <2 x double> %v
; CHECK-LABEL: @test28u
; CHECK: lxvd2x 34, 0, 3
; CHECK: blr
}
define void @test29u(<2 x double>* %a, <2 x double> %b) {
store <2 x double> %b, <2 x double>* %a, align 8
ret void
; CHECK-LABEL: @test29u
; CHECK: stxvd2x 34, 0, 3
; CHECK: blr
}
[PowerPC] Use VSX vector load/stores for v2[fi]64 These instructions have access to the complete VSX register file. In addition, they "swap" the order of the elements so that element 0 (the scalar part) comes first in memory and element 1 follows at a higher address. llvm-svn: 204838
2014-03-27 02:26:30 +08:00
define <2 x i64> @test30(<2 x i64>* %a) {
%v = load <2 x i64>* %a, align 16
ret <2 x i64> %v
; CHECK-LABEL: @test30
; CHECK: lxvd2x 34, 0, 3
; CHECK: blr
}
define void @test31(<2 x i64>* %a, <2 x i64> %b) {
store <2 x i64> %b, <2 x i64>* %a, align 16
ret void
; CHECK-LABEL: @test31
; CHECK: stxvd2x 34, 0, 3
; CHECK: blr
}
[PowerPC] Use v2f64 <-> v2i64 VSX conversion instructions llvm-svn: 204843
2014-03-27 03:13:54 +08:00
define <2 x double> @test40(<2 x i64> %a) {
%v = uitofp <2 x i64> %a to <2 x double>
ret <2 x double> %v
; CHECK-LABEL: @test40
; CHECK: xvcvuxddp 34, 34
; CHECK: blr
}
define <2 x double> @test41(<2 x i64> %a) {
%v = sitofp <2 x i64> %a to <2 x double>
ret <2 x double> %v
; CHECK-LABEL: @test41
; CHECK: xvcvsxddp 34, 34
; CHECK: blr
}
define <2 x i64> @test42(<2 x double> %a) {
%v = fptoui <2 x double> %a to <2 x i64>
ret <2 x i64> %v
; CHECK-LABEL: @test42
; CHECK: xvcvdpuxds 34, 34
; CHECK: blr
}
define <2 x i64> @test43(<2 x double> %a) {
%v = fptosi <2 x double> %a to <2 x i64>
ret <2 x i64> %v
; CHECK-LABEL: @test43
; CHECK: xvcvdpsxds 34, 34
; CHECK: blr
}
define <2 x float> @test44(<2 x i64> %a) {
%v = uitofp <2 x i64> %a to <2 x float>
ret <2 x float> %v
; CHECK-LABEL: @test44
; FIXME: The code quality here looks pretty bad.
; CHECK: blr
}
define <2 x float> @test45(<2 x i64> %a) {
%v = sitofp <2 x i64> %a to <2 x float>
ret <2 x float> %v
; CHECK-LABEL: @test45
; FIXME: The code quality here looks pretty bad.
; CHECK: blr
}
define <2 x i64> @test46(<2 x float> %a) {
%v = fptoui <2 x float> %a to <2 x i64>
ret <2 x i64> %v
; CHECK-LABEL: @test46
; FIXME: The code quality here looks pretty bad.
; CHECK: blr
}
define <2 x i64> @test47(<2 x float> %a) {
%v = fptosi <2 x float> %a to <2 x i64>
ret <2 x i64> %v
; CHECK-LABEL: @test47
; FIXME: The code quality here looks pretty bad.
; CHECK: blr
}
[PowerPC] Generate VSX permutations for v2[fi]64 vectors llvm-svn: 204873
2014-03-27 06:58:37 +08:00
define <2 x double> @test50(double* %a) {
%v = load double* %a, align 8
%w = insertelement <2 x double> undef, double %v, i32 0
%x = insertelement <2 x double> %w, double %v, i32 1
ret <2 x double> %x
; CHECK-LABEL: @test50
; CHECK: lxvdsx 34, 0, 3
; CHECK: blr
}
define <2 x double> @test51(<2 x double> %a, <2 x double> %b) {
%v = shufflevector <2 x double> %a, <2 x double> %b, <2 x i32> <i32 0, i32 0>
ret <2 x double> %v
; CHECK-LABEL: @test51
; CHECK: xxpermdi 34, 34, 34, 0
; CHECK: blr
}
define <2 x double> @test52(<2 x double> %a, <2 x double> %b) {
%v = shufflevector <2 x double> %a, <2 x double> %b, <2 x i32> <i32 0, i32 2>
ret <2 x double> %v
; CHECK-LABEL: @test52
; CHECK: xxpermdi 34, 34, 35, 0
; CHECK: blr
}
define <2 x double> @test53(<2 x double> %a, <2 x double> %b) {
%v = shufflevector <2 x double> %a, <2 x double> %b, <2 x i32> <i32 2, i32 0>
ret <2 x double> %v
; CHECK-LABEL: @test53
; CHECK: xxpermdi 34, 35, 34, 0
; CHECK: blr
}
define <2 x double> @test54(<2 x double> %a, <2 x double> %b) {
%v = shufflevector <2 x double> %a, <2 x double> %b, <2 x i32> <i32 1, i32 2>
ret <2 x double> %v
; CHECK-LABEL: @test54
[PowerPC] Fix VSX permutation isel Not only did I invert the indices when I wrote the code, but I also did the same thing when I wrote the regression test. Oops. llvm-svn: 205046
2014-03-29 04:24:55 +08:00
; CHECK: xxpermdi 34, 34, 35, 2
[PowerPC] Generate VSX permutations for v2[fi]64 vectors llvm-svn: 204873
2014-03-27 06:58:37 +08:00
; CHECK: blr
}
define <2 x double> @test55(<2 x double> %a, <2 x double> %b) {
%v = shufflevector <2 x double> %a, <2 x double> %b, <2 x i32> <i32 1, i32 3>
ret <2 x double> %v
; CHECK-LABEL: @test55
; CHECK: xxpermdi 34, 34, 35, 3
; CHECK: blr
}
define <2 x i64> @test56(<2 x i64> %a, <2 x i64> %b) {
%v = shufflevector <2 x i64> %a, <2 x i64> %b, <2 x i32> <i32 1, i32 3>
ret <2 x i64> %v
; CHECK-LABEL: @test56
; CHECK: xxpermdi 34, 34, 35, 3
; CHECK: blr
}
[PowerPC] Expand v2i64 shifts These operations need to be expanded during legalization so that isel does not crash. In theory, we might be able to custom lower some of these. That, however, would need to be follow-up work. llvm-svn: 204963
2014-03-28 05:26:33 +08:00
define <2 x i64> @test60(<2 x i64> %a, <2 x i64> %b) {
%v = shl <2 x i64> %a, %b
ret <2 x i64> %v
; CHECK-LABEL: @test60
; This should scalarize, and the current code quality is not good.
; CHECK: stxvd2x
; CHECK: stxvd2x
; CHECK: sld
; CHECK: sld
; CHECK: lxvd2x
; CHECK: blr
}
define <2 x i64> @test61(<2 x i64> %a, <2 x i64> %b) {
%v = lshr <2 x i64> %a, %b
ret <2 x i64> %v
; CHECK-LABEL: @test61
; This should scalarize, and the current code quality is not good.
; CHECK: stxvd2x
; CHECK: stxvd2x
; CHECK: srd
; CHECK: srd
; CHECK: lxvd2x
; CHECK: blr
}
define <2 x i64> @test62(<2 x i64> %a, <2 x i64> %b) {
%v = ashr <2 x i64> %a, %b
ret <2 x i64> %v
; CHECK-LABEL: @test62
; This should scalarize, and the current code quality is not good.
; CHECK: stxvd2x
; CHECK: stxvd2x
; CHECK: srad
; CHECK: srad
; CHECK: lxvd2x
; CHECK: blr
}
[PowerPC] Fix v2f64 vector extract and related patterns First, v2f64 vector extract had not been declared legal (and so the existing patterns were not being used). Second, the patterns for that, and for scalar_to_vector, should really be a regclass copy, not a subregister operation, because the VSX registers directly hold both the vector and scalar data. llvm-svn: 204971
2014-03-28 06:22:48 +08:00
define double @test63(<2 x double> %a) {
%v = extractelement <2 x double> %a, i32 0
ret double %v
; CHECK-LABEL: @test63
; CHECK: xxlor 1, 34, 34
; CHECK: blr
}
define double @test64(<2 x double> %a) {
%v = extractelement <2 x double> %a, i32 1
ret double %v
; CHECK-LABEL: @test64
; CHECK: xxpermdi 1, 34, 34, 2
; CHECK: blr
}
[PowerPC] Handle v2i64 comparisons v2i64 is a legal type under VSX, however we don't have native vector comparisons. We can handle eq/ne by casting it to an Altivec type, but everything else must be expanded. llvm-svn: 205106
2014-03-30 00:04:40 +08:00
define <2 x i1> @test65(<2 x i64> %a, <2 x i64> %b) {
%w = icmp eq <2 x i64> %a, %b
ret <2 x i1> %w
; CHECK-LABEL: @test65
; CHECK: vcmpequw 2, 2, 3
; CHECK: blr
}
define <2 x i1> @test66(<2 x i64> %a, <2 x i64> %b) {
%w = icmp ne <2 x i64> %a, %b
ret <2 x i1> %w
; CHECK-LABEL: @test66
; CHECK: vcmpequw {{[0-9]+}}, 2, 3
; CHECK: xxlnor 34, {{[0-9]+}}, {{[0-9]+}}
; CHECK: blr
}
define <2 x i1> @test67(<2 x i64> %a, <2 x i64> %b) {
%w = icmp ult <2 x i64> %a, %b
ret <2 x i1> %w
; CHECK-LABEL: @test67
; This should scalarize, and the current code quality is not good.
; CHECK: stxvd2x
; CHECK: stxvd2x
; CHECK: cmpld
; CHECK: cmpld
; CHECK: lxvd2x
; CHECK: blr
}
[PowerPC] Handle VSX v2i64 SIGN_EXTEND_INREG sitofp from v2i32 to v2f64 ends up generating a SIGN_EXTEND_INREG v2i64 node (and similarly for v2i16 and v2i8). Even though there are no sign-extension (or algebraic shifts) for v2i64 types, we can handle v2i32 sign extensions by converting two and from v2i64. The small trick necessary here is to shift the i32 elements into the right lanes before the i32 -> f64 step. This is because of the big Endian nature of the system, we need the i32 portion in the high word of the i64 elements. For v2i16 and v2i8 we can do the same, but we first use the default Altivec shift-based expansion from v2i16 or v2i8 to v2i32 (by casting to v4i32) and then apply the above procedure. llvm-svn: 205146
2014-03-30 21:22:59 +08:00
define <2 x double> @test68(<2 x i32> %a) {
%w = sitofp <2 x i32> %a to <2 x double>
ret <2 x double> %w
; CHECK-LABEL: @test68
; CHECK: xxsldwi [[V1:[0-9]+]], 34, 34, 1
; CHECK: xvcvsxwdp 34, [[V1]]
; CHECK: blr
}
define <2 x double> @test69(<2 x i16> %a) {
%w = sitofp <2 x i16> %a to <2 x double>
ret <2 x double> %w
; CHECK-LABEL: @test69
; CHECK: vspltisw [[V1:[0-9]+]], 8
; CHECK: vadduwm [[V2:[0-9]+]], [[V1]], [[V1]]
; CHECK: vslw [[V3:[0-9]+]], 2, [[V2]]
; CHECK: vsraw {{[0-9]+}}, [[V3]], [[V2]]
; CHECK: xxsldwi [[V4:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}, 1
; CHECK: xvcvsxwdp 34, [[V4]]
; CHECK: blr
}
define <2 x double> @test70(<2 x i8> %a) {
%w = sitofp <2 x i8> %a to <2 x double>
ret <2 x double> %w
; CHECK-LABEL: @test70
; CHECK: vspltisw [[V1:[0-9]+]], 12
; CHECK: vadduwm [[V2:[0-9]+]], [[V1]], [[V1]]
; CHECK: vslw [[V3:[0-9]+]], 2, [[V2]]
; CHECK: vsraw {{[0-9]+}}, [[V3]], [[V2]]
; CHECK: xxsldwi [[V4:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}, 1
; CHECK: xvcvsxwdp 34, [[V4]]
; CHECK: blr
}
Look at shuffles of build_vectors in DAGCombiner::visitEXTRACT_VECTOR_ELT When the loop vectorizer vectorizes code that uses the loop induction variable, we often end up with IR like this: %b1 = insertelement <2 x i32> undef, i32 %v, i32 0 %b2 = shufflevector <2 x i32> %b1, <2 x i32> undef, <2 x i32> zeroinitializer %i = add <2 x i32> %b2, <i32 2, i32 3> If the add in this example is not legal (as is the case on PPC with VSX), it will be scalarized, and we'll end up with a number of extract_vector_elt nodes with the vector shuffle as the input operand, and that vector shuffle is fed by one or more build_vector nodes. By the time that vector operations are expanded, visitEXTRACT_VECTOR_ELT will not create new extract_vector_elt by looking through the vector shuffle (to make sure that no illegal operations are created), and so the extract_vector_elt -> vector shuffle -> build_vector is never simplified to an operand of the build vector. By looking at build_vectors through a shuffle we fix this particular situation, preventing a vector from being built, only to be deconstructed again (for the scalarized add) -- an expensive proposition when this all needs to be done via the stack. We probably want a more comprehensive fix here where we look back recursively through any shuffles to any build_vectors or scalar_to_vectors, etc. but that can come later. llvm-svn: 205179
2014-03-31 19:43:19 +08:00
define <2 x i32> @test80(i32 %v) {
%b1 = insertelement <2 x i32> undef, i32 %v, i32 0
%b2 = shufflevector <2 x i32> %b1, <2 x i32> undef, <2 x i32> zeroinitializer
%i = add <2 x i32> %b2, <i32 2, i32 3>
ret <2 x i32> %i
; CHECK-LABEL: @test80
[PowerPC] Don't ever expand BUILD_VECTOR of v2i64 with shuffles If we have two unique values for a v2i64 build vector, this will always result in two vector loads if we expand using shuffles. Only one is necessary. llvm-svn: 205231
2014-04-01 01:48:16 +08:00
; CHECK-DAG: addi [[R1:[0-9]+]], 3, 3
; CHECK-DAG: addi [[R2:[0-9]+]], 1, -16
; CHECK-DAG: addi [[R3:[0-9]+]], 3, 2
; CHECK: std [[R1]], 8([[R2]])
; CHECK: std [[R3]], -16(1)
; CHECK: lxvd2x 34, 0, [[R2]]
Look at shuffles of build_vectors in DAGCombiner::visitEXTRACT_VECTOR_ELT When the loop vectorizer vectorizes code that uses the loop induction variable, we often end up with IR like this: %b1 = insertelement <2 x i32> undef, i32 %v, i32 0 %b2 = shufflevector <2 x i32> %b1, <2 x i32> undef, <2 x i32> zeroinitializer %i = add <2 x i32> %b2, <i32 2, i32 3> If the add in this example is not legal (as is the case on PPC with VSX), it will be scalarized, and we'll end up with a number of extract_vector_elt nodes with the vector shuffle as the input operand, and that vector shuffle is fed by one or more build_vector nodes. By the time that vector operations are expanded, visitEXTRACT_VECTOR_ELT will not create new extract_vector_elt by looking through the vector shuffle (to make sure that no illegal operations are created), and so the extract_vector_elt -> vector shuffle -> build_vector is never simplified to an operand of the build vector. By looking at build_vectors through a shuffle we fix this particular situation, preventing a vector from being built, only to be deconstructed again (for the scalarized add) -- an expensive proposition when this all needs to be done via the stack. We probably want a more comprehensive fix here where we look back recursively through any shuffles to any build_vectors or scalar_to_vectors, etc. but that can come later. llvm-svn: 205179
2014-03-31 19:43:19 +08:00
; CHECK-NOT: stxvd2x
; CHECK: blr
}