This is ../../gcc-3.4/gcc/doc/gccint.info, produced by makeinfo version
4.2 from ../../gcc-3.4/gcc/doc/gccint.texi.

Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.
INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gccint: (gccint).            Internals of the GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the internals of the GNU compilers.

   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

File: gccint.info,  Node: Leaf Functions,  Next: Stack Registers,  Prev: Values in Registers,  Up: Registers

Handling Leaf Functions
-----------------------

   On some machines, a leaf function (i.e., one which makes no calls)
can run more efficiently if it does not make its own register window.
Often this means it is required to receive its arguments in the
registers where they are passed by the caller, instead of the registers
where they would normally arrive.

   The special treatment for leaf functions generally applies only when
other conditions are met; for example, often they may use only those
registers for its own variables and temporaries.  We use the term "leaf
function" to mean a function that is suitable for this special
handling, so that functions with no calls are not necessarily "leaf
functions".

   GCC assigns register numbers before it knows whether the function is
suitable for leaf function treatment.  So it needs to renumber the
registers in order to output a leaf function.  The following macros
accomplish this.

 - Macro: LEAF_REGISTERS
     Name of a char vector, indexed by hard register number, which
     contains 1 for a register that is allowable in a candidate for leaf
     function treatment.

     If leaf function treatment involves renumbering the registers,
     then the registers marked here should be the ones before
     renumbering--those that GCC would ordinarily allocate.  The
     registers which will actually be used in the assembler code, after
     renumbering, should not be marked with 1 in this vector.

     Define this macro only if the target machine offers a way to
     optimize the treatment of leaf functions.

 - Macro: LEAF_REG_REMAP (REGNO)
     A C expression whose value is the register number to which REGNO
     should be renumbered, when a function is treated as a leaf
     function.

     If REGNO is a register number which should not appear in a leaf
     function before renumbering, then the expression should yield -1,
     which will cause the compiler to abort.

     Define this macro only if the target machine offers a way to
     optimize the treatment of leaf functions, and registers need to be
     renumbered to do this.

   `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
must usually treat leaf functions specially.  They can test the C
variable `current_function_is_leaf' which is nonzero for leaf
functions.  `current_function_is_leaf' is set prior to local register
allocation and is valid for the remaining compiler passes.  They can
also test the C variable `current_function_uses_only_leaf_regs' which
is nonzero for leaf functions which only use leaf registers.
`current_function_uses_only_leaf_regs' is valid after reload and is
only useful if `LEAF_REGISTERS' is defined.


File: gccint.info,  Node: Stack Registers,  Prev: Leaf Functions,  Up: Registers

Registers That Form a Stack
---------------------------

   There are special features to handle computers where some of the
"registers" form a stack.  Stack registers are normally written by
pushing onto the stack, and are numbered relative to the top of the
stack.

   Currently, GCC can only handle one group of stack-like registers, and
