should PEI::calculateFrameObjectOffsets align the stack?

In ARM the stack should be 8 bytes aligned during function calls. A
function that has at least one function call then has a stack size of
8 bytes. PEI::calculateFrameObjectOffsets corretly computes this
correctly.

The problem is that the alignment is computed before adding space for
the call frame size. This is done in emitProlog. Currently the ARM
backend has a bug in that it doesn't align the new stack.

Fixing this bug is simple, but it introduces an inefficiency due to
aligning twice. For example, consider f:

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.

If the PEI stuff knows the right offsets, it should do the alignment for you.

-Chris

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

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 :slight_smile:

-Chris

Thanks,
Rafael

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.

Yep, that sounds right.

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 :slight_smile:

Nice!

-Chris