2012-02-18 20:03:15 +08:00
|
|
|
//===-- PPCFrameLowering.cpp - PPC Frame Information ----------------------===//
|
2010-11-15 08:06:54 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2011-01-10 20:39:04 +08:00
|
|
|
// This file contains the PPC implementation of TargetFrameLowering class.
|
2010-11-15 08:06:54 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
#include "PPCFrameLowering.h"
|
2012-09-12 22:47:47 +08:00
|
|
|
#include "PPCInstrBuilder.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "PPCInstrInfo.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
#include "PPCMachineFunctionInfo.h"
|
2014-06-13 04:54:11 +08:00
|
|
|
#include "PPCSubtarget.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
#include "llvm/CodeGen/MachineFrameInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
|
|
|
#include "llvm/CodeGen/MachineInstrBuilder.h"
|
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineRegisterInfo.h"
|
2010-11-28 07:05:25 +08:00
|
|
|
#include "llvm/CodeGen/RegisterScavenging.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Function.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
#include "llvm/Target/TargetOptions.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
/// VRRegNo - Map from a numbered VR register to its enum value.
|
|
|
|
///
|
2012-03-11 15:16:55 +08:00
|
|
|
static const uint16_t VRRegNo[] = {
|
2010-11-15 08:06:54 +08:00
|
|
|
PPC::V0 , PPC::V1 , PPC::V2 , PPC::V3 , PPC::V4 , PPC::V5 , PPC::V6 , PPC::V7 ,
|
|
|
|
PPC::V8 , PPC::V9 , PPC::V10, PPC::V11, PPC::V12, PPC::V13, PPC::V14, PPC::V15,
|
|
|
|
PPC::V16, PPC::V17, PPC::V18, PPC::V19, PPC::V20, PPC::V21, PPC::V22, PPC::V23,
|
|
|
|
PPC::V24, PPC::V25, PPC::V26, PPC::V27, PPC::V28, PPC::V29, PPC::V30, PPC::V31
|
|
|
|
};
|
|
|
|
|
2014-06-13 04:54:11 +08:00
|
|
|
PPCFrameLowering::PPCFrameLowering(const PPCSubtarget &STI)
|
|
|
|
: TargetFrameLowering(TargetFrameLowering::StackGrowsDown,
|
|
|
|
(STI.hasQPX() || STI.isBGQ()) ? 32 : 16, 0),
|
|
|
|
Subtarget(STI) {}
|
|
|
|
|
|
|
|
// With the SVR4 ABI, callee-saved registers have fixed offsets on the stack.
|
|
|
|
const PPCFrameLowering::SpillSlot *PPCFrameLowering::getCalleeSavedSpillSlots(
|
|
|
|
unsigned &NumEntries) const {
|
|
|
|
if (Subtarget.isDarwinABI()) {
|
|
|
|
NumEntries = 1;
|
|
|
|
if (Subtarget.isPPC64()) {
|
|
|
|
static const SpillSlot darwin64Offsets = {PPC::X31, -8};
|
|
|
|
return &darwin64Offsets;
|
|
|
|
} else {
|
|
|
|
static const SpillSlot darwinOffsets = {PPC::R31, -4};
|
|
|
|
return &darwinOffsets;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Early exit if not using the SVR4 ABI.
|
|
|
|
if (!Subtarget.isSVR4ABI()) {
|
|
|
|
NumEntries = 0;
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Note that the offsets here overlap, but this is fixed up in
|
|
|
|
// processFunctionBeforeFrameFinalized.
|
|
|
|
|
|
|
|
static const SpillSlot Offsets[] = {
|
|
|
|
// Floating-point register save area offsets.
|
|
|
|
{PPC::F31, -8},
|
|
|
|
{PPC::F30, -16},
|
|
|
|
{PPC::F29, -24},
|
|
|
|
{PPC::F28, -32},
|
|
|
|
{PPC::F27, -40},
|
|
|
|
{PPC::F26, -48},
|
|
|
|
{PPC::F25, -56},
|
|
|
|
{PPC::F24, -64},
|
|
|
|
{PPC::F23, -72},
|
|
|
|
{PPC::F22, -80},
|
|
|
|
{PPC::F21, -88},
|
|
|
|
{PPC::F20, -96},
|
|
|
|
{PPC::F19, -104},
|
|
|
|
{PPC::F18, -112},
|
|
|
|
{PPC::F17, -120},
|
|
|
|
{PPC::F16, -128},
|
|
|
|
{PPC::F15, -136},
|
|
|
|
{PPC::F14, -144},
|
|
|
|
|
|
|
|
// General register save area offsets.
|
|
|
|
{PPC::R31, -4},
|
|
|
|
{PPC::R30, -8},
|
|
|
|
{PPC::R29, -12},
|
|
|
|
{PPC::R28, -16},
|
|
|
|
{PPC::R27, -20},
|
|
|
|
{PPC::R26, -24},
|
|
|
|
{PPC::R25, -28},
|
|
|
|
{PPC::R24, -32},
|
|
|
|
{PPC::R23, -36},
|
|
|
|
{PPC::R22, -40},
|
|
|
|
{PPC::R21, -44},
|
|
|
|
{PPC::R20, -48},
|
|
|
|
{PPC::R19, -52},
|
|
|
|
{PPC::R18, -56},
|
|
|
|
{PPC::R17, -60},
|
|
|
|
{PPC::R16, -64},
|
|
|
|
{PPC::R15, -68},
|
|
|
|
{PPC::R14, -72},
|
|
|
|
|
|
|
|
// CR save area offset. We map each of the nonvolatile CR fields
|
|
|
|
// to the slot for CR2, which is the first of the nonvolatile CR
|
|
|
|
// fields to be assigned, so that we only allocate one save slot.
|
|
|
|
// See PPCRegisterInfo::hasReservedSpillSlot() for more information.
|
|
|
|
{PPC::CR2, -4},
|
|
|
|
|
|
|
|
// VRSAVE save area offset.
|
|
|
|
{PPC::VRSAVE, -4},
|
|
|
|
|
|
|
|
// Vector register save area
|
|
|
|
{PPC::V31, -16},
|
|
|
|
{PPC::V30, -32},
|
|
|
|
{PPC::V29, -48},
|
|
|
|
{PPC::V28, -64},
|
|
|
|
{PPC::V27, -80},
|
|
|
|
{PPC::V26, -96},
|
|
|
|
{PPC::V25, -112},
|
|
|
|
{PPC::V24, -128},
|
|
|
|
{PPC::V23, -144},
|
|
|
|
{PPC::V22, -160},
|
|
|
|
{PPC::V21, -176},
|
|
|
|
{PPC::V20, -192}};
|
|
|
|
|
|
|
|
static const SpillSlot Offsets64[] = {
|
|
|
|
// Floating-point register save area offsets.
|
|
|
|
{PPC::F31, -8},
|
|
|
|
{PPC::F30, -16},
|
|
|
|
{PPC::F29, -24},
|
|
|
|
{PPC::F28, -32},
|
|
|
|
{PPC::F27, -40},
|
|
|
|
{PPC::F26, -48},
|
|
|
|
{PPC::F25, -56},
|
|
|
|
{PPC::F24, -64},
|
|
|
|
{PPC::F23, -72},
|
|
|
|
{PPC::F22, -80},
|
|
|
|
{PPC::F21, -88},
|
|
|
|
{PPC::F20, -96},
|
|
|
|
{PPC::F19, -104},
|
|
|
|
{PPC::F18, -112},
|
|
|
|
{PPC::F17, -120},
|
|
|
|
{PPC::F16, -128},
|
|
|
|
{PPC::F15, -136},
|
|
|
|
{PPC::F14, -144},
|
|
|
|
|
|
|
|
// General register save area offsets.
|
|
|
|
{PPC::X31, -8},
|
|
|
|
{PPC::X30, -16},
|
|
|
|
{PPC::X29, -24},
|
|
|
|
{PPC::X28, -32},
|
|
|
|
{PPC::X27, -40},
|
|
|
|
{PPC::X26, -48},
|
|
|
|
{PPC::X25, -56},
|
|
|
|
{PPC::X24, -64},
|
|
|
|
{PPC::X23, -72},
|
|
|
|
{PPC::X22, -80},
|
|
|
|
{PPC::X21, -88},
|
|
|
|
{PPC::X20, -96},
|
|
|
|
{PPC::X19, -104},
|
|
|
|
{PPC::X18, -112},
|
|
|
|
{PPC::X17, -120},
|
|
|
|
{PPC::X16, -128},
|
|
|
|
{PPC::X15, -136},
|
|
|
|
{PPC::X14, -144},
|
|
|
|
|
|
|
|
// VRSAVE save area offset.
|
|
|
|
{PPC::VRSAVE, -4},
|
|
|
|
|
|
|
|
// Vector register save area
|
|
|
|
{PPC::V31, -16},
|
|
|
|
{PPC::V30, -32},
|
|
|
|
{PPC::V29, -48},
|
|
|
|
{PPC::V28, -64},
|
|
|
|
{PPC::V27, -80},
|
|
|
|
{PPC::V26, -96},
|
|
|
|
{PPC::V25, -112},
|
|
|
|
{PPC::V24, -128},
|
|
|
|
{PPC::V23, -144},
|
|
|
|
{PPC::V22, -160},
|
|
|
|
{PPC::V21, -176},
|
|
|
|
{PPC::V20, -192}};
|
|
|
|
|
|
|
|
if (Subtarget.isPPC64()) {
|
|
|
|
NumEntries = array_lengthof(Offsets64);
|
|
|
|
|
|
|
|
return Offsets64;
|
|
|
|
} else {
|
|
|
|
NumEntries = array_lengthof(Offsets);
|
|
|
|
|
|
|
|
return Offsets;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
/// RemoveVRSaveCode - We have found that this function does not need any code
|
|
|
|
/// to manipulate the VRSAVE register, even though it uses vector registers.
|
|
|
|
/// This can happen when the only registers used are known to be live in or out
|
|
|
|
/// of the function. Remove all of the VRSAVE related code from the function.
|
2012-10-11 04:54:15 +08:00
|
|
|
/// FIXME: The removal of the code results in a compile failure at -O0 when the
|
|
|
|
/// function contains a function call, as the GPR containing original VRSAVE
|
|
|
|
/// contents is spilled and reloaded around the call. Without the prolog code,
|
|
|
|
/// the spill instruction refers to an undefined register. This code needs
|
|
|
|
/// to account for all uses of that GPR.
|
2010-11-15 08:06:54 +08:00
|
|
|
static void RemoveVRSaveCode(MachineInstr *MI) {
|
|
|
|
MachineBasicBlock *Entry = MI->getParent();
|
|
|
|
MachineFunction *MF = Entry->getParent();
|
|
|
|
|
|
|
|
// We know that the MTVRSAVE instruction immediately follows MI. Remove it.
|
|
|
|
MachineBasicBlock::iterator MBBI = MI;
|
|
|
|
++MBBI;
|
|
|
|
assert(MBBI != Entry->end() && MBBI->getOpcode() == PPC::MTVRSAVE);
|
|
|
|
MBBI->eraseFromParent();
|
|
|
|
|
|
|
|
bool RemovedAllMTVRSAVEs = true;
|
|
|
|
// See if we can find and remove the MTVRSAVE instruction from all of the
|
|
|
|
// epilog blocks.
|
|
|
|
for (MachineFunction::iterator I = MF->begin(), E = MF->end(); I != E; ++I) {
|
|
|
|
// If last instruction is a return instruction, add an epilogue
|
2011-12-07 15:15:52 +08:00
|
|
|
if (!I->empty() && I->back().isReturn()) {
|
2010-11-15 08:06:54 +08:00
|
|
|
bool FoundIt = false;
|
|
|
|
for (MBBI = I->end(); MBBI != I->begin(); ) {
|
|
|
|
--MBBI;
|
|
|
|
if (MBBI->getOpcode() == PPC::MTVRSAVE) {
|
|
|
|
MBBI->eraseFromParent(); // remove it.
|
|
|
|
FoundIt = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
RemovedAllMTVRSAVEs &= FoundIt;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we found and removed all MTVRSAVE instructions, remove the read of
|
|
|
|
// VRSAVE as well.
|
|
|
|
if (RemovedAllMTVRSAVEs) {
|
|
|
|
MBBI = MI;
|
|
|
|
assert(MBBI != Entry->begin() && "UPDATE_VRSAVE is first instr in block?");
|
|
|
|
--MBBI;
|
|
|
|
assert(MBBI->getOpcode() == PPC::MFVRSAVE && "VRSAVE instrs wandered?");
|
|
|
|
MBBI->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, nuke the UPDATE_VRSAVE.
|
|
|
|
MI->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
// HandleVRSaveUpdate - MI is the UPDATE_VRSAVE instruction introduced by the
|
|
|
|
// instruction selector. Based on the vector registers that have been used,
|
|
|
|
// transform this into the appropriate ORI instruction.
|
|
|
|
static void HandleVRSaveUpdate(MachineInstr *MI, const TargetInstrInfo &TII) {
|
|
|
|
MachineFunction *MF = MI->getParent()->getParent();
|
2014-08-05 10:39:49 +08:00
|
|
|
const TargetRegisterInfo *TRI = MF->getSubtarget().getRegisterInfo();
|
2010-11-15 08:06:54 +08:00
|
|
|
DebugLoc dl = MI->getDebugLoc();
|
|
|
|
|
|
|
|
unsigned UsedRegMask = 0;
|
|
|
|
for (unsigned i = 0; i != 32; ++i)
|
|
|
|
if (MF->getRegInfo().isPhysRegUsed(VRRegNo[i]))
|
|
|
|
UsedRegMask |= 1 << (31-i);
|
|
|
|
|
|
|
|
// Live in and live out values already must be in the mask, so don't bother
|
|
|
|
// marking them.
|
|
|
|
for (MachineRegisterInfo::livein_iterator
|
|
|
|
I = MF->getRegInfo().livein_begin(),
|
|
|
|
E = MF->getRegInfo().livein_end(); I != E; ++I) {
|
2013-03-27 04:08:20 +08:00
|
|
|
unsigned RegNo = TRI->getEncodingValue(I->first);
|
2010-11-15 08:06:54 +08:00
|
|
|
if (VRRegNo[RegNo] == I->first) // If this really is a vector reg.
|
|
|
|
UsedRegMask &= ~(1 << (31-RegNo)); // Doesn't need to be marked.
|
|
|
|
}
|
2013-02-06 01:40:36 +08:00
|
|
|
|
|
|
|
// Live out registers appear as use operands on return instructions.
|
|
|
|
for (MachineFunction::const_iterator BI = MF->begin(), BE = MF->end();
|
|
|
|
UsedRegMask != 0 && BI != BE; ++BI) {
|
|
|
|
const MachineBasicBlock &MBB = *BI;
|
|
|
|
if (MBB.empty() || !MBB.back().isReturn())
|
|
|
|
continue;
|
|
|
|
const MachineInstr &Ret = MBB.back();
|
|
|
|
for (unsigned I = 0, E = Ret.getNumOperands(); I != E; ++I) {
|
|
|
|
const MachineOperand &MO = Ret.getOperand(I);
|
|
|
|
if (!MO.isReg() || !PPC::VRRCRegClass.contains(MO.getReg()))
|
|
|
|
continue;
|
2013-03-27 04:08:20 +08:00
|
|
|
unsigned RegNo = TRI->getEncodingValue(MO.getReg());
|
2013-02-06 01:40:36 +08:00
|
|
|
UsedRegMask &= ~(1 << (31-RegNo));
|
|
|
|
}
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// If no registers are used, turn this into a copy.
|
|
|
|
if (UsedRegMask == 0) {
|
|
|
|
// Remove all VRSAVE code.
|
|
|
|
RemoveVRSaveCode(MI);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned SrcReg = MI->getOperand(1).getReg();
|
|
|
|
unsigned DstReg = MI->getOperand(0).getReg();
|
|
|
|
|
|
|
|
if ((UsedRegMask & 0xFFFF) == UsedRegMask) {
|
|
|
|
if (DstReg != SrcReg)
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORI), DstReg)
|
|
|
|
.addReg(SrcReg)
|
|
|
|
.addImm(UsedRegMask);
|
|
|
|
else
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORI), DstReg)
|
|
|
|
.addReg(SrcReg, RegState::Kill)
|
|
|
|
.addImm(UsedRegMask);
|
|
|
|
} else if ((UsedRegMask & 0xFFFF0000) == UsedRegMask) {
|
|
|
|
if (DstReg != SrcReg)
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORIS), DstReg)
|
|
|
|
.addReg(SrcReg)
|
|
|
|
.addImm(UsedRegMask >> 16);
|
|
|
|
else
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORIS), DstReg)
|
|
|
|
.addReg(SrcReg, RegState::Kill)
|
|
|
|
.addImm(UsedRegMask >> 16);
|
|
|
|
} else {
|
|
|
|
if (DstReg != SrcReg)
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORIS), DstReg)
|
|
|
|
.addReg(SrcReg)
|
|
|
|
.addImm(UsedRegMask >> 16);
|
|
|
|
else
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORIS), DstReg)
|
|
|
|
.addReg(SrcReg, RegState::Kill)
|
|
|
|
.addImm(UsedRegMask >> 16);
|
|
|
|
|
|
|
|
BuildMI(*MI->getParent(), MI, dl, TII.get(PPC::ORI), DstReg)
|
|
|
|
.addReg(DstReg, RegState::Kill)
|
|
|
|
.addImm(UsedRegMask & 0xFFFF);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Remove the old UPDATE_VRSAVE instruction.
|
|
|
|
MI->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
static bool spillsCR(const MachineFunction &MF) {
|
|
|
|
const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
return FuncInfo->isCRSpilled();
|
|
|
|
}
|
|
|
|
|
2013-03-24 06:06:03 +08:00
|
|
|
static bool spillsVRSAVE(const MachineFunction &MF) {
|
|
|
|
const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
return FuncInfo->isVRSAVESpilled();
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:06:04 +08:00
|
|
|
static bool hasSpills(const MachineFunction &MF) {
|
|
|
|
const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
return FuncInfo->hasSpills();
|
|
|
|
}
|
|
|
|
|
2013-03-17 12:43:44 +08:00
|
|
|
static bool hasNonRISpills(const MachineFunction &MF) {
|
|
|
|
const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
return FuncInfo->hasNonRISpills();
|
|
|
|
}
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
/// determineFrameLayout - Determine the size of the frame and maximum call
|
|
|
|
/// frame size.
|
2013-03-15 13:06:04 +08:00
|
|
|
unsigned PPCFrameLowering::determineFrameLayout(MachineFunction &MF,
|
|
|
|
bool UpdateMF,
|
|
|
|
bool UseEstimate) const {
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
|
|
|
|
// Get the number of bytes to allocate from the FrameInfo
|
2013-03-15 13:06:04 +08:00
|
|
|
unsigned FrameSize =
|
|
|
|
UseEstimate ? MFI->estimateStackSize(MF) : MFI->getStackSize();
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Get stack alignments. The frame must be aligned to the greatest of these:
|
|
|
|
unsigned TargetAlign = getStackAlignment(); // alignment required per the ABI
|
|
|
|
unsigned MaxAlign = MFI->getMaxAlignment(); // algmt required by data in frame
|
2013-07-17 08:45:52 +08:00
|
|
|
unsigned AlignMask = std::max(MaxAlign, TargetAlign) - 1;
|
|
|
|
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
// If we are a leaf function, and use up to 224 bytes of stack space,
|
|
|
|
// don't have a frame pointer, calls, or dynamic alloca then we do not need
|
2013-04-15 10:07:05 +08:00
|
|
|
// to adjust the stack pointer (we fit in the Red Zone).
|
2013-02-27 05:28:57 +08:00
|
|
|
// The 32-bit SVR4 ABI has no Red Zone. However, it can still generate
|
|
|
|
// stackless code if all local vars are reg-allocated.
|
2012-12-30 18:32:01 +08:00
|
|
|
bool DisableRedZone = MF.getFunction()->getAttributes().
|
|
|
|
hasAttribute(AttributeSet::FunctionIndex, Attribute::NoRedZone);
|
2010-11-15 08:06:54 +08:00
|
|
|
if (!DisableRedZone &&
|
2013-02-27 05:28:57 +08:00
|
|
|
(Subtarget.isPPC64() || // 32-bit SVR4, no stack-
|
|
|
|
!Subtarget.isSVR4ABI() || // allocated locals.
|
2014-04-29 08:16:40 +08:00
|
|
|
FrameSize == 0) &&
|
2010-11-15 08:06:54 +08:00
|
|
|
FrameSize <= 224 && // Fits in red zone.
|
|
|
|
!MFI->hasVarSizedObjects() && // No dynamic alloca.
|
|
|
|
!MFI->adjustsStack() && // No calls.
|
2013-07-17 08:45:52 +08:00
|
|
|
!RegInfo->hasBasePointer(MF)) { // No special alignment.
|
2010-11-15 08:06:54 +08:00
|
|
|
// No need for frame
|
2013-03-15 13:06:04 +08:00
|
|
|
if (UpdateMF)
|
|
|
|
MFI->setStackSize(0);
|
|
|
|
return 0;
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Get the maximum call frame size of all the calls.
|
|
|
|
unsigned maxCallFrameSize = MFI->getMaxCallFrameSize();
|
|
|
|
|
2014-06-23 21:47:52 +08:00
|
|
|
// Maximum call frame needs to be at least big enough for linkage area.
|
|
|
|
unsigned minCallFrameSize = getLinkageSize(Subtarget.isPPC64(),
|
[PowerPC] ELFv2 stack space reduction
The ELFv2 ABI reduces the amount of stack required to implement an
ABI-compliant function call in two ways:
* the "linkage area" is reduced from 48 bytes to 32 bytes by
eliminating two unused doublewords
* the 64-byte "parameter save area" is now optional and need not be
present in certain cases (it remains mandatory in functions with
variable arguments, and functions that have any parameter that is
passed on the stack)
The following patch implements this required changes:
- reducing the linkage area, and associated relocation of the TOC save
slot, in getLinkageSize / getTOCSaveOffset (this requires updating all
callers of these routines to pass in the isELFv2ABI flag).
- (partially) handling the case where the parameter save are is optional
This latter part requires some extra explanation: Currently, we still
always allocate the parameter save area when *calling* a function.
That is certainly always compliant with the ABI, but may cause code to
allocate stack unnecessarily. This can be addressed by a follow-on
optimization patch.
On the *callee* side, in LowerFormalArguments, we *must* track
correctly whether the ABI guarantees that the caller has allocated
the parameter save area for our use, and the patch does so. However,
there is one complication: the code that handles incoming "byval"
arguments will currently *always* write to the parameter save area,
because it has to force incoming register arguments to the stack since
it must return an *address* to implement the byval semantics.
To fix this, the patch changes the LowerFormalArguments code to write
arguments to a freshly allocated stack slot on the function's own stack
frame instead of the argument save area in those cases where that area
is not present.
Reviewed by Hal Finkel.
llvm-svn: 213490
2014-07-21 07:43:15 +08:00
|
|
|
Subtarget.isDarwinABI(),
|
|
|
|
Subtarget.isELFv2ABI());
|
2010-11-15 08:06:54 +08:00
|
|
|
maxCallFrameSize = std::max(maxCallFrameSize, minCallFrameSize);
|
|
|
|
|
|
|
|
// If we have dynamic alloca then maxCallFrameSize needs to be aligned so
|
|
|
|
// that allocations will be aligned.
|
|
|
|
if (MFI->hasVarSizedObjects())
|
|
|
|
maxCallFrameSize = (maxCallFrameSize + AlignMask) & ~AlignMask;
|
|
|
|
|
|
|
|
// Update maximum call frame size.
|
2013-03-15 13:06:04 +08:00
|
|
|
if (UpdateMF)
|
|
|
|
MFI->setMaxCallFrameSize(maxCallFrameSize);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
// Include call frame size in total.
|
|
|
|
FrameSize += maxCallFrameSize;
|
|
|
|
|
|
|
|
// Make sure the frame is aligned.
|
|
|
|
FrameSize = (FrameSize + AlignMask) & ~AlignMask;
|
|
|
|
|
|
|
|
// Update frame info.
|
2013-03-15 13:06:04 +08:00
|
|
|
if (UpdateMF)
|
|
|
|
MFI->setStackSize(FrameSize);
|
|
|
|
|
|
|
|
return FrameSize;
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
2010-11-19 05:19:35 +08:00
|
|
|
// hasFP - Return true if the specified function actually has a dedicated frame
|
|
|
|
// pointer register.
|
2011-01-10 20:39:04 +08:00
|
|
|
bool PPCFrameLowering::hasFP(const MachineFunction &MF) const {
|
2010-11-19 05:19:35 +08:00
|
|
|
const MachineFrameInfo *MFI = MF.getFrameInfo();
|
2010-12-19 03:53:14 +08:00
|
|
|
// FIXME: This is pretty much broken by design: hasFP() might be called really
|
|
|
|
// early, before the stack layout was calculated and thus hasFP() might return
|
|
|
|
// true or false here depending on the time of call.
|
|
|
|
return (MFI->getStackSize()) && needsFP(MF);
|
|
|
|
}
|
|
|
|
|
|
|
|
// needsFP - Return true if the specified function should have a dedicated frame
|
|
|
|
// pointer register. This is true if the function has variable sized allocas or
|
|
|
|
// if frame pointer elimination is disabled.
|
2011-01-10 20:39:04 +08:00
|
|
|
bool PPCFrameLowering::needsFP(const MachineFunction &MF) const {
|
2010-12-19 03:53:14 +08:00
|
|
|
const MachineFrameInfo *MFI = MF.getFrameInfo();
|
2010-11-19 05:19:35 +08:00
|
|
|
|
|
|
|
// Naked functions have no stack frame pushed, so we don't have a frame
|
|
|
|
// pointer.
|
2014-04-29 08:16:40 +08:00
|
|
|
if (MF.getFunction()->getAttributes().hasAttribute(
|
|
|
|
AttributeSet::FunctionIndex, Attribute::Naked))
|
2010-11-19 05:19:35 +08:00
|
|
|
return false;
|
|
|
|
|
2011-12-03 06:16:29 +08:00
|
|
|
return MF.getTarget().Options.DisableFramePointerElim(MF) ||
|
|
|
|
MFI->hasVarSizedObjects() ||
|
Revert "r225811 - Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support""
This re-applies r225808, fixed to avoid problems with SDAG dependencies along
with the preceding fix to ScheduleDAGSDNodes::RegDefIter::InitNodeNumDefs.
These problems caused the original regression tests to assert/segfault on many
(but not all) systems.
Original commit message:
This commit does two things:
1. Refactors PPCFastISel to use more of the common infrastructure for call
lowering (this lets us take advantage of this common code for lowering some
common intrinsics, stackmap/patchpoint among them).
2. Adds support for stackmap/patchpoint lowering. For the most part, this is
very similar to the support in the AArch64 target, with the obvious differences
(different registers, NOP instructions, etc.). The test cases are adapted
from the AArch64 test cases.
One difference of note is that the patchpoint call sequence takes 24 bytes, so
you can't use less than that (on AArch64 you can go down to 16). Also, as noted
in the docs, we take the patchpoint address to be the actual code address
(assuming the call is local in the TOC-sharing sense), which should yield
higher performance than generating the full cross-DSO indirect-call sequence
and is likely just as useful for JITed code (if not, we'll change it).
StackMaps and Patchpoints are still marked as experimental, and so this support
is doubly experimental. So go ahead and experiment!
llvm-svn: 225909
2015-01-14 09:07:51 +08:00
|
|
|
MFI->hasStackMap() || MFI->hasPatchPoint() ||
|
2011-12-03 06:16:29 +08:00
|
|
|
(MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
MF.getInfo<PPCFunctionInfo>()->hasFastCall());
|
2010-11-19 05:19:35 +08:00
|
|
|
}
|
|
|
|
|
2013-03-22 03:03:19 +08:00
|
|
|
void PPCFrameLowering::replaceFPWithRealFP(MachineFunction &MF) const {
|
|
|
|
bool is31 = needsFP(MF);
|
|
|
|
unsigned FPReg = is31 ? PPC::R31 : PPC::R1;
|
|
|
|
unsigned FP8Reg = is31 ? PPC::X31 : PPC::X1;
|
|
|
|
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2013-07-18 07:50:51 +08:00
|
|
|
bool HasBP = RegInfo->hasBasePointer(MF);
|
2014-07-19 07:29:49 +08:00
|
|
|
unsigned BPReg = HasBP ? (unsigned) RegInfo->getBaseRegister(MF) : FPReg;
|
2013-07-18 07:50:51 +08:00
|
|
|
unsigned BP8Reg = HasBP ? (unsigned) PPC::X30 : FPReg;
|
|
|
|
|
2013-03-22 03:03:19 +08:00
|
|
|
for (MachineFunction::iterator BI = MF.begin(), BE = MF.end();
|
|
|
|
BI != BE; ++BI)
|
|
|
|
for (MachineBasicBlock::iterator MBBI = BI->end(); MBBI != BI->begin(); ) {
|
|
|
|
--MBBI;
|
|
|
|
for (unsigned I = 0, E = MBBI->getNumOperands(); I != E; ++I) {
|
|
|
|
MachineOperand &MO = MBBI->getOperand(I);
|
|
|
|
if (!MO.isReg())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
switch (MO.getReg()) {
|
|
|
|
case PPC::FP:
|
|
|
|
MO.setReg(FPReg);
|
|
|
|
break;
|
|
|
|
case PPC::FP8:
|
|
|
|
MO.setReg(FP8Reg);
|
|
|
|
break;
|
2013-07-18 07:50:51 +08:00
|
|
|
case PPC::BP:
|
|
|
|
MO.setReg(BPReg);
|
|
|
|
break;
|
|
|
|
case PPC::BP8:
|
|
|
|
MO.setReg(BP8Reg);
|
|
|
|
break;
|
|
|
|
|
2013-03-22 03:03:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-11-19 05:19:35 +08:00
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
void PPCFrameLowering::emitPrologue(MachineFunction &MF) const {
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineBasicBlock &MBB = MF.front(); // Prolog goes in entry BB
|
|
|
|
MachineBasicBlock::iterator MBBI = MBB.begin();
|
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
MachineModuleInfo &MMI = MF.getMMI();
|
2013-06-18 15:20:20 +08:00
|
|
|
const MCRegisterInfo *MRI = MMI.getContext().getRegisterInfo();
|
2010-11-15 08:06:54 +08:00
|
|
|
DebugLoc dl;
|
2014-12-01 17:42:32 +08:00
|
|
|
bool needsCFI = MMI.hasDebugInfo() ||
|
2011-05-25 11:44:17 +08:00
|
|
|
MF.getFunction()->needsUnwindTableEntry();
|
2014-07-19 07:29:49 +08:00
|
|
|
bool isPIC = MF.getTarget().getRelocationModel() == Reloc::PIC_;
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Get processor type.
|
|
|
|
bool isPPC64 = Subtarget.isPPC64();
|
|
|
|
// Get the ABI.
|
|
|
|
bool isDarwinABI = Subtarget.isDarwinABI();
|
|
|
|
bool isSVR4ABI = Subtarget.isSVR4ABI();
|
2014-07-21 08:03:18 +08:00
|
|
|
bool isELFv2ABI = Subtarget.isELFv2ABI();
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
assert((isDarwinABI || isSVR4ABI) &&
|
|
|
|
"Currently only Darwin and SVR4 ABIs are supported for PowerPC.");
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
// Scan the prolog, looking for an UPDATE_VRSAVE instruction. If we find it,
|
|
|
|
// process it.
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (!isSVR4ABI)
|
2012-10-11 04:54:15 +08:00
|
|
|
for (unsigned i = 0; MBBI != MBB.end(); ++i, ++MBBI) {
|
|
|
|
if (MBBI->getOpcode() == PPC::UPDATE_VRSAVE) {
|
|
|
|
HandleVRSaveUpdate(MBBI, TII);
|
|
|
|
break;
|
|
|
|
}
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Move MBBI back to the beginning of the function.
|
|
|
|
MBBI = MBB.begin();
|
|
|
|
|
|
|
|
// Work out frame sizes.
|
2013-03-15 13:06:04 +08:00
|
|
|
unsigned FrameSize = determineFrameLayout(MF);
|
2010-11-15 08:06:54 +08:00
|
|
|
int NegFrameSize = -FrameSize;
|
2013-07-17 08:45:52 +08:00
|
|
|
if (!isInt<32>(NegFrameSize))
|
|
|
|
llvm_unreachable("Unhandled stack size!");
|
2010-11-15 08:06:54 +08:00
|
|
|
|
2013-03-22 03:03:19 +08:00
|
|
|
if (MFI->isFrameAddressTaken())
|
|
|
|
replaceFPWithRealFP(MF);
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
// Check if the link register (LR) must be saved.
|
|
|
|
PPCFunctionInfo *FI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
bool MustSaveLR = FI->mustSaveLR();
|
2013-07-14 12:42:23 +08:00
|
|
|
const SmallVectorImpl<unsigned> &MustSaveCRs = FI->getMustSaveCRs();
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
// Do we have a frame pointer and/or base pointer for this function?
|
2010-12-19 03:53:14 +08:00
|
|
|
bool HasFP = hasFP(MF);
|
2013-07-17 08:45:52 +08:00
|
|
|
bool HasBP = RegInfo->hasBasePointer(MF);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned SPReg = isPPC64 ? PPC::X1 : PPC::R1;
|
2014-07-19 07:29:49 +08:00
|
|
|
unsigned BPReg = RegInfo->getBaseRegister(MF);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned FPReg = isPPC64 ? PPC::X31 : PPC::R31;
|
|
|
|
unsigned LRReg = isPPC64 ? PPC::LR8 : PPC::LR;
|
|
|
|
unsigned ScratchReg = isPPC64 ? PPC::X0 : PPC::R0;
|
|
|
|
unsigned TempReg = isPPC64 ? PPC::X12 : PPC::R12; // another scratch reg
|
|
|
|
// ...(R12/X12 is volatile in both Darwin & SVR4, & can't be a function arg.)
|
|
|
|
const MCInstrDesc& MFLRInst = TII.get(isPPC64 ? PPC::MFLR8
|
|
|
|
: PPC::MFLR );
|
|
|
|
const MCInstrDesc& StoreInst = TII.get(isPPC64 ? PPC::STD
|
|
|
|
: PPC::STW );
|
|
|
|
const MCInstrDesc& StoreUpdtInst = TII.get(isPPC64 ? PPC::STDU
|
|
|
|
: PPC::STWU );
|
|
|
|
const MCInstrDesc& StoreUpdtIdxInst = TII.get(isPPC64 ? PPC::STDUX
|
|
|
|
: PPC::STWUX);
|
|
|
|
const MCInstrDesc& LoadImmShiftedInst = TII.get(isPPC64 ? PPC::LIS8
|
|
|
|
: PPC::LIS );
|
|
|
|
const MCInstrDesc& OrImmInst = TII.get(isPPC64 ? PPC::ORI8
|
|
|
|
: PPC::ORI );
|
|
|
|
const MCInstrDesc& OrInst = TII.get(isPPC64 ? PPC::OR8
|
|
|
|
: PPC::OR );
|
|
|
|
const MCInstrDesc& SubtractCarryingInst = TII.get(isPPC64 ? PPC::SUBFC8
|
|
|
|
: PPC::SUBFC);
|
|
|
|
const MCInstrDesc& SubtractImmCarryingInst = TII.get(isPPC64 ? PPC::SUBFIC8
|
|
|
|
: PPC::SUBFIC);
|
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Regarding this assert: Even though LR is saved in the caller's frame (i.e.,
|
|
|
|
// LROffset is positive), that slot is callee-owned. Because PPC32 SVR4 has no
|
|
|
|
// Red Zone, an asynchronous event (a form of "callee") could claim a frame &
|
|
|
|
// overwrite it, so PPC32 SVR4 must claim at least a minimal frame to save LR.
|
|
|
|
assert((isPPC64 || !isSVR4ABI || !(!FrameSize && (MustSaveLR || HasFP))) &&
|
|
|
|
"FrameSize must be >0 to save/restore the FP or LR for 32-bit SVR4.");
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
int LROffset = PPCFrameLowering::getReturnSaveOffset(isPPC64, isDarwinABI);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
int FPOffset = 0;
|
|
|
|
if (HasFP) {
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI) {
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int FPIndex = FI->getFramePointerSaveIndex();
|
|
|
|
assert(FPIndex && "No Frame Pointer Save Slot!");
|
|
|
|
FPOffset = FFI->getObjectOffset(FPIndex);
|
|
|
|
} else {
|
2014-04-29 08:16:40 +08:00
|
|
|
FPOffset =
|
|
|
|
PPCFrameLowering::getFramePointerSaveOffset(isPPC64, isDarwinABI);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-17 08:45:52 +08:00
|
|
|
int BPOffset = 0;
|
|
|
|
if (HasBP) {
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI) {
|
2013-07-17 08:45:52 +08:00
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int BPIndex = FI->getBasePointerSaveIndex();
|
|
|
|
assert(BPIndex && "No Base Pointer Save Slot!");
|
|
|
|
BPOffset = FFI->getObjectOffset(BPIndex);
|
|
|
|
} else {
|
|
|
|
BPOffset =
|
2014-07-19 07:29:49 +08:00
|
|
|
PPCFrameLowering::getBasePointerSaveOffset(isPPC64,
|
|
|
|
isDarwinABI,
|
|
|
|
isPIC);
|
2013-07-17 08:45:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
int PBPOffset = 0;
|
|
|
|
if (FI->usesPICBase()) {
|
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int PBPIndex = FI->getPICBasePointerSaveIndex();
|
|
|
|
assert(PBPIndex && "No PIC Base Pointer Save Slot!");
|
|
|
|
PBPOffset = FFI->getObjectOffset(PBPIndex);
|
|
|
|
}
|
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Get stack alignments.
|
|
|
|
unsigned MaxAlign = MFI->getMaxAlignment();
|
|
|
|
if (HasBP && MaxAlign > 1)
|
|
|
|
assert(isPowerOf2_32(MaxAlign) && isInt<16>(MaxAlign) &&
|
|
|
|
"Invalid alignment!");
|
|
|
|
|
|
|
|
// Frames of 32KB & larger require special handling because they cannot be
|
|
|
|
// indexed into with a simple STDU/STWU/STD/STW immediate offset operand.
|
|
|
|
bool isLargeFrame = !isInt<16>(NegFrameSize);
|
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (MustSaveLR)
|
|
|
|
BuildMI(MBB, MBBI, dl, MFLRInst, ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
assert((isPPC64 || MustSaveCRs.empty()) &&
|
|
|
|
"Prologue CR saving supported only in 64-bit mode");
|
2013-04-15 10:07:05 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (!MustSaveCRs.empty()) { // will only occur for PPC64
|
2014-07-21 08:03:18 +08:00
|
|
|
// FIXME: In the ELFv2 ABI, we are not required to save all CR fields.
|
|
|
|
// If only one or two CR fields are clobbered, it could be more
|
|
|
|
// efficient to use mfocrf to selectively save just those fields.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
MachineInstrBuilder MIB =
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::MFCR8), TempReg);
|
|
|
|
for (unsigned i = 0, e = MustSaveCRs.size(); i != e; ++i)
|
|
|
|
MIB.addReg(MustSaveCRs[i], RegState::ImplicitKill);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (HasFP)
|
|
|
|
// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreInst)
|
|
|
|
.addReg(FPReg)
|
|
|
|
.addImm(FPOffset)
|
|
|
|
.addReg(SPReg);
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
if (FI->usesPICBase())
|
2015-01-08 23:47:19 +08:00
|
|
|
// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreInst)
|
|
|
|
.addReg(PPC::R30)
|
2015-01-10 09:57:21 +08:00
|
|
|
.addImm(PBPOffset)
|
2015-01-08 23:47:19 +08:00
|
|
|
.addReg(SPReg);
|
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (HasBP)
|
|
|
|
// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreInst)
|
|
|
|
.addReg(BPReg)
|
|
|
|
.addImm(BPOffset)
|
|
|
|
.addReg(SPReg);
|
|
|
|
|
|
|
|
if (MustSaveLR)
|
|
|
|
// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreInst)
|
|
|
|
.addReg(ScratchReg)
|
|
|
|
.addImm(LROffset)
|
|
|
|
.addReg(SPReg);
|
|
|
|
|
|
|
|
if (!MustSaveCRs.empty()) // will only occur for PPC64
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::STW8))
|
|
|
|
.addReg(TempReg, getKillRegState(true))
|
|
|
|
.addImm(8)
|
|
|
|
.addReg(SPReg);
|
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Skip the rest if this is a leaf function & all spills fit in the Red Zone.
|
2010-11-15 08:06:54 +08:00
|
|
|
if (!FrameSize) return;
|
|
|
|
|
|
|
|
// Adjust stack pointer: r1 += NegFrameSize.
|
|
|
|
// If there is a preferred stack alignment, align R1 now
|
2013-07-17 08:45:52 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (HasBP) {
|
|
|
|
// Save a copy of r1 as the base pointer.
|
|
|
|
BuildMI(MBB, MBBI, dl, OrInst, BPReg)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addReg(SPReg);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (HasBP && MaxAlign > 1) {
|
|
|
|
if (isPPC64)
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::RLDICL), ScratchReg)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addImm(0)
|
|
|
|
.addImm(64 - Log2_32(MaxAlign));
|
|
|
|
else // PPC32...
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::RLWINM), ScratchReg)
|
|
|
|
.addReg(SPReg)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(0)
|
|
|
|
.addImm(32 - Log2_32(MaxAlign))
|
|
|
|
.addImm(31);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (!isLargeFrame) {
|
|
|
|
BuildMI(MBB, MBBI, dl, SubtractImmCarryingInst, ScratchReg)
|
|
|
|
.addReg(ScratchReg, RegState::Kill)
|
|
|
|
.addImm(NegFrameSize);
|
2010-11-15 08:06:54 +08:00
|
|
|
} else {
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, LoadImmShiftedInst, TempReg)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(NegFrameSize >> 16);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, OrImmInst, TempReg)
|
|
|
|
.addReg(TempReg, RegState::Kill)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(NegFrameSize & 0xFFFF);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, SubtractCarryingInst, ScratchReg)
|
|
|
|
.addReg(ScratchReg, RegState::Kill)
|
|
|
|
.addReg(TempReg, RegState::Kill);
|
2013-07-17 08:45:52 +08:00
|
|
|
}
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, StoreUpdtIdxInst, SPReg)
|
|
|
|
.addReg(SPReg, RegState::Kill)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addReg(ScratchReg);
|
2013-07-17 08:45:52 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
} else if (!isLargeFrame) {
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreUpdtInst, SPReg)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addImm(NegFrameSize)
|
|
|
|
.addReg(SPReg);
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
} else {
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadImmShiftedInst, ScratchReg)
|
|
|
|
.addImm(NegFrameSize >> 16);
|
|
|
|
BuildMI(MBB, MBBI, dl, OrImmInst, ScratchReg)
|
|
|
|
.addReg(ScratchReg, RegState::Kill)
|
|
|
|
.addImm(NegFrameSize & 0xFFFF);
|
|
|
|
BuildMI(MBB, MBBI, dl, StoreUpdtIdxInst, SPReg)
|
|
|
|
.addReg(SPReg, RegState::Kill)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addReg(ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
2014-12-01 17:42:32 +08:00
|
|
|
// Add Call Frame Information for the instructions we generated above.
|
|
|
|
if (needsCFI) {
|
|
|
|
unsigned CFIIndex;
|
|
|
|
|
|
|
|
if (HasBP) {
|
|
|
|
// Define CFA in terms of BP. Do this in preference to using FP/SP,
|
|
|
|
// because if the stack needed aligning then CFA won't be at a fixed
|
|
|
|
// offset from FP/SP.
|
|
|
|
unsigned Reg = MRI->getDwarfRegNum(BPReg, true);
|
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createDefCfaRegister(nullptr, Reg));
|
|
|
|
} else {
|
|
|
|
// Adjust the definition of CFA to account for the change in SP.
|
|
|
|
assert(NegFrameSize);
|
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createDefCfaOffset(nullptr, NegFrameSize));
|
|
|
|
}
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
|
|
|
.addCFIIndex(CFIIndex);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
if (HasFP) {
|
2014-12-01 17:42:32 +08:00
|
|
|
// Describe where FP was saved, at a fixed offset from CFA.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned Reg = MRI->getDwarfRegNum(FPReg, true);
|
2014-03-07 14:08:31 +08:00
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createOffset(nullptr, Reg, FPOffset));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
if (FI->usesPICBase()) {
|
|
|
|
// Describe where FP was saved, at a fixed offset from CFA.
|
|
|
|
unsigned Reg = MRI->getDwarfRegNum(PPC::R30, true);
|
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createOffset(nullptr, Reg, PBPOffset));
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
|
|
|
.addCFIIndex(CFIIndex);
|
|
|
|
}
|
|
|
|
|
2013-07-17 08:45:52 +08:00
|
|
|
if (HasBP) {
|
2014-12-01 17:42:32 +08:00
|
|
|
// Describe where BP was saved, at a fixed offset from CFA.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned Reg = MRI->getDwarfRegNum(BPReg, true);
|
2014-03-07 14:08:31 +08:00
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createOffset(nullptr, Reg, BPOffset));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
2013-07-17 08:45:52 +08:00
|
|
|
}
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
if (MustSaveLR) {
|
2014-12-01 17:42:32 +08:00
|
|
|
// Describe where LR was saved, at a fixed offset from CFA.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned Reg = MRI->getDwarfRegNum(LRReg, true);
|
2014-03-07 14:08:31 +08:00
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createOffset(nullptr, Reg, LROffset));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there is a frame pointer, copy R1 into R31
|
|
|
|
if (HasFP) {
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, OrInst, FPReg)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addReg(SPReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
2014-12-01 17:42:32 +08:00
|
|
|
if (!HasBP && needsCFI) {
|
|
|
|
// Change the definition of CFA from SP+offset to FP+offset, because SP
|
|
|
|
// will change at every alloca.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned Reg = MRI->getDwarfRegNum(FPReg, true);
|
2014-03-07 14:08:31 +08:00
|
|
|
unsigned CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createDefCfaRegister(nullptr, Reg));
|
|
|
|
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-01 17:42:32 +08:00
|
|
|
if (needsCFI) {
|
|
|
|
// Describe where callee saved registers were saved, at fixed offsets from
|
|
|
|
// CFA.
|
2010-11-15 08:06:54 +08:00
|
|
|
const std::vector<CalleeSavedInfo> &CSI = MFI->getCalleeSavedInfo();
|
|
|
|
for (unsigned I = 0, E = CSI.size(); I != E; ++I) {
|
|
|
|
unsigned Reg = CSI[I].getReg();
|
|
|
|
if (Reg == PPC::LR || Reg == PPC::LR8 || Reg == PPC::RM) continue;
|
2011-05-31 04:20:15 +08:00
|
|
|
|
|
|
|
// This is a bit of a hack: CR2LT, CR2GT, CR2EQ and CR2UN are just
|
|
|
|
// subregisters of CR2. We just need to emit a move of CR2.
|
2012-04-20 14:31:50 +08:00
|
|
|
if (PPC::CRBITRCRegClass.contains(Reg))
|
2011-05-31 04:20:15 +08:00
|
|
|
continue;
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
// For SVR4, don't emit a move for the CR spill slot if we haven't
|
|
|
|
// spilled CRs.
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4)
|
|
|
|
&& MustSaveCRs.empty())
|
|
|
|
continue;
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
// For 64-bit SVR4 when we have spilled CRs, the spill location
|
|
|
|
// is SP+8, not a frame-relative slot.
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI && isPPC64 && (PPC::CR2 <= Reg && Reg <= PPC::CR4)) {
|
2014-07-21 08:03:18 +08:00
|
|
|
// In the ELFv1 ABI, only CR2 is noted in CFI and stands in for
|
|
|
|
// the whole CR word. In the ELFv2 ABI, every CR that was
|
|
|
|
// actually saved gets its own CFI record.
|
|
|
|
unsigned CRReg = isELFv2ABI? Reg : (unsigned) PPC::CR2;
|
2014-03-07 14:08:31 +08:00
|
|
|
unsigned CFIIndex = MMI.addFrameInst(MCCFIInstruction::createOffset(
|
2014-07-21 08:03:18 +08:00
|
|
|
nullptr, MRI->getDwarfRegNum(CRReg, true), 8));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
continue;
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int Offset = MFI->getObjectOffset(CSI[I].getFrameIdx());
|
2014-03-07 14:08:31 +08:00
|
|
|
unsigned CFIIndex = MMI.addFrameInst(MCCFIInstruction::createOffset(
|
|
|
|
nullptr, MRI->getDwarfRegNum(Reg, true), Offset));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
2014-03-07 14:08:31 +08:00
|
|
|
.addCFIIndex(CFIIndex);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
void PPCFrameLowering::emitEpilogue(MachineFunction &MF,
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineBasicBlock &MBB) const {
|
2011-01-14 05:28:52 +08:00
|
|
|
MachineBasicBlock::iterator MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
assert(MBBI != MBB.end() && "Returning block has no terminator");
|
2010-11-15 08:06:54 +08:00
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
unsigned RetOpcode = MBBI->getOpcode();
|
|
|
|
DebugLoc dl;
|
|
|
|
|
2010-11-19 05:19:35 +08:00
|
|
|
assert((RetOpcode == PPC::BLR ||
|
2015-01-14 01:47:54 +08:00
|
|
|
RetOpcode == PPC::BLR8 ||
|
2010-11-19 05:19:35 +08:00
|
|
|
RetOpcode == PPC::TCRETURNri ||
|
|
|
|
RetOpcode == PPC::TCRETURNdi ||
|
|
|
|
RetOpcode == PPC::TCRETURNai ||
|
|
|
|
RetOpcode == PPC::TCRETURNri8 ||
|
|
|
|
RetOpcode == PPC::TCRETURNdi8 ||
|
|
|
|
RetOpcode == PPC::TCRETURNai8) &&
|
2010-11-15 08:06:54 +08:00
|
|
|
"Can only insert epilog into returning blocks");
|
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Get alignment info so we know how to restore the SP.
|
2010-11-15 08:06:54 +08:00
|
|
|
const MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
|
|
|
|
// Get the number of bytes allocated from the FrameInfo.
|
|
|
|
int FrameSize = MFI->getStackSize();
|
|
|
|
|
|
|
|
// Get processor type.
|
|
|
|
bool isPPC64 = Subtarget.isPPC64();
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Get the ABI.
|
2010-11-15 08:06:54 +08:00
|
|
|
bool isDarwinABI = Subtarget.isDarwinABI();
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
bool isSVR4ABI = Subtarget.isSVR4ABI();
|
2014-07-19 07:29:49 +08:00
|
|
|
bool isPIC = MF.getTarget().getRelocationModel() == Reloc::PIC_;
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
// Check if the link register (LR) has been saved.
|
|
|
|
PPCFunctionInfo *FI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
bool MustSaveLR = FI->mustSaveLR();
|
2013-07-14 12:42:23 +08:00
|
|
|
const SmallVectorImpl<unsigned> &MustSaveCRs = FI->getMustSaveCRs();
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
// Do we have a frame pointer and/or base pointer for this function?
|
2010-12-19 03:53:14 +08:00
|
|
|
bool HasFP = hasFP(MF);
|
2013-07-17 08:45:52 +08:00
|
|
|
bool HasBP = RegInfo->hasBasePointer(MF);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned SPReg = isPPC64 ? PPC::X1 : PPC::R1;
|
2014-07-19 07:29:49 +08:00
|
|
|
unsigned BPReg = RegInfo->getBaseRegister(MF);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
unsigned FPReg = isPPC64 ? PPC::X31 : PPC::R31;
|
|
|
|
unsigned ScratchReg = isPPC64 ? PPC::X0 : PPC::R0;
|
|
|
|
unsigned TempReg = isPPC64 ? PPC::X12 : PPC::R12; // another scratch reg
|
|
|
|
const MCInstrDesc& MTLRInst = TII.get( isPPC64 ? PPC::MTLR8
|
|
|
|
: PPC::MTLR );
|
|
|
|
const MCInstrDesc& LoadInst = TII.get( isPPC64 ? PPC::LD
|
|
|
|
: PPC::LWZ );
|
|
|
|
const MCInstrDesc& LoadImmShiftedInst = TII.get( isPPC64 ? PPC::LIS8
|
|
|
|
: PPC::LIS );
|
|
|
|
const MCInstrDesc& OrImmInst = TII.get( isPPC64 ? PPC::ORI8
|
|
|
|
: PPC::ORI );
|
|
|
|
const MCInstrDesc& AddImmInst = TII.get( isPPC64 ? PPC::ADDI8
|
|
|
|
: PPC::ADDI );
|
|
|
|
const MCInstrDesc& AddInst = TII.get( isPPC64 ? PPC::ADD8
|
|
|
|
: PPC::ADD4 );
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
int LROffset = PPCFrameLowering::getReturnSaveOffset(isPPC64, isDarwinABI);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
int FPOffset = 0;
|
|
|
|
if (HasFP) {
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI) {
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int FPIndex = FI->getFramePointerSaveIndex();
|
|
|
|
assert(FPIndex && "No Frame Pointer Save Slot!");
|
|
|
|
FPOffset = FFI->getObjectOffset(FPIndex);
|
|
|
|
} else {
|
2014-04-29 08:16:40 +08:00
|
|
|
FPOffset =
|
|
|
|
PPCFrameLowering::getFramePointerSaveOffset(isPPC64, isDarwinABI);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-17 08:45:52 +08:00
|
|
|
int BPOffset = 0;
|
|
|
|
if (HasBP) {
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
if (isSVR4ABI) {
|
2013-07-17 08:45:52 +08:00
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int BPIndex = FI->getBasePointerSaveIndex();
|
|
|
|
assert(BPIndex && "No Base Pointer Save Slot!");
|
|
|
|
BPOffset = FFI->getObjectOffset(BPIndex);
|
|
|
|
} else {
|
|
|
|
BPOffset =
|
2014-07-19 07:29:49 +08:00
|
|
|
PPCFrameLowering::getBasePointerSaveOffset(isPPC64,
|
|
|
|
isDarwinABI,
|
|
|
|
isPIC);
|
2013-07-17 08:45:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
int PBPOffset = 0;
|
|
|
|
if (FI->usesPICBase()) {
|
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
int PBPIndex = FI->getPICBasePointerSaveIndex();
|
|
|
|
assert(PBPIndex && "No PIC Base Pointer Save Slot!");
|
|
|
|
PBPOffset = FFI->getObjectOffset(PBPIndex);
|
|
|
|
}
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
bool UsesTCRet = RetOpcode == PPC::TCRETURNri ||
|
|
|
|
RetOpcode == PPC::TCRETURNdi ||
|
|
|
|
RetOpcode == PPC::TCRETURNai ||
|
|
|
|
RetOpcode == PPC::TCRETURNri8 ||
|
|
|
|
RetOpcode == PPC::TCRETURNdi8 ||
|
|
|
|
RetOpcode == PPC::TCRETURNai8;
|
|
|
|
|
|
|
|
if (UsesTCRet) {
|
|
|
|
int MaxTCRetDelta = FI->getTailCallSPDelta();
|
|
|
|
MachineOperand &StackAdjust = MBBI->getOperand(1);
|
|
|
|
assert(StackAdjust.isImm() && "Expecting immediate value.");
|
|
|
|
// Adjust stack pointer.
|
|
|
|
int StackAdj = StackAdjust.getImm();
|
|
|
|
int Delta = StackAdj - MaxTCRetDelta;
|
|
|
|
assert((Delta >= 0) && "Delta must be positive");
|
|
|
|
if (MaxTCRetDelta>0)
|
|
|
|
FrameSize += (StackAdj +Delta);
|
|
|
|
else
|
|
|
|
FrameSize += StackAdj;
|
|
|
|
}
|
|
|
|
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// Frames of 32KB & larger require special handling because they cannot be
|
|
|
|
// indexed into with a simple LD/LWZ immediate offset operand.
|
|
|
|
bool isLargeFrame = !isInt<16>(FrameSize);
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
if (FrameSize) {
|
[PowerPC] Preparatory refactoring for making prologue and epilogue
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
2013-08-17 04:05:04 +08:00
|
|
|
// In the prologue, the loaded (or persistent) stack pointer value is offset
|
|
|
|
// by the STDU/STDUX/STWU/STWUX instruction. Add this offset back now.
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
|
|
|
|
// If this function contained a fastcc call and GuaranteedTailCallOpt is
|
|
|
|
// enabled (=> hasFastCall()==true) the fastcc call might contain a tail
|
|
|
|
// call which invalidates the stack pointer value in SP(0). So we use the
|
|
|
|
// value of R31 in this case.
|
|
|
|
if (FI->hasFastCall()) {
|
|
|
|
assert(HasFP && "Expecting a valid frame pointer.");
|
|
|
|
if (!isLargeFrame) {
|
|
|
|
BuildMI(MBB, MBBI, dl, AddImmInst, SPReg)
|
|
|
|
.addReg(FPReg).addImm(FrameSize);
|
2010-11-15 08:06:54 +08:00
|
|
|
} else {
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, LoadImmShiftedInst, ScratchReg)
|
|
|
|
.addImm(FrameSize >> 16);
|
|
|
|
BuildMI(MBB, MBBI, dl, OrImmInst, ScratchReg)
|
|
|
|
.addReg(ScratchReg, RegState::Kill)
|
|
|
|
.addImm(FrameSize & 0xFFFF);
|
|
|
|
BuildMI(MBB, MBBI, dl, AddInst)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addReg(FPReg)
|
|
|
|
.addReg(ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
} else if (!isLargeFrame && !HasBP && !MFI->hasVarSizedObjects()) {
|
|
|
|
BuildMI(MBB, MBBI, dl, AddImmInst, SPReg)
|
|
|
|
.addReg(SPReg)
|
|
|
|
.addImm(FrameSize);
|
|
|
|
} else {
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadInst, SPReg)
|
|
|
|
.addImm(0)
|
|
|
|
.addReg(SPReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
2013-04-15 10:07:05 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
}
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (MustSaveLR)
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadInst, ScratchReg)
|
|
|
|
.addImm(LROffset)
|
|
|
|
.addReg(SPReg);
|
2013-07-17 08:45:52 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
assert((isPPC64 || MustSaveCRs.empty()) &&
|
|
|
|
"Epilogue CR restoring supported only in 64-bit mode");
|
2013-04-15 10:07:05 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (!MustSaveCRs.empty()) // will only occur for PPC64
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::LWZ8), TempReg)
|
|
|
|
.addImm(8)
|
|
|
|
.addReg(SPReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (HasFP)
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadInst, FPReg)
|
|
|
|
.addImm(FPOffset)
|
|
|
|
.addReg(SPReg);
|
2013-04-15 10:07:05 +08:00
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
if (FI->usesPICBase())
|
2015-01-08 23:47:19 +08:00
|
|
|
// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadInst)
|
|
|
|
.addReg(PPC::R30)
|
2015-01-10 09:57:21 +08:00
|
|
|
.addImm(PBPOffset)
|
2015-01-08 23:47:19 +08:00
|
|
|
.addReg(SPReg);
|
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (HasBP)
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadInst, BPReg)
|
|
|
|
.addImm(BPOffset)
|
|
|
|
.addReg(SPReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (!MustSaveCRs.empty()) // will only occur for PPC64
|
|
|
|
for (unsigned i = 0, e = MustSaveCRs.size(); i != e; ++i)
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::MTOCRF8), MustSaveCRs[i])
|
|
|
|
.addReg(TempReg, getKillRegState(i == e-1));
|
2013-07-17 08:45:52 +08:00
|
|
|
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
if (MustSaveLR)
|
|
|
|
BuildMI(MBB, MBBI, dl, MTLRInst).addReg(ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
// Callee pop calling convention. Pop parameter/linkage area. Used for tail
|
|
|
|
// call optimization
|
2015-01-14 01:47:54 +08:00
|
|
|
if (MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
(RetOpcode == PPC::BLR || RetOpcode == PPC::BLR8) &&
|
2010-11-15 08:06:54 +08:00
|
|
|
MF.getFunction()->getCallingConv() == CallingConv::Fast) {
|
|
|
|
PPCFunctionInfo *FI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
unsigned CallerAllocatedAmt = FI->getMinReservedArea();
|
|
|
|
|
|
|
|
if (CallerAllocatedAmt && isInt<16>(CallerAllocatedAmt)) {
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, AddImmInst, SPReg)
|
|
|
|
.addReg(SPReg).addImm(CallerAllocatedAmt);
|
2010-11-15 08:06:54 +08:00
|
|
|
} else {
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, LoadImmShiftedInst, ScratchReg)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(CallerAllocatedAmt >> 16);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, OrImmInst, ScratchReg)
|
|
|
|
.addReg(ScratchReg, RegState::Kill)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(CallerAllocatedAmt & 0xFFFF);
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, AddInst)
|
|
|
|
.addReg(SPReg)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addReg(FPReg)
|
[PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(Patch committed on behalf of Mark Minich, whose log entry follows.)
This is a continuation of the refactorings performed in svn rev 188573
(see that rev's comments for more detail).
This is my stage 2 refactoring: I combined the emitPrologue() &
emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a
lot of the code since in essence the PPC32 & PPC64 code generation
logic is the same, only the instruction forms are different (in most
cases). This simplification is necessary because my functional changes
(yet to come) add significant complexity, and without the
simplification of my stage 2 refactoring, the overall complexity of
both emitPrologue() & emitEpilogue() would have become almost
intractable for most mortal programmers (like me).
This submission was intended to be a pure refactoring (no functional
changes whatsoever). However, in the process of combining the PPC32 &
PPC64 flows, I spotted a difference that I believe is a bug (see svn
rev 186478 line 863, or svn rev 188573 line 888): This line appears to
be restoring the BP with the original FP content, not the original BP
content. When I merged the 32-bit and 64-bit code, I used the
corresponding code from the 64-bit flow, which I believe uses the
correct offset (BPOffset) for this operation.
llvm-svn: 188741
2013-08-20 11:12:23 +08:00
|
|
|
.addReg(ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNdi) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILB)).
|
|
|
|
addGlobalAddress(JumpTarget.getGlobal(), JumpTarget.getOffset());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNri) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
assert(MBBI->getOperand(0).isReg() && "Expecting register operand.");
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBCTR));
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNai) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBA)).addImm(JumpTarget.getImm());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNdi8) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILB8)).
|
|
|
|
addGlobalAddress(JumpTarget.getGlobal(), JumpTarget.getOffset());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNri8) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
assert(MBBI->getOperand(0).isReg() && "Expecting register operand.");
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBCTR8));
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNai8) {
|
2011-01-14 05:28:52 +08:00
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBA8)).addImm(JumpTarget.getImm());
|
|
|
|
}
|
|
|
|
}
|
2010-11-19 07:25:52 +08:00
|
|
|
|
2010-11-28 07:05:25 +08:00
|
|
|
/// MustSaveLR - Return true if this function requires that we save the LR
|
|
|
|
/// register onto the stack in the prolog and restore it in the epilog of the
|
|
|
|
/// function.
|
|
|
|
static bool MustSaveLR(const MachineFunction &MF, unsigned LR) {
|
|
|
|
const PPCFunctionInfo *MFI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
|
|
|
|
// We need a save/restore of LR if there is any def of LR (which is
|
|
|
|
// defined by calls, including the PIC setup sequence), or if there is
|
|
|
|
// some use of the LR stack slot (e.g. for builtin_return_address).
|
|
|
|
// (LR comes in 32 and 64 bit versions.)
|
|
|
|
MachineRegisterInfo::def_iterator RI = MF.getRegInfo().def_begin(LR);
|
|
|
|
return RI !=MF.getRegInfo().def_end() || MFI->isLRStoreRequired();
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2011-01-10 20:39:04 +08:00
|
|
|
PPCFrameLowering::processFunctionBeforeCalleeSavedScan(MachineFunction &MF,
|
2013-03-15 13:06:04 +08:00
|
|
|
RegScavenger *) const {
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2010-11-28 07:05:25 +08:00
|
|
|
|
|
|
|
// Save and clear the LR state.
|
|
|
|
PPCFunctionInfo *FI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
unsigned LR = RegInfo->getRARegister();
|
|
|
|
FI->setMustSaveLR(MustSaveLR(MF, LR));
|
2013-02-25 01:34:50 +08:00
|
|
|
MachineRegisterInfo &MRI = MF.getRegInfo();
|
|
|
|
MRI.setPhysRegUnused(LR);
|
2010-11-28 07:05:25 +08:00
|
|
|
|
|
|
|
// Save R31 if necessary
|
|
|
|
int FPSI = FI->getFramePointerSaveIndex();
|
|
|
|
bool isPPC64 = Subtarget.isPPC64();
|
|
|
|
bool isDarwinABI = Subtarget.isDarwinABI();
|
2014-07-19 07:29:49 +08:00
|
|
|
bool isPIC = MF.getTarget().getRelocationModel() == Reloc::PIC_;
|
2010-11-28 07:05:25 +08:00
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
|
|
|
|
// If the frame pointer save index hasn't been defined yet.
|
2010-12-19 03:53:14 +08:00
|
|
|
if (!FPSI && needsFP(MF)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
// Find out what the fix offset of the frame pointer save area.
|
|
|
|
int FPOffset = getFramePointerSaveOffset(isPPC64, isDarwinABI);
|
|
|
|
// Allocate the frame index for frame pointer save area.
|
2011-01-10 20:39:04 +08:00
|
|
|
FPSI = MFI->CreateFixedObject(isPPC64? 8 : 4, FPOffset, true);
|
2010-11-28 07:05:25 +08:00
|
|
|
// Save the result.
|
|
|
|
FI->setFramePointerSaveIndex(FPSI);
|
|
|
|
}
|
|
|
|
|
2013-07-17 08:45:52 +08:00
|
|
|
int BPSI = FI->getBasePointerSaveIndex();
|
|
|
|
if (!BPSI && RegInfo->hasBasePointer(MF)) {
|
2014-07-19 07:29:49 +08:00
|
|
|
int BPOffset = getBasePointerSaveOffset(isPPC64, isDarwinABI, isPIC);
|
2013-07-17 08:45:52 +08:00
|
|
|
// Allocate the frame index for the base pointer save area.
|
|
|
|
BPSI = MFI->CreateFixedObject(isPPC64? 8 : 4, BPOffset, true);
|
|
|
|
// Save the result.
|
|
|
|
FI->setBasePointerSaveIndex(BPSI);
|
|
|
|
}
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
// Reserve stack space for the PIC Base register (R30).
|
|
|
|
// Only used in SVR4 32-bit.
|
|
|
|
if (FI->usesPICBase()) {
|
|
|
|
int PBPSI = FI->getPICBasePointerSaveIndex();
|
|
|
|
PBPSI = MFI->CreateFixedObject(4, -8, true);
|
|
|
|
FI->setPICBasePointerSaveIndex(PBPSI);
|
|
|
|
}
|
|
|
|
|
2010-11-28 07:05:25 +08:00
|
|
|
// Reserve stack space to move the linkage area to in case of a tail call.
|
|
|
|
int TCSPDelta = 0;
|
2011-12-03 06:16:29 +08:00
|
|
|
if (MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
(TCSPDelta = FI->getTailCallSPDelta()) < 0) {
|
2011-01-10 20:39:04 +08:00
|
|
|
MFI->CreateFixedObject(-1 * TCSPDelta, TCSPDelta, true);
|
2010-11-28 07:05:25 +08:00
|
|
|
}
|
|
|
|
|
2014-04-29 08:16:40 +08:00
|
|
|
// For 32-bit SVR4, allocate the nonvolatile CR spill slot iff the
|
2013-02-25 01:34:50 +08:00
|
|
|
// function uses CR 2, 3, or 4.
|
2014-04-29 08:16:40 +08:00
|
|
|
if (!isPPC64 && !isDarwinABI &&
|
2013-02-25 01:34:50 +08:00
|
|
|
(MRI.isPhysRegUsed(PPC::CR2) ||
|
|
|
|
MRI.isPhysRegUsed(PPC::CR3) ||
|
|
|
|
MRI.isPhysRegUsed(PPC::CR4))) {
|
|
|
|
int FrameIdx = MFI->CreateFixedObject((uint64_t)4, (int64_t)-4, true);
|
|
|
|
FI->setCRSpillFrameIndex(FrameIdx);
|
|
|
|
}
|
2010-11-28 07:05:25 +08:00
|
|
|
}
|
|
|
|
|
2013-03-15 04:33:40 +08:00
|
|
|
void PPCFrameLowering::processFunctionBeforeFrameFinalized(MachineFunction &MF,
|
2013-03-15 13:06:04 +08:00
|
|
|
RegScavenger *RS) const {
|
2010-11-28 07:05:25 +08:00
|
|
|
// Early exit if not using the SVR4 ABI.
|
2013-03-15 13:06:04 +08:00
|
|
|
if (!Subtarget.isSVR4ABI()) {
|
|
|
|
addScavengingSpillSlot(MF, RS);
|
2010-11-28 07:05:25 +08:00
|
|
|
return;
|
2013-03-15 13:06:04 +08:00
|
|
|
}
|
2010-11-28 07:05:25 +08:00
|
|
|
|
|
|
|
// Get callee saved register information.
|
|
|
|
MachineFrameInfo *FFI = MF.getFrameInfo();
|
|
|
|
const std::vector<CalleeSavedInfo> &CSI = FFI->getCalleeSavedInfo();
|
|
|
|
|
|
|
|
// Early exit if no callee saved registers are modified!
|
2010-12-19 03:53:14 +08:00
|
|
|
if (CSI.empty() && !needsFP(MF)) {
|
2013-03-15 13:06:04 +08:00
|
|
|
addScavengingSpillSlot(MF, RS);
|
2010-11-28 07:05:25 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned MinGPR = PPC::R31;
|
|
|
|
unsigned MinG8R = PPC::X31;
|
|
|
|
unsigned MinFPR = PPC::F31;
|
|
|
|
unsigned MinVR = PPC::V31;
|
|
|
|
|
|
|
|
bool HasGPSaveArea = false;
|
|
|
|
bool HasG8SaveArea = false;
|
|
|
|
bool HasFPSaveArea = false;
|
|
|
|
bool HasVRSAVESaveArea = false;
|
|
|
|
bool HasVRSaveArea = false;
|
|
|
|
|
|
|
|
SmallVector<CalleeSavedInfo, 18> GPRegs;
|
|
|
|
SmallVector<CalleeSavedInfo, 18> G8Regs;
|
|
|
|
SmallVector<CalleeSavedInfo, 18> FPRegs;
|
|
|
|
SmallVector<CalleeSavedInfo, 18> VRegs;
|
|
|
|
|
|
|
|
for (unsigned i = 0, e = CSI.size(); i != e; ++i) {
|
|
|
|
unsigned Reg = CSI[i].getReg();
|
2012-04-20 14:31:50 +08:00
|
|
|
if (PPC::GPRCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasGPSaveArea = true;
|
|
|
|
|
|
|
|
GPRegs.push_back(CSI[i]);
|
|
|
|
|
|
|
|
if (Reg < MinGPR) {
|
|
|
|
MinGPR = Reg;
|
|
|
|
}
|
2012-04-20 14:31:50 +08:00
|
|
|
} else if (PPC::G8RCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasG8SaveArea = true;
|
|
|
|
|
|
|
|
G8Regs.push_back(CSI[i]);
|
|
|
|
|
|
|
|
if (Reg < MinG8R) {
|
|
|
|
MinG8R = Reg;
|
|
|
|
}
|
2012-04-20 14:31:50 +08:00
|
|
|
} else if (PPC::F8RCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasFPSaveArea = true;
|
|
|
|
|
|
|
|
FPRegs.push_back(CSI[i]);
|
|
|
|
|
|
|
|
if (Reg < MinFPR) {
|
|
|
|
MinFPR = Reg;
|
|
|
|
}
|
2012-04-20 14:31:50 +08:00
|
|
|
} else if (PPC::CRBITRCRegClass.contains(Reg) ||
|
|
|
|
PPC::CRRCRegClass.contains(Reg)) {
|
2012-09-12 22:47:47 +08:00
|
|
|
; // do nothing, as we already know whether CRs are spilled
|
2012-04-20 14:31:50 +08:00
|
|
|
} else if (PPC::VRSAVERCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasVRSAVESaveArea = true;
|
2012-04-20 14:31:50 +08:00
|
|
|
} else if (PPC::VRRCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasVRSaveArea = true;
|
|
|
|
|
|
|
|
VRegs.push_back(CSI[i]);
|
|
|
|
|
|
|
|
if (Reg < MinVR) {
|
|
|
|
MinVR = Reg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
llvm_unreachable("Unknown RegisterClass!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
PPCFunctionInfo *PFI = MF.getInfo<PPCFunctionInfo>();
|
2014-08-05 10:39:49 +08:00
|
|
|
const TargetRegisterInfo *TRI = MF.getSubtarget().getRegisterInfo();
|
2010-11-28 07:05:25 +08:00
|
|
|
|
|
|
|
int64_t LowerBound = 0;
|
|
|
|
|
|
|
|
// Take into account stack space reserved for tail calls.
|
|
|
|
int TCSPDelta = 0;
|
2011-12-03 06:16:29 +08:00
|
|
|
if (MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
(TCSPDelta = PFI->getTailCallSPDelta()) < 0) {
|
2010-11-28 07:05:25 +08:00
|
|
|
LowerBound = TCSPDelta;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The Floating-point register save area is right below the back chain word
|
|
|
|
// of the previous stack frame.
|
|
|
|
if (HasFPSaveArea) {
|
|
|
|
for (unsigned i = 0, e = FPRegs.size(); i != e; ++i) {
|
|
|
|
int FI = FPRegs[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
2013-03-27 04:08:20 +08:00
|
|
|
LowerBound -= (31 - TRI->getEncodingValue(MinFPR) + 1) * 8;
|
2010-11-28 07:05:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check whether the frame pointer register is allocated. If so, make sure it
|
|
|
|
// is spilled to the correct offset.
|
2010-12-19 03:53:14 +08:00
|
|
|
if (needsFP(MF)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
HasGPSaveArea = true;
|
|
|
|
|
|
|
|
int FI = PFI->getFramePointerSaveIndex();
|
|
|
|
assert(FI && "No Frame Pointer Save Slot!");
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
2015-01-10 09:57:21 +08:00
|
|
|
if (PFI->usesPICBase()) {
|
|
|
|
HasGPSaveArea = true;
|
|
|
|
|
|
|
|
int FI = PFI->getPICBasePointerSaveIndex();
|
|
|
|
assert(FI && "No PIC Base Pointer Save Slot!");
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2013-07-17 08:45:52 +08:00
|
|
|
if (RegInfo->hasBasePointer(MF)) {
|
|
|
|
HasGPSaveArea = true;
|
|
|
|
|
|
|
|
int FI = PFI->getBasePointerSaveIndex();
|
|
|
|
assert(FI && "No Base Pointer Save Slot!");
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
2010-11-28 07:05:25 +08:00
|
|
|
// General register save area starts right below the Floating-point
|
|
|
|
// register save area.
|
|
|
|
if (HasGPSaveArea || HasG8SaveArea) {
|
|
|
|
// Move general register save area spill slots down, taking into account
|
|
|
|
// the size of the Floating-point register save area.
|
|
|
|
for (unsigned i = 0, e = GPRegs.size(); i != e; ++i) {
|
|
|
|
int FI = GPRegs[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Move general register save area spill slots down, taking into account
|
|
|
|
// the size of the Floating-point register save area.
|
|
|
|
for (unsigned i = 0, e = G8Regs.size(); i != e; ++i) {
|
|
|
|
int FI = G8Regs[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned MinReg =
|
2013-03-27 04:08:20 +08:00
|
|
|
std::min<unsigned>(TRI->getEncodingValue(MinGPR),
|
|
|
|
TRI->getEncodingValue(MinG8R));
|
2010-11-28 07:05:25 +08:00
|
|
|
|
|
|
|
if (Subtarget.isPPC64()) {
|
|
|
|
LowerBound -= (31 - MinReg + 1) * 8;
|
|
|
|
} else {
|
|
|
|
LowerBound -= (31 - MinReg + 1) * 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
// For 32-bit only, the CR save area is below the general register
|
|
|
|
// save area. For 64-bit SVR4, the CR save area is addressed relative
|
|
|
|
// to the stack pointer and hence does not need an adjustment here.
|
|
|
|
// Only CR2 (the first nonvolatile spilled) has an associated frame
|
|
|
|
// index so that we have a single uniform save area.
|
|
|
|
if (spillsCR(MF) && !(Subtarget.isPPC64() && Subtarget.isSVR4ABI())) {
|
2010-11-28 07:05:25 +08:00
|
|
|
// Adjust the frame index of the CR spill slot.
|
|
|
|
for (unsigned i = 0, e = CSI.size(); i != e; ++i) {
|
|
|
|
unsigned Reg = CSI[i].getReg();
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
if ((Subtarget.isSVR4ABI() && Reg == PPC::CR2)
|
2014-04-29 08:16:40 +08:00
|
|
|
// Leave Darwin logic as-is.
|
|
|
|
|| (!Subtarget.isSVR4ABI() &&
|
|
|
|
(PPC::CRBITRCRegClass.contains(Reg) ||
|
|
|
|
PPC::CRRCRegClass.contains(Reg)))) {
|
2010-11-28 07:05:25 +08:00
|
|
|
int FI = CSI[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
LowerBound -= 4; // The CR save area is always 4 bytes long.
|
|
|
|
}
|
|
|
|
|
|
|
|
if (HasVRSAVESaveArea) {
|
|
|
|
// FIXME SVR4: Is it actually possible to have multiple elements in CSI
|
|
|
|
// which have the VRSAVE register class?
|
|
|
|
// Adjust the frame index of the VRSAVE spill slot.
|
|
|
|
for (unsigned i = 0, e = CSI.size(); i != e; ++i) {
|
|
|
|
unsigned Reg = CSI[i].getReg();
|
|
|
|
|
2012-04-20 14:31:50 +08:00
|
|
|
if (PPC::VRSAVERCRegClass.contains(Reg)) {
|
2010-11-28 07:05:25 +08:00
|
|
|
int FI = CSI[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
LowerBound -= 4; // The VRSAVE save area is always 4 bytes long.
|
|
|
|
}
|
|
|
|
|
|
|
|
if (HasVRSaveArea) {
|
|
|
|
// Insert alignment padding, we need 16-byte alignment.
|
|
|
|
LowerBound = (LowerBound - 15) & ~(15);
|
|
|
|
|
|
|
|
for (unsigned i = 0, e = VRegs.size(); i != e; ++i) {
|
|
|
|
int FI = VRegs[i].getFrameIdx();
|
|
|
|
|
|
|
|
FFI->setObjectOffset(FI, LowerBound + FFI->getObjectOffset(FI));
|
|
|
|
}
|
|
|
|
}
|
2013-03-15 13:06:04 +08:00
|
|
|
|
|
|
|
addScavengingSpillSlot(MF, RS);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
PPCFrameLowering::addScavengingSpillSlot(MachineFunction &MF,
|
|
|
|
RegScavenger *RS) const {
|
|
|
|
// Reserve a slot closest to SP or frame pointer if we have a dynalloc or
|
|
|
|
// a large stack, which will require scavenging a register to materialize a
|
|
|
|
// large offset.
|
|
|
|
|
|
|
|
// We need to have a scavenger spill slot for spills if the frame size is
|
|
|
|
// large. In case there is no free register for large-offset addressing,
|
|
|
|
// this slot is used for the necessary emergency spill. Also, we need the
|
|
|
|
// slot for dynamic stack allocations.
|
|
|
|
|
|
|
|
// The scavenger might be invoked if the frame offset does not fit into
|
|
|
|
// the 16-bit immediate. We don't know the complete frame size here
|
|
|
|
// because we've not yet computed callee-saved register spills or the
|
|
|
|
// needed alignment padding.
|
|
|
|
unsigned StackSize = determineFrameLayout(MF, false, true);
|
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
2013-03-24 06:06:03 +08:00
|
|
|
if (MFI->hasVarSizedObjects() || spillsCR(MF) || spillsVRSAVE(MF) ||
|
|
|
|
hasNonRISpills(MF) || (hasSpills(MF) && !isInt<16>(StackSize))) {
|
2013-03-15 13:06:04 +08:00
|
|
|
const TargetRegisterClass *GPRC = &PPC::GPRCRegClass;
|
|
|
|
const TargetRegisterClass *G8RC = &PPC::G8RCRegClass;
|
|
|
|
const TargetRegisterClass *RC = Subtarget.isPPC64() ? G8RC : GPRC;
|
2013-03-23 07:32:27 +08:00
|
|
|
RS->addScavengingFrameIndex(MFI->CreateStackObject(RC->getSize(),
|
2013-03-15 13:06:04 +08:00
|
|
|
RC->getAlignment(),
|
|
|
|
false));
|
2013-03-27 02:57:22 +08:00
|
|
|
|
2013-07-18 12:28:21 +08:00
|
|
|
// Might we have over-aligned allocas?
|
|
|
|
bool HasAlVars = MFI->hasVarSizedObjects() &&
|
|
|
|
MFI->getMaxAlignment() > getStackAlignment();
|
|
|
|
|
2013-03-27 02:57:22 +08:00
|
|
|
// These kinds of spills might need two registers.
|
2013-07-18 12:28:21 +08:00
|
|
|
if (spillsCR(MF) || spillsVRSAVE(MF) || HasAlVars)
|
2013-03-27 02:57:22 +08:00
|
|
|
RS->addScavengingFrameIndex(MFI->CreateStackObject(RC->getSize(),
|
|
|
|
RC->getAlignment(),
|
|
|
|
false));
|
|
|
|
|
2013-03-15 13:06:04 +08:00
|
|
|
}
|
2010-11-28 07:05:25 +08:00
|
|
|
}
|
2012-09-12 22:47:47 +08:00
|
|
|
|
2014-04-29 08:16:40 +08:00
|
|
|
bool
|
2012-09-12 22:47:47 +08:00
|
|
|
PPCFrameLowering::spillCalleeSavedRegisters(MachineBasicBlock &MBB,
|
2014-04-29 08:16:40 +08:00
|
|
|
MachineBasicBlock::iterator MI,
|
|
|
|
const std::vector<CalleeSavedInfo> &CSI,
|
|
|
|
const TargetRegisterInfo *TRI) const {
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
// Currently, this function only handles SVR4 32- and 64-bit ABIs.
|
|
|
|
// Return false otherwise to maintain pre-existing behavior.
|
|
|
|
if (!Subtarget.isSVR4ABI())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
MachineFunction *MF = MBB.getParent();
|
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF->getSubtarget().getInstrInfo());
|
2012-09-12 22:47:47 +08:00
|
|
|
DebugLoc DL;
|
|
|
|
bool CRSpilled = false;
|
2013-04-14 07:06:15 +08:00
|
|
|
MachineInstrBuilder CRMIB;
|
2014-04-29 08:16:40 +08:00
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
for (unsigned i = 0, e = CSI.size(); i != e; ++i) {
|
|
|
|
unsigned Reg = CSI[i].getReg();
|
2013-06-29 06:29:56 +08:00
|
|
|
// Only Darwin actually uses the VRSAVE register, but it can still appear
|
|
|
|
// here if, for example, @llvm.eh.unwind.init() is used. If we're not on
|
|
|
|
// Darwin, ignore it.
|
|
|
|
if (Reg == PPC::VRSAVE && !Subtarget.isDarwinABI())
|
|
|
|
continue;
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
// CR2 through CR4 are the nonvolatile CR fields.
|
|
|
|
bool IsCRField = PPC::CR2 <= Reg && Reg <= PPC::CR4;
|
|
|
|
|
|
|
|
// Add the callee-saved register as live-in; it's killed at the spill.
|
|
|
|
MBB.addLiveIn(Reg);
|
|
|
|
|
2013-04-14 07:06:15 +08:00
|
|
|
if (CRSpilled && IsCRField) {
|
|
|
|
CRMIB.addReg(Reg, RegState::ImplicitKill);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
// Insert the spill to the stack frame.
|
|
|
|
if (IsCRField) {
|
2013-04-15 10:07:05 +08:00
|
|
|
PPCFunctionInfo *FuncInfo = MF->getInfo<PPCFunctionInfo>();
|
2012-09-12 22:47:47 +08:00
|
|
|
if (Subtarget.isPPC64()) {
|
2013-04-15 10:07:05 +08:00
|
|
|
// The actual spill will happen at the start of the prologue.
|
|
|
|
FuncInfo->addMustSaveCR(Reg);
|
2012-09-12 22:47:47 +08:00
|
|
|
} else {
|
2013-04-15 10:07:05 +08:00
|
|
|
CRSpilled = true;
|
2013-05-15 00:08:32 +08:00
|
|
|
FuncInfo->setSpillsCR();
|
2013-04-15 10:07:05 +08:00
|
|
|
|
2014-04-29 08:16:40 +08:00
|
|
|
// 32-bit: FP-relative. Note that we made sure CR2-CR4 all have
|
|
|
|
// the same frame index in PPCRegisterInfo::hasReservedSpillSlot.
|
|
|
|
CRMIB = BuildMI(*MF, DL, TII.get(PPC::MFCR), PPC::R12)
|
2013-04-14 07:06:15 +08:00
|
|
|
.addReg(Reg, RegState::ImplicitKill);
|
|
|
|
|
2014-04-29 08:16:40 +08:00
|
|
|
MBB.insert(MI, CRMIB);
|
|
|
|
MBB.insert(MI, addFrameReference(BuildMI(*MF, DL, TII.get(PPC::STW))
|
|
|
|
.addReg(PPC::R12,
|
|
|
|
getKillRegState(true)),
|
|
|
|
CSI[i].getFrameIdx()));
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
const TargetRegisterClass *RC = TRI->getMinimalPhysRegClass(Reg);
|
|
|
|
TII.storeRegToStackSlot(MBB, MI, Reg, true,
|
2014-04-29 08:16:40 +08:00
|
|
|
CSI[i].getFrameIdx(), RC, TRI);
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2013-04-13 16:09:20 +08:00
|
|
|
restoreCRs(bool isPPC64, bool is31,
|
|
|
|
bool CR2Spilled, bool CR3Spilled, bool CR4Spilled,
|
2014-04-29 08:16:40 +08:00
|
|
|
MachineBasicBlock &MBB, MachineBasicBlock::iterator MI,
|
|
|
|
const std::vector<CalleeSavedInfo> &CSI, unsigned CSIIndex) {
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
MachineFunction *MF = MBB.getParent();
|
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF->getSubtarget().getInstrInfo());
|
2012-09-12 22:47:47 +08:00
|
|
|
DebugLoc DL;
|
|
|
|
unsigned RestoreOp, MoveReg;
|
|
|
|
|
2013-04-15 10:07:05 +08:00
|
|
|
if (isPPC64)
|
|
|
|
// This is handled during epilogue generation.
|
|
|
|
return;
|
|
|
|
else {
|
2012-09-12 22:47:47 +08:00
|
|
|
// 32-bit: FP-relative
|
|
|
|
MBB.insert(MI, addFrameReference(BuildMI(*MF, DL, TII.get(PPC::LWZ),
|
2014-04-29 08:16:40 +08:00
|
|
|
PPC::R12),
|
|
|
|
CSI[CSIIndex].getFrameIdx()));
|
2013-07-04 01:59:07 +08:00
|
|
|
RestoreOp = PPC::MTOCRF;
|
2012-09-12 22:47:47 +08:00
|
|
|
MoveReg = PPC::R12;
|
|
|
|
}
|
2014-04-29 08:16:40 +08:00
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
if (CR2Spilled)
|
|
|
|
MBB.insert(MI, BuildMI(*MF, DL, TII.get(RestoreOp), PPC::CR2)
|
2013-03-28 11:38:16 +08:00
|
|
|
.addReg(MoveReg, getKillRegState(!CR3Spilled && !CR4Spilled)));
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
if (CR3Spilled)
|
|
|
|
MBB.insert(MI, BuildMI(*MF, DL, TII.get(RestoreOp), PPC::CR3)
|
2013-03-28 11:38:16 +08:00
|
|
|
.addReg(MoveReg, getKillRegState(!CR4Spilled)));
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
if (CR4Spilled)
|
|
|
|
MBB.insert(MI, BuildMI(*MF, DL, TII.get(RestoreOp), PPC::CR4)
|
2013-03-28 11:38:16 +08:00
|
|
|
.addReg(MoveReg, getKillRegState(true)));
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
|
2013-02-22 04:05:00 +08:00
|
|
|
void PPCFrameLowering::
|
|
|
|
eliminateCallFramePseudoInstr(MachineFunction &MF, MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator I) const {
|
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
2013-02-22 04:05:00 +08:00
|
|
|
if (MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
I->getOpcode() == PPC::ADJCALLSTACKUP) {
|
|
|
|
// Add (actually subtract) back the amount the callee popped on return.
|
|
|
|
if (int CalleeAmt = I->getOperand(1).getImm()) {
|
|
|
|
bool is64Bit = Subtarget.isPPC64();
|
|
|
|
CalleeAmt *= -1;
|
|
|
|
unsigned StackReg = is64Bit ? PPC::X1 : PPC::R1;
|
|
|
|
unsigned TmpReg = is64Bit ? PPC::X0 : PPC::R0;
|
|
|
|
unsigned ADDIInstr = is64Bit ? PPC::ADDI8 : PPC::ADDI;
|
|
|
|
unsigned ADDInstr = is64Bit ? PPC::ADD8 : PPC::ADD4;
|
|
|
|
unsigned LISInstr = is64Bit ? PPC::LIS8 : PPC::LIS;
|
|
|
|
unsigned ORIInstr = is64Bit ? PPC::ORI8 : PPC::ORI;
|
|
|
|
MachineInstr *MI = I;
|
|
|
|
DebugLoc dl = MI->getDebugLoc();
|
|
|
|
|
|
|
|
if (isInt<16>(CalleeAmt)) {
|
|
|
|
BuildMI(MBB, I, dl, TII.get(ADDIInstr), StackReg)
|
|
|
|
.addReg(StackReg, RegState::Kill)
|
|
|
|
.addImm(CalleeAmt);
|
|
|
|
} else {
|
|
|
|
MachineBasicBlock::iterator MBBI = I;
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(LISInstr), TmpReg)
|
|
|
|
.addImm(CalleeAmt >> 16);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(ORIInstr), TmpReg)
|
|
|
|
.addReg(TmpReg, RegState::Kill)
|
|
|
|
.addImm(CalleeAmt & 0xFFFF);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(ADDInstr), StackReg)
|
|
|
|
.addReg(StackReg, RegState::Kill)
|
|
|
|
.addReg(TmpReg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Simply discard ADJCALLSTACKDOWN, ADJCALLSTACKUP instructions.
|
|
|
|
MBB.erase(I);
|
|
|
|
}
|
|
|
|
|
2014-04-29 08:16:40 +08:00
|
|
|
bool
|
2012-09-12 22:47:47 +08:00
|
|
|
PPCFrameLowering::restoreCalleeSavedRegisters(MachineBasicBlock &MBB,
|
2014-04-29 08:16:40 +08:00
|
|
|
MachineBasicBlock::iterator MI,
|
|
|
|
const std::vector<CalleeSavedInfo> &CSI,
|
|
|
|
const TargetRegisterInfo *TRI) const {
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
// Currently, this function only handles SVR4 32- and 64-bit ABIs.
|
|
|
|
// Return false otherwise to maintain pre-existing behavior.
|
|
|
|
if (!Subtarget.isSVR4ABI())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
MachineFunction *MF = MBB.getParent();
|
|
|
|
const PPCInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(MF->getSubtarget().getInstrInfo());
|
2012-09-12 22:47:47 +08:00
|
|
|
bool CR2Spilled = false;
|
|
|
|
bool CR3Spilled = false;
|
|
|
|
bool CR4Spilled = false;
|
|
|
|
unsigned CSIIndex = 0;
|
|
|
|
|
|
|
|
// Initialize insertion-point logic; we will be restoring in reverse
|
|
|
|
// order of spill.
|
|
|
|
MachineBasicBlock::iterator I = MI, BeforeI = I;
|
|
|
|
bool AtStart = I == MBB.begin();
|
|
|
|
|
|
|
|
if (!AtStart)
|
|
|
|
--BeforeI;
|
|
|
|
|
|
|
|
for (unsigned i = 0, e = CSI.size(); i != e; ++i) {
|
|
|
|
unsigned Reg = CSI[i].getReg();
|
|
|
|
|
2013-06-29 06:29:56 +08:00
|
|
|
// Only Darwin actually uses the VRSAVE register, but it can still appear
|
|
|
|
// here if, for example, @llvm.eh.unwind.init() is used. If we're not on
|
|
|
|
// Darwin, ignore it.
|
|
|
|
if (Reg == PPC::VRSAVE && !Subtarget.isDarwinABI())
|
|
|
|
continue;
|
|
|
|
|
2012-09-12 22:47:47 +08:00
|
|
|
if (Reg == PPC::CR2) {
|
|
|
|
CR2Spilled = true;
|
|
|
|
// The spill slot is associated only with CR2, which is the
|
|
|
|
// first nonvolatile spilled. Save it here.
|
|
|
|
CSIIndex = i;
|
|
|
|
continue;
|
|
|
|
} else if (Reg == PPC::CR3) {
|
|
|
|
CR3Spilled = true;
|
|
|
|
continue;
|
|
|
|
} else if (Reg == PPC::CR4) {
|
|
|
|
CR4Spilled = true;
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
// When we first encounter a non-CR register after seeing at
|
|
|
|
// least one CR register, restore all spilled CRs together.
|
|
|
|
if ((CR2Spilled || CR3Spilled || CR4Spilled)
|
2014-04-29 08:16:40 +08:00
|
|
|
&& !(PPC::CR2 <= Reg && Reg <= PPC::CR4)) {
|
2013-04-13 16:09:20 +08:00
|
|
|
bool is31 = needsFP(*MF);
|
|
|
|
restoreCRs(Subtarget.isPPC64(), is31,
|
|
|
|
CR2Spilled, CR3Spilled, CR4Spilled,
|
2014-04-29 08:16:40 +08:00
|
|
|
MBB, I, CSI, CSIIndex);
|
|
|
|
CR2Spilled = CR3Spilled = CR4Spilled = false;
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Default behavior for non-CR saves.
|
|
|
|
const TargetRegisterClass *RC = TRI->getMinimalPhysRegClass(Reg);
|
|
|
|
TII.loadRegFromStackSlot(MBB, I, Reg, CSI[i].getFrameIdx(),
|
2014-04-29 08:16:40 +08:00
|
|
|
RC, TRI);
|
2012-09-12 22:47:47 +08:00
|
|
|
assert(I != MBB.begin() &&
|
2014-04-29 08:16:40 +08:00
|
|
|
"loadRegFromStackSlot didn't insert any code!");
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Insert in reverse order.
|
|
|
|
if (AtStart)
|
|
|
|
I = MBB.begin();
|
|
|
|
else {
|
|
|
|
I = BeforeI;
|
|
|
|
++I;
|
2014-04-29 08:16:40 +08:00
|
|
|
}
|
2012-09-12 22:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// If we haven't yet spilled the CRs, do so now.
|
2013-04-13 16:09:20 +08:00
|
|
|
if (CR2Spilled || CR3Spilled || CR4Spilled) {
|
2014-04-29 08:16:40 +08:00
|
|
|
bool is31 = needsFP(*MF);
|
2013-04-13 16:09:20 +08:00
|
|
|
restoreCRs(Subtarget.isPPC64(), is31, CR2Spilled, CR3Spilled, CR4Spilled,
|
2014-04-29 08:16:40 +08:00
|
|
|
MBB, I, CSI, CSIIndex);
|
2013-04-13 16:09:20 +08:00
|
|
|
}
|
2012-09-12 22:47:47 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|