2015-07-30 00:32:47 +02:00
|
|
|
//=- AArch64MachineFunctionInfo.h - AArch64 machine function info -*- C++ -*-=//
|
2014-03-29 11:18:08 +01:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2014-03-29 11:18:08 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2014-05-24 14:50:23 +02:00
|
|
|
// This file declares AArch64-specific per-machine-function information.
|
2014-03-29 11:18:08 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-13 18:26:38 +02:00
|
|
|
#ifndef LLVM_LIB_TARGET_AARCH64_AARCH64MACHINEFUNCTIONINFO_H
|
|
|
|
#define LLVM_LIB_TARGET_AARCH64_AARCH64MACHINEFUNCTIONINFO_H
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2017-01-06 01:30:53 +01:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2018-04-03 23:56:10 +02:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2014-03-29 11:18:08 +01:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
[COFF, ARM64] Make sure to forward arguments from vararg to musttail vararg
Summary:
Thunk functions in Windows are varag functions that call a musttail function
to pass the arguments after the fixup is done. We need to make sure that we
forward the arguments from the caller vararg to the callee vararg function.
This is the same mechanism that is used for Windows on X86.
Reviewers: ssijaric, eli.friedman, TomTan, mgrang, mstorsjo, rnk, compnerd, efriedma
Reviewed By: efriedma
Subscribers: efriedma, kristof.beyls, chrib, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D53843
llvm-svn: 345641
2018-10-30 21:46:10 +01:00
|
|
|
#include "llvm/CodeGen/CallingConvLower.h"
|
2020-04-18 00:16:59 +02:00
|
|
|
#include "llvm/CodeGen/MIRYamlMapping.h"
|
2014-03-29 11:18:08 +01:00
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
2019-10-19 02:22:07 +02:00
|
|
|
#include "llvm/IR/Function.h"
|
2014-03-29 11:18:08 +01:00
|
|
|
#include "llvm/MC/MCLinkerOptimizationHint.h"
|
2017-01-06 01:30:53 +01:00
|
|
|
#include <cassert>
|
2014-03-29 11:18:08 +01:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
2020-04-18 00:16:59 +02:00
|
|
|
namespace yaml {
|
|
|
|
struct AArch64FunctionInfo;
|
|
|
|
} // end namespace yaml
|
|
|
|
|
2017-07-26 01:51:02 +02:00
|
|
|
class MachineInstr;
|
|
|
|
|
2014-05-24 14:50:23 +02:00
|
|
|
/// AArch64FunctionInfo - This class is derived from MachineFunctionInfo and
|
|
|
|
/// contains private AArch64-specific information for each MachineFunction.
|
2016-07-27 16:31:46 +02:00
|
|
|
class AArch64FunctionInfo final : public MachineFunctionInfo {
|
[AArch64] PAC/BTI code generation for LLVM generated functions
PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.
This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:
* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.
* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.
* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.
This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.
Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.
Differential Revision: https://reviews.llvm.org/D85649
2020-09-25 12:45:22 +02:00
|
|
|
/// Backreference to the machine function.
|
|
|
|
MachineFunction &MF;
|
|
|
|
|
2014-05-15 03:33:17 +02:00
|
|
|
/// Number of bytes of arguments this function has on the stack. If the callee
|
|
|
|
/// is expected to restore the argument stack this should be a multiple of 16,
|
|
|
|
/// all usable during a tail call.
|
|
|
|
///
|
|
|
|
/// The alternative would forbid tail call optimisation in some cases: if we
|
|
|
|
/// want to transfer control from a function with 8-bytes of stack-argument
|
|
|
|
/// space to a function with 16-bytes then misalignment of this value would
|
|
|
|
/// make a stack adjustment necessary, which could not be undone by the
|
|
|
|
/// callee.
|
2017-01-06 01:30:53 +01:00
|
|
|
unsigned BytesInStackArgArea = 0;
|
2014-05-15 03:33:17 +02:00
|
|
|
|
|
|
|
/// The number of bytes to restore to deallocate space for incoming
|
|
|
|
/// arguments. Canonically 0 in the C calling convention, but non-zero when
|
|
|
|
/// callee is expected to pop the args.
|
2017-01-06 01:30:53 +01:00
|
|
|
unsigned ArgumentStackToRestore = 0;
|
2014-05-15 03:33:17 +02:00
|
|
|
|
2020-11-19 13:32:50 +01:00
|
|
|
/// Space just below incoming stack pointer reserved for arguments being
|
|
|
|
/// passed on the stack during a tail call. This will be the difference
|
|
|
|
/// between the largest tail call argument space needed in this function and
|
|
|
|
/// what's already available by reusing space of incoming arguments.
|
|
|
|
unsigned TailCallReservedStack = 0;
|
|
|
|
|
2014-03-29 11:18:08 +01:00
|
|
|
/// HasStackFrame - True if this function has a stack frame. Set by
|
2015-07-15 01:06:07 +02:00
|
|
|
/// determineCalleeSaves().
|
2017-01-06 01:30:53 +01:00
|
|
|
bool HasStackFrame = false;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Amount of stack frame size, not including callee-saved registers.
|
[AArch64] Fix issues with large arrays on stack
Summary:
This patch fixes a few issues when large arrays are allocated on the
stack. Currently, clang has inconsistent behaviour, for debug builds
there is an assertion failure when the array size on stack is around 2GB
but there is no assertion when the stack is around 8GB. For release
builds there is no assertion, the compilation succeeds but generates
incorrect code. The incorrect code generated is due to using
int/unsigned int instead of their 64-bit counterparts. This patch,
1) Removes the assertion in frame legality check.
2) Converts int/unsigned int in some places to the 64-bit variants. This
helps in generating correct code and removes the inconsistent behaviour.
3) Adds a test which runs without optimisations.
Reviewers: sdesmalen, efriedma, fhahn, aemerson
Reviewed By: efriedma
Subscribers: eli.friedman, fpetrogalli, kristof.beyls, hiraditya,
llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70496
2019-11-20 13:45:26 +01:00
|
|
|
uint64_t LocalStackSize = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2019-11-05 17:54:54 +01:00
|
|
|
/// The start and end frame indices for the SVE callee saves.
|
2019-11-11 12:24:09 +01:00
|
|
|
int MinSVECSFrameIndex = 0;
|
|
|
|
int MaxSVECSFrameIndex = 0;
|
2019-11-05 17:54:54 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Amount of stack frame size used for saving callee-saved registers.
|
2019-11-11 12:24:09 +01:00
|
|
|
unsigned CalleeSavedStackSize = 0;
|
|
|
|
unsigned SVECalleeSavedStackSize = 0;
|
2019-10-29 13:49:34 +01:00
|
|
|
bool HasCalleeSavedStackSize = false;
|
2016-02-01 17:29:19 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Number of TLS accesses using the special (combinable)
|
2014-03-29 11:18:08 +01:00
|
|
|
/// _TLS_MODULE_BASE_ symbol.
|
2017-01-06 01:30:53 +01:00
|
|
|
unsigned NumLocalDynamicTLSAccesses = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// FrameIndex for start of varargs area for arguments passed on the
|
2014-03-29 11:18:08 +01:00
|
|
|
/// stack.
|
2017-01-06 01:30:53 +01:00
|
|
|
int VarArgsStackIndex = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// FrameIndex for start of varargs area for arguments passed in
|
2014-03-29 11:18:08 +01:00
|
|
|
/// general purpose registers.
|
2017-01-06 01:30:53 +01:00
|
|
|
int VarArgsGPRIndex = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Size of the varargs area for arguments passed in general purpose
|
2014-03-29 11:18:08 +01:00
|
|
|
/// registers.
|
2017-01-06 01:30:53 +01:00
|
|
|
unsigned VarArgsGPRSize = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// FrameIndex for start of varargs area for arguments passed in
|
2014-03-29 11:18:08 +01:00
|
|
|
/// floating-point registers.
|
2017-01-06 01:30:53 +01:00
|
|
|
int VarArgsFPRIndex = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Size of the varargs area for arguments passed in floating-point
|
2014-03-29 11:18:08 +01:00
|
|
|
/// registers.
|
2017-01-06 01:30:53 +01:00
|
|
|
unsigned VarArgsFPRSize = 0;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2015-12-16 22:04:19 +01:00
|
|
|
/// True if this function has a subset of CSRs that is handled explicitly via
|
|
|
|
/// copies.
|
2017-01-06 01:30:53 +01:00
|
|
|
bool IsSplitCSR = false;
|
2015-12-16 22:04:19 +01:00
|
|
|
|
2016-03-14 19:17:41 +01:00
|
|
|
/// True when the stack gets realigned dynamically because the size of stack
|
|
|
|
/// frame is unknown at compile time. e.g., in case of VLAs.
|
2017-01-06 01:30:53 +01:00
|
|
|
bool StackRealigned = false;
|
2016-03-14 19:17:41 +01:00
|
|
|
|
2016-06-02 18:22:07 +02:00
|
|
|
/// True when the callee-save stack area has unused gaps that may be used for
|
|
|
|
/// other stack allocations.
|
2017-01-06 01:30:53 +01:00
|
|
|
bool CalleeSaveStackHasFreeSpace = false;
|
2016-06-02 18:22:07 +02:00
|
|
|
|
2019-05-03 23:12:36 +02:00
|
|
|
/// SRetReturnReg - sret lowering includes returning the value of the
|
|
|
|
/// returned struct in a register. This field holds the virtual register into
|
|
|
|
/// which the sret argument is passed.
|
|
|
|
unsigned SRetReturnReg = 0;
|
[AArch64] Static (de)allocation of SVE stack objects.
Adds support to AArch64FrameLowering to allocate fixed-stack SVE objects.
The focus of this patch is purely to allow the stack frame to
allocate/deallocate space for scalable SVE objects. More dynamic
allocation (at compile-time, i.e. determining placement of SVE objects
on the stack), or resolving frame-index references that include
scalable-sized offsets, are left for subsequent patches.
SVE objects are allocated in the stack frame as a separate region below
the callee-save area, and above the alignment gap. This is done so that
the SVE objects can be accessed directly from the FP at (runtime)
VL-based offsets to benefit from using the VL-scaled addressing modes.
The layout looks as follows:
+-------------+
| stack arg |
+-------------+
| Callee Saves|
| X29, X30 | (if available)
|-------------| <- FP (if available)
| : |
| SVE area |
| : |
+-------------+
|/////////////| alignment gap.
| : |
| Stack objs |
| : |
+-------------+ <- SP after call and frame-setup
SVE and non-SVE stack objects are distinguished using different
StackIDs. The offsets for objects with TargetStackID::SVEVector should be
interpreted as purely scalable offsets within their respective SVE region.
Reviewers: thegameg, rovka, t.p.northover, efriedma, rengolin, greened
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D61437
llvm-svn: 373585
2019-10-03 13:33:50 +02:00
|
|
|
/// SVE stack size (for predicates and data vectors) are maintained here
|
|
|
|
/// rather than in FrameInfo, as the placement and Stack IDs are target
|
|
|
|
/// specific.
|
|
|
|
uint64_t StackSizeSVE = 0;
|
|
|
|
|
|
|
|
/// HasCalculatedStackSizeSVE indicates whether StackSizeSVE is valid.
|
|
|
|
bool HasCalculatedStackSizeSVE = false;
|
2019-05-03 23:12:36 +02:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Has a value when it is known whether or not the function uses a
|
2018-04-03 23:56:10 +02:00
|
|
|
/// redzone, and no value otherwise.
|
|
|
|
/// Initialized during frame lowering, unless the function has the noredzone
|
|
|
|
/// attribute, in which case it is set to false at construction.
|
|
|
|
Optional<bool> HasRedZone;
|
|
|
|
|
[COFF, ARM64] Make sure to forward arguments from vararg to musttail vararg
Summary:
Thunk functions in Windows are varag functions that call a musttail function
to pass the arguments after the fixup is done. We need to make sure that we
forward the arguments from the caller vararg to the callee vararg function.
This is the same mechanism that is used for Windows on X86.
Reviewers: ssijaric, eli.friedman, TomTan, mgrang, mstorsjo, rnk, compnerd, efriedma
Reviewed By: efriedma
Subscribers: efriedma, kristof.beyls, chrib, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D53843
llvm-svn: 345641
2018-10-30 21:46:10 +01:00
|
|
|
/// ForwardedMustTailRegParms - A list of virtual and physical registers
|
|
|
|
/// that must be forwarded to every musttail call.
|
|
|
|
SmallVector<ForwardedRegister, 1> ForwardedMustTailRegParms;
|
2019-07-17 21:24:02 +02:00
|
|
|
|
2020-04-11 00:34:11 +02:00
|
|
|
/// FrameIndex for the tagged base pointer.
|
|
|
|
Optional<int> TaggedBasePointerIndex;
|
|
|
|
|
|
|
|
/// Offset from SP-at-entry to the tagged base pointer.
|
|
|
|
/// Tagged base pointer is set up to point to the first (lowest address)
|
|
|
|
/// tagged stack slot.
|
|
|
|
unsigned TaggedBasePointerOffset;
|
2019-07-17 21:24:02 +02:00
|
|
|
|
2020-04-10 23:46:09 +02:00
|
|
|
/// OutliningStyle denotes, if a function was outined, how it was outlined,
|
|
|
|
/// e.g. Tail Call, Thunk, or Function if none apply.
|
|
|
|
Optional<std::string> OutliningStyle;
|
|
|
|
|
2020-09-01 21:25:30 +02:00
|
|
|
// Offset from SP-after-callee-saved-spills (i.e. SP-at-entry minus
|
|
|
|
// CalleeSavedStackSize) to the address of the frame record.
|
|
|
|
int CalleeSaveBaseToFrameRecordOffset = 0;
|
|
|
|
|
[AArch64] PAC/BTI code generation for LLVM generated functions
PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.
This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:
* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.
* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.
* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.
This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.
Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.
Differential Revision: https://reviews.llvm.org/D85649
2020-09-25 12:45:22 +02:00
|
|
|
/// SignReturnAddress is true if PAC-RET is enabled for the function with
|
|
|
|
/// defaults being sign non-leaf functions only, with the B key.
|
|
|
|
bool SignReturnAddress = false;
|
2017-01-06 01:30:53 +01:00
|
|
|
|
[AArch64] PAC/BTI code generation for LLVM generated functions
PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.
This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:
* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.
* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.
* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.
This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.
Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.
Differential Revision: https://reviews.llvm.org/D85649
2020-09-25 12:45:22 +02:00
|
|
|
/// SignReturnAddressAll modifies the default PAC-RET mode to signing leaf
|
|
|
|
/// functions as well.
|
|
|
|
bool SignReturnAddressAll = false;
|
|
|
|
|
|
|
|
/// SignWithBKey modifies the default PAC-RET mode to signing with the B key.
|
|
|
|
bool SignWithBKey = false;
|
|
|
|
|
|
|
|
/// BranchTargetEnforcement enables placing BTI instructions at potential
|
|
|
|
/// indirect branch destinations.
|
|
|
|
bool BranchTargetEnforcement = false;
|
|
|
|
|
2021-01-20 11:14:03 +01:00
|
|
|
/// Whether this function has an extended frame record [Ctx, FP, LR]. If so,
|
|
|
|
/// bit 60 of the in-memory FP will be 1 to enable other tools to detect the
|
|
|
|
/// extended record.
|
|
|
|
bool HasSwiftAsyncContext = false;
|
|
|
|
|
|
|
|
/// The stack slot where the Swift asynchronous context is stored.
|
|
|
|
int SwiftAsyncContextFrameIdx = std::numeric_limits<int>::max();
|
|
|
|
|
[AArch64] PAC/BTI code generation for LLVM generated functions
PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.
This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:
* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.
* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.
* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.
This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.
Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.
Differential Revision: https://reviews.llvm.org/D85649
2020-09-25 12:45:22 +02:00
|
|
|
public:
|
|
|
|
explicit AArch64FunctionInfo(MachineFunction &MF);
|
2018-04-03 23:56:10 +02:00
|
|
|
|
2020-04-18 00:16:59 +02:00
|
|
|
void initializeBaseYamlFields(const yaml::AArch64FunctionInfo &YamlMFI);
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2014-05-15 03:33:17 +02:00
|
|
|
unsigned getBytesInStackArgArea() const { return BytesInStackArgArea; }
|
|
|
|
void setBytesInStackArgArea(unsigned bytes) { BytesInStackArgArea = bytes; }
|
|
|
|
|
|
|
|
unsigned getArgumentStackToRestore() const { return ArgumentStackToRestore; }
|
|
|
|
void setArgumentStackToRestore(unsigned bytes) {
|
|
|
|
ArgumentStackToRestore = bytes;
|
|
|
|
}
|
|
|
|
|
2020-11-19 13:32:50 +01:00
|
|
|
unsigned getTailCallReservedStack() const { return TailCallReservedStack; }
|
|
|
|
void setTailCallReservedStack(unsigned bytes) {
|
|
|
|
TailCallReservedStack = bytes;
|
|
|
|
}
|
|
|
|
|
[AArch64] Static (de)allocation of SVE stack objects.
Adds support to AArch64FrameLowering to allocate fixed-stack SVE objects.
The focus of this patch is purely to allow the stack frame to
allocate/deallocate space for scalable SVE objects. More dynamic
allocation (at compile-time, i.e. determining placement of SVE objects
on the stack), or resolving frame-index references that include
scalable-sized offsets, are left for subsequent patches.
SVE objects are allocated in the stack frame as a separate region below
the callee-save area, and above the alignment gap. This is done so that
the SVE objects can be accessed directly from the FP at (runtime)
VL-based offsets to benefit from using the VL-scaled addressing modes.
The layout looks as follows:
+-------------+
| stack arg |
+-------------+
| Callee Saves|
| X29, X30 | (if available)
|-------------| <- FP (if available)
| : |
| SVE area |
| : |
+-------------+
|/////////////| alignment gap.
| : |
| Stack objs |
| : |
+-------------+ <- SP after call and frame-setup
SVE and non-SVE stack objects are distinguished using different
StackIDs. The offsets for objects with TargetStackID::SVEVector should be
interpreted as purely scalable offsets within their respective SVE region.
Reviewers: thegameg, rovka, t.p.northover, efriedma, rengolin, greened
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D61437
llvm-svn: 373585
2019-10-03 13:33:50 +02:00
|
|
|
bool hasCalculatedStackSizeSVE() const { return HasCalculatedStackSizeSVE; }
|
|
|
|
|
|
|
|
void setStackSizeSVE(uint64_t S) {
|
|
|
|
HasCalculatedStackSizeSVE = true;
|
|
|
|
StackSizeSVE = S;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t getStackSizeSVE() const { return StackSizeSVE; }
|
|
|
|
|
2014-03-29 11:18:08 +01:00
|
|
|
bool hasStackFrame() const { return HasStackFrame; }
|
|
|
|
void setHasStackFrame(bool s) { HasStackFrame = s; }
|
|
|
|
|
2016-03-14 19:17:41 +01:00
|
|
|
bool isStackRealigned() const { return StackRealigned; }
|
|
|
|
void setStackRealigned(bool s) { StackRealigned = s; }
|
|
|
|
|
2016-06-02 18:22:07 +02:00
|
|
|
bool hasCalleeSaveStackFreeSpace() const {
|
|
|
|
return CalleeSaveStackHasFreeSpace;
|
|
|
|
}
|
|
|
|
void setCalleeSaveStackHasFreeSpace(bool s) {
|
|
|
|
CalleeSaveStackHasFreeSpace = s;
|
|
|
|
}
|
2015-12-16 22:04:19 +01:00
|
|
|
bool isSplitCSR() const { return IsSplitCSR; }
|
|
|
|
void setIsSplitCSR(bool s) { IsSplitCSR = s; }
|
|
|
|
|
[AArch64] Fix issues with large arrays on stack
Summary:
This patch fixes a few issues when large arrays are allocated on the
stack. Currently, clang has inconsistent behaviour, for debug builds
there is an assertion failure when the array size on stack is around 2GB
but there is no assertion when the stack is around 8GB. For release
builds there is no assertion, the compilation succeeds but generates
incorrect code. The incorrect code generated is due to using
int/unsigned int instead of their 64-bit counterparts. This patch,
1) Removes the assertion in frame legality check.
2) Converts int/unsigned int in some places to the 64-bit variants. This
helps in generating correct code and removes the inconsistent behaviour.
3) Adds a test which runs without optimisations.
Reviewers: sdesmalen, efriedma, fhahn, aemerson
Reviewed By: efriedma
Subscribers: eli.friedman, fpetrogalli, kristof.beyls, hiraditya,
llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70496
2019-11-20 13:45:26 +01:00
|
|
|
void setLocalStackSize(uint64_t Size) { LocalStackSize = Size; }
|
|
|
|
uint64_t getLocalStackSize() const { return LocalStackSize; }
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2020-04-10 23:46:09 +02:00
|
|
|
void setOutliningStyle(std::string Style) { OutliningStyle = Style; }
|
|
|
|
Optional<std::string> getOutliningStyle() const { return OutliningStyle; }
|
|
|
|
|
2019-10-29 13:49:34 +01:00
|
|
|
void setCalleeSavedStackSize(unsigned Size) {
|
|
|
|
CalleeSavedStackSize = Size;
|
|
|
|
HasCalleeSavedStackSize = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When CalleeSavedStackSize has not been set (for example when
|
|
|
|
// some MachineIR pass is run in isolation), then recalculate
|
|
|
|
// the CalleeSavedStackSize directly from the CalleeSavedInfo.
|
|
|
|
// Note: This information can only be recalculated after PEI
|
|
|
|
// has assigned offsets to the callee save objects.
|
2020-08-26 19:17:14 +02:00
|
|
|
unsigned getCalleeSavedStackSize(const MachineFrameInfo &MFI) const {
|
2019-10-29 13:49:34 +01:00
|
|
|
bool ValidateCalleeSavedStackSize = false;
|
|
|
|
|
|
|
|
#ifndef NDEBUG
|
|
|
|
// Make sure the calculated size derived from the CalleeSavedInfo
|
|
|
|
// equals the cached size that was calculated elsewhere (e.g. in
|
|
|
|
// determineCalleeSaves).
|
|
|
|
ValidateCalleeSavedStackSize = HasCalleeSavedStackSize;
|
|
|
|
#endif
|
|
|
|
|
2020-08-26 19:17:14 +02:00
|
|
|
if (!HasCalleeSavedStackSize || ValidateCalleeSavedStackSize) {
|
2019-10-29 13:49:34 +01:00
|
|
|
assert(MFI.isCalleeSavedInfoValid() && "CalleeSavedInfo not calculated");
|
|
|
|
if (MFI.getCalleeSavedInfo().empty())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
int64_t MinOffset = std::numeric_limits<int64_t>::max();
|
|
|
|
int64_t MaxOffset = std::numeric_limits<int64_t>::min();
|
|
|
|
for (const auto &Info : MFI.getCalleeSavedInfo()) {
|
|
|
|
int FrameIdx = Info.getFrameIdx();
|
2019-11-13 10:57:51 +01:00
|
|
|
if (MFI.getStackID(FrameIdx) != TargetStackID::Default)
|
|
|
|
continue;
|
2019-10-29 13:49:34 +01:00
|
|
|
int64_t Offset = MFI.getObjectOffset(FrameIdx);
|
|
|
|
int64_t ObjSize = MFI.getObjectSize(FrameIdx);
|
|
|
|
MinOffset = std::min<int64_t>(Offset, MinOffset);
|
|
|
|
MaxOffset = std::max<int64_t>(Offset + ObjSize, MaxOffset);
|
|
|
|
}
|
|
|
|
|
2021-01-20 11:14:03 +01:00
|
|
|
if (SwiftAsyncContextFrameIdx != std::numeric_limits<int>::max()) {
|
|
|
|
int64_t Offset = MFI.getObjectOffset(getSwiftAsyncContextFrameIdx());
|
|
|
|
int64_t ObjSize = MFI.getObjectSize(getSwiftAsyncContextFrameIdx());
|
|
|
|
MinOffset = std::min<int64_t>(Offset, MinOffset);
|
|
|
|
MaxOffset = std::max<int64_t>(Offset + ObjSize, MaxOffset);
|
|
|
|
}
|
|
|
|
|
2019-10-29 13:49:34 +01:00
|
|
|
unsigned Size = alignTo(MaxOffset - MinOffset, 16);
|
2020-08-26 19:17:14 +02:00
|
|
|
assert((!HasCalleeSavedStackSize || getCalleeSavedStackSize() == Size) &&
|
2019-10-29 13:49:34 +01:00
|
|
|
"Invalid size calculated for callee saves");
|
|
|
|
return Size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return getCalleeSavedStackSize();
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getCalleeSavedStackSize() const {
|
|
|
|
assert(HasCalleeSavedStackSize &&
|
|
|
|
"CalleeSavedStackSize has not been calculated");
|
|
|
|
return CalleeSavedStackSize;
|
|
|
|
}
|
2016-02-01 17:29:19 +01:00
|
|
|
|
2019-11-05 17:54:54 +01:00
|
|
|
// Saves the CalleeSavedStackSize for SVE vectors in 'scalable bytes'
|
|
|
|
void setSVECalleeSavedStackSize(unsigned Size) {
|
|
|
|
SVECalleeSavedStackSize = Size;
|
|
|
|
}
|
|
|
|
unsigned getSVECalleeSavedStackSize() const {
|
|
|
|
return SVECalleeSavedStackSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
void setMinMaxSVECSFrameIndex(int Min, int Max) {
|
|
|
|
MinSVECSFrameIndex = Min;
|
|
|
|
MaxSVECSFrameIndex = Max;
|
|
|
|
}
|
|
|
|
|
|
|
|
int getMinSVECSFrameIndex() const { return MinSVECSFrameIndex; }
|
|
|
|
int getMaxSVECSFrameIndex() const { return MaxSVECSFrameIndex; }
|
|
|
|
|
2014-03-29 11:18:08 +01:00
|
|
|
void incNumLocalDynamicTLSAccesses() { ++NumLocalDynamicTLSAccesses; }
|
|
|
|
unsigned getNumLocalDynamicTLSAccesses() const {
|
|
|
|
return NumLocalDynamicTLSAccesses;
|
|
|
|
}
|
|
|
|
|
2018-04-03 23:56:10 +02:00
|
|
|
Optional<bool> hasRedZone() const { return HasRedZone; }
|
|
|
|
void setHasRedZone(bool s) { HasRedZone = s; }
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2014-03-29 11:18:08 +01:00
|
|
|
int getVarArgsStackIndex() const { return VarArgsStackIndex; }
|
|
|
|
void setVarArgsStackIndex(int Index) { VarArgsStackIndex = Index; }
|
|
|
|
|
|
|
|
int getVarArgsGPRIndex() const { return VarArgsGPRIndex; }
|
|
|
|
void setVarArgsGPRIndex(int Index) { VarArgsGPRIndex = Index; }
|
|
|
|
|
|
|
|
unsigned getVarArgsGPRSize() const { return VarArgsGPRSize; }
|
|
|
|
void setVarArgsGPRSize(unsigned Size) { VarArgsGPRSize = Size; }
|
|
|
|
|
|
|
|
int getVarArgsFPRIndex() const { return VarArgsFPRIndex; }
|
|
|
|
void setVarArgsFPRIndex(int Index) { VarArgsFPRIndex = Index; }
|
|
|
|
|
|
|
|
unsigned getVarArgsFPRSize() const { return VarArgsFPRSize; }
|
|
|
|
void setVarArgsFPRSize(unsigned Size) { VarArgsFPRSize = Size; }
|
|
|
|
|
2019-05-03 23:12:36 +02:00
|
|
|
unsigned getSRetReturnReg() const { return SRetReturnReg; }
|
|
|
|
void setSRetReturnReg(unsigned Reg) { SRetReturnReg = Reg; }
|
|
|
|
|
2018-10-24 22:19:09 +02:00
|
|
|
unsigned getJumpTableEntrySize(int Idx) const {
|
2020-09-08 12:08:25 +02:00
|
|
|
return JumpTableEntryInfo[Idx].first;
|
2018-10-24 22:19:09 +02:00
|
|
|
}
|
|
|
|
MCSymbol *getJumpTableEntryPCRelSymbol(int Idx) const {
|
2020-09-08 12:08:25 +02:00
|
|
|
return JumpTableEntryInfo[Idx].second;
|
2018-10-24 22:19:09 +02:00
|
|
|
}
|
|
|
|
void setJumpTableEntryInfo(int Idx, unsigned Size, MCSymbol *PCRelSym) {
|
2020-09-08 12:08:25 +02:00
|
|
|
if ((unsigned)Idx >= JumpTableEntryInfo.size())
|
|
|
|
JumpTableEntryInfo.resize(Idx+1);
|
2018-10-24 22:19:09 +02:00
|
|
|
JumpTableEntryInfo[Idx] = std::make_pair(Size, PCRelSym);
|
|
|
|
}
|
|
|
|
|
2017-07-26 01:51:02 +02:00
|
|
|
using SetOfInstructions = SmallPtrSet<const MachineInstr *, 16>;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
|
|
|
const SetOfInstructions &getLOHRelated() const { return LOHRelated; }
|
|
|
|
|
|
|
|
// Shortcuts for LOH related types.
|
2014-03-29 20:21:20 +01:00
|
|
|
class MILOHDirective {
|
|
|
|
MCLOHType Kind;
|
|
|
|
|
|
|
|
/// Arguments of this directive. Order matters.
|
|
|
|
SmallVector<const MachineInstr *, 3> Args;
|
|
|
|
|
|
|
|
public:
|
2017-07-26 01:51:02 +02:00
|
|
|
using LOHArgs = ArrayRef<const MachineInstr *>;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
2016-07-02 13:41:39 +02:00
|
|
|
MILOHDirective(MCLOHType Kind, LOHArgs Args)
|
2014-03-29 20:21:20 +01:00
|
|
|
: Kind(Kind), Args(Args.begin(), Args.end()) {
|
|
|
|
assert(isValidMCLOHType(Kind) && "Invalid LOH directive type!");
|
|
|
|
}
|
|
|
|
|
|
|
|
MCLOHType getKind() const { return Kind; }
|
2016-07-02 13:41:39 +02:00
|
|
|
LOHArgs getArgs() const { return Args; }
|
2014-03-29 20:21:20 +01:00
|
|
|
};
|
|
|
|
|
2017-07-26 01:51:02 +02:00
|
|
|
using MILOHArgs = MILOHDirective::LOHArgs;
|
|
|
|
using MILOHContainer = SmallVector<MILOHDirective, 32>;
|
2014-03-29 11:18:08 +01:00
|
|
|
|
|
|
|
const MILOHContainer &getLOHContainer() const { return LOHContainerSet; }
|
|
|
|
|
|
|
|
/// Add a LOH directive of this @p Kind and this @p Args.
|
2016-07-02 13:41:39 +02:00
|
|
|
void addLOHDirective(MCLOHType Kind, MILOHArgs Args) {
|
2014-03-29 20:21:20 +01:00
|
|
|
LOHContainerSet.push_back(MILOHDirective(Kind, Args));
|
|
|
|
LOHRelated.insert(Args.begin(), Args.end());
|
2014-03-29 11:18:08 +01:00
|
|
|
}
|
|
|
|
|
[COFF, ARM64] Make sure to forward arguments from vararg to musttail vararg
Summary:
Thunk functions in Windows are varag functions that call a musttail function
to pass the arguments after the fixup is done. We need to make sure that we
forward the arguments from the caller vararg to the callee vararg function.
This is the same mechanism that is used for Windows on X86.
Reviewers: ssijaric, eli.friedman, TomTan, mgrang, mstorsjo, rnk, compnerd, efriedma
Reviewed By: efriedma
Subscribers: efriedma, kristof.beyls, chrib, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D53843
llvm-svn: 345641
2018-10-30 21:46:10 +01:00
|
|
|
SmallVectorImpl<ForwardedRegister> &getForwardedMustTailRegParms() {
|
|
|
|
return ForwardedMustTailRegParms;
|
|
|
|
}
|
|
|
|
|
2020-04-11 00:34:11 +02:00
|
|
|
Optional<int> getTaggedBasePointerIndex() const {
|
|
|
|
return TaggedBasePointerIndex;
|
|
|
|
}
|
|
|
|
void setTaggedBasePointerIndex(int Index) { TaggedBasePointerIndex = Index; }
|
|
|
|
|
2019-07-17 21:24:02 +02:00
|
|
|
unsigned getTaggedBasePointerOffset() const {
|
|
|
|
return TaggedBasePointerOffset;
|
|
|
|
}
|
|
|
|
void setTaggedBasePointerOffset(unsigned Offset) {
|
|
|
|
TaggedBasePointerOffset = Offset;
|
|
|
|
}
|
|
|
|
|
2020-09-01 21:25:30 +02:00
|
|
|
int getCalleeSaveBaseToFrameRecordOffset() const {
|
|
|
|
return CalleeSaveBaseToFrameRecordOffset;
|
|
|
|
}
|
|
|
|
void setCalleeSaveBaseToFrameRecordOffset(int Offset) {
|
|
|
|
CalleeSaveBaseToFrameRecordOffset = Offset;
|
|
|
|
}
|
|
|
|
|
[AArch64] PAC/BTI code generation for LLVM generated functions
PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.
This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:
* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.
* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.
* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.
This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.
Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.
Differential Revision: https://reviews.llvm.org/D85649
2020-09-25 12:45:22 +02:00
|
|
|
bool shouldSignReturnAddress() const;
|
|
|
|
bool shouldSignReturnAddress(bool SpillsLR) const;
|
|
|
|
|
|
|
|
bool shouldSignWithBKey() const { return SignWithBKey; }
|
|
|
|
|
|
|
|
bool branchTargetEnforcement() const { return BranchTargetEnforcement; }
|
|
|
|
|
2021-01-20 11:14:03 +01:00
|
|
|
void setHasSwiftAsyncContext(bool HasContext) {
|
|
|
|
HasSwiftAsyncContext = HasContext;
|
|
|
|
}
|
|
|
|
bool hasSwiftAsyncContext() const { return HasSwiftAsyncContext; }
|
|
|
|
|
|
|
|
void setSwiftAsyncContextFrameIdx(int FI) {
|
|
|
|
SwiftAsyncContextFrameIdx = FI;
|
|
|
|
}
|
|
|
|
int getSwiftAsyncContextFrameIdx() const { return SwiftAsyncContextFrameIdx; }
|
|
|
|
|
2014-03-29 11:18:08 +01:00
|
|
|
private:
|
|
|
|
// Hold the lists of LOHs.
|
|
|
|
MILOHContainer LOHContainerSet;
|
|
|
|
SetOfInstructions LOHRelated;
|
2018-10-24 22:19:09 +02:00
|
|
|
|
2020-09-08 12:08:25 +02:00
|
|
|
SmallVector<std::pair<unsigned, MCSymbol *>, 2> JumpTableEntryInfo;
|
2014-03-29 11:18:08 +01:00
|
|
|
};
|
|
|
|
|
2020-04-18 00:16:59 +02:00
|
|
|
namespace yaml {
|
|
|
|
struct AArch64FunctionInfo final : public yaml::MachineFunctionInfo {
|
|
|
|
Optional<bool> HasRedZone;
|
|
|
|
|
|
|
|
AArch64FunctionInfo() = default;
|
|
|
|
AArch64FunctionInfo(const llvm::AArch64FunctionInfo &MFI);
|
|
|
|
|
|
|
|
void mappingImpl(yaml::IO &YamlIO) override;
|
|
|
|
~AArch64FunctionInfo() = default;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <> struct MappingTraits<AArch64FunctionInfo> {
|
|
|
|
static void mapping(IO &YamlIO, AArch64FunctionInfo &MFI) {
|
|
|
|
YamlIO.mapOptional("hasRedZone", MFI.HasRedZone);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end namespace yaml
|
|
|
|
|
2017-01-06 01:30:53 +01:00
|
|
|
} // end namespace llvm
|
|
|
|
|
|
|
|
#endif // LLVM_LIB_TARGET_AARCH64_AARCH64MACHINEFUNCTIONINFO_H
|