Re: function arguments offset computation with -fomit-frame-pointer

[Jim Wilson <wilson at tuliptree dot org>]

Bernardo Innocenti wrote:
> With frame pointer enabled everything is fine, but I still have problems
> with -fomit-frame-pointer. It's not yet clear to me how the rest of the
> compiler gets to know how much data the prologue has pushed on the stack
> to compute the offset to fetch incoming function arguments from.

Only reload needs to know about frame offsets.  It uses get_frame_size 
to get the stack frame size.  If it needs to know offsets between 
special registers like sp/fp, then we use INITIAL_FRAME_POINTER_OFFSET 
if it isn't an eliminable register.  Or we use the eliminable register 
macros, e.g. INITIAL_ELIMINATION_OFFSET.

The prologue/epilogue also need to know about the frame size, so that 
they agree on the size of it.  A common method here is to define a 
compute_frame_size function which lays out the frame, including the size 
and where all registers will be stored.  This calls get_frame_size to 
get the size of the area used by local variables.  compute_frame_size is 
then used by the INITIAL_*_OFFSET macros.

There are many ports that use this scheme.  Try looking at one of them. 
 This can get a bit complicated, so it may take some time to get this 
working.

> I also have a more m68k-specific question: the code path for creating
> room for the frame when no frame pointer always adds 4 bytes to the
> required frame size. Is that done to get the same offset that
> link/unlink would have done? Why is that necessary?

Probably nobody knows anymore, it has been there for well over a decard, 
but link/unlink space for the return address is the obvious guess. 
Maybe the problem is that INITIAL_FRAME_POINTER_OFFSET isn't checking 
frame_pointer_needed, and thus we always need to add the 4 bytes to make 
INITIAL_FRAME_POINTER_OFFSET work?  If so, then fixing that macro would 
let you get rid of the extra 4 bytes in the prologue code.

Jim