mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-19 19:12:56 +02:00
Reserve a stack slot if the function adjusts the stack but doesn't
simplify the call frame pseudo instructions. In that situation, the calculations for estimating the stack size will be way off, leading to not having an emergency spill slot when we need one. It should be possible to be more precise about tracking the adjustment values, but not really necessary for correctness. Upcoming cleanups for PEI in general will render that moot. llvm-svn: 110258
This commit is contained in:
parent
ecaa9f6ba4
commit
ece51f94db
@ -851,13 +851,18 @@ ARMBaseRegisterInfo::processFunctionBeforeCalleeSavedScan(MachineFunction &MF,
|
||||
// slot of the previous FP. Also, if we have variable sized objects in the
|
||||
// function, stack slot references will often be negative, and some of
|
||||
// our instructions are positive-offset only, so conservatively consider
|
||||
// that case to want a spill slot (or register) as well.
|
||||
// that case to want a spill slot (or register) as well. Similarly, if
|
||||
// the function adjusts the stack pointer during execution and the
|
||||
// adjustments aren't already part of our stack size estimate, our offset
|
||||
// calculations may be off, so be conservative.
|
||||
// FIXME: We could add logic to be more precise about negative offsets
|
||||
// and which instructions will need a scratch register for them. Is it
|
||||
// worth the effort and added fragility?
|
||||
bool BigStack =
|
||||
(RS && (estimateStackSize(MF) + (hasFP(MF) ? 4:0) >=
|
||||
estimateRSStackSizeLimit(MF))) || MFI->hasVarSizedObjects();
|
||||
estimateRSStackSizeLimit(MF))
|
||||
|| MFI->hasVarSizedObjects()
|
||||
|| (MFI->adjustsStack() && !canSimplifyCallFramePseudos(MF)));
|
||||
|
||||
bool ExtraCSSpill = false;
|
||||
if (BigStack || !CanEliminateFrame || cannotEliminateFrame(MF)) {
|
||||
|
Loading…
Reference in New Issue
Block a user