Re: About "STARTING_FRAME_OFFSET" definition

[Richard Henderson <rth at redhat dot com>]

On 03/23/2010 05:55 AM, redriver jiang wrote:
> Hi all,
> 
> Can this "STARTING_FRAME_OFFSET" macro be defined to be a non-constant
> value ( changes with the "current_function_args_size")?
> 
> As the target process has "FP+offset" with postive "offset"( stack
> grows upward, and parameters in stack grows downward), for example,
> 
> call foo( arg1, arg2, arg3,arg4), after foo's prologue, the stack is like this:
> 
>                                              <---- low address
>          |--------------------------------|
> 	 |     Incoming arg4       | <-------------FP
>          |--------------------------------|
> 	 |      Incoming arg3      |
>          |--------------------------------|
> 	 |     Incoming arg2       |
> 	 |--------------------------------|
> 	 |     Incoming arg1       | <---------------ARG
> 	 |--------------------------------|
> 	 |	return PC of foo   |
> 	 |--------------------------------|
> 	 |		saved regs  |
> 	 |--------------------------------|
> 	 |		old FP        |
> 	 |--------------------------------|
> 	 |         local var0         |
> 	 |--------------------------------|
> 			                    <---- high address
> 
>  "STARTING_FRAME_OFFSET" means the offset between FP and the first
> local variable, in this situation,
> 
> STARTING_FRAME_OFFSE = current_function_args_size+ size(PC in stack) +
> size(saved regs) + size(old FP).
> 
> so, "STARTING_FRAME_OFFSET" depends on the
> "current_function_args_size", which is a GCC internal variable.
> 
> Is this stack layout suitable?

It's possible to create this stack layout, yes.

STARTING_FRAME_OFFSET doesn't really ought not enter into it, I don't think.

What you'll want instead is to have a separate "soft" frame_pointer_rtx
and hard_frame_pointer_rtx.  Then during register allocation you eliminate
from the soft frame pointer to the hard frame pointer with an offset you
calculate at that point.  There are many examples of this in existing ports,
including the i386 port.

The reason why you want to handle this via elimination rather than a fixed
offset during initial rtl generation is your "saved regs" field there, which
of course will vary in size depending on what registers get spilled.

So I would begin with STARTING_FRAME_OFFSET=0 and have the soft frame pointer
point to "local var0" in your picture.  Then your INITIAL_ELIMINATION_OFFSET
function would map:

  ARG_POINTER_REGNUM	HARD_FRAME_POINTER_REGNUM
  = -current_function_args_size

  FRAME_POINTER_REGNUM	HARD_FRAME_POINTER_REGNUM
  = -(sizeof(saved_regs) + sizeof(FP) + sizeof(return PC) + current_function_args_size)



r~