Re: About "STARTING_FRAME_OFFSET" definition

[redriver jiang <jiang dot redriver at gmail dot com>]

Hi,

Thanks!
I  also find the doc describing the "HARD_FRAME_POINTER_REGNUM" and

"FRAME_POINTER_REGNUM" in "gcc internals", chapter "Registers That
Address the Stack Frame".

It is really "usual" way to handle this similar cases.

redriver


2010/3/24 Richard Henderson <rth@redhat.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~
>