they must be consecutively numbered.  Furthermore, the existing support
for stack-like registers is specific to the 80387 floating point
coprocessor.  If you have a new architecture that uses stack-like
registers, you will need to do substantial work on `reg-stack.c' and
write your machine description to cooperate with it, as well as
defining these macros.

 - Macro: STACK_REGS
     Define this if the machine has any stack-like registers.

 - Macro: FIRST_STACK_REG
     The number of the first stack-like register.  This one is the top
     of the stack.

 - Macro: LAST_STACK_REG
     The number of the last stack-like register.  This one is the
     bottom of the stack.


File: gccint.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.

 - Data type: 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.

 - Macro: N_REG_CLASSES
     The number of distinct register classes, defined as follows:

          #define N_REG_CLASSES (int) LIM_REG_CLASSES

 - Macro: 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.

 - Macro: 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'.  In this
     situation, the first integer in each sub-initializer corresponds to
     registers 0 through 31, the second integer to registers 32 through
     63, and so on.

 - Macro: REGNO_REG_CLASS (REGNO)
     A C expression whose value is a register class containing hard
     register REGNO.  In general there is more than one such class;
     choose a class which is "minimal", meaning that no smaller class
     also contains the register.

 - Macro: 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.

 - Macro: MODE_BASE_REG_CLASS (MODE)
     This is a variation of the `BASE_REG_CLASS' macro which allows the
     selection of a base register in a mode dependent manner.  If MODE
     is VOIDmode then it should return the same value as
     `BASE_REG_CLASS'.

 - Macro: 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).

 - Macro: CONSTRAINT_LEN (CHAR, STR)
     For the constraint at the start of STR, which starts with the
     letter C, return the length.  This allows you to have register
     class / constant / extra constraints that are longer than a single
     letter; you don't need to define this macro if you can do with
     single-letter constraints only.  The definition of this macro
     should use DEFAULT_CONSTRAINT_LEN for all the characters that you
     don't want to handle specially.  There are some sanity checks in
     genoutput.c that check the constraint lengths for the md file, so
     you can also use this macro to help you while you are
     transitioning from a byzantine single-letter-constraint scheme:
     when you return a negative length for a constraint you want to
     re-use, genoutput will complain about every instance where it is
     used in the md file.

 - Macro: 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.

 - Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
     Like `REG_CLASS_FROM_LETTER', but you also get the constraint
     string passed in STR, so that you can use suffixes to distinguish
     between different variants.

 - Macro: 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.

 - Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
     A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
     that expression may examine the mode of the memory reference in
     MODE.  You should define this macro if the mode of the memory
     reference affects whether a register may be used as a base
     register.  If you define this macro, the compiler will use it
     instead of `REGNO_OK_FOR_BASE_P'.

 - Macro: 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.

 - Macro: 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 following
     definition is safe:

          #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS

     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.

 - Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
     Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
     input reloads.  If you don't define this macro, the default is to
     use CLASS, unchanged.

 - Macro: 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.

 - Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
 - Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
 - Macro: 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, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
     defined 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 an intermediate storage.  This case often occurs between
     floating-point and general registers.

 - Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
     Certain machines have the property that some registers cannot be
     copied to some other registers without using memory.  Define this
     macro on those machines to be a C expression that is nonzero if
     objects of mode M in registers of CLASS1 can only be copied to
     registers of class CLASS2 by storing a register of CLASS1 into
     memory and loading that memory location into a register of CLASS2.

     Do not define this macro if its value would always be zero.

 - Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
     Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
     allocates a stack slot for a memory location needed for register
     copies.  If this macro is defined, the compiler instead uses the
     memory location defined by this macro.

     Do not define this macro if you do not define
     `SECONDARY_MEMORY_NEEDED'.

 - Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
     When the compiler needs a secondary memory location to copy
     between two registers of mode MODE, it normally allocates
     sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
     performs the store and load operations in a mode that many bits
     wide and whose class is the same as that of MODE.

     This is right thing to do on most machines because it ensures that
     all bits of the register are copied and prevents accesses to the
     registers in a narrower mode, which some machines prohibit for
     floating-point registers.

     However, this default behavior is not correct on some machines,
     such as the DEC Alpha, that store short integers in floating-point
     registers differently than in integer registers.  On those
     machines, the default widening will not work correctly and you
     must define this macro to suppress that widening in some cases.
     See the file `alpha.h' for details.

     Do not define this macro if you do not define
     `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
     `BITS_PER_WORD' bits wide is correct for your machine.

 - Macro: SMALL_REGISTER_CLASSES
     On some machines, it is risky to let hard registers live across
     arbitrary insns.  Typically, these machines have instructions that
     require values to be in specific registers (like an accumulator),
     and reload will fail if the required hard register is used for
     another purpose across such an insn.

     Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero
     value on these machines.  When this macro has a nonzero value, the
     compiler will try to minimize the lifetime of hard registers.

     It is always safe to define this macro with a nonzero value, but
     if you unnecessarily define it, you will reduce the amount of
     optimizations that can be performed in some cases.  If you do not
     define this macro with a nonzero value when it is required, the
     compiler will run out of spill registers and print a fatal error
     message.  For most machines, you should not define this macro at
     all.

 - Macro: CLASS_LIKELY_SPILLED_P (CLASS)
     A C expression whose value is nonzero if pseudos that have been
     assigned to registers of class CLASS would likely be spilled
     because registers of CLASS are needed for spill registers.

     The default value of this macro returns 1 if CLASS has exactly one
     register and zero otherwise.  On most machines, this default
     should be used.  Only define this macro to some other expression
     if pseudos allocated by `local-alloc.c' end up in memory because
     their hard registers were needed for spill registers.  If this
     macro returns nonzero for those classes, those pseudos will only
     be allocated by `global.c', which knows how to reallocate the
     pseudo to another register.  If there would not be another
     register available for reallocation, you should not change the
     definition of this macro since the only effect of such a
     definition would be to slow down register allocation.

 - Macro: 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.

 - Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
     If defined, a C expression that returns nonzero for a CLASS for
     which a change from mode FROM to mode TO is invalid.

     For the example, loading 32-bit integer or floating-point objects
     into floating-point registers on the Alpha extends them to 64 bits.
     Therefore loading a 64-bit object and then storing it as a 32-bit
     object does not store the low-order 32 bits, as would be the case
     for a normal register.  Therefore, `alpha.h' defines
     `CANNOT_CHANGE_MODE_CLASS' as below:

          #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
            (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
             ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)

   Three other special macros describe which operands fit which
constraint letters.

 - Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
     A C expression that defines the machine-dependent operand
     constraint letters (`I', `J', `K', ... `P') 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.

 - Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
     Like `CONST_OK_FOR_LETTER_P', but you also get the constraint
     string passed in STR, so that you can use suffixes to distinguish
     between different variants.

 - Macro: 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 (`G' or `H').

     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.

 - Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
     Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
     constraint string passed in STR, so that you can use suffixes to
     distinguish between different variants.

 - Macro: 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.  Any
     letter that is not elsewhere defined and not matched by
     `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used.
     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.

 - Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
     Like `EXTRA_CONSTRAINT', but you also get the constraint string
     passed in STR, so that you can use suffixes to distinguish between
     different variants.

 - Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
     A C expression that defines the optional machine-dependent
     constraint letters, amongst those accepted by `EXTRA_CONSTRAINT',
     that should be treated like memory constraints by the reload pass.

     It should return 1 if the operand type represented by the
     constraint at the start of STR, the first letter of which is the
     letter C,  comprises a subset of all memory references including
     all those whose address is simply a base register.  This allows
     the reload pass to reload an operand, if it does not directly
     correspond to the operand type of C, by copying its address into a
     base register.

     For example, on the S/390, some instructions do not accept
     arbitrary memory references, but only those that do not make use
     of an index register.  The constraint letter `Q' is defined via
     `EXTRA_CONSTRAINT' as representing a memory address of this type.
     If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q'
     constraint can handle any memory operand, because the reload pass
     knows it can be reloaded by copying the memory address into a base
     register if required.  This is analogous to the way a `o'
     constraint can handle any memory operand.

 - Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
     A C expression that defines the optional machine-dependent
     constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' /
     `EXTRA_CONSTRAINT_STR', that should be treated like address
     constraints by the reload pass.

     It should return 1 if the operand type represented by the
     constraint at the start of STR, which starts with the letter C,
     comprises a subset of all memory addresses including all those
     that consist of just a base register.  This allows the reload pass
     to reload an operand, if it does not directly correspond to the
     operand type of STR, by copying it into a base register.

     Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be
     used with the `address_operand' predicate.  It is treated
     analogously to the `p' constraint.


File: gccint.info,  Node: Stack and Calling,  Next: Varargs,  Prev: Register Classes,  Up: Target Macros

Stack Layout and Calling Conventions
====================================

   This describes the stack layout and calling conventions.

* Menu:

* Frame Layout::
* Exception Handling::
* Stack Checking::
* Frame Registers::
* Elimination::
* Stack Arguments::
* Register Arguments::
* Scalar Return::
* Aggregate Return::
* Caller Saves::
* Function Entry::
* Profiling::
* Tail Calls::


File: gccint.info,  Node: Frame Layout,  Next: Exception Handling,  Up: Stack and Calling

Basic Stack Layout
------------------

   Here is the basic stack layout.

 - Macro: 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.

 - Macro: STACK_PUSH_CODE
     This macro defines the operation used when something is pushed on
     the stack.  In RTL, a push operation will be `(set (mem
     (STACK_PUSH_CODE (reg sp))) ...)'

     The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'.
     Which of these is correct depends on the stack direction and on
     whether the stack pointer points to the last item on the stack or
     whether it points to the space for the next item on the stack.

     The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined,
     which is almost always right, and `PRE_INC' otherwise, which is
     often wrong.

 - Macro: FRAME_GROWS_DOWNWARD
     Define this macro if the addresses of local variable slots are at
     negative offsets from the frame pointer.

 - Macro: ARGS_GROW_DOWNWARD
     Define this macro if successive arguments to a function occupy
     decreasing addresses on the stack.

 - Macro: STARTING_FRAME_OFFSET
     Offset from the frame pointer to the first local variable slot to
     be allocated.

     If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
     subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
     Otherwise, it is found by adding the length of the first slot to
     the value `STARTING_FRAME_OFFSET'.

 - Macro: STACK_ALIGNMENT_NEEDED
     Define to zero to disable final alignment of the stack during
     reload.  The nonzero default for this macro is suitable for most
     ports.

     On ports where `STARTING_FRAME_OFFSET' is nonzero or where there
     is a register save block following the local block that doesn't
     require alignment to `STACK_BOUNDARY', it may be beneficial to
     disable stack alignment and do it in the backend.

 - Macro: 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.

 - Macro: 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.

 - Macro: 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.

 - Macro: 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.

 - Macro: SETUP_FRAME_ADDRESSES
     If defined, a C expression that produces the machine-specific code
     to setup the stack so that arbitrary frames can be accessed.  For
     example, on the SPARC, we must flush all of the register windows
     to the stack before we can access arbitrary stack frames.  You
     will seldom need to define this macro.

 - Macro: BUILTIN_SETJMP_FRAME_VALUE
     If defined, a C expression that contains an rtx that is used to
     store the address of the current frame into the built in `setjmp'
     buffer.  The default value, `virtual_stack_vars_rtx', is correct
     for most machines.  One reason you may need to define this macro
     is if `hard_frame_pointer_rtx' is the appropriate value on your
     machine.

 - Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
     A C expression whose value is RTL representing the value of the
     return address for the frame COUNT steps up from the current
     frame, after the prologue.  FRAMEADDR is the frame pointer of the
     COUNT frame, or the frame pointer of the COUNT - 1 frame if
     `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.

     The value of the expression must always be the correct address when
     COUNT is zero, but may be `NULL_RTX' if there is not way to
     determine the return address of other frames.

 - Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
     Define this if the return address of a particular stack frame is
     accessed from the frame pointer of the previous stack frame.

 - Macro: INCOMING_RETURN_ADDR_RTX
     A C expression whose value is RTL representing the location of the
     incoming return address at the beginning of any function, before
     the prologue.  This RTL is either a `REG', indicating that the
     return value is saved in `REG', or a `MEM' representing a location
     in the stack.

     You only need to define this macro if you want to support call
     frame debugging information like that provided by DWARF 2.

     If this RTL is a `REG', you should also define
     `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'.

 - Macro: INCOMING_FRAME_SP_OFFSET
     A C expression whose value is an integer giving the offset, in
     bytes, from the value of the stack pointer register to the top of
     the stack frame at the beginning of any function, before the
     prologue.  The top of the frame is defined to be the value of the
     stack pointer in the previous frame, just before the call
     instruction.

     You only need to define this macro if you want to support call
     frame debugging information like that provided by DWARF 2.

 - Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
     A C expression whose value is an integer giving the offset, in
     bytes, from the argument pointer to the canonical frame address
     (cfa).  The final value should coincide with that calculated by
     `INCOMING_FRAME_SP_OFFSET'.  Which is unfortunately not usable
     during virtual register instantiation.

     The default value for this macro is `FIRST_PARM_OFFSET (fundecl)',
     which is correct for most machines; in general, the arguments are
     found immediately before the stack frame.  Note that this is not
     the case on some targets that save registers into the caller's
     frame, such as SPARC and rs6000, and so such targets need to
     define this macro.

     You only need to define this macro if the default is incorrect,
     and you want to support call frame debugging information like that
     provided by DWARF 2.


