tm.texi

GUN开源阻止下的编译器GCC

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.

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.
@end table

@findex leaf_function
Normally, @code{FUNCTION_PROLOGUE} and @code{FUNCTION_EPILOGUE} must
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.)
@c changed this to fix overfull.  ALSO:  why the "it" at the beginning
@c of the next paragraph?!  --mew 2feb93 

@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
@findex OVERLAPPING_REGNO_P 
@item OVERLAPPING_REGNO_P (@var{regno})
If defined, this is a C expression whose value is nonzero if hard
register number @var{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 @emph{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.

@findex INSN_CLOBBERS_REGNO_P
@item INSN_CLOBBERS_REGNO_P (@var{insn}, @var{regno})
If defined, this is a C expression whose value should be nonzero if
the insn @var{insn} has the effect of mysteriously clobbering the
contents of hard register number @var{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.

@cindex death notes
@findex PRESERVE_DEATH_INFO_REGNO_P
@item PRESERVE_DEATH_INFO_REGNO_P (@var{regno})
If defined, this is a C expression whose value is nonzero if accurate
@code{REG_DEAD} notes are needed for hard register number @var{regno}
at the time of outputting the assembler code.  When this is so, a few
optimizations that take place after register allocation and could
invalidate the death notes are not done when this register is
involved.

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

If this macro is not defined, it means that no death notes need to be
preserved.  This is the usual situation.
@end table

@node Register Classes
@section Register Classes
@cindex register class definitions
@cindex class definitions, register

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 @dfn{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.

@findex ALL_REGS
@findex NO_REGS
In general, each register will belong to several classes.  In fact, one
class must be named @code{ALL_REGS} and contain all the registers.  Another
class must be named @code{NO_REGS} and contain no registers.  Often the
union of two classes will be another class; however, this is not required.

@findex GENERAL_REGS
One of the classes must be named @code{GENERAL_REGS}.  There is nothing
terribly special about the name, but the operand constraint letters
@samp{r} and @samp{g} specify this class.  If @code{GENERAL_REGS} is
the same as @code{ALL_REGS}, just define it as a macro which expands
to @code{ALL_REGS}.

Order the classes so that if class @var{x} is contained in class @var{y}
then @var{x} has a lower class number than @var{y}.

The way classes other than @code{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 @code{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 @code{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 (@code{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
@code{PREFERRED_RELOAD_CLASS} can always have a possible value to return.

@table @code
@findex enum reg_class
@item enum reg_class
An enumeral type that must be defined with all the register class names
as enumeral values.  @code{NO_REGS} must be first.  @code{ALL_REGS}
must be the last register class, followed by one more enumeral value,
@code{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 @code{int}.  The number serves as an index
in many of the tables described below.

@findex N_REG_CLASSES
@item N_REG_CLASSES
The number of distinct register classes, defined as follows:

@example
#define N_REG_CLASSES (int) LIM_REG_CLASSES
@end example

@findex REG_CLASS_NAMES
@item 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.

@findex REG_CLASS_CONTENTS
@item REG_CLASS_CONTENTS
An initializer containing the contents of the register classes, as integers
which are bit masks.  The @var{n}th integer specifies the contents of class
@var{n}.  The way the integer @var{mask} is interpreted is that
register @var{r} is in the class if @code{@var{mask} & (1 << @var{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 @code{HARD_REG_SET} which is defined in @file{hard-reg-set.h}.

@findex REGNO_REG_CLASS 
@item REGNO_REG_CLASS (@var{regno})
A C expression whose value is a register class containing hard register
@var{regno}.  In general there is more than one such class; choose a class
which is @dfn{minimal}, meaning that no smaller class also contains the
register.

@findex BASE_REG_CLASS
@item 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.

@findex INDEX_REG_CLASS
@item 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).

@findex REG_CLASS_FROM_LETTER
@item REG_CLASS_FROM_LETTER (@var{char})
A C expression which defines the machine-dependent operand constraint
letters for register classes.  If @var{char} is such a letter, the
value should be the register class corresponding to it.  Otherwise,
the value should be @code{NO_REGS}.  The register letter @samp{r},
correspondi