That is also the conclusions I made.
- Move the zone (4) to the callee if need be. You know that if your
caller had more than 8 output parameters, the last parameters are set
on the stack in zone (3).
- However, it seems to me that in the case of :
void foo (void)
{
...
bar (param1, param2, ..., param9);
...
ptr = alloca (size);
...
bar (param1, param2, ..., param9);
}
In this case, foo would need to add space for param9 on the stack for
the call to bar.
However, later in the function, it would need to perform an alloca.
Since there is another call to bar, it would need to add again some
space for param9 on the stack.
Therefore the stack would look like this :
(5) Space for param9
(6) Alloca space for ptr
(7) Space for param9
Except if there is a way to tell the compiler to retrieve space (5)
before performing the alloca in order to get this:
(6) Alloca space for ptr (retrieved space (5))
(7) Space for param9
Can this be done when expanding the alloca in order to first pop the
stack, then alloca a bit more for the parameters ? However, this needs
also to take precautions when popping the alloca's from the stack.
Thanks for your input and help,
Jean Christophe Beyler
On Tue, Jan 19, 2010 at 9:04 AM, Mikael Pettersson <mi...@it.uu.se> wrote:
> On Mon, 18 Jan 2010 13:55:16 -0500, Jean Christophe Beyler wrote:
>>I have a current issue on my port. Basically the stack is defined as follows :
>>
>>1) CALL_USED save area
>>2) Local variables
>>3) Caller arguments passed on the stack
>>4) 8 words to save arguments passed in registers, even if not passed
>>
>>Now, this was done because we have defined 8 output registers,
>>therefore zone (3) is not used except if we call a function with more
>>than 8 parameters.
>>
>>(4) is only used if we have va_arg functions that will then spill the
>>8 input registers on the stack and call the va_arg function.
>>
>>This is done, to my understanding for our ABI, because, in the case of
>>a va_arg function, we want the parameters consecutively store in
>>memory.
>
> That's indeed a desirable property.
>
>>However, this brings me to 2 problems :
>>
>>1) If there are no va_arg function calls, there still is 8 words
>>wasted on the stack per function call still active on the stack.
>>
>>2) If there is an alloca, then GCC moves the stack pointer but without
>>trying to get back those 8 words or even the space for (3).
>>
>>
>>I am currently working on not having that wasted space. I see two options:
>>
>>1) Change the ABI to go closer to what I have seen in the MIPS port :
>> - The zone (4) is handled by the callee
>> - However, I'll still have the wasted space (4) when an alloca is used no
>> ?
>
> Actually, zone (4) should just be deleted entirely from the ABI.
> That is, all the ABI should specify is that non-register arguments
> are in the caller's frame starting exactly at the stack pointer.
>
> For non-varargs calls, there's no waste.
>
> For varargs calls, the callee can allocate its frame and save the
> incoming register arguments at the top of its own frame, establishing
> the all-arguments-are-stored-consecutively property without burdening
> the caller or the ABI.
>
> An alloca() in the callee should just adjust the stack pointer and
> ignore the register arguments save area at the top of the frame.
>
> /Mikael
>
