2012-02-18 20:03:15 +08:00
|
|
|
//===-- SparcFrameLowering.cpp - Sparc 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 Sparc implementation of TargetFrameLowering class.
|
2010-11-15 08:06:54 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
#include "SparcFrameLowering.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
#include "SparcInstrInfo.h"
|
|
|
|
#include "SparcMachineFunctionInfo.h"
|
2014-06-27 06:33:50 +08:00
|
|
|
#include "SparcSubtarget.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"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Target/TargetOptions.h"
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2013-05-29 12:46:31 +08:00
|
|
|
static cl::opt<bool>
|
|
|
|
DisableLeafProc("disable-sparc-leaf-proc",
|
2013-06-02 10:24:27 +08:00
|
|
|
cl::init(false),
|
2013-05-29 12:46:31 +08:00
|
|
|
cl::desc("Disable Sparc leaf procedure optimization."),
|
|
|
|
cl::Hidden);
|
|
|
|
|
2014-06-27 06:33:50 +08:00
|
|
|
SparcFrameLowering::SparcFrameLowering(const SparcSubtarget &ST)
|
|
|
|
: TargetFrameLowering(TargetFrameLowering::StackGrowsDown,
|
|
|
|
ST.is64Bit() ? 16 : 8, 0, ST.is64Bit() ? 16 : 8) {}
|
2013-05-29 12:46:31 +08:00
|
|
|
|
2013-11-25 04:23:25 +08:00
|
|
|
void SparcFrameLowering::emitSPAdjustment(MachineFunction &MF,
|
|
|
|
MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator MBBI,
|
|
|
|
int NumBytes,
|
2015-11-06 05:54:58 +08:00
|
|
|
unsigned ADDrr,
|
|
|
|
unsigned ADDri) const {
|
|
|
|
|
|
|
|
DebugLoc dl;
|
|
|
|
const SparcInstrInfo &TII =
|
|
|
|
*static_cast<const SparcInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
|
|
|
|
2013-11-25 04:23:25 +08:00
|
|
|
if (NumBytes >= -4096 && NumBytes < 4096) {
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(ADDri), SP::O6)
|
|
|
|
.addReg(SP::O6).addImm(NumBytes);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit this the hard way. This clobbers G1 which we always know is
|
|
|
|
// available here.
|
|
|
|
if (NumBytes >= 0) {
|
|
|
|
// Emit nonnegative numbers with sethi + or.
|
|
|
|
// sethi %hi(NumBytes), %g1
|
|
|
|
// or %g1, %lo(NumBytes), %g1
|
|
|
|
// add %sp, %g1, %sp
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::SETHIi), SP::G1)
|
|
|
|
.addImm(HI22(NumBytes));
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::ORri), SP::G1)
|
|
|
|
.addReg(SP::G1).addImm(LO10(NumBytes));
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(ADDrr), SP::O6)
|
|
|
|
.addReg(SP::O6).addReg(SP::G1);
|
|
|
|
return ;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit negative numbers with sethi + xor.
|
|
|
|
// sethi %hix(NumBytes), %g1
|
|
|
|
// xor %g1, %lox(NumBytes), %g1
|
|
|
|
// add %sp, %g1, %sp
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::SETHIi), SP::G1)
|
|
|
|
.addImm(HIX22(NumBytes));
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::XORri), SP::G1)
|
|
|
|
.addReg(SP::G1).addImm(LOX10(NumBytes));
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(ADDrr), SP::O6)
|
|
|
|
.addReg(SP::O6).addReg(SP::G1);
|
|
|
|
}
|
|
|
|
|
[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 SparcFrameLowering::emitPrologue(MachineFunction &MF,
|
|
|
|
MachineBasicBlock &MBB) const {
|
2013-05-29 12:46:31 +08:00
|
|
|
SparcMachineFunctionInfo *FuncInfo = MF.getInfo<SparcMachineFunctionInfo>();
|
|
|
|
|
[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
|
|
|
assert(&MF.front() == &MBB && "Shrink-wrapping not yet supported");
|
2016-07-29 02:40:00 +08:00
|
|
|
MachineFrameInfo &MFI = MF.getFrameInfo();
|
2010-11-15 08:06:54 +08:00
|
|
|
const SparcInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const SparcInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
const SparcRegisterInfo &RegInfo =
|
|
|
|
*static_cast<const SparcRegisterInfo *>(MF.getSubtarget().getRegisterInfo());
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineBasicBlock::iterator MBBI = MBB.begin();
|
2015-11-06 01:50:17 +08:00
|
|
|
// Debug location must be unknown since the first debug location is used
|
|
|
|
// to determine the end of the prologue.
|
|
|
|
DebugLoc dl;
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
bool NeedsStackRealignment = RegInfo.needsStackRealignment(MF);
|
|
|
|
|
|
|
|
// FIXME: unfortunately, returning false from canRealignStack
|
|
|
|
// actually just causes needsStackRealignment to return false,
|
|
|
|
// rather than reporting an error, as would be sensible. This is
|
|
|
|
// poor, but fixing that bogosity is going to be a large project.
|
|
|
|
// For now, just see if it's lied, and report an error here.
|
2016-07-29 02:40:00 +08:00
|
|
|
if (!NeedsStackRealignment && MFI.getMaxAlignment() > getStackAlignment())
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
report_fatal_error("Function \"" + Twine(MF.getName()) + "\" required "
|
|
|
|
"stack re-alignment, but LLVM couldn't handle it "
|
|
|
|
"(probably because it has a dynamic alloca).");
|
2010-11-15 08:06:54 +08:00
|
|
|
|
|
|
|
// Get the number of bytes to allocate from the FrameInfo
|
2016-07-29 02:40:00 +08:00
|
|
|
int NumBytes = (int) MFI.getStackSize();
|
2010-11-15 08:06:54 +08:00
|
|
|
|
2013-06-01 12:51:18 +08:00
|
|
|
unsigned SAVEri = SP::SAVEri;
|
|
|
|
unsigned SAVErr = SP::SAVErr;
|
|
|
|
if (FuncInfo->isLeafProc()) {
|
|
|
|
if (NumBytes == 0)
|
|
|
|
return;
|
|
|
|
SAVEri = SP::ADDri;
|
|
|
|
SAVErr = SP::ADDrr;
|
2013-04-09 12:37:47 +08:00
|
|
|
}
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
|
2015-08-27 01:57:51 +08:00
|
|
|
// The SPARC ABI is a bit odd in that it requires a reserved 92-byte
|
|
|
|
// (128 in v9) area in the user's stack, starting at %sp. Thus, the
|
|
|
|
// first part of the stack that can actually be used is located at
|
|
|
|
// %sp + 92.
|
|
|
|
//
|
|
|
|
// We therefore need to add that offset to the total stack size
|
|
|
|
// after all the stack objects are placed by
|
|
|
|
// PrologEpilogInserter calculateFrameObjectOffsets. However, since the stack needs to be
|
|
|
|
// aligned *after* the extra size is added, we need to disable
|
|
|
|
// calculateFrameObjectOffsets's built-in stack alignment, by having
|
|
|
|
// targetHandlesStackFrameRounding return true.
|
|
|
|
|
|
|
|
|
|
|
|
// Add the extra call frame stack size, if needed. (This is the same
|
|
|
|
// code as in PrologEpilogInserter, but also gets disabled by
|
|
|
|
// targetHandlesStackFrameRounding)
|
2016-07-29 02:40:00 +08:00
|
|
|
if (MFI.adjustsStack() && hasReservedCallFrame(MF))
|
|
|
|
NumBytes += MFI.getMaxCallFrameSize();
|
2015-08-27 01:57:51 +08:00
|
|
|
|
|
|
|
// Adds the SPARC subtarget-specific spill area to the stack
|
|
|
|
// size. Also ensures target-required alignment.
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
NumBytes = MF.getSubtarget<SparcSubtarget>().getAdjustedFrameSize(NumBytes);
|
2015-08-27 01:57:51 +08:00
|
|
|
|
|
|
|
// Finally, ensure that the size is sufficiently aligned for the
|
|
|
|
// data on the stack.
|
2016-07-29 02:40:00 +08:00
|
|
|
if (MFI.getMaxAlignment() > 0) {
|
|
|
|
NumBytes = alignTo(NumBytes, MFI.getMaxAlignment());
|
2015-08-27 01:57:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Update stack size with corrected value.
|
2016-07-29 02:40:00 +08:00
|
|
|
MFI.setStackSize(NumBytes);
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
|
|
|
|
emitSPAdjustment(MF, MBB, MBBI, -NumBytes, SAVErr, SAVEri);
|
2010-11-15 08:06:54 +08:00
|
|
|
|
2013-09-26 23:11:00 +08:00
|
|
|
MachineModuleInfo &MMI = MF.getMMI();
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
unsigned regFP = RegInfo.getDwarfRegNum(SP::I6, true);
|
2013-09-26 23:11:00 +08:00
|
|
|
|
|
|
|
// Emit ".cfi_def_cfa_register 30".
|
2014-03-07 14:08:31 +08:00
|
|
|
unsigned CFIIndex =
|
|
|
|
MMI.addFrameInst(MCCFIInstruction::createDefCfaRegister(nullptr, regFP));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
|
|
|
.addCFIIndex(CFIIndex);
|
2014-03-07 14:08:31 +08:00
|
|
|
|
2013-09-26 23:11:00 +08:00
|
|
|
// Emit ".cfi_window_save".
|
2014-03-07 14:08:31 +08:00
|
|
|
CFIIndex = MMI.addFrameInst(MCCFIInstruction::createWindowSave(nullptr));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
|
|
|
.addCFIIndex(CFIIndex);
|
2013-09-26 23:11:00 +08:00
|
|
|
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
unsigned regInRA = RegInfo.getDwarfRegNum(SP::I7, true);
|
|
|
|
unsigned regOutRA = RegInfo.getDwarfRegNum(SP::O7, true);
|
2013-09-26 23:11:00 +08:00
|
|
|
// Emit ".cfi_register 15, 31".
|
2014-03-07 14:08:31 +08:00
|
|
|
CFIIndex = MMI.addFrameInst(
|
|
|
|
MCCFIInstruction::createRegister(nullptr, regOutRA, regInRA));
|
2014-04-29 08:16:46 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(TargetOpcode::CFI_INSTRUCTION))
|
|
|
|
.addCFIIndex(CFIIndex);
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
|
|
|
|
if (NeedsStackRealignment) {
|
|
|
|
// andn %o6, MaxAlign-1, %o6
|
2016-07-29 02:40:00 +08:00
|
|
|
int MaxAlign = MFI.getMaxAlignment();
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::ANDNri), SP::O6).addReg(SP::O6).addImm(MaxAlign - 1);
|
|
|
|
}
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
|
|
|
|
2016-04-01 02:33:38 +08:00
|
|
|
MachineBasicBlock::iterator SparcFrameLowering::
|
2013-02-22 04:05:00 +08:00
|
|
|
eliminateCallFramePseudoInstr(MachineFunction &MF, MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator I) const {
|
2013-04-09 12:37:47 +08:00
|
|
|
if (!hasReservedCallFrame(MF)) {
|
|
|
|
MachineInstr &MI = *I;
|
|
|
|
int Size = MI.getOperand(0).getImm();
|
|
|
|
if (MI.getOpcode() == SP::ADJCALLSTACKDOWN)
|
|
|
|
Size = -Size;
|
2013-11-25 04:23:25 +08:00
|
|
|
|
2013-04-09 12:37:47 +08:00
|
|
|
if (Size)
|
2013-11-25 04:23:25 +08:00
|
|
|
emitSPAdjustment(MF, MBB, I, Size, SP::ADDrr, SP::ADDri);
|
2013-04-09 12:37:47 +08:00
|
|
|
}
|
2016-04-01 02:33:38 +08:00
|
|
|
return MBB.erase(I);
|
2013-02-22 04:05:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-10 20:39:04 +08:00
|
|
|
void SparcFrameLowering::emitEpilogue(MachineFunction &MF,
|
2010-11-15 08:06:54 +08:00
|
|
|
MachineBasicBlock &MBB) const {
|
2013-05-29 12:46:31 +08:00
|
|
|
SparcMachineFunctionInfo *FuncInfo = MF.getInfo<SparcMachineFunctionInfo>();
|
2011-01-14 05:28:52 +08:00
|
|
|
MachineBasicBlock::iterator MBBI = MBB.getLastNonDebugInstr();
|
2010-11-15 08:06:54 +08:00
|
|
|
const SparcInstrInfo &TII =
|
2014-08-05 10:39:49 +08:00
|
|
|
*static_cast<const SparcInstrInfo *>(MF.getSubtarget().getInstrInfo());
|
2010-11-15 08:06:54 +08:00
|
|
|
DebugLoc dl = MBBI->getDebugLoc();
|
|
|
|
assert(MBBI->getOpcode() == SP::RETL &&
|
|
|
|
"Can only put epilog before 'retl' instruction!");
|
2013-06-01 12:51:18 +08:00
|
|
|
if (!FuncInfo->isLeafProc()) {
|
|
|
|
BuildMI(MBB, MBBI, dl, TII.get(SP::RESTORErr), SP::G0).addReg(SP::G0)
|
|
|
|
.addReg(SP::G0);
|
|
|
|
return;
|
|
|
|
}
|
2016-07-29 02:40:00 +08:00
|
|
|
MachineFrameInfo &MFI = MF.getFrameInfo();
|
2013-06-01 12:51:18 +08:00
|
|
|
|
2016-07-29 02:40:00 +08:00
|
|
|
int NumBytes = (int) MFI.getStackSize();
|
2013-06-01 12:51:18 +08:00
|
|
|
if (NumBytes == 0)
|
|
|
|
return;
|
|
|
|
|
2013-11-25 04:23:25 +08:00
|
|
|
emitSPAdjustment(MF, MBB, MBBI, NumBytes, SP::ADDrr, SP::ADDri);
|
2010-11-15 08:06:54 +08:00
|
|
|
}
|
2013-05-17 23:14:34 +08:00
|
|
|
|
|
|
|
bool SparcFrameLowering::hasReservedCallFrame(const MachineFunction &MF) const {
|
2013-06-05 02:33:25 +08:00
|
|
|
// Reserve call frame if there are no variable sized objects on the stack.
|
2016-07-29 02:40:00 +08:00
|
|
|
return !MF.getFrameInfo().hasVarSizedObjects();
|
2013-05-17 23:14:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// hasFP - 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.
|
|
|
|
bool SparcFrameLowering::hasFP(const MachineFunction &MF) const {
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
const TargetRegisterInfo *RegInfo = MF.getSubtarget().getRegisterInfo();
|
|
|
|
|
2016-07-29 02:40:00 +08:00
|
|
|
const MachineFrameInfo &MFI = MF.getFrameInfo();
|
2013-05-17 23:14:34 +08:00
|
|
|
return MF.getTarget().Options.DisableFramePointerElim(MF) ||
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
RegInfo->needsStackRealignment(MF) ||
|
2016-07-29 02:40:00 +08:00
|
|
|
MFI.hasVarSizedObjects() ||
|
|
|
|
MFI.isFrameAddressTaken();
|
2013-05-17 23:14:34 +08:00
|
|
|
}
|
|
|
|
|
2013-05-29 12:46:31 +08:00
|
|
|
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
int SparcFrameLowering::getFrameIndexReference(const MachineFunction &MF, int FI,
|
|
|
|
unsigned &FrameReg) const {
|
|
|
|
const SparcSubtarget &Subtarget = MF.getSubtarget<SparcSubtarget>();
|
2016-07-29 02:40:00 +08:00
|
|
|
const MachineFrameInfo &MFI = MF.getFrameInfo();
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
const SparcRegisterInfo *RegInfo = Subtarget.getRegisterInfo();
|
|
|
|
const SparcMachineFunctionInfo *FuncInfo = MF.getInfo<SparcMachineFunctionInfo>();
|
2016-07-29 02:40:00 +08:00
|
|
|
bool isFixed = MFI.isFixedObjectIndex(FI);
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
|
|
|
|
// Addressable stack objects are accessed using neg. offsets from
|
|
|
|
// %fp, or positive offsets from %sp.
|
|
|
|
bool UseFP;
|
|
|
|
|
|
|
|
// Sparc uses FP-based references in general, even when "hasFP" is
|
|
|
|
// false. That function is rather a misnomer, because %fp is
|
|
|
|
// actually always available, unless isLeafProc.
|
|
|
|
if (FuncInfo->isLeafProc()) {
|
|
|
|
// If there's a leaf proc, all offsets need to be %sp-based,
|
|
|
|
// because we haven't caused %fp to actually point to our frame.
|
|
|
|
UseFP = false;
|
|
|
|
} else if (isFixed) {
|
|
|
|
// Otherwise, argument access should always use %fp.
|
|
|
|
UseFP = true;
|
|
|
|
} else if (RegInfo->needsStackRealignment(MF)) {
|
|
|
|
// If there is dynamic stack realignment, all local object
|
|
|
|
// references need to be via %sp, to take account of the
|
|
|
|
// re-alignment.
|
|
|
|
UseFP = false;
|
|
|
|
} else {
|
|
|
|
// Finally, default to using %fp.
|
|
|
|
UseFP = true;
|
|
|
|
}
|
|
|
|
|
2016-07-29 02:40:00 +08:00
|
|
|
int64_t FrameOffset = MF.getFrameInfo().getObjectOffset(FI) +
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
Subtarget.getStackPointerBias();
|
|
|
|
|
|
|
|
if (UseFP) {
|
|
|
|
FrameReg = RegInfo->getFrameRegister(MF);
|
|
|
|
return FrameOffset;
|
|
|
|
} else {
|
|
|
|
FrameReg = SP::O6; // %sp
|
2016-07-29 02:40:00 +08:00
|
|
|
return FrameOffset + MF.getFrameInfo().getStackSize();
|
[Sparc] Support user-specified stack object overalignment.
Note: I do not implement a base pointer, so it's still impossible to
have dynamic realignment AND dynamic alloca in the same function.
This also moves the code for determining the frame index reference
into getFrameIndexReference, where it belongs, instead of inline in
eliminateFrameIndex.
[Begin long-winded screed]
Now, stack realignment for Sparc is actually a silly thing to support,
because the Sparc ABI has no need for it -- unlike the situation on
x86, the stack is ALWAYS aligned to the required alignment for the CPU
instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9.
However, LLVM unfortunately implements user-specified overalignment
using stack realignment support, so for now, I'm going to go along
with that tradition. GCC instead treats objects which have alignment
specification greater than the maximum CPU-required alignment for the
target as a separate block of stack memory, with their own virtual
base pointer (which gets aligned). Doing it that way avoids needing to
implement per-target support for stack realignment, except for the
targets which *actually* have an ABI-specified stack alignment which
is too small for the CPU's requirements.
Further unfortunately in LLVM, the default canRealignStack for all
targets effectively returns true, despite that implementing that is
something a target needs to do specifically. So, the previous behavior
on Sparc was to silently ignore the user's specified stack
alignment. Ugh.
Yet MORE unfortunate, if a target actually does return false from
canRealignStack, that also causes the user-specified alignment to be
*silently ignored*, rather than emitting an error.
(I started looking into fixing that last, but it broke a bunch of
tests, because LLVM actually *depends* on having it silently ignored:
some architectures (e.g. non-linux i386) have smaller stack alignment
than spilled-register alignment. But, the fact that a register needs
spilling is not known until within the register allocator. And by that
point, the decision to not reserve the frame pointer has been frozen
in place. And without a frame pointer, stack realignment is not
possible. So, canRealignStack() returns false, and
needsStackRealignment() then returns false, assuming everyone can just
go on their merry way assuming the alignment requirements were
probably just suggestions after-all. Sigh...)
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245668
2015-08-21 12:17:56 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-29 20:10:42 +08:00
|
|
|
static bool LLVM_ATTRIBUTE_UNUSED verifyLeafProcRegUse(MachineRegisterInfo *MRI)
|
2013-05-29 12:46:31 +08:00
|
|
|
{
|
|
|
|
|
|
|
|
for (unsigned reg = SP::I0; reg <= SP::I7; ++reg)
|
2015-07-15 01:52:07 +08:00
|
|
|
if (!MRI->reg_nodbg_empty(reg))
|
2013-05-29 12:46:31 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
for (unsigned reg = SP::L0; reg <= SP::L7; ++reg)
|
2015-07-15 01:52:07 +08:00
|
|
|
if (!MRI->reg_nodbg_empty(reg))
|
2013-05-29 12:46:31 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SparcFrameLowering::isLeafProc(MachineFunction &MF) const
|
|
|
|
{
|
|
|
|
|
|
|
|
MachineRegisterInfo &MRI = MF.getRegInfo();
|
2016-07-29 02:40:00 +08:00
|
|
|
MachineFrameInfo &MFI = MF.getFrameInfo();
|
2013-05-29 12:46:31 +08:00
|
|
|
|
2016-07-29 02:40:00 +08:00
|
|
|
return !(MFI.hasCalls() // has calls
|
2015-07-15 01:52:07 +08:00
|
|
|
|| !MRI.reg_nodbg_empty(SP::L0) // Too many registers needed
|
|
|
|
|| !MRI.reg_nodbg_empty(SP::O6) // %SP is used
|
|
|
|
|| hasFP(MF)); // need %FP
|
2013-05-29 12:46:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SparcFrameLowering::remapRegsForLeafProc(MachineFunction &MF) const {
|
|
|
|
MachineRegisterInfo &MRI = MF.getRegInfo();
|
2013-06-05 02:33:25 +08:00
|
|
|
// Remap %i[0-7] to %o[0-7].
|
2013-05-29 12:46:31 +08:00
|
|
|
for (unsigned reg = SP::I0; reg <= SP::I7; ++reg) {
|
2015-07-15 01:52:07 +08:00
|
|
|
if (MRI.reg_nodbg_empty(reg))
|
2013-05-29 12:46:31 +08:00
|
|
|
continue;
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
|
|
|
|
unsigned mapped_reg = reg - SP::I0 + SP::O0;
|
2015-07-15 01:52:07 +08:00
|
|
|
assert(MRI.reg_nodbg_empty(mapped_reg));
|
2013-05-29 12:46:31 +08:00
|
|
|
|
2013-06-05 02:33:25 +08:00
|
|
|
// Replace I register with O register.
|
2013-05-29 12:46:31 +08:00
|
|
|
MRI.replaceRegWith(reg, mapped_reg);
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
|
|
|
|
// Also replace register pair super-registers.
|
|
|
|
if ((reg - SP::I0) % 2 == 0) {
|
|
|
|
unsigned preg = (reg - SP::I0) / 2 + SP::I0_I1;
|
|
|
|
unsigned mapped_preg = preg - SP::I0_I1 + SP::O0_O1;
|
|
|
|
MRI.replaceRegWith(preg, mapped_preg);
|
|
|
|
}
|
2013-05-29 12:46:31 +08:00
|
|
|
}
|
|
|
|
|
2013-07-31 03:53:10 +08:00
|
|
|
// Rewrite MBB's Live-ins.
|
|
|
|
for (MachineFunction::iterator MBB = MF.begin(), E = MF.end();
|
|
|
|
MBB != E; ++MBB) {
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
for (unsigned reg = SP::I0_I1; reg <= SP::I6_I7; ++reg) {
|
|
|
|
if (!MBB->isLiveIn(reg))
|
|
|
|
continue;
|
|
|
|
MBB->removeLiveIn(reg);
|
|
|
|
MBB->addLiveIn(reg - SP::I0_I1 + SP::O0_O1);
|
|
|
|
}
|
2013-07-31 03:53:10 +08:00
|
|
|
for (unsigned reg = SP::I0; reg <= SP::I7; ++reg) {
|
|
|
|
if (!MBB->isLiveIn(reg))
|
|
|
|
continue;
|
|
|
|
MBB->removeLiveIn(reg);
|
|
|
|
MBB->addLiveIn(reg - SP::I0 + SP::O0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-29 12:46:31 +08:00
|
|
|
assert(verifyLeafProcRegUse(&MRI));
|
2016-04-29 23:22:48 +08:00
|
|
|
#ifdef EXPENSIVE_CHECKS
|
2013-05-29 12:46:31 +08:00
|
|
|
MF.verify(0, "After LeafProc Remapping");
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-07-15 01:17:13 +08:00
|
|
|
void SparcFrameLowering::determineCalleeSaves(MachineFunction &MF,
|
|
|
|
BitVector &SavedRegs,
|
|
|
|
RegScavenger *RS) const {
|
|
|
|
TargetFrameLowering::determineCalleeSaves(MF, SavedRegs, RS);
|
2013-05-29 12:46:31 +08:00
|
|
|
if (!DisableLeafProc && isLeafProc(MF)) {
|
|
|
|
SparcMachineFunctionInfo *MFI = MF.getInfo<SparcMachineFunctionInfo>();
|
|
|
|
MFI->setLeafProc(true);
|
|
|
|
|
|
|
|
remapRegsForLeafProc(MF);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|