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 <r...@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~ >
