--- gcc/gcc.info-13 2018/04/24 17:52:07 1.1.1.2 +++ gcc/gcc.info-13 2018/04/24 17:56:06 1.1.1.3 @@ -1,1033 +1,1117 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 from the input +This is Info file gcc.info, produced by Makeinfo-1.47 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Copyright (C) 1988, 1989, 1992 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 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 section entitled "GNU General Public License" is 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. +that the sections entitled "GNU General Public License" and "Boycott" +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 section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +License" and "Boycott", 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: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros +File: gcc.info, Node: Driver, Next: Run-time Target, Up: Target Macros -Register Classes -================ +Controlling the Compilation Driver, `gcc' +========================================= - 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 that 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_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 - definition - - #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS - - is safe. - - 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. - -`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, you should define - `SECONDARY_OUTPUT_RELOAD_CLASS' 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. - -`SMALL_REGISTER_CLASSES' - Normally the compiler will avoid choosing spill registers from - registers that have been explicitly mentioned in the rtl (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. - - On those machines, you should define `SMALL_REGISTER_CLASSES'. - When it is defined, the compiler allows registers explicitly used - in the rtl to be used as spill registers but prevents the - compiler from extending the lifetime of these registers. - - Defining this macro is always safe, but unnecessarily defining - this macro will reduce the amount of optimizations that can be - performed in some cases. If this macro is not defined but needs - to be, the compiler will run out of reload registers and print a - fatal error message. - - For most machines, this macro should not be defined. - -`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. - - 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 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. - - 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 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. +`SWITCH_TAKES_ARG (CHAR)' + A C expression which determines whether the option `-CHAR' takes + arguments. The value should be the number of arguments that + option takes--zero, for many options. - -File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros + By default, this macro is defined to handle the standard options + properly. You need not define it unless you wish to add additional + options which take arguments. -Describing Stack Layout and Calling Conventions -=============================================== +`WORD_SWITCH_TAKES_ARG (NAME)' + A C expression which determines whether the option `-NAME' takes + arguments. The value should be the number of arguments that + option takes--zero, for many options. This macro rather than + `SWITCH_TAKES_ARG' is used for multi-character option names. -* Menu: + By default, this macro is defined to handle the standard options + properly. You need not define it unless you wish to add additional + options which take arguments. -* Frame Layout:: -* Frame Registers:: -* Elimination:: -* Stack Arguments:: -* Register Arguments:: -* Scalar Return:: -* Aggregate Return:: -* Caller Saves:: -* Function Entry:: -* Profiling:: +`SWITCHES_NEED_SPACES' + A string-valued C expression which is nonempty if the linker needs + a space between the `-L' or `-o' option and its argument. - -File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling + If this macro is not defined, the default value is 0. -Basic Stack Layout ------------------- +`CPP_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to CPP. It can also specify how to translate options you + give to GNU CC into options for GNU CC to pass to the CPP. -`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', the next slot's offset is found by - subtracting the length of the first slot 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. + Do not define this macro if it does not need to do anything. + +`SIGNED_CHAR_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to CPP. By default, this macro is defined to pass the option + `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as + `unsigned char' by `cc1'. + + Do not define this macro unless you need to override the default + definition. + +`CC1_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to `cc1'. It can also specify how to translate options you + give to GNU CC into options for GNU CC to pass to the `cc1'. + + Do not define this macro if it does not need to do anything. + +`CC1PLUS_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to `cc1plus'. It can also specify how to translate options + you give to GNU CC into options for GNU CC to pass to the + `cc1plus'. + + Do not define this macro if it does not need to do anything. + +`ASM_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to the assembler. It can also specify how to translate + options you give to GNU CC into options for GNU CC to pass to the + assembler. See the file `sun3.h' for an example of this. + + Do not define this macro if it does not need to do anything. + +`ASM_FINAL_SPEC' + A C string constant that tells the GNU CC driver program how to + run any programs which cleanup after the normal assembler. + Normally, this is not needed. See the file `mips.h' for an + example of this. + + Do not define this macro if it does not need to do anything. + +`LINK_SPEC' + A C string constant that tells the GNU CC driver program options to + pass to the linker. It can also specify how to translate options + you give to GNU CC into options for GNU CC to pass to the linker. + + Do not define this macro if it does not need to do anything. + +`LIB_SPEC' + Another C string constant used much like `LINK_SPEC'. The + difference between the two is that `LIB_SPEC' is used at the end + of the command given to the linker. + + If this macro is not defined, a default is provided that loads the + standard C library from the usual place. See `gcc.c'. + +`STARTFILE_SPEC' + Another C string constant used much like `LINK_SPEC'. The + difference between the two is that `STARTFILE_SPEC' is used at the + very beginning of the command given to the linker. + + If this macro is not defined, a default is provided that loads the + standard C startup file from the usual place. See `gcc.c'. + +`ENDFILE_SPEC' + Another C string constant used much like `LINK_SPEC'. The + difference between the two is that `ENDFILE_SPEC' is used at the + very end of the command given to the linker. + + Do not define this macro if it does not need to do anything. + +`LINK_LIBGCC_SPECIAL' + Define this macro meaning that `gcc' should find the library + `libgcc.a' by hand, rather than passing the argument `-lgcc' to + tell the linker to do the search. + +`RELATIVE_PREFIX_NOT_LINKDIR' + Define this macro to tell `gcc' that it should only translate a + `-B' prefix into a `-L' linker option if the prefix indicates an + absolute file name. + +`STANDARD_EXEC_PREFIX' + Define this macro as a C string constant if you wish to override + the standard choice of `/usr/local/lib/gcc-lib/' as the default + prefix to try when searching for the executable files of the + compiler. + +`MD_EXEC_PREFIX' + If defined, this macro is an additional prefix to try after + `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the + `-b' option is used, or the compiler is built as a cross compiler. + +`STANDARD_STARTFILE_PREFIX' + Define this macro as a C string constant if you wish to override + the standard choice of `/usr/local/lib/' as the default prefix to + try when searching for startup files such as `crt0.o'. + +`MD_STARTFILE_PREFIX' + If defined, this macro supplies an additional prefix to try after + the standard prefixes. `MD_EXEC_PREFIX' is not searched when the + `-b' option is used, or when the compiler is built as a cross + compiler. + +`MD_STARTFILE_PREFIX_1' + If defined, this macro supplies yet another prefix to try after the + standard prefixes. It is not searched when the `-b' option is + used, or when the compiler is built as a cross compiler. + +`LOCAL_INCLUDE_DIR' + Define this macro as a C string constant if you wish to override + the standard choice of `/usr/local/include' as the default prefix + to try when searching for local header files. `LOCAL_INCLUDE_DIR' + comes before `SYSTEM_INCLUDE_DIR' in the search order. + + Cross compilers do not use this macro and do not search either + `/usr/local/include' or its replacement. + +`SYSTEM_INCLUDE_DIR' + Define this macro as a C string constant if you wish to specify a + system-specific directory to search for header files before the + standard directory. `SYSTEM_INCLUDE_DIR' comes before + `STANDARD_INCLUDE_DIR' in the search order. + + Cross compilers do not use this macro and do not search the + directory specified. + +`STANDARD_INCLUDE_DIR' + Define this macro as a C string constant if you wish to override + the standard choice of `/usr/include' as the default prefix to try + when searching for header files. + + Cross compilers do not use this macro and do not search either + `/usr/include' or its replacement. + +`INCLUDE_DEFAULTS' + Define this macro if you wish to override the entire default + search path for include files. The default search path includes + `GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR', + `SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, + the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are + defined automatically by `Makefile', and specify private search + areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only + for C++ programs. + + The definition should be an initializer for an array of structures. + Each array element should have two elements: the directory name (a + string constant) and a flag for C++-only directories. Mark the + end of the array with a null element. For example, here is the + definition used for VMS: + + #define INCLUDE_DEFAULTS \ + { \ + { "GNU_GXX_INCLUDE:", 1}, \ + { "GNU_CC_INCLUDE:", 0}, \ + { "SYS$SYSROOT:[SYSLIB.]", 0}, \ + { ".", 0}, \ + { 0, 0} \ + } + + Here is the order of prefixes tried for exec files: + + 1. Any prefixes specified by the user with `-B'. + + 2. The environment variable `GCC_EXEC_PREFIX', if any. - If `ARGS_GROW_DOWNWARD', this is the offset to the location above - the first argument's address. + 3. The directories specified by the environment variable + `COMPILER_PATH'. -`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. + 4. The macro `STANDARD_EXEC_PREFIX'. + + 5. `/usr/lib/gcc/'. + + 6. The macro `MD_EXEC_PREFIX', if any. + + Here is the order of prefixes tried for startfiles: + + 1. Any prefixes specified by the user with `-B'. + + 2. The environment variable `GCC_EXEC_PREFIX', if any. + + 3. The directories specified by the environment variable + `LIBRARY_PATH'. + + 4. The macro `STANDARD_EXEC_PREFIX'. + + 5. `/usr/lib/gcc/'. + + 6. The macro `MD_EXEC_PREFIX', if any. + + 7. The macro `MD_STARTFILE_PREFIX', if any. + + 8. The macro `STANDARD_STARTFILE_PREFIX'. + + 9. `/lib/'. + + 10. `/usr/lib/'.  -File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling +File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Target Macros + +Run-time Target Specification +============================= + +`CPP_PREDEFINES' + Define this to be a string constant containing `-D' options to + define the predefined macros that identify this machine and system. + These macros will be predefined unless the `-ansi' option is + specified. -Registers That Address the Stack Frame --------------------------------------- + In addition, a parallel set of macros are predefined, whose names + are made by appending `__' at the beginning and at the end. These + `__' macros are permitted by the ANSI standard, so they are + predefined regardless of whether `-ansi' is specified. + + For example, on the Sun, one can use the following value: + + "-Dmc68000 -Dsun -Dunix" + + The result is to define the macros `__mc68000__', `__sun__' and + `__unix__' unconditionally, and the macros `mc68000', `sun' and + `unix' provided `-ansi' is not specified. + +`STDC_VALUE' + Define the value to be assigned to the built-in macro `__STDC__'. + The default is the value `1'. + +`extern int target_flags;' + This declaration should be present. + +`TARGET_...' + This series of macros is to allow compiler command arguments to + enable or disable the use of optional features of the target + machine. For example, one machine description serves both the + 68000 and the 68020; a command argument tells the compiler whether + it should use 68020-only instructions or not. This command + argument works by means of a macro `TARGET_68020' that tests a bit + in `target_flags'. + + Define a macro `TARGET_FEATURENAME' for each such option. Its + definition should test a bit in `target_flags'; for example: + + #define TARGET_68020 (target_flags & 1) + + One place where these macros are used is in the + condition-expressions of instruction patterns. Note how + `TARGET_68020' appears frequently in the 68000 machine description + file, `m68k.md'. Another place they are used is in the definitions + of the other macros in the `MACHINE.h' file. + +`TARGET_SWITCHES' + This macro defines names of command options to set and clear bits + in `target_flags'. Its definition is an initializer with a + subgrouping for each command option. + + Each subgrouping contains a string constant, that defines the + option name, and a number, which contains the bits to set in + `target_flags'. A negative number says to clear bits instead; the + negative of the number is which bits to clear. The actual option + name is made by appending `-m' to the specified name. + + One of the subgroupings should have a null string. The number in + this grouping is the default value for `target_flags'. Any target + options act starting with that value. + + Here is an example which defines `-m68000' and `-m68020' with + opposite meanings, and picks the latter as the default: + + #define TARGET_SWITCHES \ + { { "68020", 1}, \ + { "68000", -1}, \ + { "", 1}} + +`TARGET_OPTIONS' + This macro is similar to `TARGET_SWITCHES' but defines names of + command options that have values. Its definition is an + initializer with a subgrouping for each command option. + + Each subgrouping contains a string constant, that defines the + fixed part of the option name, and the address of a variable. The + variable, type `char *', is set to the variable part of the given + option if the fixed part matches. The actual option name is made + by appending `-m' to the specified name. + + Here is an example which defines `-mshort-data-NUMBER'. If the + given option is `-mshort-data-512', the variable `m88k_short_data' + will be set to the string `"512"'. + + extern char *m88k_short_data; + #define TARGET_OPTIONS { { "short-data-", &m88k_short_data } } + +`TARGET_VERSION' + This macro is a C statement to print on `stderr' a string + describing the particular machine description choice. Every + machine description should define `TARGET_VERSION'. For example: + + #ifdef MOTOROLA + #define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)"); + #else + #define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)"); + #endif + +`OVERRIDE_OPTIONS' + Sometimes certain combinations of command options do not make + sense on a particular target machine. You can define a macro + `OVERRIDE_OPTIONS' to take account of this. This macro, if + defined, is executed once just after all the command options have + been parsed. + + Don't use this macro to turn on various extra optimizations for + `-O'. That is what `OPTIMIZATION_OPTIONS' is for. + +`OPTIMIZATION_OPTIONS (LEVEL)' + Some machines may desire to change what optimizations are + performed for various optimization levels. This macro, if + defined, is executed once just after the optimization level is + determined and before the remainder of the command options have + been parsed. Values set in this macro are used as the default + values for the other command line options. -`STACK_POINTER_REGNUM' - The register number of the stack pointer register, which must - also be a fixed register according to `FIXED_REGISTERS'. On most - machines, the hardware determines which register this is. - -`FRAME_POINTER_REGNUM' - The register number of the frame pointer register, which is used - to access automatic variables in the stack frame. On some - machines, the hardware determines which register this is. On - other machines, you can choose any register you wish for this - purpose. - -`ARG_POINTER_REGNUM' - The register number of the arg pointer register, which is used to - access the function's argument list. On some machines, this is - the same as the frame pointer register. On some machines, the - hardware determines which register this is. On other machines, - you can choose any register you wish for this purpose. If this - is not the same register as the frame pointer register, then you - must mark it as a fixed register according to `FIXED_REGISTERS', - or arrange to be able to eliminate it (*note Elimination::.). - -`STATIC_CHAIN_REGNUM' -`STATIC_CHAIN_INCOMING_REGNUM' - Register numbers used for passing a function's static chain - pointer. If register windows are used, - `STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by - the called function, while `STATIC_CHAIN_REGNUM' is the register - number as seen by the calling function. If these registers are - the same, `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. - - The static chain register need not be a fixed register. - - If the static chain is passed in memory, these macros should not - be defined; instead, the next two macros should be defined. - -`STATIC_CHAIN' -`STATIC_CHAIN_INCOMING' - If the static chain is passed in memory, these macros provide rtx - giving `mem' expressions that denote where they are stored. - `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as - seen by the calling and called functions, respectively. Often - the former will be at an offset from the stack pointer and the - latter at an offset from the frame pointer. - - The variables `stack_pointer_rtx', `frame_pointer_rtx', and - `arg_pointer_rtx' will have been initialized prior to the use of - these macros and should be used to refer to those items. + LEVEL is the optimization level specified; 2 if -O2 is specified, + 1 if -O is specified, and 0 if neither is specified. - If the static chain is passed in a register, the two previous - macros should be defined instead. + *Do not examine `write_symbols' in this macro!* The debugging + options are not supposed to alter the generated code.  -File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling +File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Target Macros -Eliminating Frame Pointer and Arg Pointer ------------------------------------------ +Storage Layout +============== -`FRAME_POINTER_REQUIRED' - A C expression which is nonzero if a function must have and use a - frame pointer. This expression is evaluated in the reload pass. - If its value is nonzero the function will have a frame pointer. - - The expression can in principle examine the current function and - decide according to the facts, but on most machines the constant - 0 or the constant 1 suffices. Use 0 when the machine allows code - to be generated with no frame pointer, and doing so saves some - time or space. Use 1 when there is no possible advantage to - avoiding a frame pointer. - - In certain cases, the compiler does not know how to produce valid - code without a frame pointer. The compiler recognizes those - cases and automatically gives the function a frame pointer - regardless of what `FRAME_POINTER_REQUIRED' says. You don't need - to worry about them. - - In a function that does not require a frame pointer, the frame - pointer register can be allocated for ordinary usage, unless you - mark it as a fixed register. See `FIXED_REGISTERS' for more + Note that the definitions of the macros in this table which are +sizes or alignments measured in bits do not need to be constant. They +can be C expressions that refer to static variables, such as the +`target_flags'. *Note Run-time Target::. + +`BITS_BIG_ENDIAN' + Define this macro to be the value 1 if the most significant bit in + a byte has the lowest number; otherwise define it to be the value + zero. This means that bit-field instructions count from the most + significant bit. If the machine has no bit-field instructions, + this macro is irrelevant. + + This macro does not affect the way structure fields are packed into + bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. + +`BYTES_BIG_ENDIAN' + Define this macro to be 1 if the most significant byte in a word + has the lowest number. + +`WORDS_BIG_ENDIAN' + Define this macro to be 1 if, in a multiword object, the most + significant word has the lowest number. + +`BITS_PER_UNIT' + Number of bits in an addressable storage unit (byte); normally 8. + +`BITS_PER_WORD' + Number of bits in a word; normally 32. + +`MAX_BITS_PER_WORD' + Maximum number of bits in a word. If this is undefined, the + default is `BITS_PER_WORD'. Otherwise, it is the constant value + that is the largest value that `BITS_PER_WORD' can have at + run-time. + +`UNITS_PER_WORD' + Number of storage units in a word; normally 4. + +`POINTER_SIZE' + Width of a pointer, in bits. + +`PARM_BOUNDARY' + Normal alignment required for function parameters on the stack, in + bits. All stack parameters receive least this much alignment + regardless of data type. On most machines, this is the same as the + size of an integer. + +`STACK_BOUNDARY' + Define this macro if you wish to preserve a certain alignment for + the stack pointer. The definition is a C expression for the + desired alignment (measured in bits). + + If `PUSH_ROUNDING' is not defined, the stack will always be aligned + to the specified boundary. If `PUSH_ROUNDING' is defined and + specifies a less strict alignment than `STACK_BOUNDARY', the stack + may be momentarily unaligned while pushing arguments. + +`FUNCTION_BOUNDARY' + Alignment required for a function entry point, in bits. + +`BIGGEST_ALIGNMENT' + Biggest alignment that any data type can require on this machine, + in bits. + +`BIGGEST_FIELD_ALIGNMENT' + Biggest alignment that any structure field can require on this + machine, in bits. If defined, this overrides `BIGGEST_ALIGNMENT' + for structure fields only. + +`MAX_OFILE_ALIGNMENT' + Biggest alignment supported by the object file format of this + machine. Use this macro to limit the alignment which can be + specified using the `__attribute__ ((aligned (N)))' construct. If + not defined, the default value is `BIGGEST_ALIGNMENT'. + +`DATA_ALIGNMENT (TYPE, BASIC-ALIGN)' + If defined, a C expression to compute the alignment for a static + variable. TYPE is the data type, and BASIC-ALIGN is the alignment + that the object would ordinarily have. The value of this macro is + used instead of that alignment to align the object. + + If this macro is not defined, then BASIC-ALIGN is used. + + One use of this macro is to increase alignment of medium-size data + to make it all fit in fewer cache lines. Another is to cause + character arrays to be word-aligned so that `strcpy' calls that + copy constants to character arrays can be done inline. + +`CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)' + If defined, a C expression to compute the alignment given to a + constant that is being placed in memory. CONSTANT is the constant + and BASIC-ALIGN is the alignment that the object would ordinarily + have. The value of this macro is used instead of that alignment to + align the object. + + If this macro is not defined, then BASIC-ALIGN is used. + + The typical use of this macro is to increase alignment for string + constants to be word aligned so that `strcpy' calls that copy + constants can be done inline. + +`EMPTY_FIELD_BOUNDARY' + Alignment in bits to be given to a structure bit field that + follows an empty field such as `int : 0;'. + + Note that `PCC_BITFIELD_TYPE_MATTERS' also affects the alignment + that results from an empty field. + +`STRUCTURE_SIZE_BOUNDARY' + Number of bits which any structure or union's size must be a + multiple of. Each structure or union's size is rounded up to a + multiple of this. + + If you do not define this macro, the default is the same as + `BITS_PER_UNIT'. + +`STRICT_ALIGNMENT' + Define this macro to be the value 1 if instructions will fail to + work if given data not on the nominal alignment. If instructions + will merely go slower in that case, define this macro as 0. + +`PCC_BITFIELD_TYPE_MATTERS' + Define this if you wish to imitate the way many other C compilers + handle alignment of bitfields and the structures that contain them. + + The behavior is that the type written for a bitfield (`int', + `short', or other integer type) imposes an alignment for the + entire structure, as if the structure really did contain an + ordinary field of that type. In addition, the bitfield is placed + within the structure so that it would fit within such a field, not + crossing a boundary for it. + + Thus, on most machines, a bitfield whose type is written as `int' + would not cross a four-byte boundary, and would force four-byte + alignment for the whole structure. (The alignment used may not be + four bytes; it is controlled by the other alignment parameters.) + + If the macro is defined, its definition should be a C expression; + a nonzero value for the expression enables this behavior. + + Note that if this macro is not defined, or its value is zero, some + bitfields may cross more than one alignment boundary. The + compiler can support such references if there are `insv', `extv', + and `extzv' insns that can directly reference memory. + + The other known way of making bitfields work is to define + `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then + every structure can be accessed with fullwords. + + Unless the machine has bitfield instructions or you define + `STRUCTURE_SIZE_BOUNDARY' that way, you must define + `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. + +`BITFIELD_NBYTES_LIMITED' + Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to + aligning a bitfield within the structure. + +`ROUND_TYPE_SIZE (STRUCT, SIZE, ALIGN)' + Define this macro as an expression for the overall size of a + structure (given by STRUCT as a tree node) when the size computed + from the fields is SIZE and the alignment is ALIGN. + + The default is to round SIZE up to a multiple of ALIGN. + +`ROUND_TYPE_ALIGN (STRUCT, COMPUTED, SPECIFIED)' + Define this macro as an expression for the alignment of a structure + (given by STRUCT as a tree node) if the alignment computed in the + usual way is COMPUTED and the alignment explicitly specified was + SPECIFIED. + + The default is to use SPECIFIED if it is larger; otherwise, use + the smaller of COMPUTED and `BIGGEST_ALIGNMENT' + +`MAX_FIXED_MODE_SIZE' + An integer expression for the size in bits of the largest integer + machine mode that should actually be used. All integer machine + modes of this size or smaller can be used for structures and + unions with the appropriate sizes. If this macro is undefined, + `GET_MODE_BITSIZE (DImode)' is assumed. + +`CHECK_FLOAT_VALUE (MODE, VALUE)' + A C statement to validate the value VALUE (of type `double') for + mode MODE. This means that you check whether VALUE fits within + the possible range of values for mode MODE on this target machine. + The mode MODE is always `SFmode' or `DFmode'. + + If VALUE is not valid, you should call `error' to print an error + message and then assign some valid value to VALUE. Allowing an + invalid value to go through the compiler can produce incorrect + assembler code which may even cause Unix assemblers to crash. + + This macro need not be defined if there is no work for it to do. + +`TARGET_FLOAT_FORMAT' + A code distinguishing the floating point format of the target + machine. There are three defined values: + + `IEEE_FLOAT_FORMAT' + This code indicates IEEE floating point. It is the default; + there is no need to define this macro when the format is IEEE. + + `VAX_FLOAT_FORMAT' + This code indicates the peculiar format used on the Vax. + + `UNKNOWN_FLOAT_FORMAT' + This code indicates any other format. + + The value of this macro is compared with `HOST_FLOAT_FORMAT' + (*note Config::.) to determine whether the target machine has the + same format as the host machine. If any other formats are + actually in use on supported machines, new codes should be defined + for them. + + +File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros + +Layout of Source Language Data Types +==================================== + + These macros define the sizes and other characteristics of the +standard basic data types used in programs being compiled. Unlike the +macros in the previous section, these apply to specific features of C +and related languages, rather than to fundamental aspects of storage +layout. + +`INT_TYPE_SIZE' + A C expression for the size in bits of the type `int' on the + target machine. If you don't define this, the default is one word. + +`SHORT_TYPE_SIZE' + A C expression for the size in bits of the type `short' on the + target machine. If you don't define this, the default is half a + word. (If this would be less than one storage unit, it is rounded + up to one unit.) + +`LONG_TYPE_SIZE' + A C expression for the size in bits of the type `long' on the + target machine. If you don't define this, the default is one word. + +`LONG_LONG_TYPE_SIZE' + A C expression for the size in bits of the type `long long' on the + target machine. If you don't define this, the default is two + words. + +`CHAR_TYPE_SIZE' + A C expression for the size in bits of the type `char' on the + target machine. If you don't define this, the default is one + quarter of a word. (If this would be less than one storage unit, + it is rounded up to one unit.) + +`FLOAT_TYPE_SIZE' + A C expression for the size in bits of the type `float' on the + target machine. If you don't define this, the default is one word. + +`DOUBLE_TYPE_SIZE' + A C expression for the size in bits of the type `double' on the + target machine. If you don't define this, the default is two + words. + +`LONG_DOUBLE_TYPE_SIZE' + A C expression for the size in bits of the type `long double' on + the target machine. If you don't define this, the default is two + words. + +`DEFAULT_SIGNED_CHAR' + An expression whose value is 1 or 0, according to whether the type + `char' should be signed or unsigned by default. The user can + always override this default with the options `-fsigned-char' and + `-funsigned-char'. + +`DEFAULT_SHORT_ENUMS' + A C expression to determine whether to give an `enum' type only as + many bytes as it takes to represent the range of possible values + of that type. A nonzero value means to do that; a zero value + means all `enum' types should be allocated like `int'. + + If you don't define the macro, the default is 0. + +`SIZE_TYPE' + A C expression for a string describing the name of the data type + to use for size values. The typedef name `size_t' is defined + using the contents of the string. + + The string can contain more than one keyword. If so, separate + them with spaces, and write first any length keyword, then + `unsigned' if appropriate, and finally `int'. The string must + exactly match one of the data type names defined in the function + `init_decl_processing' in the file `c-decl.c'. You may not omit + `int' or change the order--that would cause the compiler to crash + on startup. + + If you don't define this macro, the default is `"long unsigned + int"'. + +`PTRDIFF_TYPE' + A C expression for a string describing the name of the data type + to use for the result of subtracting two pointers. The typedef + name `ptrdiff_t' is defined using the contents of the string. See + `SIZE_TYPE' above for more information. + + If you don't define this macro, the default is `"long int"'. + +`WCHAR_TYPE' + A C expression for a string describing the name of the data type + to use for wide characters. The typedef name `wchar_t' is defined + using the contents of the string. See `SIZE_TYPE' above for more information. - This macro is ignored and need not be defined if `ELIMINABLE_REGS' - is defined. + If you don't define this macro, the default is `"int"'. -`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)' - A C statement to store in the variable DEPTH-VAR the difference - between the frame pointer and the stack pointer values - immediately after the function prologue. The value would be - computed from information such as the result of `get_frame_size - ()' and the tables of registers `regs_ever_live' and - `call_used_regs'. - - If `ELIMINABLE_REGS' is defined, this macro will be not be used - and need not be defined. Otherwise, it must be defined even if - `FRAME_POINTER_REQUIRED' is defined to always be true; in that - case, you may set DEPTH-VAR to anything. - -`ELIMINABLE_REGS' - If defined, this macro specifies a table of register pairs used to - eliminate unneeded registers that point into the stack frame. If - it is not defined, the only elimination attempted by the compiler - is to replace references to the frame pointer with references to - the stack pointer. - - The definition of this macro is a list of structure - initializations, each of which specifies an original and - replacement register. - - On some machines, the position of the argument pointer is not - known until the compilation is completed. In such a case, a - separate hard register must be used for the argument pointer. - This register can be eliminated by replacing it with either the - frame pointer or the argument pointer, depending on whether or - not the frame pointer has been eliminated. - - In this case, you might specify: - #define ELIMINABLE_REGS \ - {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ - {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ - {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} - - Note that the elimination of the argument pointer with the stack - pointer is specified first since that is the preferred - elimination. - -`CAN_ELIMINATE (FROM-REG, TO-REG)' - A C expression that returns non-zero if the compiler is allowed - to try to replace register number FROM-REG with register number - TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is - defined, and will usually be the constant 1, since most of the - cases preventing register elimination are things that the - compiler already knows about. - -`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)' - This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It - specifies the initial difference between the specified pair of - registers. This macro must be defined if `ELIMINABLE_REGS' is - defined. - -`LONGJMP_RESTORE_FROM_STACK' - Define this macro if the `longjmp' function restores registers - from the stack frames, rather than from those saved specifically - by `setjmp'. Certain quantities must not be kept in registers - across a call to `setjmp' on such machines. +`WCHAR_TYPE_SIZE' + A C expression for the size in bits of the data type for wide + characters. This is used in `cpp', which cannot make use of + `WCHAR_TYPE'. + +`OBJC_INT_SELECTORS' + Define this macro if the type of Objective C selectors should be + `int'. + + If this macro is not defined, then selectors should have the type + `struct objc_selector *'. + +`OBJC_SELECTORS_WITHOUT_LABELS' + Define this macro if the compiler can group all the selectors + together into a vector and use just one label at the beginning of + the vector. Otherwise, the compiler must give each selector its + own assembler label. + + On certain machines, it is important to have a separate label for + each selector because this enables the linker to eliminate + duplicate selectors. + +`TARGET_BELL' + A C constant expression for the integer value for escape sequence + `\a'. + +`TARGET_BS' +`TARGET_TAB' +`TARGET_NEWLINE' + C constant expressions for the integer values for escape sequences + `\b', `\t' and `\n'. + +`TARGET_VT' +`TARGET_FF' +`TARGET_CR' + C constant expressions for the integer values for escape sequences + `\v', `\f' and `\r'.  -File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling +File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros -Passing Function Arguments on the Stack ---------------------------------------- +Register Usage +============== - The macros in this section control how arguments are passed on the -stack. See the following section for other macros that control -passing certain arguments in registers. - -`PROMOTE_PROTOTYPES' - Define this macro if an argument declared as `char' or `short' in - a prototype should actually be passed as an `int'. In addition - to avoiding errors in certain cases of mismatch, it also makes - for better code on certain machines. - -`PUSH_ROUNDING (NPUSHED)' - A C expression that is the number of bytes actually pushed onto - the stack when an instruction attempts to push NPUSHED bytes. - - If the target machine does not have a push instruction, do not - define this macro. That directs GNU CC to use an alternate - strategy: to allocate the entire argument block and then store - the arguments into it. - - On some machines, the definition - - #define PUSH_ROUNDING(BYTES) (BYTES) - - will suffice. But on other machines, instructions that appear to - push one byte actually push two bytes in an attempt to maintain - alignment. Then the definition should be - - #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) - -`ACCUMULATE_OUTGOING_ARGS' - If defined, the maximum amount of space required for outgoing - arguments will be computed and placed into the variable - `current_function_outgoing_args_size'. No space will be pushed - onto the stack for each call; instead, the function prologue - should increase the stack frame size by this amount. - - It is not proper to define both `PUSH_ROUNDING' and - `ACCUMULATE_OUTGOING_ARGS'. - -`REG_PARM_STACK_SPACE' - Define this macro if functions should assume that stack space has - been allocated for arguments even when their values are passed in - registers. - - The value of this macro is the size, in bytes, of the area - reserved for arguments passed in registers. - - This space can either be allocated by the caller or be a part of - the machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' - says which. - -`OUTGOING_REG_PARM_STACK_SPACE' - Define this if it is the responsibility of the caller to allocate - the area reserved for arguments passed in registers. - - If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls - whether the space for these arguments counts in the value of - `current_function_outgoing_args_size'. - -`STACK_PARMS_IN_REG_PARM_AREA' - Define this macro if `REG_PARM_STACK_SPACE' is defined but stack - parameters don't skip the area specified by - `REG_PARM_STACK_SPACE'. - - Normally, when a parameter is not passed in registers, it is - placed on the stack beyond the `REG_PARM_STACK_SPACE' area. - Defining this macro suppresses this behavior and causes the - parameter to be passed on the stack in its natural location. - -`RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)' - A C expression that should indicate the number of bytes of its own - arguments that a function pops on returning, or 0 if the function - pops no arguments and the caller must therefore pop them all - after the function returns. - - FUNTYPE is a C variable whose value is a tree node that describes - the function in question. Normally it is a node of type - `FUNCTION_TYPE' that describes the data type of the function. - From this it is possible to obtain the data types of the value and - arguments (if known). - - When a call to a library function is being considered, FUNTYPE - will contain an identifier node for the library function. Thus, - if you need to distinguish among various library functions, you - can do so by their names. Note that "library function" in this - context means a function used to perform arithmetic, whose name - is known specially in the compiler and was not mentioned in the C - code being compiled. - - STACK-SIZE is the number of bytes of arguments passed on the - stack. If a variable number of bytes is passed, it is zero, and - argument popping will always be the responsibility of the calling - function. + This section explains how to describe what registers the target +machine has, and how (in general) they can be used. - On the Vax, all functions always pop their arguments, so the - definition of this macro is STACK-SIZE. On the 68000, using the - standard calling convention, no functions pop their arguments, so - the value of the macro is always 0 in this case. But an - alternative calling convention is available in which functions - that take a fixed number of arguments pop them but other - functions (such as `printf') pop nothing (the caller pops all). - When this convention is in use, FUNTYPE is examined to determine - whether a function takes a fixed number of arguments. + 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 Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling +File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers -Passing Arguments in Registers ------------------------------- +Basic Characteristics of Registers +---------------------------------- - This section describes the macros which let you control how various -types of arguments are passed in registers or how they are arranged in -the stack. - -`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)' - A C expression that controls whether a function argument is passed - in a register, and which register. - - The arguments are CUM, which summarizes all the previous - arguments; MODE, the machine mode of the argument; TYPE, the data - type of the argument as a tree node or 0 if that is not known - (which happens for C support library functions); and NAMED, which - is 1 for an ordinary argument and 0 for nameless arguments that - correspond to `...' in the called function's prototype. - - The value of the expression should either be a `reg' RTX for the - hard register in which to pass the argument, or zero to pass the - argument on the stack. - - For machines like the Vax and 68000, where normally all arguments - are pushed, zero suffices as a definition. - - The usual way to make the ANSI library `stdarg.h' work on a - machine where some arguments are usually passed in registers, is - to cause nameless arguments to be passed on the stack instead. - This is done by making `FUNCTION_ARG' return 0 whenever NAMED is - 0. - - You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the - definition of this macro to determine if this argument is of a - type that must be passed in the stack. If `REG_PARM_STACK_SPACE' - is not defined and `FUNCTION_ARG' returns non-zero for such an - argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is - defined, the argument will be computed in the stack and then - loaded into a register. - -`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)' - Define this macro if the target machine has "register windows", so - that the register in which a function sees an arguments is not - necessarily the same as the one in which the caller passed the - argument. - - For such machines, `FUNCTION_ARG' computes the register in which - the caller passes the value, and `FUNCTION_INCOMING_ARG' should - be defined in a similar fashion to tell the function being called - where the arguments will arrive. - - If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves - both purposes. - -`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)' - A C expression for the number of words, at the beginning of an - argument, must be put in registers. The value must be zero for - arguments that are passed entirely in registers or that are - entirely pushed on the stack. - - On some machines, certain arguments must be passed partially in - registers and partially in memory. On these machines, typically - the first N words of arguments are passed in registers, and the - rest on the stack. If a multi-word argument (a `double' or a - structure) crosses that boundary, its first few words must be - passed in registers and the rest must be pushed. This macro - tells the compiler when this occurs, and how many of the words - should go in registers. - - `FUNCTION_ARG' for these arguments should return the first - register to be used by the caller for this argument; likewise - `FUNCTION_INCOMING_ARG', for the called function. - -`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)' - A C expression that indicates when an argument must be passed by - reference. If nonzero for an argument, a copy of that argument - is made in memory and a pointer to the argument is passed instead - of the argument itself. The pointer is passed in whatever way is - appropriate for passing a pointer to that type. - - On machines where `REG_PARM_STACK_SPACE' is not defined, a - suitable definition of this macro might be - #define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \ - MUST_PASS_IN_STACK (MODE, TYPE) - -`CUMULATIVE_ARGS' - A C type for declaring a variable that is used as the first - argument of `FUNCTION_ARG' and other related values. For some - target machines, the type `int' suffices and can hold the number - of bytes of argument so far. - - There is no need to record in `CUMULATIVE_ARGS' anything about the - arguments that have been passed on the stack. The compiler has - other variables to keep track of that. For target machines on - which all arguments are passed on the stack, there is no need to - store anything in `CUMULATIVE_ARGS'; however, the data structure - must exist and should not be empty, so use `int'. - -`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)' - A C statement (sans semicolon) for initializing the variable CUM - for the state at the beginning of the argument list. The - variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the - tree node for the data type of the function which will receive - the args, or 0 if the args are to a compiler support library - function. +`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'. + + +File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers + +Order of Allocation of Registers +-------------------------------- + +`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 allocatable 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 order of registers 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. - When processing a call to a compiler support library function, - LIBNAME identifies which one. It is a `symbol_ref' rtx which - contains the name of the function, as a string. LIBNAME is 0 when - an ordinary C function call is being processed. Thus, each time - this macro is called, either LIBNAME or FNTYPE is nonzero, but - never both of them at once. - -`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)' - Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of - finding the arguments for the function being compiled. If this - macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. - - The argument LIBNAME exists for symmetry with - `INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always - 0, since library routines with special calling conventions are - never compiled with GNU CC. - -`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)' - A C statement (sans semicolon) to update the summarizer variable - CUM to advance past an argument in the argument list. The values - MODE, TYPE and NAMED describe that argument. Once this is done, - the variable CUM is suitable for analyzing the *following* - argument with `FUNCTION_ARG', etc. - - This macro need not do anything if the argument in question was - passed on the stack. The compiler knows how to track the amount - of stack space used for arguments without any special help. - -`FUNCTION_ARG_PADDING (MODE, TYPE)' - If defined, a C expression which determines whether, and in which - direction, to pad out an argument with extra space. The value - should be of type `enum direction': either `upward' to pad above - the argument, `downward' to pad below, or `none' to inhibit - padding. - - This macro does not control the *amount* of padding; that is - always just enough to reach the next multiple of - `FUNCTION_ARG_BOUNDARY'. - - This macro has a default definition which is right for most - systems. For little-endian machines, the default is to pad - upward. For big-endian machines, the default is to pad downward - for an argument of constant size shorter than an `int', and - upward otherwise. - -`FUNCTION_ARG_BOUNDARY (MODE, TYPE)' - If defined, a C expression that gives the alignment boundary, in - bits, of an argument with the specified mode and type. If it is - not defined, `PARM_BOUNDARY' is used for all arguments. - -`FUNCTION_ARG_REGNO_P (REGNO)' - A C expression that is nonzero if REGNO is the number of a hard - register in which function arguments are sometimes passed. This - does *not* include implicit arguments such as the static chain and - the structure-value address. On many machines, no registers can - be used for this purpose since all function arguments are pushed - on the stack. + On most machines, it is not necessary to define this macro.  -File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling +File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers -How Scalar Function Values Are Returned ---------------------------------------- +How Values Fit in Registers +--------------------------- - This section discusses the macros that control returning scalars as -values--values that can 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 + + 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. + + 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. + + The minimum requirement for a mode to be OK in a register is that + the `movMODE' 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 `SImode' 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. + + On some machines, such as the Sparc and the Mips, we get better + code by defining `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 + `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 it is desirable to choose + register allocation so as to avoid move instructions between a + value of mode MODE1 and a value of mode MODE2. + + If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, + MODE2)' are ever different for any R, then `MODES_TIEABLE_P (MODE1, + MODE2)' must be zero. -`TRADITIONAL_RETURN_FLOAT' - Define this macro if `-traditional' should not cause functions - declared to return `float' to convert the value to `double'. - -`FUNCTION_VALUE (VALTYPE, FUNC)' - A C expression to create an RTX representing the place where a - function returns a value of data type VALTYPE. VALTYPE is a tree - node representing a data type. Write `TYPE_MODE (VALTYPE)' to - get the machine mode used to represent that type. On many - machines, only the mode is relevant. (Actually, on most - machines, scalar values are returned in the same place regardless - of mode). - - If the precise function being called is known, FUNC is a tree - node (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. - This makes it possible to use a different value-returning - convention for specific functions when all their calls are known. - - `FUNCTION_VALUE' is not used for return vales with aggregate data - types, because these are returned in another way. See - `STRUCT_VALUE_REGNUM' and related macros, below. - -`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' - Define this macro if the target machine has "register windows" so - that the register in which a function returns its value is not - the same as the one in which the caller sees the value. - - For such machines, `FUNCTION_VALUE' computes the register in - which the caller will see the value, and - `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion - to tell the function where to put the value. - - If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' - serves both purposes. - - `FUNCTION_OUTGOING_VALUE' is not used for return vales with - aggregate data types, because these are returned in another way. - See `STRUCT_VALUE_REGNUM' and related macros, below. - -`LIBCALL_VALUE (MODE)' - A C expression to create an RTX representing the place where a - library function returns a value of mode MODE. If the precise - function being called is known, FUNC is a tree node - (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. - This makes it possible to use a different value-returning - convention for specific functions when all their calls are known. - - Note that "library function" in this context means a compiler - support routine, used to perform arithmetic, whose name is known - specially by the compiler and was not mentioned in the C code - being compiled. - - The definition of `LIBRARY_VALUE' need not be concerned aggregate - data types, because none of the library functions returns such - types. - -`FUNCTION_VALUE_REGNO_P (REGNO)' - A C expression that is nonzero if REGNO is the number of a hard - register in which the values of called function may come back. - - A register whose use for returning values is limited to serving - as the second of a pair (for a value of type `double', say) need - not be recognized by this macro. So for most machines, this - definition suffices: - - #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) - - If the machine has register windows, so that the caller and the - called function use different registers for the return value, - this macro should recognize only the caller's register numbers. + +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 make 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. + +`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. + + Normally, it is necessary for `FUNCTION_PROLOGUE' and +`FUNCTION_EPILOGUE' to 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: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling +File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers -How Large Values Are Returned ------------------------------ +Registers That Form a Stack +--------------------------- - When a function value's mode is `BLKmode' (and in some other -cases), the value is not returned according to `FUNCTION_VALUE' (*note -Scalar Return::.). Instead, the caller passes the address of a block -of memory in which the value should be stored. This address is called -the "structure value address". - - This section describes how to control returning structure values in -memory. - -`RETURN_IN_MEMORY (TYPE)' - A C expression which can inhibit the returning of certain function - values in registers, based on the type of value. A nonzero value - says to return the function value in memory, just as large - structures are always returned. Here TYPE will be a C expression - of type `tree', representing the data type of the value. - - Note that values of mode `BLKmode' are returned in memory - regardless of this macro. Also, the option `-fpcc-struct-return' - takes effect regardless of this macro. On most systems, it is - possible to leave the macro undefined; this causes a default - definition to be used, whose value is the constant 0. - -`STRUCT_VALUE_REGNUM' - If the structure value address is passed in a register, then - `STRUCT_VALUE_REGNUM' should be the number of that register. - -`STRUCT_VALUE' - If the structure value address is not passed in a register, define - `STRUCT_VALUE' as an expression returning an RTX for the place - where the address is passed. If it returns 0, the address is - passed as an "invisible" first argument. - -`STRUCT_VALUE_INCOMING_REGNUM' - On some architectures the place where the structure value address - is found by the called function is not the same place that the - caller put it. This can be due to register windows, or it could - be because the function prologue moves it to a different place. - - If the incoming location of the structure value address is in a - register, define this macro as the register number. - -`STRUCT_VALUE_INCOMING' - If the incoming location is not a register, define - `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the - called function should find the value. If it should find the - value on the stack, define this to create a `mem' which refers to - the frame pointer. A definition of 0 means that the address is - passed as an "invisible" first argument. - -`PCC_STATIC_STRUCT_RETURN' - Define this macro if the usual system convention on the target - machine for returning structures and unions is for the called - function to return the address of a static variable containing - the value. GNU CC does not normally use this convention, even if - it is the usual one, but does use it if `-fpcc-struct-value' is - specified. + 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. - Do not define this if the usual system convention is for the - caller to pass an address to the subroutine. +`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: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling +File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers -Caller-Saves Register Allocation --------------------------------- +Obsolete Macros for Controlling Register Usage +---------------------------------------------- - If you enable it, GNU CC can save registers around function calls. -This makes it possible to use call-clobbered registers to hold -variables that must live across calls. - -`DEFAULT_CALLER_SAVES' - Define this macro if function calls on the target machine do not - preserve any registers; in other words, if `CALL_USED_REGISTERS' - has 1 for all registers. This macro enables `-fcaller-saves' by - default. Eventually that option will be enabled by default on - all machines and both the option and this macro will be - eliminated. - -`CALLER_SAVE_PROFITABLE (REFS, CALLS)' - A C expression to determine whether it is worthwhile to consider - placing a pseudo-register in a call-clobbered hard register and - saving and restoring it around each function call. The - expression should be 1 when this is worth doing, and 0 otherwise. + 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 + accurate `REG_DEAD' notes are needed for hard register number 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 you don't define this macro, a default is used which is good - on most machines: `4 * CALLS < REFS'. + If this macro is not defined, it means that no death notes need to + be preserved. This is the usual situation.  \ No newline at end of file