tm.texi

早期freebsd实现

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 @var{n}th number is 1 if
register @var{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 @code{CONDITIONAL_REGISTER_USAGE}, or by
the user with the command options @samp{-ffixed-@var{reg}},
@samp{-fcall-used-@var{reg}} and @samp{-fcall-saved-@var{reg}}.

@findex CALL_USED_REGISTERS
@item CALL_USED_REGISTERS
@cindex call-used register
@cindex call-clobbered register
@cindex call-saved register
Like @code{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 @code{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.

@findex CONDITIONAL_REGISTER_USAGE
@findex fixed_regs
@findex call_used_regs
@item CONDITIONAL_REGISTER_USAGE
Zero or more C statements that may conditionally modify two variables
@code{fixed_regs} and @code{call_used_regs} (both of type @code{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.

@cindex disabling certain registers
@cindex controlling register usage 
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
@code{fixed_regs} and @code{call_used_regs} to 1 for each of the
registers in the classes which should not be used by GCC.  Also define
the macro @code{REG_CLASS_FROM_LETTER} to return @code{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 @code{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.)

@findex NON_SAVING_SETJMP
@item NON_SAVING_SETJMP
If this macro is defined and has a nonzero value, it means that
@code{setjmp} and related functions fail to save the registers, or that
@code{longjmp} fails to restore them.  To compensate, the compiler
avoids putting variables in registers in functions that use
@code{setjmp}.

@ignore
@findex PC_REGNUM
@item PC_REGNUM
If the program counter has a register number, define this as that
register number.  Otherwise, do not define it.
@end ignore
@end table

@node Allocation Order
@subsection Order of Allocation of Registers
@cindex order of register allocation
@cindex register allocation order

@table @code
@findex REG_ALLOC_ORDER
@item 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 @code{REG_ALLOC_ORDER} to be an initializer that lists
the highest numbered allocatable register first.

@findex ORDER_REGS_FOR_LOCAL_ALLOC
@item 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 order of registers in the array
@code{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
@code{reg_alloc_order} before execution of the macro.

On most machines, it is not necessary to define this macro.
@end table

@node Values in Registers
@subsection 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.

@table @code
@findex HARD_REGNO_NREGS
@item HARD_REGNO_NREGS (@var{regno}, @var{mode})
A C expression for the number of consecutive hard registers, starting
at register number @var{regno}, required to hold a value of mode
@var{mode}.

On a machine where all registers are exactly one word, a suitable
definition of this macro is

@example
#define HARD_REGNO_NREGS(REGNO, MODE)            \
   ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1)  \
    / UNITS_PER_WORD))
@end example

@findex HARD_REGNO_MODE_OK
@item HARD_REGNO_MODE_OK (@var{regno}, @var{mode})
A C expression that is nonzero if it is permissible to store a value
of mode @var{mode} in hard register number @var{regno} (or in several
registers starting with that one).  For a machine where all registers
are equivalent, a suitable definition is

@example
#define HARD_REGNO_MODE_OK(REGNO, MODE) 1
@end example

It is not necessary for this macro to check for the numbers of fixed
registers, because the allocation mechanism considers them to be always
occupied.

@cindex register pairs
On some machines, double-precision values must be kept in even/odd
register pairs.  The way to implement that is to define this macro
to reject odd register numbers for such modes.

@ignore
@c I think this is not true now
GNU CC assumes that it can always move values between registers and
(suitably addressed) memory locations.  If it is impossible to move a
value of a certain mode between memory and certain registers, then
@code{HARD_REGNO_MODE_OK} must not allow this mode in those registers.
@end ignore

The minimum requirement for a mode to be OK in a register is that the
@samp{mov@var{mode}} instruction pattern support moves between the
register and any other hard register for which the mode is OK; and that
moving a value into the register and back out not alter it.

Since the same instruction used to move @code{SImode} will work for all
narrower integer modes, it is not necessary on any machine for
@code{HARD_REGNO_MODE_OK} to distinguish between these modes, provided
you define patterns @samp{movhi}, etc., to take advantage of this.  This
is useful because of the interaction between @code{HARD_REGNO_MODE_OK}
and @code{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 @emph{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,
@code{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.

On some machines, such as the Sparc and the Mips, we get better code
by defining @code{HARD_REGNO_MODE_OK} to forbid integers in floating
registers, even though the hardware is capable of handling them.  This
is because transferring values between floating registers and general
registers is so slow that it is better to keep the integer in memory.

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
@code{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 @code{GENERAL_REGS}, they will not
be used unless some pattern's constraint asks for one.

@findex MODES_TIEABLE_P
@item MODES_TIEABLE_P (@var{mode1}, @var{mode2})
A C expression that is nonzero if it is desirable to choose register
allocation so as to avoid move instructions between a value of mode
@var{mode1} and a value of mode @var{mode2}.

If @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode1})} and
@code{HARD_REGNO_MODE_OK (@var{r}, @var{mode2})} are ever different
for any @var{r}, then @code{MODES_TIEABLE_P (@var{mode1},
@var{mode2})} must be zero.
@end table

@node Leaf Functions
@subsection Handling Leaf Functions

@cindex leaf functions
@cindex functions, leaf
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.

@table @code
@findex LEAF_REGISTERS
@item 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.

@findex LEAF_REG_REMAP
@item LEAF_REG_REMAP (@var{regno})
A C expression whose value is the register number to which @var{regno}
should be renumbered, when a function is treated as a leaf function.

If @var{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.

@findex REG_LEAF_ALLOC_ORDER
@item REG_LEAF_ALLOC_ORDER
If defined, an initializer for a vector of integers, containing the
numbers of hard registers in the order in which the GNU CC should prefer
to use them (from most preferred to least) in a leaf function.  If this
macro is not defined, REG_ALLOC_ORDER is used for both non-leaf and
leaf-functions.
@end table

@findex leaf_function
Normally, it is necessary for @code{FUNCTION_PROLOGUE} and
@code{FUNCTION_EPILOGUE} to treat leaf functions specially.  It can test
the C variable @code{leaf_function} which is nonzero for leaf functions.
(The variable @code{leaf_function} is defined only if
@code{LEAF_REGISTERS} is defined.)

@node Stack Registers
@subsection 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.

@table @code
@findex STACK_REGS
@item STACK_REGS
Define this if the machine has any stack-like registers.

@findex FIRST_STACK_REG
@item FIRST_STACK_REG
The number of the first stack-like register.  This one is the top
of the stack.

@findex LAST_STACK_REG
@item LAST_STACK_REG
The number of the last stack-like register.  This one is the bottom of
the stack.
@end table

@node Obsolete Register Macros
@subsection 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!

@table @code