| This is Info file gcc.info, produced by Makeinfo version 1.68 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. |
| |