2013-05-07 00:15:19 +08:00
|
|
|
//===-- SystemZCallingConv.h - Calling conventions for SystemZ --*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_TARGET_SYSTEMZ_SYSTEMZCALLINGCONV_H
|
|
|
|
#define LLVM_LIB_TARGET_SYSTEMZ_SYSTEMZCALLINGCONV_H
|
2013-05-07 00:15:19 +08:00
|
|
|
|
[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
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/CodeGen/CallingConvLower.h"
|
[SystemZ] Fix ABI for i128 argument and return types
According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently implemented at the LLVM IR level for the i128
type. This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.
However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).
This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end. Therefore, common
code will already split arguments and return values into multiple
parts. The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts. If at some time in the
future, i128 becomes a legal type, this code can be removed again.
This fixes PR26559.
llvm-svn: 261325
2016-02-19 22:10:21 +08:00
|
|
|
#include "llvm/MC/MCRegisterInfo.h"
|
[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
|
|
|
|
2013-05-07 00:15:19 +08:00
|
|
|
namespace llvm {
|
2014-03-06 18:38:30 +08:00
|
|
|
namespace SystemZ {
|
|
|
|
const unsigned NumArgGPRs = 5;
|
[SystemZ] Fix ABI for i128 argument and return types
According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently implemented at the LLVM IR level for the i128
type. This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.
However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).
This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end. Therefore, common
code will already split arguments and return values into multiple
parts. The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts. If at some time in the
future, i128 becomes a legal type, this code can be removed again.
This fixes PR26559.
llvm-svn: 261325
2016-02-19 22:10:21 +08:00
|
|
|
extern const MCPhysReg ArgGPRs[NumArgGPRs];
|
2013-05-07 00:15:19 +08:00
|
|
|
|
2014-03-06 18:38:30 +08:00
|
|
|
const unsigned NumArgFPRs = 4;
|
[SystemZ] Fix ABI for i128 argument and return types
According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently implemented at the LLVM IR level for the i128
type. This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.
However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).
This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end. Therefore, common
code will already split arguments and return values into multiple
parts. The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts. If at some time in the
future, i128 becomes a legal type, this code can be removed again.
This fixes PR26559.
llvm-svn: 261325
2016-02-19 22:10:21 +08:00
|
|
|
extern const MCPhysReg ArgFPRs[NumArgFPRs];
|
2014-03-06 18:38:30 +08:00
|
|
|
} // end namespace SystemZ
|
[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 SystemZCCState : public CCState {
|
|
|
|
private:
|
|
|
|
/// Records whether the value was a fixed argument.
|
|
|
|
/// See ISD::OutputArg::IsFixed.
|
|
|
|
SmallVector<bool, 4> ArgIsFixed;
|
|
|
|
|
2015-05-06 03:29:21 +08:00
|
|
|
/// Records whether the value was widened from a short vector type.
|
|
|
|
SmallVector<bool, 4> ArgIsShortVector;
|
|
|
|
|
|
|
|
// Check whether ArgVT is a short vector type.
|
|
|
|
bool IsShortVectorType(EVT ArgVT) {
|
|
|
|
return ArgVT.isVector() && ArgVT.getStoreSize() <= 8;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
public:
|
|
|
|
SystemZCCState(CallingConv::ID CC, bool isVarArg, MachineFunction &MF,
|
|
|
|
SmallVectorImpl<CCValAssign> &locs, LLVMContext &C)
|
|
|
|
: CCState(CC, isVarArg, MF, locs, C) {}
|
|
|
|
|
|
|
|
void AnalyzeFormalArguments(const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
CCAssignFn Fn) {
|
|
|
|
// Formal arguments are always fixed.
|
|
|
|
ArgIsFixed.clear();
|
|
|
|
for (unsigned i = 0; i < Ins.size(); ++i)
|
|
|
|
ArgIsFixed.push_back(true);
|
2015-05-06 03:29:21 +08:00
|
|
|
// Record whether the call operand was a short vector.
|
|
|
|
ArgIsShortVector.clear();
|
|
|
|
for (unsigned i = 0; i < Ins.size(); ++i)
|
|
|
|
ArgIsShortVector.push_back(IsShortVectorType(Ins[i].ArgVT));
|
[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
|
|
|
|
|
|
|
CCState::AnalyzeFormalArguments(Ins, Fn);
|
|
|
|
}
|
|
|
|
|
|
|
|
void AnalyzeCallOperands(const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
CCAssignFn Fn) {
|
|
|
|
// Record whether the call operand was a fixed argument.
|
|
|
|
ArgIsFixed.clear();
|
|
|
|
for (unsigned i = 0; i < Outs.size(); ++i)
|
|
|
|
ArgIsFixed.push_back(Outs[i].IsFixed);
|
2015-05-06 03:29:21 +08:00
|
|
|
// Record whether the call operand was a short vector.
|
|
|
|
ArgIsShortVector.clear();
|
|
|
|
for (unsigned i = 0; i < Outs.size(); ++i)
|
|
|
|
ArgIsShortVector.push_back(IsShortVectorType(Outs[i].ArgVT));
|
[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
|
|
|
|
|
|
|
CCState::AnalyzeCallOperands(Outs, Fn);
|
|
|
|
}
|
|
|
|
|
|
|
|
// This version of AnalyzeCallOperands in the base class is not usable
|
|
|
|
// since we must provide a means of accessing ISD::OutputArg::IsFixed.
|
|
|
|
void AnalyzeCallOperands(const SmallVectorImpl<MVT> &Outs,
|
|
|
|
SmallVectorImpl<ISD::ArgFlagsTy> &Flags,
|
|
|
|
CCAssignFn Fn) = delete;
|
|
|
|
|
|
|
|
bool IsFixed(unsigned ValNo) { return ArgIsFixed[ValNo]; }
|
2015-05-06 03:29:21 +08:00
|
|
|
bool IsShortVector(unsigned ValNo) { return ArgIsShortVector[ValNo]; }
|
[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
|
|
|
};
|
|
|
|
|
[SystemZ] Fix ABI for i128 argument and return types
According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference. However, this is
not currently implemented at the LLVM IR level for the i128
type. This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.
However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).
This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end. Therefore, common
code will already split arguments and return values into multiple
parts. The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts. If at some time in the
future, i128 becomes a legal type, this code can be removed again.
This fixes PR26559.
llvm-svn: 261325
2016-02-19 22:10:21 +08:00
|
|
|
// Handle i128 argument types. These need to be passed by implicit
|
|
|
|
// reference. This could be as simple as the following .td line:
|
|
|
|
// CCIfType<[i128], CCPassIndirect<i64>>,
|
|
|
|
// except that i128 is not a legal type, and therefore gets split by
|
|
|
|
// common code into a pair of i64 arguments.
|
|
|
|
inline bool CC_SystemZ_I128Indirect(unsigned &ValNo, MVT &ValVT,
|
|
|
|
MVT &LocVT,
|
|
|
|
CCValAssign::LocInfo &LocInfo,
|
|
|
|
ISD::ArgFlagsTy &ArgFlags,
|
|
|
|
CCState &State) {
|
|
|
|
SmallVectorImpl<CCValAssign> &PendingMembers = State.getPendingLocs();
|
|
|
|
|
|
|
|
// ArgFlags.isSplit() is true on the first part of a i128 argument;
|
|
|
|
// PendingMembers.empty() is false on all subsequent parts.
|
|
|
|
if (!ArgFlags.isSplit() && PendingMembers.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Push a pending Indirect value location for each part.
|
|
|
|
LocVT = MVT::i64;
|
|
|
|
LocInfo = CCValAssign::Indirect;
|
|
|
|
PendingMembers.push_back(CCValAssign::getPending(ValNo, ValVT,
|
|
|
|
LocVT, LocInfo));
|
|
|
|
if (!ArgFlags.isSplitEnd())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// OK, we've collected all parts in the pending list. Allocate
|
|
|
|
// the location (register or stack slot) for the indirect pointer.
|
|
|
|
// (This duplicates the usual i64 calling convention rules.)
|
|
|
|
unsigned Reg = State.AllocateReg(SystemZ::ArgGPRs);
|
|
|
|
unsigned Offset = Reg ? 0 : State.AllocateStack(8, 8);
|
|
|
|
|
|
|
|
// Use that same location for all the pending parts.
|
|
|
|
for (auto &It : PendingMembers) {
|
|
|
|
if (Reg)
|
|
|
|
It.convertToReg(Reg);
|
|
|
|
else
|
|
|
|
It.convertToMem(Offset);
|
|
|
|
State.addLoc(It);
|
|
|
|
}
|
|
|
|
|
|
|
|
PendingMembers.clear();
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-03-06 18:38:30 +08:00
|
|
|
} // end namespace llvm
|
2013-05-07 00:15:19 +08:00
|
|
|
|
|
|
|
#endif
|