@ignore@findex PC_REGNUM@item PC_REGNUMIf the program counter has a register number, define this as thatregister 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@c prevent bad page break with this lineRegisters are allocated in order.@table @code@findex REG_ALLOC_ORDER@item REG_ALLOC_ORDERIf defined, an initializer for a vector of integers, containing thenumbers of hard registers in the order in which GNU CC should preferto 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 numberedregisters must always be saved and the save-multiple-registersinstruction supports only sequences of consecutive registers.  On suchmachines, define @code{REG_ALLOC_ORDER} to be an initializer that liststhe highest numbered allocable register first.@findex ORDER_REGS_FOR_LOCAL_ALLOC@item ORDER_REGS_FOR_LOCAL_ALLOCA C statement (sans semicolon) to choose the order in which to allocatehard registers for pseudo-registers local to a basic block.Store the desired register order in the array @code{reg_alloc_order}.Element 0 should be the register to allocate first; element 1, the nextregister; 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 RegistersThis section discusses the macros that describe which kinds of values(specifically, which machine modes) each register can hold, and how manyconsecutive 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, startingat register number @var{regno}, required to hold a value of mode@var{mode}.On a machine where all registers are exactly one word, a suitabledefinition of this macro is@smallexample#define HARD_REGNO_NREGS(REGNO, MODE)            \   ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1)  \    / UNITS_PER_WORD))@end smallexample@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 valueof mode @var{mode} in hard register number @var{regno} (or in severalregisters starting with that one).  For a machine where all registersare equivalent, a suitable definition is@smallexample#define HARD_REGNO_MODE_OK(REGNO, MODE) 1@end smallexampleYou need not include code to check for the numbers of fixed registers,because the allocation mechanism considers them to be always occupied.@cindex register pairsOn some machines, double-precision values must be kept in even/oddregister pairs.  You can implement that by defining this macro to rejectodd register numbers for such modes.The minimum requirement for a mode to be OK in a register is that the@samp{mov@var{mode}} instruction pattern support moves between theregister and other hard register in the same class and that moving avalue into the register and back out not alter it.Since the same instruction used to move @code{word_mode} will work forall narrower integer modes, it is not necessary on any machine for@code{HARD_REGNO_MODE_OK} to distinguish between these modes, providedyou define patterns @samp{movhi}, etc., to take advantage of this.  Thisis useful because of the interaction between @code{HARD_REGNO_MODE_OK}and @code{MODES_TIEABLE_P}; it is very desirable for all integer modesto be tieable.Many machines have special registers for floating point arithmetic.Often people assume that floating point machine modes are allowed onlyin floating point registers.  This is not true.  Any registers thatcan hold integers can safely @emph{hold} a floating point machinemode, whether or not floating arithmetic can be done on it in thoseregisters.  Integer move instructions can be used to move the values.On some machines, though, the converse is true: fixed-point machinemodes may not go in floating registers.  This is true if the floatingregisters normalize any value stored in them, because storing anon-floating value there would garble it.  In this case,@code{HARD_REGNO_MODE_OK} should reject fixed-point machine modes infloating registers.  But if the floating registers do not automaticallynormalize, if you can store any bit pattern in one and retrieve itunchanged without a trap, then any machine mode may go in a floatingregister, so you can define this macro to say so.The primary significance of special floating registers is rather thatthey are the registers acceptable in floating point arithmeticinstructions.  However, this is of no concern to@code{HARD_REGNO_MODE_OK}.  You handle it by writing the properconstraints 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 aregister if floating point arithmetic is not being done.  As long as thefloating registers are not in class @code{GENERAL_REGS}, they will notbe 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 a value of mode@var{mode1} is accessible in mode @var{mode2} without copying.If @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode1})} and@code{HARD_REGNO_MODE_OK (@var{r}, @var{mode2})} are always the same forany @var{r}, then @code{MODES_TIEABLE_P (@var{mode1}, @var{mode2})}should be nonzero.  If they differ for any @var{r}, you should definethis macro to return zero unless some other mechanism ensures theaccessibility of the value in a narrower mode.You should define this macro to return nonzero in as many cases aspossible since doing so will allow GNU CC to perform better registerallocation.@end table@node Leaf Functions@subsection Handling Leaf Functions@cindex leaf functions@cindex functions, leafOn some machines, a leaf function (i.e., one which makes no calls) can runmore efficiently if it does not make its own register window.  Often thismeans it is required to receive its arguments in the registers where theyare passed by the caller, instead of the registers where they wouldnormally arrive.The special treatment for leaf functions generally applies only whenother conditions are met; for example, often they may use only thoseregisters for its own variables and temporaries.  We use the term ``leaffunction'' to mean a function that is suitable for this specialhandling, so that functions with no calls are not necessarily ``leaffunctions''.GNU CC assigns register numbers before it knows whether the function issuitable for leaf function treatment.  So it needs to renumber theregisters in order to output a leaf function.  The following macrosaccomplish this.@table @code@findex LEAF_REGISTERS@item LEAF_REGISTERSA C initializer for a vector, indexed by hard register number, whichcontains 1 for a register that is allowable in a candidate for leaffunction treatment.If leaf function treatment involves renumbering the registers, then theregisters marked here should be the ones before renumbering---those thatGNU CC would ordinarily allocate.  The registers which will actually beused in the assembler code, after renumbering, should not be marked with 1in this vector.Define this macro only if the target machine offers a way to optimizethe 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 leaffunction before renumbering, then the expression should yield -1, whichwill cause the compiler to abort.Define this macro only if the target machine offers a way to optimize thetreatment of leaf functions, and registers need to be renumbered to dothis.@end table@findex leaf_functionNormally, @code{FUNCTION_PROLOGUE} and @code{FUNCTION_EPILOGUE} musttreat 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} isdefined.)@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 StackThere 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 arenumbered relative to the top of the stack.Currently, GNU CC can only handle one group of stack-like registers, andthey must be consecutively numbered.@table @code@findex STACK_REGS@item STACK_REGSDefine this if the machine has any stack-like registers.@findex FIRST_STACK_REG@item FIRST_STACK_REGThe number of the first stack-like register.  This one is the topof the stack.@findex LAST_STACK_REG@item LAST_STACK_REGThe number of the last stack-like register.  This one is the bottom ofthe stack.@end table@node Obsolete Register Macros@subsection Obsolete Macros for Controlling Register UsageThese features do not work very well.  They exist because they used tobe required to generate correct code for the 80387 coprocessor of the80386.  They are no longer used by that machine description and may beremoved 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 hardregister number @var{regno} is an overlapping register.  This means ahard register which overlaps a hard register with a different number.(Such overlap is undesirable, but occasionally it allows a machine tobe supported which otherwise could not be.)  This macro must returnnonzero for @emph{all} the registers which overlap each other.  GNU CCcan use an overlapping register only in certain limited ways.  It canbe used for allocation within a basic block, and may be spilled forreloading; that is all.If this macro is not defined, it means that none of the hard registersoverlap 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 ifthe insn @var{insn} has the effect of mysteriously clobbering thecontents of hard register number @var{regno}.  By ``mysterious'' wemean that the insn's RTL expression doesn't describe such an effect.If this macro is not defined, it means that no insn clobbers registersmysteriously.  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 correct@code{REG_DEAD} notes are needed for hard register number @var{regno}after reload.You would arrange to preserve death info for a register when some of thecode in the machine description which is executed to write the assemblercode looks at the death notes.  This is necessary only when the actualhardware feature which GNU CC thinks of as a register is not actually aregister of the usual sort.  (It might, for example, be a hardwarestack.)It is also useful for peepholes and linker relaxation.If this macro is not defined, it means that no death notes need to bepreserved, and some may even be incorrect.  This is the usual situation.@end table@node Register Classes@section Register Classes@cindex register class definitions@cindex class definitions, registerOn 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 machinerestrictions are described to the compiler using @dfn{register classes}.You define a number of register classes, giving each one a name and sayingwhich of the registers belong to it.  Then you can specify register classesthat are allowed as operands to particular instruction patterns.@findex ALL_REGS@findex NO_REGSIn general, each register will belong to several classes.  In fact, oneclass must be named @code{ALL_REGS} and contain all the registers.  Anotherclass must be named @code{NO_REGS} and contain no registers.  Often theunion of two classes will be another class; however, this is not required.@findex GENERAL_REGSOne of the classes must be named @code{GENERAL_REGS}.  There is nothingterribly special about the name, but the operand constraint letters@samp{r} and @samp{g} specify this class.  If @code{GENERAL_REGS} isthe same as @code{ALL_REGS}, just define it as a macro which expandsto @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 operandconstraints is through machine-dependent operand constraint letters.You can define such letters to correspond to various classes, then usethem in operand constraints.You should define a class for the union of two classes whenever someinstruction allows both classes.  For example, if an instruction allowseither a flo