2013-05-07 00:15:19 +08:00
|
|
|
//=- SystemZCallingConv.td - Calling conventions for SystemZ -*- tablegen -*-=//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// This describes the calling conventions for the SystemZ ABI.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
class CCIfExtend<CCAction A>
|
|
|
|
: CCIf<"ArgFlags.isSExt() || ArgFlags.isZExt()", A>;
|
|
|
|
|
[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-06 03:25:42 +08:00
|
|
|
class CCIfSubtarget<string F, CCAction A>
|
|
|
|
: CCIf<!strconcat("static_cast<const SystemZSubtarget&>"
|
|
|
|
"(State.getMachineFunction().getSubtarget()).", F),
|
|
|
|
A>;
|
|
|
|
|
|
|
|
// Match if this specific argument is a fixed (i.e. named) argument.
|
|
|
|
class CCIfFixed<CCAction A>
|
|
|
|
: CCIf<"static_cast<SystemZCCState *>(&State)->IsFixed(ValNo)", A>;
|
|
|
|
|
2013-05-07 00:15:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2014-07-10 19:44:37 +08:00
|
|
|
// z/Linux return value calling convention
|
2013-05-07 00:15:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
def RetCC_SystemZ : CallingConv<[
|
|
|
|
// Promote i32 to i64 if it has an explicit extension type.
|
|
|
|
CCIfType<[i32], CCIfExtend<CCPromoteToType<i64>>>,
|
|
|
|
|
|
|
|
// ABI-compliant code returns 64-bit integers in R2. Make the other
|
|
|
|
// call-clobbered argument registers available for code that doesn't
|
|
|
|
// care about the ABI. (R6 is an argument register too, but is
|
|
|
|
// call-saved and therefore not suitable for return values.)
|
2013-09-30 16:48:38 +08:00
|
|
|
CCIfType<[i32], CCAssignToReg<[R2L, R3L, R4L, R5L]>>,
|
2013-05-07 00:15:19 +08:00
|
|
|
CCIfType<[i64], CCAssignToReg<[R2D, R3D, R4D, R5D]>>,
|
|
|
|
|
|
|
|
// ABI-complaint code returns float and double in F0. Make the
|
|
|
|
// other floating-point argument registers available for code that
|
|
|
|
// doesn't care about the ABI. All floating-point argument registers
|
|
|
|
// are call-clobbered, so we can use all of them here.
|
|
|
|
CCIfType<[f32], CCAssignToReg<[F0S, F2S, F4S, F6S]>>,
|
[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-06 03:25:42 +08:00
|
|
|
CCIfType<[f64], CCAssignToReg<[F0D, F2D, F4D, F6D]>>,
|
|
|
|
|
|
|
|
// Similarly for vectors, with V24 being the ABI-compliant choice.
|
|
|
|
CCIfSubtarget<"hasVector()",
|
2015-05-06 03:27:45 +08:00
|
|
|
CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
|
[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-06 03:25:42 +08:00
|
|
|
CCAssignToReg<[V24, V26, V28, V30, V25, V27, V29, V31]>>>
|
2013-05-07 00:15:19 +08:00
|
|
|
|
|
|
|
// ABI-compliant code returns long double by reference, but that conversion
|
|
|
|
// is left to higher-level code. Perhaps we could add an f128 definition
|
|
|
|
// here for code that doesn't care about the ABI?
|
|
|
|
]>;
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2014-07-10 19:44:37 +08:00
|
|
|
// z/Linux argument calling conventions
|
2013-05-07 00:15:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
def CC_SystemZ : CallingConv<[
|
|
|
|
// Promote i32 to i64 if it has an explicit extension type.
|
|
|
|
// The convention is that true integer arguments that are smaller
|
|
|
|
// than 64 bits should be marked as extended, but structures that
|
|
|
|
// are smaller than 64 bits shouldn't.
|
|
|
|
CCIfType<[i32], CCIfExtend<CCPromoteToType<i64>>>,
|
|
|
|
|
|
|
|
// Force long double values to the stack and pass i64 pointers to them.
|
|
|
|
CCIfType<[f128], CCPassIndirect<i64>>,
|
|
|
|
|
|
|
|
// The first 5 integer arguments are passed in R2-R6. Note that R6
|
|
|
|
// is call-saved.
|
2013-09-30 16:48:38 +08:00
|
|
|
CCIfType<[i32], CCAssignToReg<[R2L, R3L, R4L, R5L, R6L]>>,
|
2013-05-07 00:15:19 +08:00
|
|
|
CCIfType<[i64], CCAssignToReg<[R2D, R3D, R4D, R5D, R6D]>>,
|
|
|
|
|
|
|
|
// The first 4 float and double arguments are passed in even registers F0-F6.
|
|
|
|
CCIfType<[f32], CCAssignToReg<[F0S, F2S, F4S, F6S]>>,
|
|
|
|
CCIfType<[f64], CCAssignToReg<[F0D, F2D, F4D, F6D]>>,
|
|
|
|
|
[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-06 03:25:42 +08:00
|
|
|
// The first 8 named vector arguments are passed in V24-V31.
|
|
|
|
CCIfSubtarget<"hasVector()",
|
2015-05-06 03:27:45 +08:00
|
|
|
CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
|
[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-06 03:25:42 +08:00
|
|
|
CCIfFixed<CCAssignToReg<[V24, V26, V28, V30,
|
|
|
|
V25, V27, V29, V31]>>>>,
|
|
|
|
|
|
|
|
// Other vector arguments are passed in 8-byte-aligned 16-byte stack slots.
|
|
|
|
CCIfSubtarget<"hasVector()",
|
2015-05-06 03:27:45 +08:00
|
|
|
CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
|
[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-06 03:25:42 +08:00
|
|
|
CCAssignToStack<16, 8>>>,
|
|
|
|
|
2013-05-07 00:15:19 +08:00
|
|
|
// Other arguments are passed in 8-byte-aligned 8-byte stack slots.
|
|
|
|
CCIfType<[i32, i64, f32, f64], CCAssignToStack<8, 8>>
|
|
|
|
]>;
|
2014-07-10 19:44:37 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// z/Linux callee-saved registers
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
def CSR_SystemZ : CalleeSavedRegs<(add (sequence "R%dD", 6, 15),
|
|
|
|
(sequence "F%dD", 8, 15))>;
|