File: gccint.info,  Node: Exception Handling,  Next: Stack Checking,  Prev: Frame Layout,  Up: Stack and Calling

Exception Handling Support
--------------------------

 - Macro: EH_RETURN_DATA_REGNO (N)
     A C expression whose value is the Nth register number used for
     data by exception handlers, or `INVALID_REGNUM' if fewer than N
     registers are usable.

     The exception handling library routines communicate with the
     exception handlers via a set of agreed upon registers.  Ideally
     these registers should be call-clobbered; it is possible to use
     call-saved registers, but may negatively impact code size.  The
     target must support at least 2 data registers, but should define 4
     if there are enough free registers.

     You must define this macro if you want to support call frame
     exception handling like that provided by DWARF 2.

 - Macro: EH_RETURN_STACKADJ_RTX
     A C expression whose value is RTL representing a location in which
     to store a stack adjustment to be applied before function return.
     This is used to unwind the stack to an exception handler's call
     frame.  It will be assigned zero on code paths that return
     normally.

     Typically this is a call-clobbered hard register that is otherwise
     untouched by the epilogue, but could also be a stack slot.

     Do not define this macro if the stack pointer is saved and restored
     by the regular prolog and epilog code in the call frame itself; in
     this case, the exception handling library routines will update the
     stack location to be restored in place.  Otherwise, you must define
     this macro if you want to support call frame exception handling
     like that provided by DWARF 2.

 - Macro: EH_RETURN_HANDLER_RTX
     A C expression whose value is RTL representing a location in which
     to store the address of an exception handler to which we should
     return.  It will not be assigned on code paths that return
     normally.

     Typically this is the location in the call frame at which the
     normal return address is stored.  For targets that return by
     popping an address off the stack, this might be a memory address
     just below the _target_ call frame rather than inside the current
     call frame.  If defined, `EH_RETURN_STACKADJ_RTX' will have already
     been assigned, so it may be used to calculate the location of the
     target call frame.

     Some targets have more complex requirements than storing to an
     address calculable during initial code generation.  In that case
     the `eh_return' instruction pattern should be used instead.

     If you want to support call frame exception handling, you must
     define either this macro or the `eh_return' instruction pattern.

 - Macro: RETURN_ADDR_OFFSET
     If defined, an integer-valued C expression for which rtl will be
     generated to add it to the exception handler address before it is
     searched in the exception handling tables, and to subtract it
     again from the address before using it to return to the exception
     handler.

 - Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
     This macro chooses the encoding of pointers embedded in the
     exception handling sections.  If at all possible, this should be
     defined such that the exception handling section will not require
     dynamic relocations, and so may be read-only.

     CODE is 0 for data, 1 for code labels, 2 for function pointers.
     GLOBAL is true if the symbol may be affected by dynamic
     relocations.  The macro should return a combination of the
     `DW_EH_PE_*' defines as found in `dwarf2.h'.

     If this macro is not defined, pointers will not be encoded but
     represented directly.

 - Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
          ADDR, DONE)
     This macro allows the target to emit whatever special magic is
     required to represent the encoding chosen by
     `ASM_PREFERRED_EH_DATA_FORMAT'.  Generic code takes care of
     pc-relative and indirect encodings; this must be defined if the
     target uses text-relative or data-relative encodings.

     This is a C statement that branches to DONE if the format was
     handled.  ENCODING is the format chosen, SIZE is the number of
     bytes that the format occupies, ADDR is the `SYMBOL_REF' to be
     emitted.

 - Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS, SUCCESS)
     This macro allows the target to add cpu and operating system
     specific code to the call-frame unwinder for use when there is no
     unwind data available.  The most common reason to implement this
     macro is to unwind through signal frames.

     This macro is called from `uw_frame_state_for' in `unwind-dw2.c'
     and `unwind-ia64.c'.  CONTEXT is an `_Unwind_Context'; FS is an
     `_Unwind_FrameState'.  Examine `context->ra' for the address of
     the code being executed and `context->cfa' for the stack pointer
     value.  If the frame can be decoded, the register save addresses
     should be updated in FS and the macro should branch to SUCCESS.
     If the frame cannot be decoded, the macro should do nothing.

     For proper signal handling in Java this macro is accompanied by
     `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h'
     headers.


