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"
|
2015-02-14 06:48:53 +08:00
|
|
|
#include "PPCTargetMachine.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.
|
|
|
|
///
|
2015-12-05 15:13:35 +08:00
|
|
|
static const MCPhysReg 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
|
|
|
|
};
|
|
|
|
|
2015-02-13 08:39:27 +08:00
|
|
|
static unsigned computeReturnSaveOffset(const PPCSubtarget &STI) {
|
|
|
|
if (STI.isDarwinABI())
|
|
|
|
return STI.isPPC64() ? 16 : 8;
|
|
|
|
// SVR4 ABI:
|
|
|
|
return STI.isPPC64() ? 16 : 4;
|
|
|
|
}
|
|
|
|
|
2015-02-13 08:39:36 +08:00
|
|
|
static unsigned computeTOCSaveOffset(const PPCSubtarget &STI) {
|
|
|
|
return STI.isELFv2ABI() ? 24 : 40;
|
|
|
|
}
|
|
|
|
|
2015-02-13 08:39:38 +08:00
|
|
|
static unsigned computeFramePointerSaveOffset(const PPCSubtarget &STI) {
|
|
|
|
// For the Darwin ABI:
|
|
|
|
// We cannot use the TOC save slot (offset +20) in the PowerPC linkage area
|
|
|
|
// for saving the frame pointer (if needed.) While the published ABI has
|
|
|
|
// not used this slot since at least MacOSX 10.2, there is older code
|
|
|
|
// around that does use it, and that needs to continue to work.
|
|
|
|
if (STI.isDarwinABI())
|
|
|
|
return STI.isPPC64() ? -8U : -4U;
|
|
|
|
|
|
|
|
// SVR4 ABI: First slot in the general register save area.
|
|
|
|
return STI.isPPC64() ? -8U : -4U;
|
|
|
|
}
|
|
|
|
|
2015-02-14 06:22:57 +08:00
|
|
|
static unsigned computeLinkageSize(const PPCSubtarget &STI) {
|
|
|
|
if (STI.isDarwinABI() || STI.isPPC64())
|
|
|
|
return (STI.isELFv2ABI() ? 4 : 6) * (STI.isPPC64() ? 8 : 4);
|
|
|
|
|
|
|
|
// SVR4 ABI:
|
|
|
|
return 8;
|
|
|
|
}
|
|
|
|
|
2015-02-14 06:48:53 +08:00
|
|
|
static unsigned computeBasePointerSaveOffset(const PPCSubtarget &STI) {
|
|
|
|
if (STI.isDarwinABI())
|
|
|
|
return STI.isPPC64() ? -16U : -8U;
|
|
|
|
|
|
|
|
// SVR4 ABI: First slot in the general register save area.
|
|
|
|
return STI.isPPC64()
|
|
|
|
? -16U
|
|
|
|
: (STI.getTargetMachine().getRelocationModel() == Reloc::PIC_)
|
|
|
|
? -12U
|
|
|
|
: -8U;
|
|
|
|
}
|
|
|
|
|
2014-06-13 04:54:11 +08:00
|
|
|
PPCFrameLowering::PPCFrameLowering(const PPCSubtarget &STI)
|
|
|
|
: TargetFrameLowering(TargetFrameLowering::StackGrowsDown,
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
STI.getPlatformStackAlignment(), 0),
|
2015-02-13 08:39:36 +08:00
|
|
|
Subtarget(STI), ReturnSaveOffset(computeReturnSaveOffset(Subtarget)),
|
2015-02-13 08:39:38 +08:00
|
|
|
TOCSaveOffset(computeTOCSaveOffset(Subtarget)),
|
2015-02-14 06:22:57 +08:00
|
|
|
FramePointerSaveOffset(computeFramePointerSaveOffset(Subtarget)),
|
2015-02-14 06:48:53 +08:00
|
|
|
LinkageSize(computeLinkageSize(Subtarget)),
|
|
|
|
BasePointerSaveOffset(computeBasePointerSaveOffset(STI)) {}
|
2014-06-13 04:54:11 +08:00
|
|
|
|
|
|
|
// 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
|
2015-09-26 05:25:19 +08:00
|
|
|
if (I->isReturnBlock()) {
|
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();
|
|
|
|
|
2015-07-15 01:52:07 +08:00
|
|
|
const MachineRegisterInfo &MRI = MF->getRegInfo();
|
2010-11-15 08:06:54 +08:00
|
|
|
unsigned UsedRegMask = 0;
|
|
|
|
for (unsigned i = 0; i != 32; ++i)
|
2015-07-15 01:52:07 +08:00
|
|
|
if (MRI.isPhysRegModified(VRRegNo[i]))
|
2010-11-15 08:06:54 +08:00
|
|
|
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;
|
2015-09-26 05:25:19 +08:00
|
|
|
if (!MBB.isReturnBlock())
|
2013-02-06 01:40:36 +08:00
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
2015-02-11 03:09:05 +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();
|
|
|
|
}
|
|
|
|
|
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 =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.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.
|
2015-02-14 10:54:07 +08:00
|
|
|
bool DisableRedZone = MF.getFunction()->hasFnAttribute(Attribute::NoRedZone);
|
2015-02-11 03:09:05 +08:00
|
|
|
unsigned LR = RegInfo->getRARegister();
|
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.
|
2015-02-11 03:09:05 +08:00
|
|
|
!MustSaveLR(MF, LR) &&
|
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.
|
2015-02-14 06:22:57 +08:00
|
|
|
unsigned minCallFrameSize = getLinkageSize();
|
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.
|
2015-02-14 10:54:07 +08:00
|
|
|
if (MF.getFunction()->hasFnAttribute(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 =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.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
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
/* This function will do the following:
|
|
|
|
- If MBB is an entry or exit block, set SR1 and SR2 to R0 and R12
|
|
|
|
respectively (defaults recommended by the ABI) and return true
|
|
|
|
- If MBB is not an entry block, initialize the register scavenger and look
|
|
|
|
for available registers.
|
|
|
|
- If the defaults (R0/R12) are available, return true
|
|
|
|
- If TwoUniqueRegsRequired is set to true, it looks for two unique
|
|
|
|
registers. Otherwise, look for a single available register.
|
|
|
|
- If the required registers are found, set SR1 and SR2 and return true.
|
|
|
|
- If the required registers are not found, set SR2 or both SR1 and SR2 to
|
|
|
|
PPC::NoRegister and return false.
|
|
|
|
|
|
|
|
Note that if both SR1 and SR2 are valid parameters and TwoUniqueRegsRequired
|
|
|
|
is not set, this function will attempt to find two different registers, but
|
|
|
|
still return true if only one register is available (and set SR1 == SR2).
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
PPCFrameLowering::findScratchRegister(MachineBasicBlock *MBB,
|
|
|
|
bool UseAtEnd,
|
|
|
|
bool TwoUniqueRegsRequired,
|
|
|
|
unsigned *SR1,
|
|
|
|
unsigned *SR2) const {
|
2015-11-17 04:22:15 +08:00
|
|
|
RegScavenger RS;
|
2016-02-21 02:16:25 +08:00
|
|
|
unsigned R0 = Subtarget.isPPC64() ? PPC::X0 : PPC::R0;
|
|
|
|
unsigned R12 = Subtarget.isPPC64() ? PPC::X12 : PPC::R12;
|
2015-11-17 04:22:15 +08:00
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
// Set the defaults for the two scratch registers.
|
|
|
|
if (SR1)
|
|
|
|
*SR1 = R0;
|
2015-11-17 04:22:15 +08:00
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
if (SR2) {
|
|
|
|
assert (SR1 && "Asking for the second scratch register but not the first?");
|
|
|
|
*SR2 = R12;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If MBB is an entry or exit block, use R0 and R12 as the scratch registers.
|
2015-11-17 04:22:15 +08:00
|
|
|
if ((UseAtEnd && MBB->isReturnBlock()) ||
|
|
|
|
(!UseAtEnd && (&MBB->getParent()->front() == MBB)))
|
|
|
|
return true;
|
2015-12-03 05:25:28 +08:00
|
|
|
|
2016-04-06 10:47:09 +08:00
|
|
|
RS.enterBasicBlock(*MBB);
|
2015-11-17 04:22:15 +08:00
|
|
|
|
2015-12-01 02:59:41 +08:00
|
|
|
if (UseAtEnd && !MBB->empty()) {
|
2016-02-21 02:16:25 +08:00
|
|
|
// The scratch register will be used at the end of the block, so must
|
|
|
|
// consider all registers used within the block
|
2015-12-01 02:59:41 +08:00
|
|
|
|
|
|
|
MachineBasicBlock::iterator MBBI = MBB->getFirstTerminator();
|
|
|
|
// If no terminator, back iterator up to previous instruction.
|
|
|
|
if (MBBI == MBB->end())
|
|
|
|
MBBI = std::prev(MBBI);
|
|
|
|
|
|
|
|
if (MBBI != MBB->begin())
|
|
|
|
RS.forward(MBBI);
|
|
|
|
}
|
2016-02-21 02:16:25 +08:00
|
|
|
|
|
|
|
// If the two registers are available, we're all good.
|
|
|
|
// Note that we only return here if both R0 and R12 are available because
|
|
|
|
// although the function may not require two unique registers, it may benefit
|
|
|
|
// from having two so we should try to provide them.
|
|
|
|
if (!RS.isRegUsed(R0) && !RS.isRegUsed(R12))
|
2015-11-17 04:22:15 +08:00
|
|
|
return true;
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
// Get the list of callee-saved registers for the target.
|
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.getRegisterInfo());
|
|
|
|
const MCPhysReg *CSRegs = RegInfo->getCalleeSavedRegs(MBB->getParent());
|
|
|
|
|
|
|
|
// Get all the available registers in the block.
|
|
|
|
BitVector BV = RS.getRegsAvailable(Subtarget.isPPC64() ? &PPC::G8RCRegClass :
|
|
|
|
&PPC::GPRCRegClass);
|
|
|
|
|
|
|
|
// We shouldn't use callee-saved registers as scratch registers as they may be
|
|
|
|
// available when looking for a candidate block for shrink wrapping but not
|
|
|
|
// available when the actual prologue/epilogue is being emitted because they
|
|
|
|
// were added as live-in to the prologue block by PrologueEpilogueInserter.
|
|
|
|
for (int i = 0; CSRegs[i]; ++i)
|
|
|
|
BV.reset(CSRegs[i]);
|
|
|
|
|
|
|
|
// Set the first scratch register to the first available one.
|
|
|
|
if (SR1) {
|
|
|
|
int FirstScratchReg = BV.find_first();
|
|
|
|
*SR1 = FirstScratchReg == -1 ? (unsigned)PPC::NoRegister : FirstScratchReg;
|
|
|
|
}
|
2015-11-17 04:22:15 +08:00
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
// If there is another one available, set the second scratch register to that.
|
|
|
|
// Otherwise, set it to either PPC::NoRegister if this function requires two
|
|
|
|
// or to whatever SR1 is set to if this function doesn't require two.
|
|
|
|
if (SR2) {
|
|
|
|
int SecondScratchReg = BV.find_next(*SR1);
|
|
|
|
if (SecondScratchReg != -1)
|
|
|
|
*SR2 = SecondScratchReg;
|
|
|
|
else
|
|
|
|
*SR2 = TwoUniqueRegsRequired ? (unsigned)PPC::NoRegister : *SR1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now that we've done our best to provide both registers, double check
|
|
|
|
// whether we were unable to provide enough.
|
2016-02-23 23:02:43 +08:00
|
|
|
if (BV.count() < (TwoUniqueRegsRequired ? 2U : 1U))
|
2016-02-21 02:16:25 +08:00
|
|
|
return false;
|
2015-11-17 04:22:15 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
// We need a scratch register for spilling LR and for spilling CR. By default,
|
|
|
|
// we use two scratch registers to hide latency. However, if only one scratch
|
|
|
|
// register is available, we can adjust for that by not overlapping the spill
|
|
|
|
// code. However, if we need to realign the stack (i.e. have a base pointer)
|
|
|
|
// and the stack frame is large, we need two scratch registers.
|
|
|
|
bool
|
|
|
|
PPCFrameLowering::twoUniqueScratchRegsRequired(MachineBasicBlock *MBB) const {
|
|
|
|
const PPCRegisterInfo *RegInfo =
|
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.getRegisterInfo());
|
|
|
|
MachineFunction &MF = *(MBB->getParent());
|
|
|
|
bool HasBP = RegInfo->hasBasePointer(MF);
|
|
|
|
unsigned FrameSize = determineFrameLayout(MF, false);
|
|
|
|
int NegFrameSize = -FrameSize;
|
|
|
|
bool IsLargeFrame = !isInt<16>(NegFrameSize);
|
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
unsigned MaxAlign = MFI->getMaxAlignment();
|
|
|
|
|
|
|
|
return IsLargeFrame && HasBP && MaxAlign > 1;
|
|
|
|
}
|
|
|
|
|
2015-11-17 04:22:15 +08:00
|
|
|
bool PPCFrameLowering::canUseAsPrologue(const MachineBasicBlock &MBB) const {
|
|
|
|
MachineBasicBlock *TmpMBB = const_cast<MachineBasicBlock *>(&MBB);
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
return findScratchRegister(TmpMBB, false,
|
|
|
|
twoUniqueScratchRegsRequired(TmpMBB));
|
2015-11-17 04:22:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool PPCFrameLowering::canUseAsEpilogue(const MachineBasicBlock &MBB) const {
|
|
|
|
MachineBasicBlock *TmpMBB = const_cast<MachineBasicBlock *>(&MBB);
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
return findScratchRegister(TmpMBB, true);
|
2015-11-17 04:22:15 +08:00
|
|
|
}
|
|
|
|
|
[ShrinkWrap] Add (a simplified version) of shrink-wrapping.
This patch introduces a new pass that computes the safe point to insert the
prologue and epilogue of the function.
The interest is to find safe points that are cheaper than the entry and exits
blocks.
As an example and to avoid regressions to be introduce, this patch also
implements the required bits to enable the shrink-wrapping pass for AArch64.
** Context **
Currently we insert the prologue and epilogue of the method/function in the
entry and exits blocks. Although this is correct, we can do a better job when
those are not immediately required and insert them at less frequently executed
places.
The job of the shrink-wrapping pass is to identify such places.
** Motivating example **
Let us consider the following function that perform a call only in one branch of
a if:
define i32 @f(i32 %a, i32 %b) {
%tmp = alloca i32, align 4
%tmp2 = icmp slt i32 %a, %b
br i1 %tmp2, label %true, label %false
true:
store i32 %a, i32* %tmp, align 4
%tmp4 = call i32 @doSomething(i32 0, i32* %tmp)
br label %false
false:
%tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ]
ret i32 %tmp.0
}
On AArch64 this code generates (removing the cfi directives to ease
readabilities):
_f: ; @f
; BB#0:
stp x29, x30, [sp, #-16]!
mov x29, sp
sub sp, sp, #16 ; =16
cmp w0, w1
b.ge LBB0_2
; BB#1: ; %true
stur w0, [x29, #-4]
sub x1, x29, #4 ; =4
mov w0, wzr
bl _doSomething
LBB0_2: ; %false
mov sp, x29
ldp x29, x30, [sp], #16
ret
With shrink-wrapping we could generate:
_f: ; @f
; BB#0:
cmp w0, w1
b.ge LBB0_2
; BB#1: ; %true
stp x29, x30, [sp, #-16]!
mov x29, sp
sub sp, sp, #16 ; =16
stur w0, [x29, #-4]
sub x1, x29, #4 ; =4
mov w0, wzr
bl _doSomething
add sp, x29, #16 ; =16
ldp x29, x30, [sp], #16
LBB0_2: ; %false
ret
Therefore, we would pay the overhead of setting up/destroying the frame only if
we actually do the call.
** Proposed Solution **
This patch introduces a new machine pass that perform the shrink-wrapping
analysis (See the comments at the beginning of ShrinkWrap.cpp for more details).
It then stores the safe save and restore point into the MachineFrameInfo
attached to the MachineFunction.
This information is then used by the PrologEpilogInserter (PEI) to place the
related code at the right place. This pass runs right before the PEI.
Unlike the original paper of Chow from PLDI’88, this implementation of
shrink-wrapping does not use expensive data-flow analysis and does not need hack
to properly avoid frequently executed point. Instead, it relies on dominance and
loop properties.
The pass is off by default and each target can opt-in by setting the
EnableShrinkWrap boolean to true in their derived class of TargetPassConfig.
This setting can also be overwritten on the command line by using
-enable-shrink-wrap.
Before you try out the pass for your target, make sure you properly fix your
emitProlog/emitEpilog/adjustForXXX method to cope with basic blocks that are not
necessarily the entry block.
** Design Decisions **
1. ShrinkWrap is its own pass right now. It could frankly be merged into PEI but
for debugging and clarity I thought it was best to have its own file.
2. Right now, we only support one save point and one restore point. At some
point we can expand this to several save point and restore point, the impacted
component would then be:
- The pass itself: New algorithm needed.
- MachineFrameInfo: Hold a list or set of Save/Restore point instead of one
pointer.
- PEI: Should loop over the save point and restore point.
Anyhow, at least for this first iteration, I do not believe this is interesting
to support the complex cases. We should revisit that when we motivating
examples.
Differential Revision: http://reviews.llvm.org/D9210
<rdar://problem/3201744>
llvm-svn: 236507
2015-05-06 01:38:16 +08:00
|
|
|
void PPCFrameLowering::emitPrologue(MachineFunction &MF,
|
|
|
|
MachineBasicBlock &MBB) const {
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineBasicBlock::iterator MBBI = MBB.begin();
|
|
|
|
MachineFrameInfo *MFI = MF.getFrameInfo();
|
|
|
|
const PPCInstrInfo &TII =
|
2015-01-30 10:11:26 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(Subtarget.getInstrInfo());
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.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();
|
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 isSVR4ABI = Subtarget.isSVR4ABI();
|
2014-07-21 08:03:18 +08:00
|
|
|
bool isELFv2ABI = Subtarget.isELFv2ABI();
|
2015-02-14 17:14:44 +08:00
|
|
|
assert((Subtarget.isDarwinABI() || isSVR4ABI) &&
|
[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
|
|
|
"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
|
|
|
}
|
|
|
|
|
2015-09-10 09:55:44 +08:00
|
|
|
// Move MBBI back to the beginning of the prologue block.
|
2010-11-15 08:06:54 +08:00
|
|
|
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();
|
2016-02-21 02:16:25 +08:00
|
|
|
bool MustSaveCR = !MustSaveCRs.empty();
|
[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;
|
2015-11-17 04:22:15 +08:00
|
|
|
unsigned ScratchReg = 0;
|
[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 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.");
|
|
|
|
|
2016-02-21 04:45:37 +08:00
|
|
|
// Using the same bool variable as below to supress compiler warnings.
|
|
|
|
bool SingleScratchReg =
|
|
|
|
findScratchRegister(&MBB, false, twoUniqueScratchRegsRequired(&MBB),
|
|
|
|
&ScratchReg, &TempReg);
|
|
|
|
assert(SingleScratchReg &&
|
2016-02-21 02:16:25 +08:00
|
|
|
"Required number of registers not available in this block");
|
|
|
|
|
2016-02-21 04:45:37 +08:00
|
|
|
SingleScratchReg = ScratchReg == TempReg;
|
2016-02-21 02:16:25 +08:00
|
|
|
|
2015-02-13 08:39:27 +08:00
|
|
|
int LROffset = getReturnSaveOffset();
|
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 {
|
2015-02-13 08:39:38 +08:00
|
|
|
FPOffset = getFramePointerSaveOffset();
|
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 {
|
2015-02-14 06:48:53 +08:00
|
|
|
BPOffset = getBasePointerSaveOffset();
|
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);
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
assert((isPPC64 || !MustSaveCR) &&
|
|
|
|
"Prologue CR saving supported only in 64-bit mode");
|
|
|
|
|
|
|
|
// If we need to spill the CR and the LR but we don't have two separate
|
|
|
|
// registers available, we must spill them one at a time
|
|
|
|
if (MustSaveCR && SingleScratchReg && MustSaveLR) {
|
2016-04-12 11:04:44 +08:00
|
|
|
// In the ELFv2 ABI, we are not required to save all CR fields.
|
|
|
|
// If only one or two CR fields are clobbered, it is more efficient to use
|
|
|
|
// mfocrf to selectively save just those fields, because mfocrf has short
|
|
|
|
// latency compares to mfcr.
|
|
|
|
unsigned MfcrOpcode = PPC::MFCR8;
|
2016-04-27 10:59:28 +08:00
|
|
|
unsigned CrState = RegState::ImplicitKill;
|
|
|
|
if (isELFv2ABI && MustSaveCRs.size() == 1) {
|
2016-04-12 11:04:44 +08:00
|
|
|
MfcrOpcode = PPC::MFOCRF8;
|
2016-04-27 10:59:28 +08:00
|
|
|
CrState = RegState::Kill;
|
|
|
|
}
|
2016-02-21 02:16:25 +08:00
|
|
|
MachineInstrBuilder MIB =
|
2016-04-12 11:04:44 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(MfcrOpcode), TempReg);
|
2016-02-21 02:16:25 +08:00
|
|
|
for (unsigned i = 0, e = MustSaveCRs.size(); i != e; ++i)
|
2016-04-27 10:59:28 +08:00
|
|
|
MIB.addReg(MustSaveCRs[i], CrState);
|
2016-02-21 02:16:25 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::STW8))
|
|
|
|
.addReg(TempReg, getKillRegState(true))
|
|
|
|
.addImm(8)
|
|
|
|
.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 (MustSaveLR)
|
|
|
|
BuildMI(MBB, MBBI, dl, MFLRInst, ScratchReg);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
if (MustSaveCR &&
|
|
|
|
!(SingleScratchReg && MustSaveLR)) { // will only occur for PPC64
|
2016-04-12 11:04:44 +08:00
|
|
|
// In the ELFv2 ABI, we are not required to save all CR fields.
|
|
|
|
// If only one or two CR fields are clobbered, it is more efficient to use
|
|
|
|
// mfocrf to selectively save just those fields, because mfocrf has short
|
|
|
|
// latency compares to mfcr.
|
|
|
|
unsigned MfcrOpcode = PPC::MFCR8;
|
2016-04-27 10:59:28 +08:00
|
|
|
unsigned CrState = RegState::ImplicitKill;
|
|
|
|
if (isELFv2ABI && MustSaveCRs.size() == 1) {
|
2016-04-12 11:04:44 +08:00
|
|
|
MfcrOpcode = PPC::MFOCRF8;
|
2016-04-27 10:59:28 +08:00
|
|
|
CrState = RegState::Kill;
|
|
|
|
}
|
[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 =
|
2016-04-12 11:04:44 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(MfcrOpcode), TempReg);
|
[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
|
|
|
for (unsigned i = 0, e = MustSaveCRs.size(); i != e; ++i)
|
2016-04-27 10:59:28 +08:00
|
|
|
MIB.addReg(MustSaveCRs[i], CrState);
|
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);
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
if (MustSaveCR &&
|
|
|
|
!(SingleScratchReg && MustSaveLR)) // will only occur for PPC64
|
[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, 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);
|
|
|
|
}
|
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
// This condition must be kept in sync with canUseAsPrologue.
|
[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 && 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 {
|
2016-02-21 02:16:25 +08:00
|
|
|
assert(!SingleScratchReg && "Only a single scratch reg available");
|
[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)
|
2016-02-21 02:16:25 +08:00
|
|
|
&& !MustSaveCR)
|
[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
|
|
|
|
|
|
|
// 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,
|
2015-09-10 09:55:44 +08:00
|
|
|
MachineBasicBlock &MBB) const {
|
|
|
|
MachineBasicBlock::iterator MBBI = MBB.getFirstTerminator();
|
|
|
|
DebugLoc dl;
|
|
|
|
|
|
|
|
if (MBBI != MBB.end())
|
|
|
|
dl = MBBI->getDebugLoc();
|
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
const PPCInstrInfo &TII =
|
2015-01-30 10:11:26 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(Subtarget.getInstrInfo());
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.getRegisterInfo());
|
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 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.
|
|
|
|
bool isSVR4ABI = Subtarget.isSVR4ABI();
|
|
|
|
|
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();
|
2016-02-21 02:16:25 +08:00
|
|
|
bool MustSaveCR = !MustSaveCRs.empty();
|
[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;
|
2015-11-17 04:22:15 +08:00
|
|
|
unsigned ScratchReg = 0;
|
[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 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 );
|
2016-02-21 02:16:25 +08:00
|
|
|
|
2015-02-13 08:39:27 +08:00
|
|
|
int LROffset = getReturnSaveOffset();
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
int FPOffset = 0;
|
2015-11-17 04:22:15 +08:00
|
|
|
|
2016-02-21 04:45:37 +08:00
|
|
|
// Using the same bool variable as below to supress compiler warnings.
|
|
|
|
bool SingleScratchReg = findScratchRegister(&MBB, true, false, &ScratchReg,
|
|
|
|
&TempReg);
|
|
|
|
assert(SingleScratchReg &&
|
2016-02-21 02:16:25 +08:00
|
|
|
"Could not find an available scratch register");
|
|
|
|
|
2016-02-21 04:45:37 +08:00
|
|
|
SingleScratchReg = ScratchReg == TempReg;
|
2016-02-21 02:16:25 +08:00
|
|
|
|
2010-11-15 08:06:54 +08:00
|
|
|
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 {
|
2015-02-13 08:39:38 +08:00
|
|
|
FPOffset = getFramePointerSaveOffset();
|
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 {
|
2015-02-14 06:48:53 +08:00
|
|
|
BPOffset = getBasePointerSaveOffset();
|
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);
|
|
|
|
}
|
|
|
|
|
2015-09-11 16:20:56 +08:00
|
|
|
bool IsReturnBlock = (MBBI != MBB.end() && MBBI->isReturn());
|
2015-09-10 09:55:44 +08:00
|
|
|
|
|
|
|
if (IsReturnBlock) {
|
|
|
|
unsigned RetOpcode = MBBI->getOpcode();
|
|
|
|
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;
|
|
|
|
}
|
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
|
|
|
// 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
|
|
|
}
|
[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
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
assert((isPPC64 || !MustSaveCR) &&
|
|
|
|
"Epilogue CR restoring supported only in 64-bit mode");
|
|
|
|
|
|
|
|
// If we need to save both the LR and the CR and we only have one available
|
|
|
|
// scratch register, we must do them one at a time.
|
|
|
|
if (MustSaveCR && SingleScratchReg && MustSaveLR) {
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::LWZ8), TempReg)
|
|
|
|
.addImm(8)
|
|
|
|
.addReg(SPReg);
|
|
|
|
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));
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
if (MustSaveCR &&
|
|
|
|
!(SingleScratchReg && MustSaveLR)) // will only occur for PPC64
|
[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, 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
|
|
|
|
2016-02-21 02:16:25 +08:00
|
|
|
if (MustSaveCR &&
|
|
|
|
!(SingleScratchReg && MustSaveLR)) // will only occur for PPC64
|
[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
|
|
|
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-09-10 09:55:44 +08:00
|
|
|
if (IsReturnBlock) {
|
|
|
|
unsigned RetOpcode = MBBI->getOpcode();
|
|
|
|
if (MF.getTarget().Options.GuaranteedTailCallOpt &&
|
|
|
|
(RetOpcode == PPC::BLR || RetOpcode == PPC::BLR8) &&
|
|
|
|
MF.getFunction()->getCallingConv() == CallingConv::Fast) {
|
|
|
|
PPCFunctionInfo *FI = MF.getInfo<PPCFunctionInfo>();
|
|
|
|
unsigned CallerAllocatedAmt = FI->getMinReservedArea();
|
|
|
|
|
|
|
|
if (CallerAllocatedAmt && isInt<16>(CallerAllocatedAmt)) {
|
|
|
|
BuildMI(MBB, MBBI, dl, AddImmInst, SPReg)
|
|
|
|
.addReg(SPReg).addImm(CallerAllocatedAmt);
|
|
|
|
} else {
|
|
|
|
BuildMI(MBB, MBBI, dl, LoadImmShiftedInst, ScratchReg)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(CallerAllocatedAmt >> 16);
|
2015-09-10 09:55:44 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, OrImmInst, ScratchReg)
|
[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, RegState::Kill)
|
2010-11-15 08:06:54 +08:00
|
|
|
.addImm(CallerAllocatedAmt & 0xFFFF);
|
2015-09-10 09:55:44 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, AddInst)
|
[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(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);
|
2015-09-10 09:55:44 +08:00
|
|
|
}
|
[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear
Bug Pattern:
# BB#0: # %entry
cmpldi 3, 0
beq- 0, .LBB0_2
# BB#1: # %exit
lwz 4, 0(3)
#TC_RETURNd8 LVComputationKind 0
.LBB0_2: # %cond.false
mflr 0
std 0, 16(1)
stdu 1, -96(1)
.Ltmp0:
.cfi_def_cfa_offset 96
.Ltmp1:
.cfi_offset lr, 16
bl __assert_fail
nop
The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.
Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton
http://reviews.llvm.org/D17606
llvm-svn: 265112
2016-04-01 14:44:32 +08:00
|
|
|
} else {
|
|
|
|
createTailCallBranchInstr(MBB);
|
2015-09-10 09:55:44 +08:00
|
|
|
}
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
}
|
2010-11-19 07:25:52 +08:00
|
|
|
|
[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear
Bug Pattern:
# BB#0: # %entry
cmpldi 3, 0
beq- 0, .LBB0_2
# BB#1: # %exit
lwz 4, 0(3)
#TC_RETURNd8 LVComputationKind 0
.LBB0_2: # %cond.false
mflr 0
std 0, 16(1)
stdu 1, -96(1)
.Ltmp0:
.cfi_def_cfa_offset 96
.Ltmp1:
.cfi_offset lr, 16
bl __assert_fail
nop
The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.
Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton
http://reviews.llvm.org/D17606
llvm-svn: 265112
2016-04-01 14:44:32 +08:00
|
|
|
void PPCFrameLowering::createTailCallBranchInstr(MachineBasicBlock &MBB) const {
|
|
|
|
MachineBasicBlock::iterator MBBI = MBB.getFirstTerminator();
|
|
|
|
DebugLoc dl;
|
|
|
|
|
|
|
|
if (MBBI != MBB.end())
|
|
|
|
dl = MBBI->getDebugLoc();
|
|
|
|
|
|
|
|
const PPCInstrInfo &TII =
|
|
|
|
*static_cast<const PPCInstrInfo *>(Subtarget.getInstrInfo());
|
|
|
|
|
|
|
|
// Create branch instruction for pseudo tail call return instruction
|
|
|
|
unsigned RetOpcode = MBBI->getOpcode();
|
|
|
|
if (RetOpcode == PPC::TCRETURNdi) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILB)).
|
|
|
|
addGlobalAddress(JumpTarget.getGlobal(), JumpTarget.getOffset());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNri) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
assert(MBBI->getOperand(0).isReg() && "Expecting register operand.");
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBCTR));
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNai) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBA)).addImm(JumpTarget.getImm());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNdi8) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILB8)).
|
|
|
|
addGlobalAddress(JumpTarget.getGlobal(), JumpTarget.getOffset());
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNri8) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
assert(MBBI->getOperand(0).isReg() && "Expecting register operand.");
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBCTR8));
|
|
|
|
} else if (RetOpcode == PPC::TCRETURNai8) {
|
|
|
|
MBBI = MBB.getLastNonDebugInstr();
|
|
|
|
MachineOperand &JumpTarget = MBBI->getOperand(0);
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(PPC::TAILBA8)).addImm(JumpTarget.getImm());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-15 01:17:13 +08:00
|
|
|
void PPCFrameLowering::determineCalleeSaves(MachineFunction &MF,
|
|
|
|
BitVector &SavedRegs,
|
|
|
|
RegScavenger *RS) const {
|
|
|
|
TargetFrameLowering::determineCalleeSaves(MF, SavedRegs, RS);
|
|
|
|
|
2014-08-05 10:39:49 +08:00
|
|
|
const PPCRegisterInfo *RegInfo =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.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));
|
2015-07-15 01:17:13 +08:00
|
|
|
SavedRegs.reset(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();
|
|
|
|
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.
|
2015-02-13 08:39:38 +08:00
|
|
|
int FPOffset = getFramePointerSaveOffset();
|
2010-11-28 07:05:25 +08:00
|
|
|
// 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)) {
|
2015-02-14 06:48:53 +08:00
|
|
|
int BPOffset = getBasePointerSaveOffset();
|
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()) {
|
2015-08-14 11:48:35 +08:00
|
|
|
int PBPSI = MFI->CreateFixedObject(4, -8, true);
|
2015-01-10 09:57:21 +08:00
|
|
|
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 &&
|
2015-07-15 01:17:13 +08:00
|
|
|
(SavedRegs.test(PPC::CR2) ||
|
|
|
|
SavedRegs.test(PPC::CR3) ||
|
|
|
|
SavedRegs.test(PPC::CR4))) {
|
2013-02-25 01:34:50 +08:00
|
|
|
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();
|
|
|
|
|
[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear
Bug Pattern:
# BB#0: # %entry
cmpldi 3, 0
beq- 0, .LBB0_2
# BB#1: # %exit
lwz 4, 0(3)
#TC_RETURNd8 LVComputationKind 0
.LBB0_2: # %cond.false
mflr 0
std 0, 16(1)
stdu 1, -96(1)
.Ltmp0:
.cfi_def_cfa_offset 96
.Ltmp1:
.cfi_offset lr, 16
bl __assert_fail
nop
The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.
Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton
http://reviews.llvm.org/D17606
llvm-svn: 265112
2016-04-01 14:44:32 +08:00
|
|
|
// If the function is shrink-wrapped, and if the function has a tail call, the
|
|
|
|
// tail call might not be in the new RestoreBlock, so real branch instruction
|
|
|
|
// won't be generated by emitEpilogue(), because shrink-wrap has chosen new
|
|
|
|
// RestoreBlock. So we handle this case here.
|
|
|
|
if (FFI->getSavePoint() && FFI->hasTailCall()) {
|
|
|
|
MachineBasicBlock *RestoreBlock = FFI->getRestorePoint();
|
|
|
|
for (MachineBasicBlock &MBB : MF) {
|
|
|
|
if (MBB.isReturnBlock() && (&MBB) != RestoreBlock)
|
|
|
|
createTailCallBranchInstr(MBB);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-28 07:05:25 +08:00
|
|
|
// 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>();
|
2015-01-30 10:11:26 +08:00
|
|
|
const TargetRegisterInfo *TRI = Subtarget.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 =
|
2015-01-30 10:11:26 +08:00
|
|
|
static_cast<const PPCRegisterInfo *>(Subtarget.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 =
|
2015-01-30 10:11:26 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(Subtarget.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();
|
2015-01-31 06:02:31 +08:00
|
|
|
const PPCInstrInfo &TII = *MF->getSubtarget<PPCSubtarget>().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
|
|
|
}
|
|
|
|
|
2016-04-01 02:33:38 +08:00
|
|
|
MachineBasicBlock::iterator PPCFrameLowering::
|
2013-02-22 04:05:00 +08:00
|
|
|
eliminateCallFramePseudoInstr(MachineFunction &MF, MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator I) const {
|
2015-01-30 10:11:26 +08:00
|
|
|
const TargetInstrInfo &TII = *Subtarget.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.
|
2016-04-01 02:33:38 +08:00
|
|
|
return MBB.erase(I);
|
2013-02-22 04:05:00 +08:00
|
|
|
}
|
|
|
|
|
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 =
|
2015-01-30 10:11:26 +08:00
|
|
|
*static_cast<const PPCInstrInfo *>(Subtarget.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;
|
|
|
|
}
|
2015-09-10 09:55:44 +08:00
|
|
|
|
|
|
|
bool PPCFrameLowering::enableShrinkWrapping(const MachineFunction &MF) const {
|
2015-12-01 02:59:41 +08:00
|
|
|
return (MF.getSubtarget<PPCSubtarget>().isSVR4ABI() &&
|
|
|
|
MF.getSubtarget<PPCSubtarget>().isPPC64());
|
2015-09-10 09:55:44 +08:00
|
|
|
}
|