mirror of
https://github.com/pmret/gcc-papermario.git
synced 2024-11-08 11:53:01 +01:00
1030 lines
46 KiB
Plaintext
1030 lines
46 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.67 from the
|
||
input file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||
Boston, MA 02111-1307 USA
|
||
|
||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998
|
||
Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the sections entitled "GNU General Public License," "Funding for
|
||
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
|
||
included exactly as in the original, and provided that the entire
|
||
resulting derived work is distributed under the terms of a permission
|
||
notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the sections entitled "GNU General Public
|
||
License," "Funding for Free Software," and "Protect Your Freedom--Fight
|
||
`Look And Feel'", and this permission notice, may be included in
|
||
translations approved by the Free Software Foundation instead of in the
|
||
original English.
|
||
|
||
|
||
File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
|
||
|
||
Register Usage
|
||
==============
|
||
|
||
This section explains how to describe what registers the target
|
||
machine has, and how (in general) they can be used.
|
||
|
||
The description of which registers a specific instruction can use is
|
||
done with register classes; see *Note Register Classes::. For
|
||
information on using registers to access a stack frame, see *Note Frame
|
||
Registers::. For passing values in registers, see *Note Register
|
||
Arguments::. For returning values in registers, see *Note Scalar
|
||
Return::.
|
||
|
||
* Menu:
|
||
|
||
* Register Basics:: Number and kinds of registers.
|
||
* Allocation Order:: Order in which registers are allocated.
|
||
* Values in Registers:: What kinds of values each reg can hold.
|
||
* Leaf Functions:: Renumbering registers for leaf functions.
|
||
* Stack Registers:: Handling a register stack such as 80387.
|
||
* Obsolete Register Macros:: Macros formerly used for the 80387.
|
||
|
||
|
||
File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers
|
||
|
||
Basic Characteristics of Registers
|
||
----------------------------------
|
||
|
||
Registers have various characteristics.
|
||
|
||
`FIRST_PSEUDO_REGISTER'
|
||
Number of hardware registers known to the compiler. They receive
|
||
numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
|
||
pseudo register's number really is assigned the number
|
||
`FIRST_PSEUDO_REGISTER'.
|
||
|
||
`FIXED_REGISTERS'
|
||
An initializer that says which registers are used for fixed
|
||
purposes all throughout the compiled code and are therefore not
|
||
available for general allocation. These would include the stack
|
||
pointer, the frame pointer (except on machines where that can be
|
||
used as a general register when no frame pointer is needed), the
|
||
program counter on machines where that is considered one of the
|
||
addressable registers, and any other numbered register with a
|
||
standard use.
|
||
|
||
This information is expressed as a sequence of numbers, separated
|
||
by commas and surrounded by braces. The Nth number is 1 if
|
||
register N is fixed, 0 otherwise.
|
||
|
||
The table initialized from this macro, and the table initialized by
|
||
the following one, may be overridden at run time either
|
||
automatically, by the actions of the macro
|
||
`CONDITIONAL_REGISTER_USAGE', or by the user with the command
|
||
options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
|
||
|
||
`CALL_USED_REGISTERS'
|
||
Like `FIXED_REGISTERS' but has 1 for each register that is
|
||
clobbered (in general) by function calls as well as for fixed
|
||
registers. This macro therefore identifies the registers that are
|
||
not available for general allocation of values that must live
|
||
across function calls.
|
||
|
||
If a register has 0 in `CALL_USED_REGISTERS', the compiler
|
||
automatically saves it on function entry and restores it on
|
||
function exit, if the register is used within the function.
|
||
|
||
`CONDITIONAL_REGISTER_USAGE'
|
||
Zero or more C statements that may conditionally modify two
|
||
variables `fixed_regs' and `call_used_regs' (both of type `char
|
||
[]') after they have been initialized from the two preceding
|
||
macros.
|
||
|
||
This is necessary in case the fixed or call-clobbered registers
|
||
depend on target flags.
|
||
|
||
You need not define this macro if it has no work to do.
|
||
|
||
If the usage of an entire class of registers depends on the target
|
||
flags, you may indicate this to GCC by using this macro to modify
|
||
`fixed_regs' and `call_used_regs' to 1 for each of the registers
|
||
in the classes which should not be used by GCC. Also define the
|
||
macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called
|
||
with a letter for a class that shouldn't be used.
|
||
|
||
(However, if this class is not included in `GENERAL_REGS' and all
|
||
of the insn patterns whose constraints permit this class are
|
||
controlled by target switches, then GCC will automatically avoid
|
||
using these registers when the target switches are opposed to
|
||
them.)
|
||
|
||
`NON_SAVING_SETJMP'
|
||
If this macro is defined and has a nonzero value, it means that
|
||
`setjmp' and related functions fail to save the registers, or that
|
||
`longjmp' fails to restore them. To compensate, the compiler
|
||
avoids putting variables in registers in functions that use
|
||
`setjmp'.
|
||
|
||
`INCOMING_REGNO (OUT)'
|
||
Define this macro if the target machine has register windows.
|
||
This C expression returns the register number as seen by the
|
||
called function corresponding to the register number OUT as seen
|
||
by the calling function. Return OUT if register number OUT is not
|
||
an outbound register.
|
||
|
||
`OUTGOING_REGNO (IN)'
|
||
Define this macro if the target machine has register windows.
|
||
This C expression returns the register number as seen by the
|
||
calling function corresponding to the register number IN as seen
|
||
by the called function. Return IN if register number IN is not an
|
||
inbound register.
|
||
|
||
|
||
File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
|
||
|
||
Order of Allocation of Registers
|
||
--------------------------------
|
||
|
||
Registers are allocated in order.
|
||
|
||
`REG_ALLOC_ORDER'
|
||
If defined, an initializer for a vector of integers, containing the
|
||
numbers of hard registers in the order in which GNU CC should
|
||
prefer to use them (from most preferred to least).
|
||
|
||
If this macro is not defined, registers are used lowest numbered
|
||
first (all else being equal).
|
||
|
||
One use of this macro is on machines where the highest numbered
|
||
registers must always be saved and the save-multiple-registers
|
||
instruction supports only sequences of consecutive registers. On
|
||
such machines, define `REG_ALLOC_ORDER' to be an initializer that
|
||
lists the highest numbered allocable register first.
|
||
|
||
`ORDER_REGS_FOR_LOCAL_ALLOC'
|
||
A C statement (sans semicolon) to choose the order in which to
|
||
allocate hard registers for pseudo-registers local to a basic
|
||
block.
|
||
|
||
Store the desired register order in the array `reg_alloc_order'.
|
||
Element 0 should be the register to allocate first; element 1, the
|
||
next register; and so on.
|
||
|
||
The macro body should not assume anything about the contents of
|
||
`reg_alloc_order' before execution of the macro.
|
||
|
||
On most machines, it is not necessary to define this macro.
|
||
|
||
|
||
File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
|
||
|
||
How Values Fit in Registers
|
||
---------------------------
|
||
|
||
This section discusses the macros that describe which kinds of values
|
||
(specifically, which machine modes) each register can hold, and how many
|
||
consecutive registers are needed for a given mode.
|
||
|
||
`HARD_REGNO_NREGS (REGNO, MODE)'
|
||
A C expression for the number of consecutive hard registers,
|
||
starting at register number REGNO, required to hold a value of mode
|
||
MODE.
|
||
|
||
On a machine where all registers are exactly one word, a suitable
|
||
definition of this macro is
|
||
|
||
#define HARD_REGNO_NREGS(REGNO, MODE) \
|
||
((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
|
||
/ UNITS_PER_WORD))
|
||
|
||
`HARD_REGNO_MODE_OK (REGNO, MODE)'
|
||
A C expression that is nonzero if it is permissible to store a
|
||
value of mode MODE in hard register number REGNO (or in several
|
||
registers starting with that one). For a machine where all
|
||
registers are equivalent, a suitable definition is
|
||
|
||
#define HARD_REGNO_MODE_OK(REGNO, MODE) 1
|
||
|
||
You need not include code to check for the numbers of fixed
|
||
registers, because the allocation mechanism considers them to be
|
||
always occupied.
|
||
|
||
On some machines, double-precision values must be kept in even/odd
|
||
register pairs. You can implement that by defining this macro to
|
||
reject odd register numbers for such modes.
|
||
|
||
The minimum requirement for a mode to be OK in a register is that
|
||
the `movMODE' instruction pattern support moves between the
|
||
register and other hard register in the same class and that moving
|
||
a value into the register and back out not alter it.
|
||
|
||
Since the same instruction used to move `word_mode' will work for
|
||
all narrower integer modes, it is not necessary on any machine for
|
||
`HARD_REGNO_MODE_OK' to distinguish between these modes, provided
|
||
you define patterns `movhi', etc., to take advantage of this. This
|
||
is useful because of the interaction between `HARD_REGNO_MODE_OK'
|
||
and `MODES_TIEABLE_P'; it is very desirable for all integer modes
|
||
to be tieable.
|
||
|
||
Many machines have special registers for floating point arithmetic.
|
||
Often people assume that floating point machine modes are allowed
|
||
only in floating point registers. This is not true. Any
|
||
registers that can hold integers can safely *hold* a floating
|
||
point machine mode, whether or not floating arithmetic can be done
|
||
on it in those registers. Integer move instructions can be used
|
||
to move the values.
|
||
|
||
On some machines, though, the converse is true: fixed-point machine
|
||
modes may not go in floating registers. This is true if the
|
||
floating registers normalize any value stored in them, because
|
||
storing a non-floating value there would garble it. In this case,
|
||
`HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
|
||
floating registers. But if the floating registers do not
|
||
automatically normalize, if you can store any bit pattern in one
|
||
and retrieve it unchanged without a trap, then any machine mode
|
||
may go in a floating register, so you can define this macro to say
|
||
so.
|
||
|
||
The primary significance of special floating registers is rather
|
||
that they are the registers acceptable in floating point arithmetic
|
||
instructions. However, this is of no concern to
|
||
`HARD_REGNO_MODE_OK'. You handle it by writing the proper
|
||
constraints for those instructions.
|
||
|
||
On some machines, the floating registers are especially slow to
|
||
access, so that it is better to store a value in a stack frame
|
||
than in such a register if floating point arithmetic is not being
|
||
done. As long as the floating registers are not in class
|
||
`GENERAL_REGS', they will not be used unless some pattern's
|
||
constraint asks for one.
|
||
|
||
`MODES_TIEABLE_P (MODE1, MODE2)'
|
||
A C expression that is nonzero if a value of mode MODE1 is
|
||
accessible in mode MODE2 without copying.
|
||
|
||
If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
|
||
MODE2)' are always the same for any R, then `MODES_TIEABLE_P
|
||
(MODE1, MODE2)' should be nonzero. If they differ for any R, you
|
||
should define this macro to return zero unless some other
|
||
mechanism ensures the accessibility of the value in a narrower
|
||
mode.
|
||
|
||
You should define this macro to return nonzero in as many cases as
|
||
possible since doing so will allow GNU CC to perform better
|
||
register allocation.
|
||
|
||
|
||
File: gcc.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".
|
||
|
||
GNU CC 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.
|
||
|
||
`LEAF_REGISTERS'
|
||
A C initializer for a 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 GNU CC 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.
|
||
|
||
`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.
|
||
|
||
Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
|
||
leaf functions specially. It can test the C variable `leaf_function'
|
||
which is nonzero for leaf functions. (The variable `leaf_function' is
|
||
defined only if `LEAF_REGISTERS' is defined.)
|
||
|
||
|
||
File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, 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, as in the 80387 coprocessor for the 80386.
|
||
Stack registers are normally written by pushing onto the stack, and are
|
||
numbered relative to the top of the stack.
|
||
|
||
Currently, GNU CC can only handle one group of stack-like registers,
|
||
and they must be consecutively numbered.
|
||
|
||
`STACK_REGS'
|
||
Define this if the machine has any stack-like registers.
|
||
|
||
`FIRST_STACK_REG'
|
||
The number of the first stack-like register. This one is the top
|
||
of the stack.
|
||
|
||
`LAST_STACK_REG'
|
||
The number of the last stack-like register. This one is the
|
||
bottom of the stack.
|
||
|
||
|
||
File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
|
||
|
||
Obsolete Macros for Controlling Register Usage
|
||
----------------------------------------------
|
||
|
||
These features do not work very well. They exist because they used
|
||
to be required to generate correct code for the 80387 coprocessor of the
|
||
80386. They are no longer used by that machine description and may be
|
||
removed in a later version of the compiler. Don't use them!
|
||
|
||
`OVERLAPPING_REGNO_P (REGNO)'
|
||
If defined, this is a C expression whose value is nonzero if hard
|
||
register number REGNO is an overlapping register. This means a
|
||
hard register which overlaps a hard register with a different
|
||
number. (Such overlap is undesirable, but occasionally it allows
|
||
a machine to be supported which otherwise could not be.) This
|
||
macro must return nonzero for *all* the registers which overlap
|
||
each other. GNU CC can use an overlapping register only in
|
||
certain limited ways. It can be used for allocation within a
|
||
basic block, and may be spilled for reloading; that is all.
|
||
|
||
If this macro is not defined, it means that none of the hard
|
||
registers overlap each other. This is the usual situation.
|
||
|
||
`INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
|
||
If defined, this is a C expression whose value should be nonzero if
|
||
the insn INSN has the effect of mysteriously clobbering the
|
||
contents of hard register number REGNO. By "mysterious" we mean
|
||
that the insn's RTL expression doesn't describe such an effect.
|
||
|
||
If this macro is not defined, it means that no insn clobbers
|
||
registers mysteriously. This is the usual situation; all else
|
||
being equal, it is best for the RTL expression to show all the
|
||
activity.
|
||
|
||
`PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
|
||
If defined, this is a C expression whose value is nonzero if
|
||
correct `REG_DEAD' notes are needed for hard register number REGNO
|
||
after reload.
|
||
|
||
You would arrange to preserve death info for a register when some
|
||
of the code in the machine description which is executed to write
|
||
the assembler code looks at the death notes. This is necessary
|
||
only when the actual hardware feature which GNU CC thinks of as a
|
||
register is not actually a register of the usual sort. (It might,
|
||
for example, be a hardware stack.)
|
||
|
||
It is also useful for peepholes and linker relaxation.
|
||
|
||
If this macro is not defined, it means that no death notes need to
|
||
be preserved, and some may even be incorrect. This is the usual
|
||
situation.
|
||
|
||
|
||
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 than 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_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'.
|
||
|
||
`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 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.
|
||
|
||
`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.
|
||
|
||
`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, `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 a intermediate storage. This case often occurs between
|
||
floating-point and general registers.
|
||
|
||
`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 non-zero 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.
|
||
|
||
`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'.
|
||
|
||
`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.
|
||
|
||
`SMALL_REGISTER_CLASSES'
|
||
Normally the compiler avoids choosing registers that have been
|
||
explicitly mentioned in the rtl as spill registers (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.
|
||
|
||
Define `SMALL_REGISTER_CLASSES' to be an expression with a non-zero
|
||
value on these machines. When this macro has a non-zero value, the
|
||
compiler allows registers explicitly used in the rtl to be used as
|
||
spill registers but avoids extending the lifetime of these
|
||
registers.
|
||
|
||
It is always safe to define this macro with a non-zero 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 non-zero 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.
|
||
|
||
`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 pseudo 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.
|
||
|
||
`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.
|
||
|
||
`CLASS_CANNOT_CHANGE_SIZE'
|
||
If defined, a C expression for a class that contains registers
|
||
which the compiler must always access in a mode that is the same
|
||
size as the mode in which it loaded the register.
|
||
|
||
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 this macro as
|
||
`FLOAT_REGS'.
|
||
|
||
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 (`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.
|
||
|
||
`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.
|
||
|
||
`EXTRA_CONSTRAINT (VALUE, C)'
|
||
A C expression that defines the optional machine-dependent
|
||
constraint letters (`Q', `R', `S', `T', `U') 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
|
||
|
||
Stack Layout and Calling Conventions
|
||
====================================
|
||
|
||
This describes the stack layout and calling conventions.
|
||
|
||
* Menu:
|
||
|
||
* Frame Layout::
|
||
* Stack Checking::
|
||
* Frame Registers::
|
||
* Elimination::
|
||
* Stack Arguments::
|
||
* Register Arguments::
|
||
* Scalar Return::
|
||
* Aggregate Return::
|
||
* Caller Saves::
|
||
* Function Entry::
|
||
* Profiling::
|
||
|
||
|
||
File: gcc.info, Node: Frame Layout, Next: Stack Checking, Up: Stack and Calling
|
||
|
||
Basic Stack Layout
|
||
------------------
|
||
|
||
Here is the 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', 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'.
|
||
|
||
`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.
|
||
|
||
`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. This
|
||
macro will seldom need to be defined.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
|
||
File: gcc.info, Node: Stack Checking, Next: Frame Registers, Prev: Frame Layout, Up: Stack and Calling
|
||
|
||
Specifying How Stack Checking is Done
|
||
-------------------------------------
|
||
|
||
GNU CC 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, GNU CC
|
||
will assume that you have arranged for stack checking to be done at
|
||
appropriate places in the configuration files, e.g., in
|
||
`FUNCTION_PROLOGUE'. GNU CC 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, GNU CC 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, GNU CC 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 GNU CC
|
||
will use the third approach.
|
||
|
||
`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 GNU CC's portable approach. The default value of this macro
|
||
is zero.
|
||
|
||
`STACK_CHECK_PROBE_INTERVAL'
|
||
An integer representing the interval at which GNU CC 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.
|
||
|
||
`STACK_CHECK_PROBE_LOAD'
|
||
A integer which is nonzero if GNU CC should perform the stack probe
|
||
as a load instruction and zero if GNU CC should use a store
|
||
instruction. The default is zero, which is the most efficient
|
||
choice on most systems.
|
||
|
||
`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.
|
||
|
||
`STACK_CHECK_MAX_FRAME_SIZE'
|
||
The maximum size of a stack frame, in bytes. GNU CC 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 GNU CC
|
||
will issue a warning. The default is chosen so that GNU CC only
|
||
generates one instruction on most systems. You should normally
|
||
not change the default value of this macro.
|
||
|
||
`STACK_CHECK_FIXED_FRAME_SIZE'
|
||
GNU CC 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.
|
||
|
||
`STACK_CHECK_MAX_VAR_SIZE'
|
||
The maximum size, in bytes, of an object that GNU CC will place in
|
||
the fixed area of the stack frame when the user specifies
|
||
`-fstack-check'. GNU CC computed the default from the values of
|
||
the above macros and you will normally not need to override that
|
||
default.
|
||
|