llvm dev - Oct 2006 - [LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?

> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the
call
> aren't set right, or you have declared a SP offset.  It doesn't
look like
> the ARM backend does this, so this is probably the problem.
The ARM backend currently doesn't use a frame pointer. It uses the
same technique of the PPC backend to avoid add/subs around calls. In
the PPC backend we have:

----------------------------------------------------------------------
if (MFI->hasCalls()) {
    NumBytes += MFI->getMaxCallFrameSize();
  }
if ((NumBytes == 0) || (NumBytes <= 224 && !HasFP &&
!MFI->hasCalls()
&&   MaxAlign <= TargetAlign)) {
    MFI->setStackSize(0);
    return;
  }
  unsigned Align = std::max(TargetAlign, MaxAlign);
  unsigned GPRSize = 4;
  unsigned Size = HasFP ? GPRSize + GPRSize : GPRSize;
  NumBytes = (NumBytes+Size+Align-1)/Align*Align;
-----------------------------------------------------------------------------------
Numbytes was correctly aligned before adding getMaxCallFrameSize, but
it must be aligned again afterwards.
> If the PEI stuff knows the right offsets, it should do the alignment for
> you.
It does. The problem is that, when a second alignment must be made,
some stack may be wasted.
> -Chris
Thanks,
Rafael

On Sat, 7 Oct 2006, [UTF-8] Rafael Esp?ndola wrote:
>> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around
the call
>> aren't set right, or you have declared a SP offset.  It doesn't
look like
>> the ARM backend does this, so this is probably the problem.
> The ARM backend currently doesn't use a frame pointer. It uses the
> same technique of the PPC backend to avoid add/subs around calls. In
> the PPC backend we have:
That is irrelevant.  The PEI code needs to know how much stack space is 
required for each call to allocate and align the stack frame properly.  It 
gets this info from the ADJCALLSTACK instructions.

Further, you *do* need to have a frame pointer if the function contains 
any dynamic allocas.  In that case, the SP isn't fixed within a function. 
You may not care about this right now, but it is required to support C99 
VLA's and the 'alloca' C function.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

> That is irrelevant.  The PEI code needs to know how much stack space is
> required for each call to allocate and align the stack frame properly.  It
> gets this info from the ADJCALLSTACK instructions.
I see. Looking at PEI::calculateCalleeSavedRegisters shows that the
ADJCALLSTACK instructions is used to set up MaxCallFrameSize. Adding
debug prints also show that in the example code the ADJCALLSTACK
argument is 4. I believe that this is the correct argument for only a
32bit integer is passed on the stack.

The problem is that MaxCallFrameSize is **not** used in
PEI::calculateFrameObjectOffsets and it must then be used in the
target specific code. The only architecture that doesn't adds
MaxCallFrameSize to the value returned by getStackSize is Sparc. This
is so because the Sparc backend generates add/sub pairs around call
sites.
> Further, you *do* need to have a frame pointer if the function contains
> any dynamic allocas.  In that case, the SP isn't fixed within a
function.
> You may not care about this right now, but it is required to support C99
> VLA's and the 'alloca' C function.
Sure. Currently I am implementing the next missing feature that causes
a gcc bootstrap to fail. It shouldn't be long before I hit a VLA :-)
> -Chris
Thanks,
Rafael