mirror of
https://github.com/pmret/gcc-papermario.git
synced 2024-11-09 12:22:38 +01:00
962 lines
45 KiB
Plaintext
962 lines
45 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.67 from the
|
||
input file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||
Boston, MA 02111-1307 USA
|
||
|
||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998
|
||
Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the sections entitled "GNU General Public License," "Funding for
|
||
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
|
||
included exactly as in the original, and provided that the entire
|
||
resulting derived work is distributed under the terms of a permission
|
||
notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the sections entitled "GNU General Public
|
||
License," "Funding for Free Software," and "Protect Your Freedom--Fight
|
||
`Look And Feel'", and this permission notice, may be included in
|
||
translations approved by the Free Software Foundation instead of in the
|
||
original English.
|
||
|
||
|
||
File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
|
||
|
||
Registers That Address the Stack Frame
|
||
--------------------------------------
|
||
|
||
This discusses registers that address the stack frame.
|
||
|
||
`STACK_POINTER_REGNUM'
|
||
The register number of the stack pointer register, which must also
|
||
be a fixed register according to `FIXED_REGISTERS'. On most
|
||
machines, the hardware determines which register this is.
|
||
|
||
`FRAME_POINTER_REGNUM'
|
||
The register number of the frame pointer register, which is used to
|
||
access automatic variables in the stack frame. On some machines,
|
||
the hardware determines which register this is. On other
|
||
machines, you can choose any register you wish for this purpose.
|
||
|
||
`HARD_FRAME_POINTER_REGNUM'
|
||
On some machines the offset between the frame pointer and starting
|
||
offset of the automatic variables is not known until after register
|
||
allocation has been done (for example, because the saved registers
|
||
are between these two locations). On those machines, define
|
||
`FRAME_POINTER_REGNUM' the number of a special, fixed register to
|
||
be used internally until the offset is known, and define
|
||
`HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
|
||
used for the frame pointer.
|
||
|
||
You should define this macro only in the very rare circumstances
|
||
when it is not possible to calculate the offset between the frame
|
||
pointer and the automatic variables until after register
|
||
allocation has been completed. When this macro is defined, you
|
||
must also indicate in your definition of `ELIMINABLE_REGS' how to
|
||
eliminate `FRAME_POINTER_REGNUM' into either
|
||
`HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
|
||
|
||
Do not define this macro if it would be the same as
|
||
`FRAME_POINTER_REGNUM'.
|
||
|
||
`ARG_POINTER_REGNUM'
|
||
The register number of the arg pointer register, which is used to
|
||
access the function's argument list. On some machines, this is
|
||
the same as the frame pointer register. On some machines, the
|
||
hardware determines which register this is. On other machines,
|
||
you can choose any register you wish for this purpose. If this is
|
||
not the same register as the frame pointer register, then you must
|
||
mark it as a fixed register according to `FIXED_REGISTERS', or
|
||
arrange to be able to eliminate it (*note Elimination::.).
|
||
|
||
`RETURN_ADDRESS_POINTER_REGNUM'
|
||
The register number of the return address pointer register, which
|
||
is used to access the current function's return address from the
|
||
stack. On some machines, the return address is not at a fixed
|
||
offset from the frame pointer or stack pointer or argument
|
||
pointer. This register can be defined to point to the return
|
||
address on the stack, and then be converted by `ELIMINABLE_REGS'
|
||
into either the frame pointer or stack pointer.
|
||
|
||
Do not define this macro unless there is no other way to get the
|
||
return address from the stack.
|
||
|
||
`STATIC_CHAIN_REGNUM'
|
||
`STATIC_CHAIN_INCOMING_REGNUM'
|
||
Register numbers used for passing a function's static chain
|
||
pointer. If register windows are used, the register number as
|
||
seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
|
||
while the register number as seen by the calling function is
|
||
`STATIC_CHAIN_REGNUM'. If these registers are the same,
|
||
`STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
|
||
|
||
The static chain register need not be a fixed register.
|
||
|
||
If the static chain is passed in memory, these macros should not be
|
||
defined; instead, the next two macros should be defined.
|
||
|
||
`STATIC_CHAIN'
|
||
`STATIC_CHAIN_INCOMING'
|
||
If the static chain is passed in memory, these macros provide rtx
|
||
giving `mem' expressions that denote where they are stored.
|
||
`STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
|
||
seen by the calling and called functions, respectively. Often the
|
||
former will be at an offset from the stack pointer and the latter
|
||
at an offset from the frame pointer.
|
||
|
||
The variables `stack_pointer_rtx', `frame_pointer_rtx', and
|
||
`arg_pointer_rtx' will have been initialized prior to the use of
|
||
these macros and should be used to refer to those items.
|
||
|
||
If the static chain is passed in a register, the two previous
|
||
macros should be defined instead.
|
||
|
||
|
||
File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
|
||
|
||
Eliminating Frame Pointer and Arg Pointer
|
||
-----------------------------------------
|
||
|
||
This is about eliminating the frame pointer and arg pointer.
|
||
|
||
`FRAME_POINTER_REQUIRED'
|
||
A C expression which is nonzero if a function must have and use a
|
||
frame pointer. This expression is evaluated in the reload pass.
|
||
If its value is nonzero the function will have a frame pointer.
|
||
|
||
The expression can in principle examine the current function and
|
||
decide according to the facts, but on most machines the constant 0
|
||
or the constant 1 suffices. Use 0 when the machine allows code to
|
||
be generated with no frame pointer, and doing so saves some time
|
||
or space. Use 1 when there is no possible advantage to avoiding a
|
||
frame pointer.
|
||
|
||
In certain cases, the compiler does not know how to produce valid
|
||
code without a frame pointer. The compiler recognizes those cases
|
||
and automatically gives the function a frame pointer regardless of
|
||
what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
|
||
them.
|
||
|
||
In a function that does not require a frame pointer, the frame
|
||
pointer register can be allocated for ordinary usage, unless you
|
||
mark it as a fixed register. See `FIXED_REGISTERS' for more
|
||
information.
|
||
|
||
`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
|
||
A C statement to store in the variable DEPTH-VAR the difference
|
||
between the frame pointer and the stack pointer values immediately
|
||
after the function prologue. The value would be computed from
|
||
information such as the result of `get_frame_size ()' and the
|
||
tables of registers `regs_ever_live' and `call_used_regs'.
|
||
|
||
If `ELIMINABLE_REGS' is defined, this macro will be not be used and
|
||
need not be defined. Otherwise, it must be defined even if
|
||
`FRAME_POINTER_REQUIRED' is defined to always be true; in that
|
||
case, you may set DEPTH-VAR to anything.
|
||
|
||
`ELIMINABLE_REGS'
|
||
If defined, this macro specifies a table of register pairs used to
|
||
eliminate unneeded registers that point into the stack frame. If
|
||
it is not defined, the only elimination attempted by the compiler
|
||
is to replace references to the frame pointer with references to
|
||
the stack pointer.
|
||
|
||
The definition of this macro is a list of structure
|
||
initializations, each of which specifies an original and
|
||
replacement register.
|
||
|
||
On some machines, the position of the argument pointer is not
|
||
known until the compilation is completed. In such a case, a
|
||
separate hard register must be used for the argument pointer.
|
||
This register can be eliminated by replacing it with either the
|
||
frame pointer or the argument pointer, depending on whether or not
|
||
the frame pointer has been eliminated.
|
||
|
||
In this case, you might specify:
|
||
#define ELIMINABLE_REGS \
|
||
{{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
|
||
{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
|
||
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
|
||
|
||
Note that the elimination of the argument pointer with the stack
|
||
pointer is specified first since that is the preferred elimination.
|
||
|
||
`CAN_ELIMINATE (FROM-REG, TO-REG)'
|
||
A C expression that returns non-zero if the compiler is allowed to
|
||
try to replace register number FROM-REG with register number
|
||
TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
|
||
defined, and will usually be the constant 1, since most of the
|
||
cases preventing register elimination are things that the compiler
|
||
already knows about.
|
||
|
||
`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
|
||
This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
|
||
specifies the initial difference between the specified pair of
|
||
registers. This macro must be defined if `ELIMINABLE_REGS' is
|
||
defined.
|
||
|
||
`LONGJMP_RESTORE_FROM_STACK'
|
||
Define this macro if the `longjmp' function restores registers from
|
||
the stack frames, rather than from those saved specifically by
|
||
`setjmp'. Certain quantities must not be kept in registers across
|
||
a call to `setjmp' on such machines.
|
||
|
||
|
||
File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
|
||
|
||
Passing Function Arguments on the Stack
|
||
---------------------------------------
|
||
|
||
The macros in this section control how arguments are passed on the
|
||
stack. See the following section for other macros that control passing
|
||
certain arguments in registers.
|
||
|
||
`PROMOTE_PROTOTYPES'
|
||
Define this macro if an argument declared in a prototype as an
|
||
integral type smaller than `int' should actually be passed as an
|
||
`int'. In addition to avoiding errors in certain cases of
|
||
mismatch, it also makes for better code on certain machines.
|
||
|
||
`PUSH_ROUNDING (NPUSHED)'
|
||
A C expression that is the number of bytes actually pushed onto the
|
||
stack when an instruction attempts to push NPUSHED bytes.
|
||
|
||
If the target machine does not have a push instruction, do not
|
||
define this macro. That directs GNU CC to use an alternate
|
||
strategy: to allocate the entire argument block and then store the
|
||
arguments into it.
|
||
|
||
On some machines, the definition
|
||
|
||
#define PUSH_ROUNDING(BYTES) (BYTES)
|
||
|
||
will suffice. But on other machines, instructions that appear to
|
||
push one byte actually push two bytes in an attempt to maintain
|
||
alignment. Then the definition should be
|
||
|
||
#define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
|
||
|
||
`ACCUMULATE_OUTGOING_ARGS'
|
||
If defined, the maximum amount of space required for outgoing
|
||
arguments will be computed and placed into the variable
|
||
`current_function_outgoing_args_size'. No space will be pushed
|
||
onto the stack for each call; instead, the function prologue should
|
||
increase the stack frame size by this amount.
|
||
|
||
Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
|
||
not proper.
|
||
|
||
`REG_PARM_STACK_SPACE (FNDECL)'
|
||
Define this macro if functions should assume that stack space has
|
||
been allocated for arguments even when their values are passed in
|
||
registers.
|
||
|
||
The value of this macro is the size, in bytes, of the area
|
||
reserved for arguments passed in registers for the function
|
||
represented by FNDECL.
|
||
|
||
This space can be allocated by the caller, or be a part of the
|
||
machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
|
||
which.
|
||
|
||
`MAYBE_REG_PARM_STACK_SPACE'
|
||
`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
|
||
Define these macros in addition to the one above if functions might
|
||
allocate stack space for arguments even when their values are
|
||
passed in registers. These should be used when the stack space
|
||
allocated for arguments in registers is not a simple constant
|
||
independent of the function declaration.
|
||
|
||
The value of the first macro is the size, in bytes, of the area
|
||
that we should initially assume would be reserved for arguments
|
||
passed in registers.
|
||
|
||
The value of the second macro is the actual size, in bytes, of the
|
||
area that will be reserved for arguments passed in registers.
|
||
This takes two arguments: an integer representing the number of
|
||
bytes of fixed sized arguments on the stack, and a tree
|
||
representing the number of bytes of variable sized arguments on
|
||
the stack.
|
||
|
||
When these macros are defined, `REG_PARM_STACK_SPACE' will only be
|
||
called for libcall functions, the current function, or for a
|
||
function being called when it is known that such stack space must
|
||
be allocated. In each case this value can be easily computed.
|
||
|
||
When deciding whether a called function needs such stack space,
|
||
and how much space to reserve, GNU CC uses these two macros
|
||
instead of `REG_PARM_STACK_SPACE'.
|
||
|
||
`OUTGOING_REG_PARM_STACK_SPACE'
|
||
Define this if it is the responsibility of the caller to allocate
|
||
the area reserved for arguments passed in registers.
|
||
|
||
If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
|
||
whether the space for these arguments counts in the value of
|
||
`current_function_outgoing_args_size'.
|
||
|
||
`STACK_PARMS_IN_REG_PARM_AREA'
|
||
Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
|
||
stack parameters don't skip the area specified by it.
|
||
|
||
Normally, when a parameter is not passed in registers, it is
|
||
placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
|
||
Defining this macro suppresses this behavior and causes the
|
||
parameter to be passed on the stack in its natural location.
|
||
|
||
`RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
|
||
A C expression that should indicate the number of bytes of its own
|
||
arguments that a function pops on returning, or 0 if the function
|
||
pops no arguments and the caller must therefore pop them all after
|
||
the function returns.
|
||
|
||
FUNDECL is a C variable whose value is a tree node that describes
|
||
the function in question. Normally it is a node of type
|
||
`FUNCTION_DECL' that describes the declaration of the function.
|
||
From this you can obtain the DECL_MACHINE_ATTRIBUTES of the
|
||
function.
|
||
|
||
FUNTYPE is a C variable whose value is a tree node that describes
|
||
the function in question. Normally it is a node of type
|
||
`FUNCTION_TYPE' that describes the data type of the function.
|
||
From this it is possible to obtain the data types of the value and
|
||
arguments (if known).
|
||
|
||
When a call to a library function is being considered, FUNDECL
|
||
will contain an identifier node for the library function. Thus, if
|
||
you need to distinguish among various library functions, you can
|
||
do so by their names. Note that "library function" in this
|
||
context means a function used to perform arithmetic, whose name is
|
||
known specially in the compiler and was not mentioned in the C
|
||
code being compiled.
|
||
|
||
STACK-SIZE is the number of bytes of arguments passed on the
|
||
stack. If a variable number of bytes is passed, it is zero, and
|
||
argument popping will always be the responsibility of the calling
|
||
function.
|
||
|
||
On the Vax, all functions always pop their arguments, so the
|
||
definition of this macro is STACK-SIZE. On the 68000, using the
|
||
standard calling convention, no functions pop their arguments, so
|
||
the value of the macro is always 0 in this case. But an
|
||
alternative calling convention is available in which functions
|
||
that take a fixed number of arguments pop them but other functions
|
||
(such as `printf') pop nothing (the caller pops all). When this
|
||
convention is in use, FUNTYPE is examined to determine whether a
|
||
function takes a fixed number of arguments.
|
||
|
||
|
||
File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
|
||
|
||
Passing Arguments in Registers
|
||
------------------------------
|
||
|
||
This section describes the macros which let you control how various
|
||
types of arguments are passed in registers or how they are arranged in
|
||
the stack.
|
||
|
||
`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
|
||
A C expression that controls whether a function argument is passed
|
||
in a register, and which register.
|
||
|
||
The arguments are CUM, which summarizes all the previous
|
||
arguments; MODE, the machine mode of the argument; TYPE, the data
|
||
type of the argument as a tree node or 0 if that is not known
|
||
(which happens for C support library functions); and NAMED, which
|
||
is 1 for an ordinary argument and 0 for nameless arguments that
|
||
correspond to `...' in the called function's prototype.
|
||
|
||
The value of the expression is usually either a `reg' RTX for the
|
||
hard register in which to pass the argument, or zero to pass the
|
||
argument on the stack.
|
||
|
||
For machines like the Vax and 68000, where normally all arguments
|
||
are pushed, zero suffices as a definition.
|
||
|
||
The value of the expression can also be a `parallel' RTX. This is
|
||
used when an argument is passed in multiple locations. The mode
|
||
of the of the `parallel' should be the mode of the entire
|
||
argument. The `parallel' holds any number of `expr_list' pairs;
|
||
each one describes where part of the argument is passed. In each
|
||
`expr_list', the first operand can be either a `reg' RTX for the
|
||
hard register in which to pass this part of the argument, or zero
|
||
to pass the argument on the stack. If this operand is a `reg',
|
||
then the mode indicates how large this part of the argument is.
|
||
The second operand of the `expr_list' is a `const_int' which gives
|
||
the offset in bytes into the entire argument where this part
|
||
starts.
|
||
|
||
The usual way to make the ANSI library `stdarg.h' work on a machine
|
||
where some arguments are usually passed in registers, is to cause
|
||
nameless arguments to be passed on the stack instead. This is done
|
||
by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
|
||
|
||
You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
|
||
definition of this macro to determine if this argument is of a
|
||
type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
|
||
is not defined and `FUNCTION_ARG' returns non-zero for such an
|
||
argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
|
||
defined, the argument will be computed in the stack and then
|
||
loaded into a register.
|
||
|
||
`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
|
||
Define this macro if the target machine has "register windows", so
|
||
that the register in which a function sees an arguments is not
|
||
necessarily the same as the one in which the caller passed the
|
||
argument.
|
||
|
||
For such machines, `FUNCTION_ARG' computes the register in which
|
||
the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
|
||
defined in a similar fashion to tell the function being called
|
||
where the arguments will arrive.
|
||
|
||
If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
|
||
both purposes.
|
||
|
||
`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
|
||
A C expression for the number of words, at the beginning of an
|
||
argument, must be put in registers. The value must be zero for
|
||
arguments that are passed entirely in registers or that are
|
||
entirely pushed on the stack.
|
||
|
||
On some machines, certain arguments must be passed partially in
|
||
registers and partially in memory. On these machines, typically
|
||
the first N words of arguments are passed in registers, and the
|
||
rest on the stack. If a multi-word argument (a `double' or a
|
||
structure) crosses that boundary, its first few words must be
|
||
passed in registers and the rest must be pushed. This macro tells
|
||
the compiler when this occurs, and how many of the words should go
|
||
in registers.
|
||
|
||
`FUNCTION_ARG' for these arguments should return the first
|
||
register to be used by the caller for this argument; likewise
|
||
`FUNCTION_INCOMING_ARG', for the called function.
|
||
|
||
`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
|
||
A C expression that indicates when an argument must be passed by
|
||
reference. If nonzero for an argument, a copy of that argument is
|
||
made in memory and a pointer to the argument is passed instead of
|
||
the argument itself. The pointer is passed in whatever way is
|
||
appropriate for passing a pointer to that type.
|
||
|
||
On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
|
||
definition of this macro might be
|
||
#define FUNCTION_ARG_PASS_BY_REFERENCE\
|
||
(CUM, MODE, TYPE, NAMED) \
|
||
MUST_PASS_IN_STACK (MODE, TYPE)
|
||
|
||
`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)'
|
||
If defined, a C expression that indicates when it is the called
|
||
function's responsibility to make a copy of arguments passed by
|
||
invisible reference. Normally, the caller makes a copy and passes
|
||
the address of the copy to the routine being called. When
|
||
FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller
|
||
does not make a copy. Instead, it passes a pointer to the "live"
|
||
value. The called function must not modify this value. If it can
|
||
be determined that the value won't be modified, it need not make a
|
||
copy; otherwise a copy must be made.
|
||
|
||
`CUMULATIVE_ARGS'
|
||
A C type for declaring a variable that is used as the first
|
||
argument of `FUNCTION_ARG' and other related values. For some
|
||
target machines, the type `int' suffices and can hold the number
|
||
of bytes of argument so far.
|
||
|
||
There is no need to record in `CUMULATIVE_ARGS' anything about the
|
||
arguments that have been passed on the stack. The compiler has
|
||
other variables to keep track of that. For target machines on
|
||
which all arguments are passed on the stack, there is no need to
|
||
store anything in `CUMULATIVE_ARGS'; however, the data structure
|
||
must exist and should not be empty, so use `int'.
|
||
|
||
`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)'
|
||
A C statement (sans semicolon) for initializing the variable CUM
|
||
for the state at the beginning of the argument list. The variable
|
||
has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
|
||
for the data type of the function which will receive the args, or 0
|
||
if the args are to a compiler support library function. The value
|
||
of INDIRECT is nonzero when processing an indirect call, for
|
||
example a call through a function pointer. The value of INDIRECT
|
||
is zero for a call to an explicitly named function, a library
|
||
function call, or when `INIT_CUMULATIVE_ARGS' is used to find
|
||
arguments for the function being compiled.
|
||
|
||
When processing a call to a compiler support library function,
|
||
LIBNAME identifies which one. It is a `symbol_ref' rtx which
|
||
contains the name of the function, as a string. LIBNAME is 0 when
|
||
an ordinary C function call is being processed. Thus, each time
|
||
this macro is called, either LIBNAME or FNTYPE is nonzero, but
|
||
never both of them at once.
|
||
|
||
`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
|
||
Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
|
||
finding the arguments for the function being compiled. If this
|
||
macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
|
||
|
||
The value passed for LIBNAME is always 0, since library routines
|
||
with special calling conventions are never compiled with GNU CC.
|
||
The argument LIBNAME exists for symmetry with
|
||
`INIT_CUMULATIVE_ARGS'.
|
||
|
||
`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
|
||
A C statement (sans semicolon) to update the summarizer variable
|
||
CUM to advance past an argument in the argument list. The values
|
||
MODE, TYPE and NAMED describe that argument. Once this is done,
|
||
the variable CUM is suitable for analyzing the *following*
|
||
argument with `FUNCTION_ARG', etc.
|
||
|
||
This macro need not do anything if the argument in question was
|
||
passed on the stack. The compiler knows how to track the amount
|
||
of stack space used for arguments without any special help.
|
||
|
||
`FUNCTION_ARG_PADDING (MODE, TYPE)'
|
||
If defined, a C expression which determines whether, and in which
|
||
direction, to pad out an argument with extra space. The value
|
||
should be of type `enum direction': either `upward' to pad above
|
||
the argument, `downward' to pad below, or `none' to inhibit
|
||
padding.
|
||
|
||
The *amount* of padding is always just enough to reach the next
|
||
multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
|
||
it.
|
||
|
||
This macro has a default definition which is right for most
|
||
systems. For little-endian machines, the default is to pad
|
||
upward. For big-endian machines, the default is to pad downward
|
||
for an argument of constant size shorter than an `int', and upward
|
||
otherwise.
|
||
|
||
`FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
|
||
If defined, a C expression that gives the alignment boundary, in
|
||
bits, of an argument with the specified mode and type. If it is
|
||
not defined, `PARM_BOUNDARY' is used for all arguments.
|
||
|
||
`FUNCTION_ARG_REGNO_P (REGNO)'
|
||
A C expression that is nonzero if REGNO is the number of a hard
|
||
register in which function arguments are sometimes passed. This
|
||
does *not* include implicit arguments such as the static chain and
|
||
the structure-value address. On many machines, no registers can be
|
||
used for this purpose since all function arguments are pushed on
|
||
the stack.
|
||
|
||
|
||
File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
|
||
|
||
How Scalar Function Values Are Returned
|
||
---------------------------------------
|
||
|
||
This section discusses the macros that control returning scalars as
|
||
values--values that can fit in registers.
|
||
|
||
`TRADITIONAL_RETURN_FLOAT'
|
||
Define this macro if `-traditional' should not cause functions
|
||
declared to return `float' to convert the value to `double'.
|
||
|
||
`FUNCTION_VALUE (VALTYPE, FUNC)'
|
||
A C expression to create an RTX representing the place where a
|
||
function returns a value of data type VALTYPE. VALTYPE is a tree
|
||
node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
|
||
the machine mode used to represent that type. On many machines,
|
||
only the mode is relevant. (Actually, on most machines, scalar
|
||
values are returned in the same place regardless of mode).
|
||
|
||
The value of the expression is usually a `reg' RTX for the hard
|
||
register where the return value is stored. The value can also be a
|
||
`parallel' RTX, if the return value is in multiple places. See
|
||
`FUNCTION_ARG' for an explanation of the `parallel' form.
|
||
|
||
If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same
|
||
promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar
|
||
type.
|
||
|
||
If the precise function being called is known, FUNC is a tree node
|
||
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
|
||
makes it possible to use a different value-returning convention
|
||
for specific functions when all their calls are known.
|
||
|
||
`FUNCTION_VALUE' is not used for return vales with aggregate data
|
||
types, because these are returned in another way. See
|
||
`STRUCT_VALUE_REGNUM' and related macros, below.
|
||
|
||
`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
|
||
Define this macro if the target machine has "register windows" so
|
||
that the register in which a function returns its value is not the
|
||
same as the one in which the caller sees the value.
|
||
|
||
For such machines, `FUNCTION_VALUE' computes the register in which
|
||
the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
|
||
defined in a similar fashion to tell the function where to put the
|
||
value.
|
||
|
||
If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
|
||
serves both purposes.
|
||
|
||
`FUNCTION_OUTGOING_VALUE' is not used for return vales with
|
||
aggregate data types, because these are returned in another way.
|
||
See `STRUCT_VALUE_REGNUM' and related macros, below.
|
||
|
||
`LIBCALL_VALUE (MODE)'
|
||
A C expression to create an RTX representing the place where a
|
||
library function returns a value of mode MODE. If the precise
|
||
function being called is known, FUNC is a tree node
|
||
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
|
||
makes it possible to use a different value-returning convention
|
||
for specific functions when all their calls are known.
|
||
|
||
Note that "library function" in this context means a compiler
|
||
support routine, used to perform arithmetic, whose name is known
|
||
specially by the compiler and was not mentioned in the C code being
|
||
compiled.
|
||
|
||
The definition of `LIBRARY_VALUE' need not be concerned aggregate
|
||
data types, because none of the library functions returns such
|
||
types.
|
||
|
||
`FUNCTION_VALUE_REGNO_P (REGNO)'
|
||
A C expression that is nonzero if REGNO is the number of a hard
|
||
register in which the values of called function may come back.
|
||
|
||
A register whose use for returning values is limited to serving as
|
||
the second of a pair (for a value of type `double', say) need not
|
||
be recognized by this macro. So for most machines, this definition
|
||
suffices:
|
||
|
||
#define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
|
||
|
||
If the machine has register windows, so that the caller and the
|
||
called function use different registers for the return value, this
|
||
macro should recognize only the caller's register numbers.
|
||
|
||
`APPLY_RESULT_SIZE'
|
||
Define this macro if `untyped_call' and `untyped_return' need more
|
||
space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
|
||
restoring an arbitrary return value.
|
||
|
||
|
||
File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
|
||
|
||
How Large Values Are Returned
|
||
-----------------------------
|
||
|
||
When a function value's mode is `BLKmode' (and in some other cases),
|
||
the value is not returned according to `FUNCTION_VALUE' (*note Scalar
|
||
Return::.). Instead, the caller passes the address of a block of
|
||
memory in which the value should be stored. This address is called the
|
||
"structure value address".
|
||
|
||
This section describes how to control returning structure values in
|
||
memory.
|
||
|
||
`RETURN_IN_MEMORY (TYPE)'
|
||
A C expression which can inhibit the returning of certain function
|
||
values in registers, based on the type of value. A nonzero value
|
||
says to return the function value in memory, just as large
|
||
structures are always returned. Here TYPE will be a C expression
|
||
of type `tree', representing the data type of the value.
|
||
|
||
Note that values of mode `BLKmode' must be explicitly handled by
|
||
this macro. Also, the option `-fpcc-struct-return' takes effect
|
||
regardless of this macro. On most systems, it is possible to
|
||
leave the macro undefined; this causes a default definition to be
|
||
used, whose value is the constant 1 for `BLKmode' values, and 0
|
||
otherwise.
|
||
|
||
Do not use this macro to indicate that structures and unions
|
||
should always be returned in memory. You should instead use
|
||
`DEFAULT_PCC_STRUCT_RETURN' to indicate this.
|
||
|
||
`DEFAULT_PCC_STRUCT_RETURN'
|
||
Define this macro to be 1 if all structure and union return values
|
||
must be in memory. Since this results in slower code, this should
|
||
be defined only if needed for compatibility with other compilers
|
||
or with an ABI. If you define this macro to be 0, then the
|
||
conventions used for structure and union return values are decided
|
||
by the `RETURN_IN_MEMORY' macro.
|
||
|
||
If not defined, this defaults to the value 1.
|
||
|
||
`STRUCT_VALUE_REGNUM'
|
||
If the structure value address is passed in a register, then
|
||
`STRUCT_VALUE_REGNUM' should be the number of that register.
|
||
|
||
`STRUCT_VALUE'
|
||
If the structure value address is not passed in a register, define
|
||
`STRUCT_VALUE' as an expression returning an RTX for the place
|
||
where the address is passed. If it returns 0, the address is
|
||
passed as an "invisible" first argument.
|
||
|
||
`STRUCT_VALUE_INCOMING_REGNUM'
|
||
On some architectures the place where the structure value address
|
||
is found by the called function is not the same place that the
|
||
caller put it. This can be due to register windows, or it could
|
||
be because the function prologue moves it to a different place.
|
||
|
||
If the incoming location of the structure value address is in a
|
||
register, define this macro as the register number.
|
||
|
||
`STRUCT_VALUE_INCOMING'
|
||
If the incoming location is not a register, then you should define
|
||
`STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
|
||
called function should find the value. If it should find the
|
||
value on the stack, define this to create a `mem' which refers to
|
||
the frame pointer. A definition of 0 means that the address is
|
||
passed as an "invisible" first argument.
|
||
|
||
`PCC_STATIC_STRUCT_RETURN'
|
||
Define this macro if the usual system convention on the target
|
||
machine for returning structures and unions is for the called
|
||
function to return the address of a static variable containing the
|
||
value.
|
||
|
||
Do not define this if the usual system convention is for the
|
||
caller to pass an address to the subroutine.
|
||
|
||
This macro has effect in `-fpcc-struct-return' mode, but it does
|
||
nothing when you use `-freg-struct-return' mode.
|
||
|
||
|
||
File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
|
||
|
||
Caller-Saves Register Allocation
|
||
--------------------------------
|
||
|
||
If you enable it, GNU CC can save registers around function calls.
|
||
This makes it possible to use call-clobbered registers to hold
|
||
variables that must live across calls.
|
||
|
||
`DEFAULT_CALLER_SAVES'
|
||
Define this macro if function calls on the target machine do not
|
||
preserve any registers; in other words, if `CALL_USED_REGISTERS'
|
||
has 1 for all registers. This macro enables `-fcaller-saves' by
|
||
default. Eventually that option will be enabled by default on all
|
||
machines and both the option and this macro will be eliminated.
|
||
|
||
`CALLER_SAVE_PROFITABLE (REFS, CALLS)'
|
||
A C expression to determine whether it is worthwhile to consider
|
||
placing a pseudo-register in a call-clobbered hard register and
|
||
saving and restoring it around each function call. The expression
|
||
should be 1 when this is worth doing, and 0 otherwise.
|
||
|
||
If you don't define this macro, a default is used which is good on
|
||
most machines: `4 * CALLS < REFS'.
|
||
|
||
|
||
File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
|
||
|
||
Function Entry and Exit
|
||
-----------------------
|
||
|
||
This section describes the macros that output function entry
|
||
("prologue") and exit ("epilogue") code.
|
||
|
||
`FUNCTION_PROLOGUE (FILE, SIZE)'
|
||
A C compound statement that outputs the assembler code for entry
|
||
to a function. The prologue is responsible for setting up the
|
||
stack frame, initializing the frame pointer register, saving
|
||
registers that must be saved, and allocating SIZE additional bytes
|
||
of storage for the local variables. SIZE is an integer. FILE is
|
||
a stdio stream to which the assembler code should be output.
|
||
|
||
The label for the beginning of the function need not be output by
|
||
this macro. That has already been done when the macro is run.
|
||
|
||
To determine which registers to save, the macro can refer to the
|
||
array `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_EPILOGUE' must 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. *Note
|
||
Elimination::.
|
||
|
||
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_DOWNWARD' is
|
||
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.
|
||
|
||
* A region of `current_function_pretend_args_size' bytes 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'.
|
||
|
||
* An area of memory used to save certain registers used by the
|
||
function. The size of this area, which may also include
|
||
space for such things as the return address and pointers to
|
||
previous stack frames, is machine-specific and usually
|
||
depends on which registers have been used in the function.
|
||
Machines with register windows often do not require a save
|
||
area.
|
||
|
||
* A region of at least SIZE bytes, possibly rounded up to an
|
||
allocation boundary, to contain the local variables of the
|
||
function. On some machines, this region and the save area
|
||
may occur in the opposite order, with the save area closer to
|
||
the top of the stack.
|
||
|
||
* Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a
|
||
region of `current_function_outgoing_args_size' bytes to be
|
||
used for outgoing argument lists of the function. *Note
|
||
Stack Arguments::.
|
||
|
||
Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and
|
||
`FUNCTION_EPILOGUE' to treat leaf functions specially. The C
|
||
variable `leaf_function' is nonzero for such a function.
|
||
|
||
`EXIT_IGNORE_STACK'
|
||
Define this macro as a C expression that is nonzero if the return
|
||
instruction or the function epilogue ignores the value of the stack
|
||
pointer; in other words, if it is safe to delete an instruction to
|
||
adjust the stack pointer before a return from the function.
|
||
|
||
Note that this macro's value is relevant only for functions for
|
||
which frame pointers are maintained. It is never safe to delete a
|
||
final stack adjustment in a function that has no frame pointer,
|
||
and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
|
||
|
||
`EPILOGUE_USES (REGNO)'
|
||
Define this macro as a C expression that is nonzero for registers
|
||
are used by the epilogue or the `return' pattern. The stack and
|
||
frame pointer registers are already be assumed to be used as
|
||
needed.
|
||
|
||
`FUNCTION_EPILOGUE (FILE, SIZE)'
|
||
A C compound statement that outputs the assembler code for exit
|
||
from a function. The epilogue is responsible for restoring the
|
||
saved registers and stack pointer to their values when the
|
||
function was called, and returning control to the caller. This
|
||
macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
|
||
and the registers to restore are determined from `regs_ever_live'
|
||
and `CALL_USED_REGISTERS' in 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_EPILOGUE' at all.
|
||
|
||
Do not define a pattern named `return' if you want the
|
||
`FUNCTION_EPILOGUE' to 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_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
|
||
leaf functions specially. The C variable `leaf_function' is
|
||
nonzero for such a function. *Note 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_ARGS' decides which
|
||
functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
|
||
know what was decided. The variable that is called
|
||
`current_function_pops_args' is the number of bytes of its
|
||
arguments that a function should pop. *Note Scalar Return::.
|
||
|
||
`DELAY_SLOTS_FOR_EPILOGUE'
|
||
Define this macro if the function epilogue contains delay slots to
|
||
which instructions from the rest of the function can be "moved".
|
||
The definition should be a C expression whose value is an integer
|
||
representing the number of delay slots there.
|
||
|
||
`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
|
||
A C expression that returns 1 if INSN can be placed in delay slot
|
||
number N of the epilogue.
|
||
|
||
The argument N is an integer which identifies the delay slot now
|
||
being considered (since different slots may have different rules of
|
||
eligibility). It is never negative and is always less than the
|
||
number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
|
||
returns). 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_list' objects, 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_EPILOGUE' should 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
|
||
`DELAY_SLOTS_FOR_EPILOGUE'.
|
||
|
||
`ASM_OUTPUT_MI_THUNK (FILE, THUNK_FNDECL, DELTA, FUNCTION)'
|
||
A C compound statement that outputs the assembler code for a thunk
|
||
function, used to implement C++ virtual function calls with
|
||
multiple inheritance. The thunk acts as a wrapper around a
|
||
virtual function, adjusting the implicit object parameter before
|
||
handing control off to the real function.
|
||
|
||
First, emit code to add the integer DELTA to the location that
|
||
contains the incoming first argument. Assume that this argument
|
||
contains a pointer, and is the one used to pass the `this' pointer
|
||
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_PROLOGUE'
|
||
and `FUNCTION_EPILOGUE' are 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.
|
||
|