llvm-project/llvm/lib/Target/RISCV/RISCVFrameLowering.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1106 lines
41 KiB
C++
Raw Normal View History

//===-- RISCVFrameLowering.cpp - RISCV Frame Information ------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// This file contains the RISCV implementation of TargetFrameLowering class.
//
//===----------------------------------------------------------------------===//
#include "RISCVFrameLowering.h"
#include "RISCVMachineFunctionInfo.h"
#include "RISCVSubtarget.h"
#include "llvm/CodeGen/MachineFrameInfo.h"
#include "llvm/CodeGen/MachineFunction.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
#include "llvm/CodeGen/RegisterScavenging.h"
#include "llvm/IR/DiagnosticInfo.h"
#include "llvm/MC/MCDwarf.h"
using namespace llvm;
// For now we use x18, a.k.a s2, as pointer to shadow call stack.
// User should explicitly set -ffixed-x18 and not use x18 in their asm.
static void emitSCSPrologue(MachineFunction &MF, MachineBasicBlock &MBB,
MachineBasicBlock::iterator MI,
const DebugLoc &DL) {
if (!MF.getFunction().hasFnAttribute(Attribute::ShadowCallStack))
return;
const auto &STI = MF.getSubtarget<RISCVSubtarget>();
Register RAReg = STI.getRegisterInfo()->getRARegister();
// Do not save RA to the SCS if it's not saved to the regular stack,
// i.e. RA is not at risk of being overwritten.
std::vector<CalleeSavedInfo> &CSI = MF.getFrameInfo().getCalleeSavedInfo();
if (std::none_of(CSI.begin(), CSI.end(),
[&](CalleeSavedInfo &CSR) { return CSR.getReg() == RAReg; }))
return;
Register SCSPReg = RISCVABI::getSCSPReg();
auto &Ctx = MF.getFunction().getContext();
if (!STI.isRegisterReservedByUser(SCSPReg)) {
Ctx.diagnose(DiagnosticInfoUnsupported{
MF.getFunction(), "x18 not reserved by user for Shadow Call Stack."});
return;
}
const auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
if (RVFI->useSaveRestoreLibCalls(MF)) {
Ctx.diagnose(DiagnosticInfoUnsupported{
MF.getFunction(),
"Shadow Call Stack cannot be combined with Save/Restore LibCalls."});
return;
}
const RISCVInstrInfo *TII = STI.getInstrInfo();
bool IsRV64 = STI.hasFeature(RISCV::Feature64Bit);
int64_t SlotSize = STI.getXLen() / 8;
// Store return address to shadow call stack
// s[w|d] ra, 0(s2)
// addi s2, s2, [4|8]
BuildMI(MBB, MI, DL, TII->get(IsRV64 ? RISCV::SD : RISCV::SW))
.addReg(RAReg)
.addReg(SCSPReg)
.addImm(0);
BuildMI(MBB, MI, DL, TII->get(RISCV::ADDI))
.addReg(SCSPReg, RegState::Define)
.addReg(SCSPReg)
.addImm(SlotSize);
}
static void emitSCSEpilogue(MachineFunction &MF, MachineBasicBlock &MBB,
MachineBasicBlock::iterator MI,
const DebugLoc &DL) {
if (!MF.getFunction().hasFnAttribute(Attribute::ShadowCallStack))
return;
const auto &STI = MF.getSubtarget<RISCVSubtarget>();
Register RAReg = STI.getRegisterInfo()->getRARegister();
// See emitSCSPrologue() above.
std::vector<CalleeSavedInfo> &CSI = MF.getFrameInfo().getCalleeSavedInfo();
if (std::none_of(CSI.begin(), CSI.end(),
[&](CalleeSavedInfo &CSR) { return CSR.getReg() == RAReg; }))
return;
Register SCSPReg = RISCVABI::getSCSPReg();
auto &Ctx = MF.getFunction().getContext();
if (!STI.isRegisterReservedByUser(SCSPReg)) {
Ctx.diagnose(DiagnosticInfoUnsupported{
MF.getFunction(), "x18 not reserved by user for Shadow Call Stack."});
return;
}
const auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
if (RVFI->useSaveRestoreLibCalls(MF)) {
Ctx.diagnose(DiagnosticInfoUnsupported{
MF.getFunction(),
"Shadow Call Stack cannot be combined with Save/Restore LibCalls."});
return;
}
const RISCVInstrInfo *TII = STI.getInstrInfo();
bool IsRV64 = STI.hasFeature(RISCV::Feature64Bit);
int64_t SlotSize = STI.getXLen() / 8;
// Load return address from shadow call stack
// l[w|d] ra, -[4|8](s2)
// addi s2, s2, -[4|8]
BuildMI(MBB, MI, DL, TII->get(IsRV64 ? RISCV::LD : RISCV::LW))
.addReg(RAReg, RegState::Define)
.addReg(SCSPReg)
.addImm(-SlotSize);
BuildMI(MBB, MI, DL, TII->get(RISCV::ADDI))
.addReg(SCSPReg, RegState::Define)
.addReg(SCSPReg)
.addImm(-SlotSize);
}
// Get the ID of the libcall used for spilling and restoring callee saved
// registers. The ID is representative of the number of registers saved or
// restored by the libcall, except it is zero-indexed - ID 0 corresponds to a
// single register.
static int getLibCallID(const MachineFunction &MF,
const std::vector<CalleeSavedInfo> &CSI) {
const auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
if (CSI.empty() || !RVFI->useSaveRestoreLibCalls(MF))
return -1;
Register MaxReg = RISCV::NoRegister;
for (auto &CS : CSI)
// RISCVRegisterInfo::hasReservedSpillSlot assigns negative frame indexes to
// registers which can be saved by libcall.
if (CS.getFrameIdx() < 0)
2020-12-23 06:45:34 +08:00
MaxReg = std::max(MaxReg.id(), CS.getReg().id());
if (MaxReg == RISCV::NoRegister)
return -1;
switch (MaxReg) {
default:
llvm_unreachable("Something has gone wrong!");
case /*s11*/ RISCV::X27: return 12;
case /*s10*/ RISCV::X26: return 11;
case /*s9*/ RISCV::X25: return 10;
case /*s8*/ RISCV::X24: return 9;
case /*s7*/ RISCV::X23: return 8;
case /*s6*/ RISCV::X22: return 7;
case /*s5*/ RISCV::X21: return 6;
case /*s4*/ RISCV::X20: return 5;
case /*s3*/ RISCV::X19: return 4;
case /*s2*/ RISCV::X18: return 3;
case /*s1*/ RISCV::X9: return 2;
case /*s0*/ RISCV::X8: return 1;
case /*ra*/ RISCV::X1: return 0;
}
}
// Get the name of the libcall used for spilling callee saved registers.
// If this function will not use save/restore libcalls, then return a nullptr.
static const char *
getSpillLibCallName(const MachineFunction &MF,
const std::vector<CalleeSavedInfo> &CSI) {
static const char *const SpillLibCalls[] = {
"__riscv_save_0",
"__riscv_save_1",
"__riscv_save_2",
"__riscv_save_3",
"__riscv_save_4",
"__riscv_save_5",
"__riscv_save_6",
"__riscv_save_7",
"__riscv_save_8",
"__riscv_save_9",
"__riscv_save_10",
"__riscv_save_11",
"__riscv_save_12"
};
int LibCallID = getLibCallID(MF, CSI);
if (LibCallID == -1)
return nullptr;
return SpillLibCalls[LibCallID];
}
// Get the name of the libcall used for restoring callee saved registers.
// If this function will not use save/restore libcalls, then return a nullptr.
static const char *
getRestoreLibCallName(const MachineFunction &MF,
const std::vector<CalleeSavedInfo> &CSI) {
static const char *const RestoreLibCalls[] = {
"__riscv_restore_0",
"__riscv_restore_1",
"__riscv_restore_2",
"__riscv_restore_3",
"__riscv_restore_4",
"__riscv_restore_5",
"__riscv_restore_6",
"__riscv_restore_7",
"__riscv_restore_8",
"__riscv_restore_9",
"__riscv_restore_10",
"__riscv_restore_11",
"__riscv_restore_12"
};
int LibCallID = getLibCallID(MF, CSI);
if (LibCallID == -1)
return nullptr;
return RestoreLibCalls[LibCallID];
}
bool RISCVFrameLowering::hasFP(const MachineFunction &MF) const {
const TargetRegisterInfo *RegInfo = MF.getSubtarget().getRegisterInfo();
const MachineFrameInfo &MFI = MF.getFrameInfo();
return MF.getTarget().Options.DisableFramePointerElim(MF) ||
RegInfo->hasStackRealignment(MF) || MFI.hasVarSizedObjects() ||
MFI.isFrameAddressTaken();
}
bool RISCVFrameLowering::hasBP(const MachineFunction &MF) const {
const MachineFrameInfo &MFI = MF.getFrameInfo();
const TargetRegisterInfo *TRI = STI.getRegisterInfo();
return MFI.hasVarSizedObjects() && TRI->hasStackRealignment(MF);
}
// Determines the size of the frame and maximum call frame size.
void RISCVFrameLowering::determineFrameLayout(MachineFunction &MF) const {
MachineFrameInfo &MFI = MF.getFrameInfo();
// Get the number of bytes to allocate from the FrameInfo.
uint64_t FrameSize = MFI.getStackSize();
// Get the alignment.
Align StackAlign = getStackAlign();
// Make sure the frame is aligned.
FrameSize = alignTo(FrameSize, StackAlign);
// Update frame info.
MFI.setStackSize(FrameSize);
}
void RISCVFrameLowering::adjustReg(MachineBasicBlock &MBB,
MachineBasicBlock::iterator MBBI,
const DebugLoc &DL, Register DestReg,
Register SrcReg, int64_t Val,
MachineInstr::MIFlag Flag) const {
MachineRegisterInfo &MRI = MBB.getParent()->getRegInfo();
const RISCVInstrInfo *TII = STI.getInstrInfo();
if (DestReg == SrcReg && Val == 0)
return;
if (isInt<12>(Val)) {
BuildMI(MBB, MBBI, DL, TII->get(RISCV::ADDI), DestReg)
.addReg(SrcReg)
.addImm(Val)
.setMIFlag(Flag);
} else {
unsigned Opc = RISCV::ADD;
bool isSub = Val < 0;
if (isSub) {
Val = -Val;
Opc = RISCV::SUB;
}
Register ScratchReg = MRI.createVirtualRegister(&RISCV::GPRRegClass);
TII->movImm(MBB, MBBI, DL, ScratchReg, Val, Flag);
BuildMI(MBB, MBBI, DL, TII->get(Opc), DestReg)
.addReg(SrcReg)
.addReg(ScratchReg, RegState::Kill)
.setMIFlag(Flag);
}
}
// Returns the register used to hold the frame pointer.
static Register getFPReg(const RISCVSubtarget &STI) { return RISCV::X8; }
// Returns the register used to hold the stack pointer.
static Register getSPReg(const RISCVSubtarget &STI) { return RISCV::X2; }
static SmallVector<CalleeSavedInfo, 8>
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
getNonLibcallCSI(const MachineFunction &MF,
const std::vector<CalleeSavedInfo> &CSI) {
const MachineFrameInfo &MFI = MF.getFrameInfo();
SmallVector<CalleeSavedInfo, 8> NonLibcallCSI;
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
for (auto &CS : CSI) {
int FI = CS.getFrameIdx();
if (FI >= 0 && MFI.getStackID(FI) == TargetStackID::Default)
NonLibcallCSI.push_back(CS);
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
}
return NonLibcallCSI;
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
void RISCVFrameLowering::adjustStackForRVV(MachineFunction &MF,
MachineBasicBlock &MBB,
MachineBasicBlock::iterator MBBI,
const DebugLoc &DL,
int64_t Amount) const {
assert(Amount != 0 && "Did not need to adjust stack pointer for RVV.");
const RISCVInstrInfo *TII = STI.getInstrInfo();
Register SPReg = getSPReg(STI);
unsigned Opc = RISCV::ADD;
if (Amount < 0) {
Amount = -Amount;
Opc = RISCV::SUB;
}
// 1. Multiply the number of v-slots to the length of registers
Register FactorRegister = TII->getVLENFactoredAmount(MF, MBB, MBBI, Amount);
// 2. SP = SP - RVV stack size
BuildMI(MBB, MBBI, DL, TII->get(Opc), SPReg)
.addReg(SPReg)
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
.addReg(FactorRegister, RegState::Kill);
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
}
void RISCVFrameLowering::emitPrologue(MachineFunction &MF,
MachineBasicBlock &MBB) const {
MachineFrameInfo &MFI = MF.getFrameInfo();
auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
const RISCVRegisterInfo *RI = STI.getRegisterInfo();
const RISCVInstrInfo *TII = STI.getInstrInfo();
MachineBasicBlock::iterator MBBI = MBB.begin();
Register FPReg = getFPReg(STI);
Register SPReg = getSPReg(STI);
Register BPReg = RISCVABI::getBPReg();
// Debug location must be unknown since the first debug location is used
// to determine the end of the prologue.
DebugLoc DL;
// All calls are tail calls in GHC calling conv, and functions have no
// prologue/epilogue.
if (MF.getFunction().getCallingConv() == CallingConv::GHC)
return;
// Emit prologue for shadow call stack.
emitSCSPrologue(MF, MBB, MBBI, DL);
// Since spillCalleeSavedRegisters may have inserted a libcall, skip past
// any instructions marked as FrameSetup
while (MBBI != MBB.end() && MBBI->getFlag(MachineInstr::FrameSetup))
++MBBI;
// Determine the correct frame layout
determineFrameLayout(MF);
// If libcalls are used to spill and restore callee-saved registers, the frame
// has two sections; the opaque section managed by the libcalls, and the
// section managed by MachineFrameInfo which can also hold callee saved
// registers in fixed stack slots, both of which have negative frame indices.
// This gets even more complicated when incoming arguments are passed via the
// stack, as these too have negative frame indices. An example is detailed
// below:
//
// | incoming arg | <- FI[-3]
// | libcallspill |
// | calleespill | <- FI[-2]
// | calleespill | <- FI[-1]
// | this_frame | <- FI[0]
//
// For negative frame indices, the offset from the frame pointer will differ
// depending on which of these groups the frame index applies to.
// The following calculates the correct offset knowing the number of callee
// saved registers spilt by the two methods.
if (int LibCallRegs = getLibCallID(MF, MFI.getCalleeSavedInfo()) + 1) {
// Calculate the size of the frame managed by the libcall. The libcalls are
// implemented such that the stack will always be 16 byte aligned.
unsigned LibCallFrameSize = alignTo((STI.getXLen() / 8) * LibCallRegs, 16);
RVFI->setLibCallStackSize(LibCallFrameSize);
}
// FIXME (note copied from Lanai): This appears to be overallocating. Needs
// investigation. Get the number of bytes to allocate from the FrameInfo.
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
uint64_t StackSize = MFI.getStackSize() + RVFI->getRVVPadding();
uint64_t RealStackSize = StackSize + RVFI->getLibCallStackSize();
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
uint64_t RVVStackSize = RVFI->getRVVStackSize();
// Early exit if there is no need to allocate on the stack
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
if (RealStackSize == 0 && !MFI.adjustsStack() && RVVStackSize == 0)
return;
// If the stack pointer has been marked as reserved, then produce an error if
// the frame requires stack allocation
if (STI.isRegisterReservedByUser(SPReg))
MF.getFunction().getContext().diagnose(DiagnosticInfoUnsupported{
MF.getFunction(), "Stack pointer required, but has been reserved."});
uint64_t FirstSPAdjustAmount = getFirstSPAdjustAmount(MF);
// Split the SP adjustment to reduce the offsets of callee saved spill.
if (FirstSPAdjustAmount) {
StackSize = FirstSPAdjustAmount;
RealStackSize = FirstSPAdjustAmount;
}
// Allocate space on the stack if necessary.
adjustReg(MBB, MBBI, DL, SPReg, SPReg, -StackSize, MachineInstr::FrameSetup);
// Emit ".cfi_def_cfa_offset RealStackSize"
unsigned CFIIndex = MF.addFrameInst(
MCCFIInstruction::cfiDefCfaOffset(nullptr, RealStackSize));
BuildMI(MBB, MBBI, DL, TII->get(TargetOpcode::CFI_INSTRUCTION))
.addCFIIndex(CFIIndex);
const auto &CSI = MFI.getCalleeSavedInfo();
// The frame pointer is callee-saved, and code has been generated for us to
// save it to the stack. We need to skip over the storing of callee-saved
// registers as the frame pointer must be modified after it has been saved
// to the stack, not before.
// FIXME: assumes exactly one instruction is used to save each callee-saved
// register.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
std::advance(MBBI, getNonLibcallCSI(MF, CSI).size());
// Iterate over list of callee-saved registers and emit .cfi_offset
// directives.
for (const auto &Entry : CSI) {
int FrameIdx = Entry.getFrameIdx();
int64_t Offset;
// Offsets for objects with fixed locations (IE: those saved by libcall) are
// simply calculated from the frame index.
if (FrameIdx < 0)
Offset = FrameIdx * (int64_t) STI.getXLen() / 8;
else
Offset = MFI.getObjectOffset(Entry.getFrameIdx()) -
RVFI->getLibCallStackSize();
Register Reg = Entry.getReg();
unsigned CFIIndex = MF.addFrameInst(MCCFIInstruction::createOffset(
nullptr, RI->getDwarfRegNum(Reg, true), Offset));
BuildMI(MBB, MBBI, DL, TII->get(TargetOpcode::CFI_INSTRUCTION))
.addCFIIndex(CFIIndex);
}
// Generate new FP.
if (hasFP(MF)) {
if (STI.isRegisterReservedByUser(FPReg))
MF.getFunction().getContext().diagnose(DiagnosticInfoUnsupported{
MF.getFunction(), "Frame pointer required, but has been reserved."});
adjustReg(MBB, MBBI, DL, FPReg, SPReg,
RealStackSize - RVFI->getVarArgsSaveSize(),
MachineInstr::FrameSetup);
// Emit ".cfi_def_cfa $fp, RVFI->getVarArgsSaveSize()"
unsigned CFIIndex = MF.addFrameInst(MCCFIInstruction::cfiDefCfa(
nullptr, RI->getDwarfRegNum(FPReg, true), RVFI->getVarArgsSaveSize()));
BuildMI(MBB, MBBI, DL, TII->get(TargetOpcode::CFI_INSTRUCTION))
.addCFIIndex(CFIIndex);
}
// Emit the second SP adjustment after saving callee saved registers.
if (FirstSPAdjustAmount) {
uint64_t SecondSPAdjustAmount = MFI.getStackSize() - FirstSPAdjustAmount;
assert(SecondSPAdjustAmount > 0 &&
"SecondSPAdjustAmount should be greater than zero");
adjustReg(MBB, MBBI, DL, SPReg, SPReg, -SecondSPAdjustAmount,
MachineInstr::FrameSetup);
// If we are using a frame-pointer, and thus emitted ".cfi_def_cfa fp, 0",
// don't emit an sp-based .cfi_def_cfa_offset
if (!hasFP(MF)) {
// Emit ".cfi_def_cfa_offset StackSize"
unsigned CFIIndex = MF.addFrameInst(
MCCFIInstruction::cfiDefCfaOffset(nullptr, MFI.getStackSize()));
BuildMI(MBB, MBBI, DL, TII->get(TargetOpcode::CFI_INSTRUCTION))
.addCFIIndex(CFIIndex);
}
}
if (RVVStackSize)
adjustStackForRVV(MF, MBB, MBBI, DL, -RVVStackSize);
if (hasFP(MF)) {
// Realign Stack
const RISCVRegisterInfo *RI = STI.getRegisterInfo();
if (RI->hasStackRealignment(MF)) {
Align MaxAlignment = MFI.getMaxAlign();
const RISCVInstrInfo *TII = STI.getInstrInfo();
if (isInt<12>(-(int)MaxAlignment.value())) {
BuildMI(MBB, MBBI, DL, TII->get(RISCV::ANDI), SPReg)
.addReg(SPReg)
.addImm(-(int)MaxAlignment.value());
} else {
unsigned ShiftAmount = Log2(MaxAlignment);
Register VR =
MF.getRegInfo().createVirtualRegister(&RISCV::GPRRegClass);
BuildMI(MBB, MBBI, DL, TII->get(RISCV::SRLI), VR)
.addReg(SPReg)
.addImm(ShiftAmount);
BuildMI(MBB, MBBI, DL, TII->get(RISCV::SLLI), SPReg)
.addReg(VR)
.addImm(ShiftAmount);
}
// FP will be used to restore the frame in the epilogue, so we need
// another base register BP to record SP after re-alignment. SP will
// track the current stack after allocating variable sized objects.
if (hasBP(MF)) {
// move BP, SP
TII->copyPhysReg(MBB, MBBI, DL, BPReg, SPReg, false);
}
}
}
}
void RISCVFrameLowering::emitEpilogue(MachineFunction &MF,
MachineBasicBlock &MBB) const {
const RISCVRegisterInfo *RI = STI.getRegisterInfo();
MachineFrameInfo &MFI = MF.getFrameInfo();
auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
Register FPReg = getFPReg(STI);
Register SPReg = getSPReg(STI);
// All calls are tail calls in GHC calling conv, and functions have no
// prologue/epilogue.
if (MF.getFunction().getCallingConv() == CallingConv::GHC)
return;
// Get the insert location for the epilogue. If there were no terminators in
// the block, get the last instruction.
MachineBasicBlock::iterator MBBI = MBB.end();
DebugLoc DL;
if (!MBB.empty()) {
MBBI = MBB.getFirstTerminator();
if (MBBI == MBB.end())
MBBI = MBB.getLastNonDebugInstr();
DL = MBBI->getDebugLoc();
// If this is not a terminator, the actual insert location should be after the
// last instruction.
if (!MBBI->isTerminator())
MBBI = std::next(MBBI);
// If callee-saved registers are saved via libcall, place stack adjustment
// before this call.
while (MBBI != MBB.begin() &&
std::prev(MBBI)->getFlag(MachineInstr::FrameDestroy))
--MBBI;
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
const auto &CSI = getNonLibcallCSI(MF, MFI.getCalleeSavedInfo());
// Skip to before the restores of callee-saved registers
// FIXME: assumes exactly one instruction is used to restore each
// callee-saved register.
auto LastFrameDestroy = MBBI;
if (!CSI.empty())
LastFrameDestroy = std::prev(MBBI, CSI.size());
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
uint64_t StackSize = MFI.getStackSize() + RVFI->getRVVPadding();
uint64_t RealStackSize = StackSize + RVFI->getLibCallStackSize();
uint64_t FPOffset = RealStackSize - RVFI->getVarArgsSaveSize();
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
uint64_t RVVStackSize = RVFI->getRVVStackSize();
// Restore the stack pointer using the value of the frame pointer. Only
// necessary if the stack pointer was modified, meaning the stack size is
// unknown.
if (RI->hasStackRealignment(MF) || MFI.hasVarSizedObjects()) {
assert(hasFP(MF) && "frame pointer should not have been eliminated");
adjustReg(MBB, LastFrameDestroy, DL, SPReg, FPReg, -FPOffset,
MachineInstr::FrameDestroy);
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
} else {
if (RVVStackSize)
adjustStackForRVV(MF, MBB, LastFrameDestroy, DL, RVVStackSize);
}
uint64_t FirstSPAdjustAmount = getFirstSPAdjustAmount(MF);
if (FirstSPAdjustAmount) {
uint64_t SecondSPAdjustAmount = MFI.getStackSize() - FirstSPAdjustAmount;
assert(SecondSPAdjustAmount > 0 &&
"SecondSPAdjustAmount should be greater than zero");
adjustReg(MBB, LastFrameDestroy, DL, SPReg, SPReg, SecondSPAdjustAmount,
MachineInstr::FrameDestroy);
}
if (FirstSPAdjustAmount)
StackSize = FirstSPAdjustAmount;
// Deallocate stack
adjustReg(MBB, MBBI, DL, SPReg, SPReg, StackSize, MachineInstr::FrameDestroy);
// Emit epilogue for shadow call stack.
emitSCSEpilogue(MF, MBB, MBBI, DL);
}
StackOffset
RISCVFrameLowering::getFrameIndexReference(const MachineFunction &MF, int FI,
Register &FrameReg) const {
const MachineFrameInfo &MFI = MF.getFrameInfo();
const TargetRegisterInfo *RI = MF.getSubtarget().getRegisterInfo();
const auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
// Callee-saved registers should be referenced relative to the stack
// pointer (positive offset), otherwise use the frame pointer (negative
// offset).
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
const auto &CSI = getNonLibcallCSI(MF, MFI.getCalleeSavedInfo());
int MinCSFI = 0;
int MaxCSFI = -1;
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
StackOffset Offset;
auto StackID = MFI.getStackID(FI);
assert((StackID == TargetStackID::Default ||
StackID == TargetStackID::ScalableVector) &&
"Unexpected stack ID for the frame object.");
if (StackID == TargetStackID::Default) {
Offset =
StackOffset::getFixed(MFI.getObjectOffset(FI) - getOffsetOfLocalArea() +
MFI.getOffsetAdjustment());
} else if (StackID == TargetStackID::ScalableVector) {
Offset = StackOffset::getScalable(MFI.getObjectOffset(FI));
}
uint64_t FirstSPAdjustAmount = getFirstSPAdjustAmount(MF);
if (CSI.size()) {
MinCSFI = CSI[0].getFrameIdx();
MaxCSFI = CSI[CSI.size() - 1].getFrameIdx();
}
if (FI >= MinCSFI && FI <= MaxCSFI) {
FrameReg = RISCV::X2;
if (FirstSPAdjustAmount)
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
Offset += StackOffset::getFixed(FirstSPAdjustAmount);
else
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
Offset +=
StackOffset::getFixed(MFI.getStackSize() + RVFI->getRVVPadding());
} else if (RI->hasStackRealignment(MF) && !MFI.isFixedObjectIndex(FI)) {
// If the stack was realigned, the frame pointer is set in order to allow
// SP to be restored, so we need another base register to record the stack
// after realignment.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
if (hasBP(MF)) {
FrameReg = RISCVABI::getBPReg();
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// |--------------------------| -- <-- FP
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
// | callee-saved registers | | <----.
// |--------------------------| -- |
// | realignment (the size of | | |
// | this area is not counted | | |
// | in MFI.getStackSize()) | | |
// |--------------------------| -- |
// | Padding after RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |-- MFI.getStackSize()
// | RVV objects | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | Padding before RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | scalar local variables | | <----'
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// |--------------------------| -- <-- BP
// | VarSize objects | |
// |--------------------------| -- <-- SP
} else {
FrameReg = RISCV::X2;
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// |--------------------------| -- <-- FP
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
// | callee-saved registers | | <----.
// |--------------------------| -- |
// | realignment (the size of | | |
// | this area is not counted | | |
// | in MFI.getStackSize()) | | |
// |--------------------------| -- |
// | Padding after RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |-- MFI.getStackSize()
// | RVV objects | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | Padding before RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | scalar local variables | | <----'
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// |--------------------------| -- <-- SP
}
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
// The total amount of padding surrounding RVV objects is described by
// RVV->getRVVPadding() and it can be zero. It allows us to align the RVV
// objects to 8 bytes.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
if (MFI.getStackID(FI) == TargetStackID::Default) {
Offset += StackOffset::getFixed(MFI.getStackSize());
if (FI < 0)
Offset += StackOffset::getFixed(RVFI->getLibCallStackSize());
} else if (MFI.getStackID(FI) == TargetStackID::ScalableVector) {
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
Offset += StackOffset::get(
alignTo(MFI.getStackSize() - RVFI->getCalleeSavedStackSize(), 8),
RVFI->getRVVStackSize());
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
}
} else {
FrameReg = RI->getFrameRegister(MF);
if (hasFP(MF)) {
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
Offset += StackOffset::getFixed(RVFI->getVarArgsSaveSize());
if (FI >= 0)
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
Offset -= StackOffset::getFixed(RVFI->getLibCallStackSize());
// When using FP to access scalable vector objects, we need to minus
// the frame size.
//
// |--------------------------| -- <-- FP
// | callee-saved registers | |
// |--------------------------| | MFI.getStackSize()
// | scalar local variables | |
// |--------------------------| -- (Offset of RVV objects is from here.)
// | RVV objects |
// |--------------------------|
// | VarSize objects |
// |--------------------------| <-- SP
if (MFI.getStackID(FI) == TargetStackID::ScalableVector)
Offset -= StackOffset::getFixed(MFI.getStackSize());
} else {
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// When using SP to access frame objects, we need to add RVV stack size.
//
// |--------------------------| -- <-- FP
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
// | callee-saved registers | | <----.
// |--------------------------| -- |
// | Padding after RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | RVV objects | | |-- MFI.getStackSize()
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | Padding before RVV | | |
// | (not counted in | | |
// | MFI.getStackSize() | | |
// |--------------------------| -- |
// | scalar local variables | | <----'
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
// |--------------------------| -- <-- SP
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
//
// The total amount of padding surrounding RVV objects is described by
// RVV->getRVVPadding() and it can be zero. It allows us to align the RVV
// objects to 8 bytes.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
if (MFI.getStackID(FI) == TargetStackID::Default) {
Offset += StackOffset::getFixed(MFI.getStackSize());
if (FI < 0)
Offset += StackOffset::getFixed(RVFI->getLibCallStackSize());
} else if (MFI.getStackID(FI) == TargetStackID::ScalableVector) {
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
Offset += StackOffset::get(
alignTo(MFI.getStackSize() - RVFI->getCalleeSavedStackSize(), 8),
RVFI->getRVVStackSize());
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
}
}
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
return Offset;
}
void RISCVFrameLowering::determineCalleeSaves(MachineFunction &MF,
BitVector &SavedRegs,
RegScavenger *RS) const {
TargetFrameLowering::determineCalleeSaves(MF, SavedRegs, RS);
// Unconditionally spill RA and FP only if the function uses a frame
// pointer.
if (hasFP(MF)) {
SavedRegs.set(RISCV::X1);
SavedRegs.set(RISCV::X8);
}
// Mark BP as used if function has dedicated base pointer.
if (hasBP(MF))
SavedRegs.set(RISCVABI::getBPReg());
// If interrupt is enabled and there are calls in the handler,
// unconditionally save all Caller-saved registers and
// all FP registers, regardless whether they are used.
MachineFrameInfo &MFI = MF.getFrameInfo();
if (MF.getFunction().hasFnAttribute("interrupt") && MFI.hasCalls()) {
static const MCPhysReg CSRegs[] = { RISCV::X1, /* ra */
RISCV::X5, RISCV::X6, RISCV::X7, /* t0-t2 */
RISCV::X10, RISCV::X11, /* a0-a1, a2-a7 */
RISCV::X12, RISCV::X13, RISCV::X14, RISCV::X15, RISCV::X16, RISCV::X17,
RISCV::X28, RISCV::X29, RISCV::X30, RISCV::X31, 0 /* t3-t6 */
};
for (unsigned i = 0; CSRegs[i]; ++i)
SavedRegs.set(CSRegs[i]);
if (MF.getSubtarget<RISCVSubtarget>().hasStdExtF()) {
// If interrupt is enabled, this list contains all FP registers.
const MCPhysReg * Regs = MF.getRegInfo().getCalleeSavedRegs();
for (unsigned i = 0; Regs[i]; ++i)
if (RISCV::FPR16RegClass.contains(Regs[i]) ||
RISCV::FPR32RegClass.contains(Regs[i]) ||
RISCV::FPR64RegClass.contains(Regs[i]))
SavedRegs.set(Regs[i]);
}
}
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
int64_t
RISCVFrameLowering::assignRVVStackObjectOffsets(MachineFrameInfo &MFI) const {
int64_t Offset = 0;
// Create a buffer of RVV objects to allocate.
SmallVector<int, 8> ObjectsToAllocate;
for (int I = 0, E = MFI.getObjectIndexEnd(); I != E; ++I) {
unsigned StackID = MFI.getStackID(I);
if (StackID != TargetStackID::ScalableVector)
continue;
if (MFI.isDeadObjectIndex(I))
continue;
ObjectsToAllocate.push_back(I);
}
// Allocate all RVV locals and spills
for (int FI : ObjectsToAllocate) {
// ObjectSize in bytes.
int64_t ObjectSize = MFI.getObjectSize(FI);
// If the data type is the fractional vector type, reserve one vector
// register for it.
if (ObjectSize < 8)
ObjectSize = 8;
// Currently, all scalable vector types are aligned to 8 bytes.
Offset = alignTo(Offset + ObjectSize, 8);
MFI.setObjectOffset(FI, -Offset);
}
return Offset;
}
void RISCVFrameLowering::processFunctionBeforeFrameFinalized(
MachineFunction &MF, RegScavenger *RS) const {
const TargetRegisterInfo *RegInfo = MF.getSubtarget().getRegisterInfo();
MachineFrameInfo &MFI = MF.getFrameInfo();
const TargetRegisterClass *RC = &RISCV::GPRRegClass;
auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
int64_t RVVStackSize = assignRVVStackObjectOffsets(MFI);
RVFI->setRVVStackSize(RVVStackSize);
// estimateStackSize has been observed to under-estimate the final stack
// size, so give ourselves wiggle-room by checking for stack size
// representable an 11-bit signed field rather than 12-bits.
// FIXME: It may be possible to craft a function with a small stack that
// still needs an emergency spill slot for branch relaxation. This case
// would currently be missed.
if (!isInt<11>(MFI.estimateStackSize(MF)) || RVVStackSize != 0) {
int RegScavFI = MFI.CreateStackObject(RegInfo->getSpillSize(*RC),
RegInfo->getSpillAlign(*RC), false);
RS->addScavengingFrameIndex(RegScavFI);
// For RVV, scalable stack offsets require up to two scratch registers to
// compute the final offset. Reserve an additional emergency spill slot.
if (RVVStackSize != 0) {
int RVVRegScavFI = MFI.CreateStackObject(
RegInfo->getSpillSize(*RC), RegInfo->getSpillAlign(*RC), false);
RS->addScavengingFrameIndex(RVVRegScavFI);
}
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
if (MFI.getCalleeSavedInfo().empty() || RVFI->useSaveRestoreLibCalls(MF)) {
RVFI->setCalleeSavedStackSize(0);
return;
}
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
unsigned Size = 0;
for (const auto &Info : MFI.getCalleeSavedInfo()) {
int FrameIdx = Info.getFrameIdx();
if (MFI.getStackID(FrameIdx) != TargetStackID::Default)
continue;
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
Size += MFI.getObjectSize(FrameIdx);
}
RVFI->setCalleeSavedStackSize(Size);
[RISCV] Fix offset computation for RVV In D97111 we changed the RVV frame layout when using sp or bp to address the stack slots so we could address the emergency stack slot. The idea is to put the RVV objects as far as possible (in offset terms) from the frame reference register (sp / fp / bp). When using fp this happens naturally because the RVV objects are already the top of the stack and due to the constraints of RVV (VLENB being a power of two >= 128) the stack remains aligned. The rest of this summary does not apply to this case. When using sp / bp we need to skip the non-RVV stack slots. The size of the the non-RVV objects is computed subtracting the callee saved register size (whose computation is added in D97111 itself) to the total size of the stack (which does not account for RVV stack slots). However, when doing so we round to 16 bytes when computing that size and we end emitting a smaller offset that may belong to a scalar stack slot (see D98801). So this change removes that rounding. Also, because we want the RVV objects be between the non-RVV stack slots and the callee-saved register slots, we need to make sure the RVV objects are properly aligned to 8 bytes. Adding a padding of 8 would render the stack unaligned. So when allocating space for RVV (only when we don't use fp) we need to have extra padding that preserves the stack alignment. This way we can round to 8 bytes the offset that skips the non-RVV objects and we do not misalign the whole stack in the way. In some circumstances this means that the RVV objects may have padding before (=lower offsets from sp/bp) and after (before the CSR stack slots). Differential Revision: https://reviews.llvm.org/D98802
2021-03-18 18:26:33 +08:00
// Padding required to keep the RVV stack aligned to 8 bytes
// within the main stack. We only need this when not using FP.
if (RVVStackSize && !hasFP(MF) && Size % 8 != 0) {
// Because we add the padding to the size of the stack, adding
// getStackAlign() will keep it aligned.
RVFI->setRVVPadding(getStackAlign().value());
}
}
// Not preserve stack space within prologue for outgoing variables when the
// function contains variable size objects and let eliminateCallFramePseudoInstr
// preserve stack space for it.
bool RISCVFrameLowering::hasReservedCallFrame(const MachineFunction &MF) const {
return !MF.getFrameInfo().hasVarSizedObjects();
}
// Eliminate ADJCALLSTACKDOWN, ADJCALLSTACKUP pseudo instructions.
MachineBasicBlock::iterator RISCVFrameLowering::eliminateCallFramePseudoInstr(
MachineFunction &MF, MachineBasicBlock &MBB,
MachineBasicBlock::iterator MI) const {
Register SPReg = RISCV::X2;
DebugLoc DL = MI->getDebugLoc();
if (!hasReservedCallFrame(MF)) {
// If space has not been reserved for a call frame, ADJCALLSTACKDOWN and
// ADJCALLSTACKUP must be converted to instructions manipulating the stack
// pointer. This is necessary when there is a variable length stack
// allocation (e.g. alloca), which means it's not possible to allocate
// space for outgoing arguments from within the function prologue.
int64_t Amount = MI->getOperand(0).getImm();
if (Amount != 0) {
// Ensure the stack remains aligned after adjustment.
Amount = alignSPAdjust(Amount);
if (MI->getOpcode() == RISCV::ADJCALLSTACKDOWN)
Amount = -Amount;
adjustReg(MBB, MI, DL, SPReg, SPReg, Amount, MachineInstr::NoFlags);
}
}
return MBB.erase(MI);
}
// We would like to split the SP adjustment to reduce prologue/epilogue
// as following instructions. In this way, the offset of the callee saved
// register could fit in a single store.
// add sp,sp,-2032
// sw ra,2028(sp)
// sw s0,2024(sp)
// sw s1,2020(sp)
// sw s3,2012(sp)
// sw s4,2008(sp)
// add sp,sp,-64
uint64_t
RISCVFrameLowering::getFirstSPAdjustAmount(const MachineFunction &MF) const {
const auto *RVFI = MF.getInfo<RISCVMachineFunctionInfo>();
const MachineFrameInfo &MFI = MF.getFrameInfo();
const std::vector<CalleeSavedInfo> &CSI = MFI.getCalleeSavedInfo();
uint64_t StackSize = MFI.getStackSize();
// Disable SplitSPAdjust if save-restore libcall used. The callee saved
// registers will be pushed by the save-restore libcalls, so we don't have to
// split the SP adjustment in this case.
if (RVFI->getLibCallStackSize())
return 0;
// Return the FirstSPAdjustAmount if the StackSize can not fit in signed
// 12-bit and there exists a callee saved register need to be pushed.
if (!isInt<12>(StackSize) && (CSI.size() > 0)) {
// FirstSPAdjustAmount is choosed as (2048 - StackAlign)
// because 2048 will cause sp = sp + 2048 in epilogue split into
// multi-instructions. The offset smaller than 2048 can fit in signle
// load/store instruction and we have to stick with the stack alignment.
// 2048 is 16-byte alignment. The stack alignment for RV32 and RV64 is 16,
// for RV32E is 4. So (2048 - StackAlign) will satisfy the stack alignment.
return 2048 - getStackAlign().value();
}
return 0;
}
bool RISCVFrameLowering::spillCalleeSavedRegisters(
MachineBasicBlock &MBB, MachineBasicBlock::iterator MI,
ArrayRef<CalleeSavedInfo> CSI, const TargetRegisterInfo *TRI) const {
if (CSI.empty())
return true;
MachineFunction *MF = MBB.getParent();
const TargetInstrInfo &TII = *MF->getSubtarget().getInstrInfo();
DebugLoc DL;
if (MI != MBB.end() && !MI->isDebugInstr())
DL = MI->getDebugLoc();
const char *SpillLibCall = getSpillLibCallName(*MF, CSI);
if (SpillLibCall) {
// Add spill libcall via non-callee-saved register t0.
BuildMI(MBB, MI, DL, TII.get(RISCV::PseudoCALLReg), RISCV::X5)
.addExternalSymbol(SpillLibCall, RISCVII::MO_CALL)
.setMIFlag(MachineInstr::FrameSetup);
// Add registers spilled in libcall as liveins.
for (auto &CS : CSI)
MBB.addLiveIn(CS.getReg());
}
// Manually spill values not spilled by libcall.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
const auto &NonLibcallCSI = getNonLibcallCSI(*MF, CSI);
for (auto &CS : NonLibcallCSI) {
// Insert the spill to the stack frame.
Register Reg = CS.getReg();
const TargetRegisterClass *RC = TRI->getMinimalPhysRegClass(Reg);
TII.storeRegToStackSlot(MBB, MI, Reg, true, CS.getFrameIdx(), RC, TRI);
}
return true;
}
bool RISCVFrameLowering::restoreCalleeSavedRegisters(
MachineBasicBlock &MBB, MachineBasicBlock::iterator MI,
MutableArrayRef<CalleeSavedInfo> CSI, const TargetRegisterInfo *TRI) const {
if (CSI.empty())
return true;
MachineFunction *MF = MBB.getParent();
const TargetInstrInfo &TII = *MF->getSubtarget().getInstrInfo();
DebugLoc DL;
if (MI != MBB.end() && !MI->isDebugInstr())
DL = MI->getDebugLoc();
// Manually restore values not restored by libcall. Insert in reverse order.
// loadRegFromStackSlot can insert multiple instructions.
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
const auto &NonLibcallCSI = getNonLibcallCSI(*MF, CSI);
for (auto &CS : reverse(NonLibcallCSI)) {
Register Reg = CS.getReg();
const TargetRegisterClass *RC = TRI->getMinimalPhysRegClass(Reg);
TII.loadRegFromStackSlot(MBB, MI, Reg, CS.getFrameIdx(), RC, TRI);
assert(MI != MBB.begin() && "loadRegFromStackSlot didn't insert any code!");
}
const char *RestoreLibCall = getRestoreLibCallName(*MF, CSI);
if (RestoreLibCall) {
// Add restore libcall via tail call.
MachineBasicBlock::iterator NewMI =
BuildMI(MBB, MI, DL, TII.get(RISCV::PseudoTAIL))
.addExternalSymbol(RestoreLibCall, RISCVII::MO_CALL)
.setMIFlag(MachineInstr::FrameDestroy);
// Remove trailing returns, since the terminator is now a tail call to the
// restore function.
if (MI != MBB.end() && MI->getOpcode() == RISCV::PseudoRET) {
NewMI->copyImplicitOps(*MF, *MI);
MI->eraseFromParent();
}
}
return true;
}
bool RISCVFrameLowering::canUseAsPrologue(const MachineBasicBlock &MBB) const {
MachineBasicBlock *TmpMBB = const_cast<MachineBasicBlock *>(&MBB);
const MachineFunction *MF = MBB.getParent();
const auto *RVFI = MF->getInfo<RISCVMachineFunctionInfo>();
if (!RVFI->useSaveRestoreLibCalls(*MF))
return true;
// Inserting a call to a __riscv_save libcall requires the use of the register
// t0 (X5) to hold the return address. Therefore if this register is already
// used we can't insert the call.
RegScavenger RS;
RS.enterBasicBlock(*TmpMBB);
return !RS.isRegUsed(RISCV::X5);
}
bool RISCVFrameLowering::canUseAsEpilogue(const MachineBasicBlock &MBB) const {
const MachineFunction *MF = MBB.getParent();
MachineBasicBlock *TmpMBB = const_cast<MachineBasicBlock *>(&MBB);
const auto *RVFI = MF->getInfo<RISCVMachineFunctionInfo>();
if (!RVFI->useSaveRestoreLibCalls(*MF))
return true;
// Using the __riscv_restore libcalls to restore CSRs requires a tail call.
// This means if we still need to continue executing code within this function
// the restore cannot take place in this basic block.
if (MBB.succ_size() > 1)
return false;
MachineBasicBlock *SuccMBB =
MBB.succ_empty() ? TmpMBB->getFallThrough() : *MBB.succ_begin();
// Doing a tail call should be safe if there are no successors, because either
// we have a returning block or the end of the block is unreachable, so the
// restore will be eliminated regardless.
if (!SuccMBB)
return true;
// The successor can only contain a return, since we would effectively be
// replacing the successor with our own tail return at the end of our block.
return SuccMBB->isReturnBlock() && SuccMBB->size() == 1;
}
[RISCV] Frame handling for RISC-V V extension. This patch proposes how to deal with RISC-V vector frame objects. The layout of RISC-V vector frame will look like |---------------------------------| | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there is realignment or variable length array in the stack, we will use frame pointer to access fixed objects and stack pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| | scalar outgoing arguments | |---------------------------------| | RVV local variables && | | RVV outgoing arguments | |---------------------------------| <- end of frame (sp) If there are both realignment and variable length array in the stack, we will use frame pointer to access fixed objects and base pointer to access non-fixed objects. |---------------------------------| <- frame pointer (fp) | scalar callee-saved registers | |---------------------------------| | scalar local variables | |---------------------------------| | ///// realignment ///// | |---------------------------------| <- base pointer (bp) | RVV local variables && | | RVV outgoing arguments | |---------------------------------| | /////////////////////////////// | | variable length array | | /////////////////////////////// | |---------------------------------| <- end of frame (sp) | scalar outgoing arguments | |---------------------------------| In this version, we do not save the addresses of RVV objects in the stack. We access them directly through the polynomial expression (a x VLENB + b). We do not reserve frame pointer when there is any RVV object in the stack. So, we also access the scalar frame objects through the polynomial expression (a x VLENB + b) if the access across RVV stack area. Differential Revision: https://reviews.llvm.org/D94465
2021-01-08 10:18:26 +08:00
bool RISCVFrameLowering::isSupportedStackID(TargetStackID::Value ID) const {
switch (ID) {
case TargetStackID::Default:
case TargetStackID::ScalableVector:
return true;
case TargetStackID::NoAlloc:
case TargetStackID::SGPRSpill:
return false;
}
llvm_unreachable("Invalid TargetStackID::Value");
}
TargetStackID::Value RISCVFrameLowering::getStackIDForScalableVectors() const {
return TargetStackID::ScalableVector;
}