mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-13 20:32:21 +00:00
410ca67ab2
- Copy patterns with float/double types are enough. - Fix typos in test case names that were using v1fx. - There is no ACLE intrinsic that uses v1f32 type. And there is no conflict of neon and non-neon ovelapped operations with this type, so there is no need to support operations with this type. - Remove v1f32 from FPR32 register and disallow v1f32 as a legal type for operations. Patch by Ana Pazos! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197159 91177308-0d34-0410-b5e6-96231b3b80d8
198 lines
9.8 KiB
TableGen
198 lines
9.8 KiB
TableGen
//==-- AArch64CallingConv.td - Calling Conventions for ARM ----*- tblgen -*-==//
|
|
//
|
|
// 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 AArch64 architecture.
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
// The AArch64 Procedure Call Standard is unfortunately specified at a slightly
|
|
// higher level of abstraction than LLVM's target interface presents. In
|
|
// particular, it refers (like other ABIs, in fact) directly to
|
|
// structs. However, generic LLVM code takes the liberty of lowering structure
|
|
// arguments to the component fields before we see them.
|
|
//
|
|
// As a result, the obvious direct map from LLVM IR to PCS concepts can't be
|
|
// implemented, so the goals of this calling convention are, in decreasing
|
|
// priority order:
|
|
// 1. Expose *some* way to express the concepts required to implement the
|
|
// generic PCS from a front-end.
|
|
// 2. Provide a sane ABI for pure LLVM.
|
|
// 3. Follow the generic PCS as closely as is naturally possible.
|
|
//
|
|
// The suggested front-end implementation of PCS features is:
|
|
// * Integer, float and vector arguments of all sizes which end up in
|
|
// registers are passed and returned via the natural LLVM type.
|
|
// * Structure arguments with size <= 16 bytes are passed and returned in
|
|
// registers as similar integer or composite types. For example:
|
|
// [1 x i64], [2 x i64] or [1 x i128] (if alignment 16 needed).
|
|
// * HFAs in registers follow rules similar to small structs: appropriate
|
|
// composite types.
|
|
// * Structure arguments with size > 16 bytes are passed via a pointer,
|
|
// handled completely by the front-end.
|
|
// * Structure return values > 16 bytes via an sret pointer argument.
|
|
// * Other stack-based arguments (not large structs) are passed using byval
|
|
// pointers. Padding arguments are added beforehand to guarantee a large
|
|
// struct doesn't later use integer registers.
|
|
//
|
|
// N.b. this means that it is the front-end's responsibility (if it cares about
|
|
// PCS compliance) to check whether enough registers are available for an
|
|
// argument when deciding how to pass it.
|
|
|
|
class CCIfAlign<int Align, CCAction A>:
|
|
CCIf<"ArgFlags.getOrigAlign() == " # Align, A>;
|
|
|
|
def CC_A64_APCS : CallingConv<[
|
|
// SRet is an LLVM-specific concept, so it takes precedence over general ABI
|
|
// concerns. However, this rule will be used by C/C++ frontends to implement
|
|
// structure return.
|
|
CCIfSRet<CCAssignToReg<[X8]>>,
|
|
|
|
// Put ByVal arguments directly on the stack. Minimum size and alignment of a
|
|
// slot is 64-bit.
|
|
CCIfByVal<CCPassByVal<8, 8>>,
|
|
|
|
// Canonicalise the various types that live in different floating-point
|
|
// registers. This makes sense because the PCS does not distinguish Short
|
|
// Vectors and Floating-point types.
|
|
CCIfType<[v1i16, v2i8], CCBitConvertToType<f16>>,
|
|
CCIfType<[v1i32, v4i8, v2i16], CCBitConvertToType<f32>>,
|
|
CCIfType<[v8i8, v4i16, v2i32, v2f32, v1i64, v1f64], CCBitConvertToType<f64>>,
|
|
CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
|
|
CCBitConvertToType<f128>>,
|
|
|
|
// PCS: "C.1: If the argument is a Half-, Single-, Double- or Quad- precision
|
|
// Floating-point or Short Vector Type and the NSRN is less than 8, then the
|
|
// argument is allocated to the least significant bits of register
|
|
// v[NSRN]. The NSRN is incremented by one. The argument has now been
|
|
// allocated."
|
|
CCIfType<[v1i8], CCAssignToReg<[B0, B1, B2, B3, B4, B5, B6, B7]>>,
|
|
CCIfType<[f16], CCAssignToReg<[H0, H1, H2, H3, H4, H5, H6, H7]>>,
|
|
CCIfType<[f32], CCAssignToReg<[S0, S1, S2, S3, S4, S5, S6, S7]>>,
|
|
CCIfType<[f64], CCAssignToReg<[D0, D1, D2, D3, D4, D5, D6, D7]>>,
|
|
CCIfType<[f128], CCAssignToReg<[Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7]>>,
|
|
|
|
// PCS: "C.2: If the argument is an HFA and there are sufficient unallocated
|
|
// SIMD and Floating-point registers (NSRN - number of elements < 8), then the
|
|
// argument is allocated to SIMD and Floating-point registers (with one
|
|
// register per element of the HFA). The NSRN is incremented by the number of
|
|
// registers used. The argument has now been allocated."
|
|
//
|
|
// N.b. As above, this rule is the responsibility of the front-end.
|
|
|
|
// "C.3: If the argument is an HFA then the NSRN is set to 8 and the size of
|
|
// the argument is rounded up to the nearest multiple of 8 bytes."
|
|
//
|
|
// "C.4: If the argument is an HFA, a Quad-precision Floating-point or Short
|
|
// Vector Type then the NSAA is rounded up to the larger of 8 or the Natural
|
|
// Alignment of the Argument's type."
|
|
//
|
|
// It is expected that these will be satisfied by adding dummy arguments to
|
|
// the prototype.
|
|
|
|
// PCS: "C.5: If the argument is a Half- or Single- precision Floating-point
|
|
// type then the size of the argument is set to 8 bytes. The effect is as if
|
|
// the argument had been copied to the least significant bits of a 64-bit
|
|
// register and the remaining bits filled with unspecified values."
|
|
CCIfType<[f16, f32], CCPromoteToType<f64>>,
|
|
|
|
// PCS: "C.6: If the argument is an HFA, a Half-, Single-, Double- or Quad-
|
|
// precision Floating-point or Short Vector Type, then the argument is copied
|
|
// to memory at the adjusted NSAA. The NSAA is incremented by the size of the
|
|
// argument. The argument has now been allocated."
|
|
CCIfType<[f64], CCAssignToStack<8, 8>>,
|
|
CCIfType<[f128], CCAssignToStack<16, 16>>,
|
|
|
|
// PCS: "C.7: If the argument is an Integral Type, the size of the argument is
|
|
// less than or equal to 8 bytes and the NGRN is less than 8, the argument is
|
|
// copied to the least significant bits of x[NGRN]. The NGRN is incremented by
|
|
// one. The argument has now been allocated."
|
|
|
|
// First we implement C.8 and C.9 (128-bit types get even registers). i128 is
|
|
// represented as two i64s, the first one being split. If we delayed this
|
|
// operation C.8 would never be reached.
|
|
CCIfType<[i64],
|
|
CCIfSplit<CCAssignToRegWithShadow<[X0, X2, X4, X6], [X0, X1, X3, X5]>>>,
|
|
|
|
// Note: the promotion also implements C.14.
|
|
CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,
|
|
|
|
// And now the real implementation of C.7
|
|
CCIfType<[i64], CCAssignToReg<[X0, X1, X2, X3, X4, X5, X6, X7]>>,
|
|
|
|
// PCS: "C.8: If the argument has an alignment of 16 then the NGRN is rounded
|
|
// up to the next even number."
|
|
//
|
|
// "C.9: If the argument is an Integral Type, the size of the argument is
|
|
// equal to 16 and the NGRN is less than 7, the argument is copied to x[NGRN]
|
|
// and x[NGRN+1], x[NGRN] shall contain the lower addressed double-word of the
|
|
// memory representation of the argument. The NGRN is incremented by two. The
|
|
// argument has now been allocated."
|
|
//
|
|
// Subtlety here: what if alignment is 16 but it is not an integral type? All
|
|
// floating-point types have been allocated already, which leaves composite
|
|
// types: this is why a front-end may need to produce i128 for a struct <= 16
|
|
// bytes.
|
|
|
|
// PCS: "C.10 If the argument is a Composite Type and the size in double-words
|
|
// of the argument is not more than 8 minus NGRN, then the argument is copied
|
|
// into consecutive general-purpose registers, starting at x[NGRN]. The
|
|
// argument is passed as though it had been loaded into the registers from a
|
|
// double-word aligned address with an appropriate sequence of LDR
|
|
// instructions loading consecutive registers from memory (the contents of any
|
|
// unused parts of the registers are unspecified by this standard). The NGRN
|
|
// is incremented by the number of registers used. The argument has now been
|
|
// allocated."
|
|
//
|
|
// Another one that's the responsibility of the front-end (sigh).
|
|
|
|
// PCS: "C.11: The NGRN is set to 8."
|
|
CCCustom<"CC_AArch64NoMoreRegs">,
|
|
|
|
// PCS: "C.12: The NSAA is rounded up to the larger of 8 or the Natural
|
|
// Alignment of the argument's type."
|
|
//
|
|
// PCS: "C.13: If the argument is a composite type then the argument is copied
|
|
// to memory at the adjusted NSAA. The NSAA is by the size of the
|
|
// argument. The argument has now been allocated."
|
|
//
|
|
// Note that the effect of this corresponds to a memcpy rather than register
|
|
// stores so that the struct ends up correctly addressable at the adjusted
|
|
// NSAA.
|
|
|
|
// PCS: "C.14: If the size of the argument is less than 8 bytes then the size
|
|
// of the argument is set to 8 bytes. The effect is as if the argument was
|
|
// copied to the least significant bits of a 64-bit register and the remaining
|
|
// bits filled with unspecified values."
|
|
//
|
|
// Integer types were widened above. Floating-point and composite types have
|
|
// already been allocated completely. Nothing to do.
|
|
|
|
// PCS: "C.15: The argument is copied to memory at the adjusted NSAA. The NSAA
|
|
// is incremented by the size of the argument. The argument has now been
|
|
// allocated."
|
|
CCIfType<[i64], CCIfSplit<CCAssignToStack<8, 16>>>,
|
|
CCIfType<[i64], CCAssignToStack<8, 8>>
|
|
|
|
]>;
|
|
|
|
// According to the PCS, X19-X30 are callee-saved, however only the low 64-bits
|
|
// of vector registers (8-15) are callee-saved. The order here is is picked up
|
|
// by PrologEpilogInserter.cpp to allocate stack slots, starting from top of
|
|
// stack upon entry. This gives the customary layout of x30 at [sp-8], x29 at
|
|
// [sp-16], ...
|
|
def CSR_PCS : CalleeSavedRegs<(add (sequence "X%u", 30, 19),
|
|
(sequence "D%u", 15, 8))>;
|
|
|
|
|
|
// TLS descriptor calls are extremely restricted in their changes, to allow
|
|
// optimisations in the (hopefully) more common fast path where no real action
|
|
// is needed. They actually have to preserve all registers, except for the
|
|
// unavoidable X30 and the return register X0.
|
|
def TLSDesc : CalleeSavedRegs<(add (sequence "X%u", 29, 1),
|
|
(sequence "Q%u", 31, 0))>;
|