1052 lines
48 KiB
Plaintext
1052 lines
48 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo-1.47 from the input
|
||
file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Copyright (C) 1988, 1989, 1992 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" and "Boycott"
|
||
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" and "Boycott", 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: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
|
||
|
||
Register Classes
|
||
================
|
||
|
||
On many machines, the numbered registers are not all equivalent. For
|
||
example, certain registers may not be allowed for indexed addressing;
|
||
certain registers may not be allowed in some instructions. These
|
||
machine restrictions are described to the compiler using "register
|
||
classes".
|
||
|
||
You define a number of register classes, giving each one a name and
|
||
saying which of the registers belong to it. Then you can specify
|
||
register classes that are allowed as operands to particular instruction
|
||
patterns.
|
||
|
||
In general, each register will belong to several classes. In fact,
|
||
one class must be named `ALL_REGS' and contain all the registers.
|
||
Another class must be named `NO_REGS' and contain no registers. Often
|
||
the union of two classes will be another class; however, this is not
|
||
required.
|
||
|
||
One of the classes must be named `GENERAL_REGS'. There is nothing
|
||
terribly special about the name, but the operand constraint letters `r'
|
||
and `g' specify this class. If `GENERAL_REGS' is the same as
|
||
`ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
|
||
|
||
Order the classes so that if class X is contained in class Y then X
|
||
has a lower class number than Y.
|
||
|
||
The way classes other than `GENERAL_REGS' are specified in operand
|
||
constraints is through machine-dependent operand constraint letters.
|
||
You can define such letters to correspond to various classes, then use
|
||
them in operand constraints.
|
||
|
||
You should define a class for the union of two classes whenever some
|
||
instruction allows both classes. For example, if an instruction allows
|
||
either a floating point (coprocessor) register or a general register
|
||
for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
|
||
which includes both of them. Otherwise you will get suboptimal code.
|
||
|
||
You must also specify certain redundant information about the
|
||
register classes: for each class, which classes contain it and which
|
||
ones are contained in it; for each pair of classes, the largest class
|
||
contained in their union.
|
||
|
||
When a value occupying several consecutive registers is expected in a
|
||
certain class, all the registers used must belong to that class.
|
||
Therefore, register classes cannot be used to enforce a requirement for
|
||
a register pair to start with an even-numbered register. The way to
|
||
specify this requirement is with `HARD_REGNO_MODE_OK'.
|
||
|
||
Register classes used for input-operands of bitwise-and or shift
|
||
instructions have a special requirement: each such class must have, for
|
||
each fixed-point machine mode, a subclass whose registers can transfer
|
||
that mode to or from memory. For example, on some machines, the
|
||
operations for single-byte values (`QImode') are limited to certain
|
||
registers. When this is so, each register class that is used in a
|
||
bitwise-and or shift instruction must have a subclass consisting of
|
||
registers from which single-byte values can be loaded or stored. This
|
||
is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
|
||
return.
|
||
|
||
`enum reg_class'
|
||
An enumeral type that must be defined with all the register class
|
||
names as enumeral values. `NO_REGS' must be first. `ALL_REGS'
|
||
must be the last register class, followed by one more enumeral
|
||
value, `LIM_REG_CLASSES', which is not a register class but rather
|
||
tells how many classes there are.
|
||
|
||
Each register class has a number, which is the value of casting
|
||
the class name to type `int'. The number serves as an index in
|
||
many of the tables described below.
|
||
|
||
`N_REG_CLASSES'
|
||
The number of distinct register classes, defined as follows:
|
||
|
||
#define N_REG_CLASSES (int) LIM_REG_CLASSES
|
||
|
||
`REG_CLASS_NAMES'
|
||
An initializer containing the names of the register classes as C
|
||
string constants. These names are used in writing some of the
|
||
debugging dumps.
|
||
|
||
`REG_CLASS_CONTENTS'
|
||
An initializer containing the contents of the register classes, as
|
||
integers which are bit masks. The Nth integer specifies the
|
||
contents of class N. The way the integer MASK is interpreted is
|
||
that register R is in the class if `MASK & (1 << R)' is 1.
|
||
|
||
When the machine has more than 32 registers, an integer does not
|
||
suffice. Then the integers are replaced by sub-initializers,
|
||
braced groupings containing several integers. Each
|
||
sub-initializer must be suitable as an initializer for the type
|
||
`HARD_REG_SET' which is defined in `hard-reg-set.h'.
|
||
|
||
`REGNO_REG_CLASS (REGNO)'
|
||
A C expression whose value is a register class containing hard
|
||
register REGNO. In general there is more that one such class;
|
||
choose a class which is "minimal", meaning that no smaller class
|
||
also contains the register.
|
||
|
||
`BASE_REG_CLASS'
|
||
A macro whose definition is the name of the class to which a valid
|
||
base register must belong. A base register is one used in an
|
||
address which is the register value plus a displacement.
|
||
|
||
`INDEX_REG_CLASS'
|
||
A macro whose definition is the name of the class to which a valid
|
||
index register must belong. An index register is one used in an
|
||
address where its value is either multiplied by a scale factor or
|
||
added to another register (as well as added to a displacement).
|
||
|
||
`REG_CLASS_FROM_LETTER (CHAR)'
|
||
A C expression which defines the machine-dependent operand
|
||
constraint letters for register classes. If CHAR is such a
|
||
letter, the value should be the register class corresponding to
|
||
it. Otherwise, the value should be `NO_REGS'. The register
|
||
letter `r', corresponding to class `GENERAL_REGS', will not be
|
||
passed to this macro; you do not need to handle it.
|
||
|
||
`REGNO_OK_FOR_BASE_P (NUM)'
|
||
A C expression which is nonzero if register number NUM is suitable
|
||
for use as a base register in operand addresses. It may be either
|
||
a suitable hard register or a pseudo register that has been
|
||
allocated such a hard register.
|
||
|
||
`REGNO_OK_FOR_INDEX_P (NUM)'
|
||
A C expression which is nonzero if register number NUM is suitable
|
||
for use as an index register in operand addresses. It may be
|
||
either a suitable hard register or a pseudo register that has been
|
||
allocated such a hard register.
|
||
|
||
The difference between an index register and a base register is
|
||
that the index register may be scaled. If an address involves the
|
||
sum of two registers, neither one of them scaled, then either one
|
||
may be labeled the "base" and the other the "index"; but whichever
|
||
labeling is used must fit the machine's constraints of which
|
||
registers may serve in each capacity. The compiler will try both
|
||
labelings, looking for one that is valid, and will reload one or
|
||
both registers only if neither labeling works.
|
||
|
||
`PREFERRED_RELOAD_CLASS (X, CLASS)'
|
||
A C expression that places additional restrictions on the register
|
||
class to use when it is necessary to copy value X into a register
|
||
in class CLASS. The value is a register class; perhaps CLASS, or
|
||
perhaps another, smaller class. On many machines, the definition
|
||
|
||
#define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
|
||
|
||
is safe.
|
||
|
||
Sometimes returning a more restrictive class makes better code.
|
||
For example, on the 68000, when X is an integer constant that is
|
||
in range for a `moveq' instruction, the value of this macro is
|
||
always `DATA_REGS' as long as CLASS includes the data registers.
|
||
Requiring a data register guarantees that a `moveq' will be used.
|
||
|
||
If X is a `const_double', by returning `NO_REGS' you can force X
|
||
into a memory constant. This is useful on certain machines where
|
||
immediate floating values cannot be loaded into certain kinds of
|
||
registers.
|
||
|
||
`LIMIT_RELOAD_CLASS (MODE, CLASS)'
|
||
A C expression that places additional restrictions on the register
|
||
class to use when it is necessary to be able to hold a value of
|
||
mode MODE in a reload register for which class CLASS would
|
||
ordinarily be used.
|
||
|
||
Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
|
||
there are certain modes that simply can't go in certain reload
|
||
classes.
|
||
|
||
The value is a register class; perhaps CLASS, or perhaps another,
|
||
smaller class.
|
||
|
||
Don't define this macro unless the target machine has limitations
|
||
which require the macro to do something nontrivial.
|
||
|
||
`SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
|
||
`SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
|
||
`SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
|
||
Many machines have some registers that cannot be copied directly
|
||
to or from memory or even from other types of registers. An
|
||
example is the `MQ' register, which on most machines, can only be
|
||
copied to or from general registers, but not memory. Some
|
||
machines allow copying all registers to and from memory, but
|
||
require a scratch register for stores to some memory locations
|
||
(e.g., those with symbolic address on the RT, and those with
|
||
certain symbolic address on the Sparc when compiling PIC). In
|
||
some cases, both an intermediate and a scratch register are
|
||
required.
|
||
|
||
You should define these macros to indicate to the reload phase
|
||
that it may need to allocate at least one register for a reload in
|
||
addition to the register to contain the data. Specifically, if
|
||
copying X to a register CLASS in MODE requires an intermediate
|
||
register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
|
||
return the largest register class all of whose registers can be
|
||
used as intermediate registers or scratch registers.
|
||
|
||
If copying a register CLASS in MODE to X requires an intermediate
|
||
or scratch register, you should define
|
||
`SECONDARY_OUTPUT_RELOAD_CLASS' to return the largest register
|
||
class required. If the requirements for input and output reloads
|
||
are the same, the macro `SECONDARY_RELOAD_CLASS' should be used
|
||
instead of defining both macros identically.
|
||
|
||
The values returned by these macros are often `GENERAL_REGS'.
|
||
Return `NO_REGS' if no spare register is needed; i.e., if X can be
|
||
directly copied to or from a register of CLASS in MODE without
|
||
requiring a scratch register. Do not define this macro if it
|
||
would always return `NO_REGS'.
|
||
|
||
If a scratch register is required (either with or without an
|
||
intermediate register), you should define patterns for
|
||
`reload_inM' or `reload_outM', as required (*note Standard
|
||
Names::.. These patterns, which will normally be implemented with
|
||
a `define_expand', should be similar to the `movM' patterns,
|
||
except that operand 2 is the scratch register.
|
||
|
||
Define constraints for the reload register and scratch register
|
||
that contain a single register class. If the original reload
|
||
register (whose class is CLASS) can meet the constraint given in
|
||
the pattern, the value returned by these macros is used for the
|
||
class of the scratch register. Otherwise, two additional reload
|
||
registers are required. Their classes are obtained from the
|
||
constraints in the insn pattern.
|
||
|
||
X might be a pseudo-register or a `subreg' of a pseudo-register,
|
||
which could either be in a hard register or in memory. Use
|
||
`true_regnum' to find out; it will return -1 if the pseudo is in
|
||
memory and the hard register number if it is in a register.
|
||
|
||
These macros should not be used in the case where a particular
|
||
class of registers can only be copied to memory and not to another
|
||
class of registers. In that case, secondary reload registers are
|
||
not needed and would not be helpful. Instead, a stack location
|
||
must be used to perform the copy and the `movM' pattern should use
|
||
memory as a intermediate storage. This case often occurs between
|
||
floating-point and general registers.
|
||
|
||
`SMALL_REGISTER_CLASSES'
|
||
Normally the compiler will avoid choosing spill registers from
|
||
registers that have been explicitly mentioned in the rtl (these
|
||
registers are normally those used to pass parameters and return
|
||
values). However, some machines have so few registers of certain
|
||
classes that there would not be enough registers to use as spill
|
||
registers if this were done.
|
||
|
||
On those machines, you should define `SMALL_REGISTER_CLASSES'.
|
||
When it is defined, the compiler allows registers explicitly used
|
||
in the rtl to be used as spill registers but prevents the compiler
|
||
from extending the lifetime of these registers.
|
||
|
||
Defining this macro is always safe, but unnecessarily defining
|
||
this macro will reduce the amount of optimizations that can be
|
||
performed in some cases. If this macro is not defined but needs
|
||
to be, the compiler will run out of reload registers and print a
|
||
fatal error message.
|
||
|
||
For most machines, this macro should not be defined.
|
||
|
||
`CLASS_MAX_NREGS (CLASS, MODE)'
|
||
A C expression for the maximum number of consecutive registers of
|
||
class CLASS needed to hold a value of mode MODE.
|
||
|
||
This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
|
||
the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
|
||
the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
|
||
REGNO values in the class CLASS.
|
||
|
||
This macro helps control the handling of multiple-word values in
|
||
the reload pass.
|
||
|
||
Three other special macros describe which operands fit which
|
||
constraint letters.
|
||
|
||
`CONST_OK_FOR_LETTER_P (VALUE, C)'
|
||
A C expression that defines the machine-dependent operand
|
||
constraint letters that specify particular ranges of integer
|
||
values. If C is one of those letters, the expression should check
|
||
that VALUE, an integer, is in the appropriate range and return 1
|
||
if so, 0 otherwise. If C is not one of those letters, the value
|
||
should be 0 regardless of VALUE.
|
||
|
||
`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
|
||
A C expression that defines the machine-dependent operand
|
||
constraint letters that specify particular ranges of
|
||
`const_double' values.
|
||
|
||
If C is one of those letters, the expression should check that
|
||
VALUE, an RTX of code `const_double', is in the appropriate range
|
||
and return 1 if so, 0 otherwise. If C is not one of those
|
||
letters, the value should be 0 regardless of VALUE.
|
||
|
||
`const_double' is used for all floating-point constants and for
|
||
`DImode' fixed-point constants. A given letter can accept either
|
||
or both kinds of values. It can use `GET_MODE' to distinguish
|
||
between these kinds.
|
||
|
||
`EXTRA_CONSTRAINT (VALUE, C)'
|
||
A C expression that defines the optional machine-dependent
|
||
constraint letters that can be used to segregate specific types of
|
||
operands, usually memory references, for the target machine.
|
||
Normally this macro will not be defined. If it is required for a
|
||
particular target machine, it should return 1 if VALUE corresponds
|
||
to the operand type represented by the constraint letter C. If C
|
||
is not defined as an extra constraint, the value returned should
|
||
be 0 regardless of VALUE.
|
||
|
||
For example, on the ROMP, load instructions cannot have their
|
||
output in r0 if the memory reference contains a symbolic address.
|
||
Constraint letter `Q' is defined as representing a memory address
|
||
that does *not* contain a symbolic address. An alternative is
|
||
specified with a `Q' constraint on the input and `r' on the
|
||
output. The next alternative specifies `m' on the input and a
|
||
register class that does not include r0 on the output.
|
||
|
||
|
||
File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
|
||
|
||
Describing Stack Layout and Calling Conventions
|
||
===============================================
|
||
|
||
* Menu:
|
||
|
||
* Frame Layout::
|
||
* Frame Registers::
|
||
* Elimination::
|
||
* Stack Arguments::
|
||
* Register Arguments::
|
||
* Scalar Return::
|
||
* Aggregate Return::
|
||
* Caller Saves::
|
||
* Function Entry::
|
||
* Profiling::
|
||
|
||
|
||
File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling
|
||
|
||
Basic Stack Layout
|
||
------------------
|
||
|
||
`STACK_GROWS_DOWNWARD'
|
||
Define this macro if pushing a word onto the stack moves the stack
|
||
pointer to a smaller address.
|
||
|
||
When we say, "define this macro if ...," it means that the
|
||
compiler checks this macro only with `#ifdef' so the precise
|
||
definition used does not matter.
|
||
|
||
`FRAME_GROWS_DOWNWARD'
|
||
Define this macro if the addresses of local variable slots are at
|
||
negative offsets from the frame pointer.
|
||
|
||
`ARGS_GROW_DOWNWARD'
|
||
Define this macro if successive arguments to a function occupy
|
||
decreasing addresses on the stack.
|
||
|
||
`STARTING_FRAME_OFFSET'
|
||
Offset from the frame pointer to the first local variable slot to
|
||
be allocated.
|
||
|
||
If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
|
||
subtracting the length of the first slot from
|
||
`STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
|
||
length of the first slot to the value `STARTING_FRAME_OFFSET'.
|
||
|
||
`STACK_POINTER_OFFSET'
|
||
Offset from the stack pointer register to the first location at
|
||
which outgoing arguments are placed. If not specified, the
|
||
default value of zero is used. This is the proper value for most
|
||
machines.
|
||
|
||
If `ARGS_GROW_DOWNWARD', this is the offset to the location above
|
||
the first location at which outgoing arguments are placed.
|
||
|
||
`FIRST_PARM_OFFSET (FUNDECL)'
|
||
Offset from the argument pointer register to the first argument's
|
||
address. On some machines it may depend on the data type of the
|
||
function.
|
||
|
||
If `ARGS_GROW_DOWNWARD', this is the offset to the location above
|
||
the first argument's address.
|
||
|
||
`STACK_DYNAMIC_OFFSET (FUNDECL)'
|
||
Offset from the stack pointer register to an item dynamically
|
||
allocated on the stack, e.g., by `alloca'.
|
||
|
||
The default value for this macro is `STACK_POINTER_OFFSET' plus the
|
||
length of the outgoing arguments. The default is correct for most
|
||
machines. See `function.c' for details.
|
||
|
||
`DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
|
||
A C expression whose value is RTL representing the address in a
|
||
stack frame where the pointer to the caller's frame is stored.
|
||
Assume that FRAMEADDR is an RTL expression for the address of the
|
||
stack frame itself.
|
||
|
||
If you don't define this macro, the default is to return the value
|
||
of FRAMEADDR--that is, the stack frame address is also the address
|
||
of the stack word that points to the previous frame.
|
||
|
||
|
||
File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling
|
||
|
||
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.
|
||
|
||
`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::.).
|
||
|
||
`STATIC_CHAIN_REGNUM'
|
||
`STATIC_CHAIN_INCOMING_REGNUM'
|
||
Register numbers used for passing a function's static chain
|
||
pointer. If register windows are used,
|
||
`STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by
|
||
the called function, while `STATIC_CHAIN_REGNUM' is the register
|
||
number as seen by the calling function. 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
|
||
-----------------------------------------
|
||
|
||
`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.
|
||
|
||
This macro is ignored and need not be defined if `ELIMINABLE_REGS'
|
||
is defined.
|
||
|
||
`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 as `char' or `short' in
|
||
a prototype 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.
|
||
|
||
It is not proper to define both `PUSH_ROUNDING' and
|
||
`ACCUMULATE_OUTGOING_ARGS'.
|
||
|
||
`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 either 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 stack
|
||
parameters don't skip the area specified by `REG_PARM_STACK_SPACE'.
|
||
|
||
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 (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.
|
||
|
||
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, FUNTYPE
|
||
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 should either be 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 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)
|
||
|
||
`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)'
|
||
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.
|
||
|
||
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 argument LIBNAME exists for symmetry with
|
||
`INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always 0,
|
||
since library routines with special calling conventions are never
|
||
compiled with GNU CC.
|
||
|
||
`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.
|
||
|
||
This macro does not control the *amount* of padding; that is
|
||
always just enough to reach the next multiple of
|
||
`FUNCTION_ARG_BOUNDARY'.
|
||
|
||
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).
|
||
|
||
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, and `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.
|
||
|
||
|
||
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' are returned in memory
|
||
regardless of 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 0.
|
||
|
||
`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, 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. GNU CC does not normally use this convention, even if it
|
||
is the usual one, but does use it if `-fpcc-struct-value' is
|
||
specified.
|
||
|
||
Do not define this if the usual system convention is for the
|
||
caller to pass an address to the subroutine.
|
||
|
||
|
||
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'.
|
||
|
||
|