This section describes the macros that output function entry (prologue) and exit (epilogue) code.
FUNCTION_PROLOGUE (file, size)
regs_ever_live: element r is nonzero if hard register r is used anywhere within the function. This implies the function prologue should save register r, provided it is not one of the call-used registers. (
FUNCTION_EPILOGUEmust likewise use
regs_ever_live.) On machines that have "register windows", the function entry code does not save on the stack the registers that are in the windows, even if they are supposed to be preserved by function calls; instead it takes appropriate steps to "push" the register stack, if any non-call-used registers are used in the function. On machines where functions may or may not have frame-pointers, the function entry code must vary accordingly; it must set up the frame pointer if one is wanted, and not otherwise. To determine whether a frame pointer is in wanted, the macro can refer to the variable
frame_pointer_needed. The variable's value will be 1 at run time in a function that needs a frame pointer. See section Eliminating Frame Pointer and Arg Pointer. The function entry code is responsible for allocating any stack space required for the function. This stack space consists of the regions listed below. In most cases, these regions are allocated in the order listed, with the last listed region closest to the top of the stack (the lowest address if
STACK_GROWS_DOWNWARDis defined, and the highest address if it is not defined). You can use a different order for a machine if doing so is more convenient or required for compatibility reasons. Except in cases where required by standard or by a debugger, there is no reason why the stack layout used by GCC need agree with that used by other compilers for a machine.
current_function_pretend_args_sizebytes of uninitialized space just underneath the first argument arriving on the stack. (This may not be at the very start of the allocated stack region if the calling sequence has pushed anything else since pushing the stack arguments. But usually, on such machines, nothing else has been pushed yet, because the function prologue itself does all the pushing.) This region is used on machines where an argument may be passed partly in registers and partly in memory, and, in some cases to support the features in `varargs.h' and `stdargs.h'.
ACCUMULATE_OUTGOING_ARGSis defined, a region of
current_function_outgoing_args_sizebytes to be used for outgoing argument lists of the function. See section Passing Function Arguments on the Stack.
FUNCTION_EPILOGUEto treat leaf functions specially. The C variable
leaf_functionis nonzero for such a function.
FUNCTION_EPILOGUE (file, size)
FUNCTION_PROLOGUE, and the registers to restore are determined from
CALL_USED_REGISTERSin the same way. On some machines, there is a single instruction that does all the work of returning from the function. On these machines, give that instruction the name `return' and do not define the macro
FUNCTION_EPILOGUEat all. Do not define a pattern named `return' if you want the
FUNCTION_EPILOGUEto be used. If you want the target switches to control whether return instructions or epilogues are used, define a `return' pattern with a validity condition that tests the target switches appropriately. If the `return' pattern's validity condition is false, epilogues will be used. On machines where functions may or may not have frame-pointers, the function exit code must vary accordingly. Sometimes the code for these two cases is completely different. To determine whether a frame pointer is wanted, the macro can refer to the variable
frame_pointer_needed. The variable's value will be 1 when compiling a function that needs a frame pointer. Normally,
FUNCTION_EPILOGUEmust treat leaf functions specially. The C variable
leaf_functionis nonzero for such a function. See section Handling Leaf Functions. On some machines, some functions pop their arguments on exit while others leave that for the caller to do. For example, the 68020 when given `-mrtd' pops arguments in functions that take a fixed number of arguments. Your definition of the macro
RETURN_POPS_ARGSdecides which functions pop their own arguments.
FUNCTION_EPILOGUEneeds to know what was decided. The variable that is called
current_function_pops_argsis the number of bytes of its arguments that a function should pop. See section How Scalar Function Values Are Returned.
ELIGIBLE_FOR_EPILOGUE_DELAY (insn, n)
DELAY_SLOTS_FOR_EPILOGUEreturns). If you reject a particular insn for a given delay slot, in principle, it may be reconsidered for a subsequent delay slot. Also, other insns may (at least in principle) be considered for the so far unfilled delay slot. The insns accepted to fill the epilogue delay slots are put in an RTL list made with
insn_listobjects, stored in the variable
current_function_epilogue_delay_list. The insn for the first delay slot comes first in the list. Your definition of the macro
FUNCTION_EPILOGUEshould fill the delay slots by outputting the insns in this list, usually by calling
final_scan_insn. You need not define this macro if you did not define
ASM_OUTPUT_MI_THUNK (file, thunk_fndecl, delta, function)
thispointer in C++. This is the incoming argument before the function prologue, e.g. `%o0' on a sparc. The addition must preserve the values of all other incoming arguments. After the addition, emit code to jump to function, which is a
FUNCTION_DECL. This is a direct pure jump, not a call, and does not touch the return address. Hence returning from FUNCTION will return to whoever called the current `thunk'. The effect must be as if function had been called directly with the adjusted first argument. This macro is responsible for emitting all of the code for a thunk function;
FUNCTION_EPILOGUEare not invoked. The thunk_fndecl is redundant. (delta and function have already been extracted from it.) It might possibly be useful on some targets, but probably not. If you do not define this macro, the target-independent code in the C++ frontend will generate a less efficient heavyweight thunk that calls function instead of jumping to it. The generic approach does not support varargs.