RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 11:42:57 +01:00
Code Issues Projects Releases Wiki Activity
db855efbed
llvm-mirror/test/CodeGen/SystemZ/vec-move-02.ll

185 lines
4.2 KiB
LLVM
Raw Normal View History

[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; Test vector loads.
;
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 | FileCheck %s
; Test v16i8 loads.
define <16 x i8> @f1(<16 x i8> *%ptr) {
; CHECK-LABEL: f1:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ret = load <16 x i8>, <16 x i8> *%ptr
ret <16 x i8> %ret
}
; Test v8i16 loads.
define <8 x i16> @f2(<8 x i16> *%ptr) {
; CHECK-LABEL: f2:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ret = load <8 x i16>, <8 x i16> *%ptr
ret <8 x i16> %ret
}
; Test v4i32 loads.
define <4 x i32> @f3(<4 x i32> *%ptr) {
; CHECK-LABEL: f3:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ret = load <4 x i32>, <4 x i32> *%ptr
ret <4 x i32> %ret
}
; Test v2i64 loads.
define <2 x i64> @f4(<2 x i64> *%ptr) {
; CHECK-LABEL: f4:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ret = load <2 x i64>, <2 x i64> *%ptr
ret <2 x i64> %ret
}
[SystemZ] Add CodeGen support for v4f32 The architecture doesn't really have any native v4f32 operations except v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32 elements being used. Even so, using vector registers for <4 x float> and scalarising individual operations is much better than generating completely scalar code, since there's much less register pressure. It's also more efficient to do v4f32 comparisons by extending to 2 v2f64s, comparing those, then packing the result. This particularly helps with llvmpipe. Based on a patch by Richard Sandiford. llvm-svn: 236523
2015-05-05 21:27:45 +02:00
; Test v4f32 loads.
define <4 x float> @f5(<4 x float> *%ptr) {
; CHECK-LABEL: f5:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for v4f32 The architecture doesn't really have any native v4f32 operations except v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32 elements being used. Even so, using vector registers for <4 x float> and scalarising individual operations is much better than generating completely scalar code, since there's much less register pressure. It's also more efficient to do v4f32 comparisons by extending to 2 v2f64s, comparing those, then packing the result. This particularly helps with llvmpipe. Based on a patch by Richard Sandiford. llvm-svn: 236523
2015-05-05 21:27:45 +02:00
; CHECK: br %r14
%ret = load <4 x float>, <4 x float> *%ptr
ret <4 x float> %ret
}
[SystemZ] Add CodeGen support for v2f64 This adds ABI and CodeGen support for the v2f64 type, which is natively supported by z13 instructions. Based on a patch by Richard Sandiford. llvm-svn: 236522
2015-05-05 21:26:48 +02:00
; Test v2f64 loads.
define <2 x double> @f6(<2 x double> *%ptr) {
; CHECK-LABEL: f6:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for v2f64 This adds ABI and CodeGen support for the v2f64 type, which is natively supported by z13 instructions. Based on a patch by Richard Sandiford. llvm-svn: 236522
2015-05-05 21:26:48 +02:00
; CHECK: br %r14
%ret = load <2 x double>, <2 x double> *%ptr
ret <2 x double> %ret
}
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; Test the highest aligned in-range offset.
define <16 x i8> @f7(<16 x i8> *%base) {
; CHECK-LABEL: f7:
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 4080(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ptr = getelementptr <16 x i8>, <16 x i8> *%base, i64 255
%ret = load <16 x i8>, <16 x i8> *%ptr
ret <16 x i8> %ret
}
; Test the highest unaligned in-range offset.
define <16 x i8> @f8(i8 *%base) {
; CHECK-LABEL: f8:
; CHECK: vl %v24, 4095(%r2)
; CHECK: br %r14
%addr = getelementptr i8, i8 *%base, i64 4095
%ptr = bitcast i8 *%addr to <16 x i8> *
%ret = load <16 x i8>, <16 x i8> *%ptr, align 1
ret <16 x i8> %ret
}
; Test the next offset up, which requires separate address logic,
define <16 x i8> @f9(<16 x i8> *%base) {
; CHECK-LABEL: f9:
; CHECK: aghi %r2, 4096
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ptr = getelementptr <16 x i8>, <16 x i8> *%base, i64 256
%ret = load <16 x i8>, <16 x i8> *%ptr
ret <16 x i8> %ret
}
; Test negative offsets, which also require separate address logic,
define <16 x i8> @f10(<16 x i8> *%base) {
; CHECK-LABEL: f10:
; CHECK: aghi %r2, -16
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; CHECK: vl %v24, 0(%r2), 3
[SystemZ] Add CodeGen support for integer vector types This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
2015-05-05 21:25:42 +02:00
; CHECK: br %r14
%ptr = getelementptr <16 x i8>, <16 x i8> *%base, i64 -1
%ret = load <16 x i8>, <16 x i8> *%ptr
ret <16 x i8> %ret
}
; Check that indexes are allowed.
define <16 x i8> @f11(i8 *%base, i64 %index) {
; CHECK-LABEL: f11:
; CHECK: vl %v24, 0(%r3,%r2)
; CHECK: br %r14
%addr = getelementptr i8, i8 *%base, i64 %index
%ptr = bitcast i8 *%addr to <16 x i8> *
%ret = load <16 x i8>, <16 x i8> *%ptr, align 1
ret <16 x i8> %ret
}
[LegalizeVectorTypes] Allow single loads and stores for more short vectors When lowering a load or store for TypeWidenVector, the type legalizer would use a single load or store if the associated integer type was legal. E.g. it would load a v4i8 as an i32 if i32 was legal. This patch extends that behavior to promoted integers as well as legal ones. If the integer type for the full vector width is TypePromoteInteger, the element type is going to be TypePromoteInteger too, and it's still better to use a single promoting load or truncating store rather than N individual promoting loads or truncating stores. E.g. if you have a v2i8 on a target where i16 is promoted to i32, it's better to load the v2i8 as an i16 rather than load both i8s individually. Original patch by Richard Sandiford. llvm-svn: 236528
2015-05-05 21:32:57 +02:00
; Test v2i8 loads.
define <2 x i8> @f12(<2 x i8> *%ptr) {
; CHECK-LABEL: f12:
; CHECK: vlreph %v24, 0(%r2)
; CHECK: br %r14
%ret = load <2 x i8>, <2 x i8> *%ptr
ret <2 x i8> %ret
}
; Test v4i8 loads.
define <4 x i8> @f13(<4 x i8> *%ptr) {
; CHECK-LABEL: f13:
; CHECK: vlrepf %v24, 0(%r2)
; CHECK: br %r14
%ret = load <4 x i8>, <4 x i8> *%ptr
ret <4 x i8> %ret
}
; Test v8i8 loads.
define <8 x i8> @f14(<8 x i8> *%ptr) {
; CHECK-LABEL: f14:
; CHECK: vlrepg %v24, 0(%r2)
; CHECK: br %r14
%ret = load <8 x i8>, <8 x i8> *%ptr
ret <8 x i8> %ret
}
; Test v2i16 loads.
define <2 x i16> @f15(<2 x i16> *%ptr) {
; CHECK-LABEL: f15:
; CHECK: vlrepf %v24, 0(%r2)
; CHECK: br %r14
%ret = load <2 x i16>, <2 x i16> *%ptr
ret <2 x i16> %ret
}
; Test v4i16 loads.
define <4 x i16> @f16(<4 x i16> *%ptr) {
; CHECK-LABEL: f16:
; CHECK: vlrepg %v24, 0(%r2)
; CHECK: br %r14
%ret = load <4 x i16>, <4 x i16> *%ptr
ret <4 x i16> %ret
}
; Test v2i32 loads.
define <2 x i32> @f17(<2 x i32> *%ptr) {
; CHECK-LABEL: f17:
; CHECK: vlrepg %v24, 0(%r2)
; CHECK: br %r14
%ret = load <2 x i32>, <2 x i32> *%ptr
ret <2 x i32> %ret
}
; Test v2f32 loads.
define <2 x float> @f18(<2 x float> *%ptr) {
; CHECK-LABEL: f18:
; CHECK: vlrepg %v24, 0(%r2)
; CHECK: br %r14
%ret = load <2 x float>, <2 x float> *%ptr
ret <2 x float> %ret
}
[SystemZ] Support vector load/store alignment hints Vector load/store instructions support an optional alignment field that the compiler can use to provide known alignment info to the hardware. If the field is used (and the information is correct), the hardware may be able (on some models) to perform faster memory accesses than otherwise. This patch adds support for alignment hints in the assembler and disassembler, and fills in known alignment during codegen. llvm-svn: 363806
2019-06-19 16:20:00 +02:00
; Test quadword-aligned loads.
define <16 x i8> @f19(<16 x i8> *%ptr) {
; CHECK-LABEL: f19:
; CHECK: vl %v24, 0(%r2), 4
; CHECK: br %r14
%ret = load <16 x i8>, <16 x i8> *%ptr, align 16
ret <16 x i8> %ret
}
Reference in New Issue Copy Permalink