File: gccint.info,  Node: Stack Checking,  Next: Frame Registers,  Prev: Exception Handling,  Up: Stack and Calling

Specifying How Stack Checking is Done
-------------------------------------

   GCC will check that stack references are within the boundaries of
the stack, if the `-fstack-check' is specified, in one of three ways:

  1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC
     will assume that you have arranged for stack checking to be done at
     appropriate places in the configuration files, e.g., in
     `TARGET_ASM_FUNCTION_PROLOGUE'.  GCC will do not other special
     processing.

  2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern
     called `check_stack' in your `md' file, GCC will call that pattern
     with one argument which is the address to compare the stack value
     against.  You must arrange for this pattern to report an error if
     the stack pointer is out of range.

  3. If neither of the above are true, GCC will generate code to
     periodically "probe" the stack pointer using the values of the
     macros defined below.

   Normally, you will use the default values of these macros, so GCC
will use the third approach.

 - Macro: STACK_CHECK_BUILTIN
     A nonzero value if stack checking is done by the configuration
     files in a machine-dependent manner.  You should define this macro
     if stack checking is require by the ABI of your machine or if you
     would like to have to stack checking in some more efficient way
     than GCC's portable approach.  The default value of this macro is
     zero.

 - Macro: STACK_CHECK_PROBE_INTERVAL
     An integer representing the interval at which GCC must generate
     stack probe instructions.  You will normally define this macro to
     be no larger than the size of the "guard pages" at the end of a
     stack area.  The default value of 4096 is suitable for most
     systems.

 - Macro: STACK_CHECK_PROBE_LOAD
     A integer which is nonzero if GCC should perform the stack probe
     as a load instruction and zero if GCC should use a store
     instruction.  The default is zero, which is the most efficient
     choice on most systems.

 - Macro: STACK_CHECK_PROTECT
     The number of bytes of stack needed to recover from a stack
     overflow, for languages where such a recovery is supported.  The
     default value of 75 words should be adequate for most machines.

 - Macro: STACK_CHECK_MAX_FRAME_SIZE
     The maximum size of a stack frame, in bytes.  GCC will generate
     probe instructions in non-leaf functions to ensure at least this
     many bytes of stack are available.  If a stack frame is larger
     than this size, stack checking will not be reliable and GCC will
     issue a warning.  The default is chosen so that GCC only generates
     one instruction on most systems.  You should normally not change
     the default value of this macro.

 - Macro: STACK_CHECK_FIXED_FRAME_SIZE
     GCC uses this value to generate the above warning message.  It
     represents the amount of fixed frame used by a function, not
     including space for any callee-saved registers, temporaries and
     user variables.  You need only specify an upper bound for this
     amount and will normally use the default of four words.

 - Macro: STACK_CHECK_MAX_VAR_SIZE
     The maximum size, in bytes, of an object that GCC will place in the
     fixed area of the stack frame when the user specifies
     `-fstack-check'.  GCC computed the default from the values of the
     above macros and you will normally not need to override that
     default.

