| @c Copyright (C) 1988,89,92,93,94,96,1997 Free Software Foundation, Inc. |
| @c This is part of the GCC manual. |
| @c For copying conditions, see the file gcc.texi. |
| |
| @node Target Macros |
| @chapter Target Description Macros |
| @cindex machine description macros |
| @cindex target description macros |
| @cindex macros, target description |
| @cindex @file{tm.h} macros |
| |
| In addition to the file @file{@var{machine}.md}, a machine description |
| includes a C header file conventionally given the name |
| @file{@var{machine}.h}. This header file defines numerous macros |
| that convey the information about the target machine that does not fit |
| into the scheme of the @file{.md} file. The file @file{tm.h} should be |
| a link to @file{@var{machine}.h}. The header file @file{config.h} |
| includes @file{tm.h} and most compiler source files include |
| @file{config.h}. |
| |
| @menu |
| * Driver:: Controlling how the driver runs the compilation passes. |
| * Run-time Target:: Defining @samp{-m} options like @samp{-m68000} and @samp{-m68020}. |
| * Storage Layout:: Defining sizes and alignments of data. |
| * Type Layout:: Defining sizes and properties of basic user data types. |
| * Registers:: Naming and describing the hardware registers. |
| * Register Classes:: Defining the classes of hardware registers. |
| * Stack and Calling:: Defining which way the stack grows and by how much. |
| * Varargs:: Defining the varargs macros. |
| * Trampolines:: Code set up at run time to enter a nested function. |
| * Library Calls:: Controlling how library routines are implicitly called. |
| * Addressing Modes:: Defining addressing modes valid for memory operands. |
| * Condition Code:: Defining how insns update the condition code. |
| * Costs:: Defining relative costs of different operations. |
| * Sections:: Dividing storage into text, data, and other sections. |
| * PIC:: Macros for position independent code. |
| * Assembler Format:: Defining how to write insns and pseudo-ops to output. |
| * Debugging Info:: Defining the format of debugging output. |
| * Cross-compilation:: Handling floating point for cross-compilers. |
| * Misc:: Everything else. |
| @end menu |
| |
| @node Driver |
| @section Controlling the Compilation Driver, @file{gcc} |
| @cindex driver |
| @cindex controlling the compilation driver |
| |
| @c prevent bad page break with this line |
| You can control the compilation driver. |
| |
| @table @code |
| @findex SWITCH_TAKES_ARG |
| @item SWITCH_TAKES_ARG (@var{char}) |
| A C expression which determines whether the option @samp{-@var{char}} |
| takes arguments. The value should be the number of arguments that |
| option takes--zero, for many options. |
| |
| By default, this macro is defined as |
| @code{DEFAULT_SWITCH_TAKES_ARG}, which handles the standard options |
| properly. You need not define @code{SWITCH_TAKES_ARG} unless you |
| wish to add additional options which take arguments. Any redefinition |
| should call @code{DEFAULT_SWITCH_TAKES_ARG} and then check for |
| additional options. |
| |
| @findex WORD_SWITCH_TAKES_ARG |
| @item WORD_SWITCH_TAKES_ARG (@var{name}) |
| A C expression which determines whether the option @samp{-@var{name}} |
| takes arguments. The value should be the number of arguments that |
| option takes--zero, for many options. This macro rather than |
| @code{SWITCH_TAKES_ARG} is used for multi-character option names. |
| |
| By default, this macro is defined as |
| @code{DEFAULT_WORD_SWITCH_TAKES_ARG}, which handles the standard options |
| properly. You need not define @code{WORD_SWITCH_TAKES_ARG} unless you |
| wish to add additional options which take arguments. Any redefinition |
| should call @code{DEFAULT_WORD_SWITCH_TAKES_ARG} and then check for |
| additional options. |
| |
| @findex SWITCHES_NEED_SPACES |
| @item SWITCHES_NEED_SPACES |
| A string-valued C expression which enumerates the options for which |
| the linker needs a space between the option and its argument. |
| |
| If this macro is not defined, the default value is @code{""}. |
| |
| @findex CPP_SPEC |
| @item 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. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @findex NO_BUILTIN_SIZE_TYPE |
| @item NO_BUILTIN_SIZE_TYPE |
| If this macro is defined, the preprocessor will not define the builtin macro |
| @code{__SIZE_TYPE__}. The macro @code{__SIZE_TYPE__} must then be defined |
| by @code{CPP_SPEC} instead. |
| |
| This should be defined if @code{SIZE_TYPE} depends on target dependent flags |
| which are not accessible to the preprocessor. Otherwise, it should not |
| be defined. |
| |
| @findex NO_BUILTIN_PTRDIFF_TYPE |
| @item NO_BUILTIN_PTRDIFF_TYPE |
| If this macro is defined, the preprocessor will not define the builtin macro |
| @code{__PTRDIFF_TYPE__}. The macro @code{__PTRDIFF_TYPE__} must then be |
| defined by @code{CPP_SPEC} instead. |
| |
| This should be defined if @code{PTRDIFF_TYPE} depends on target dependent flags |
| which are not accessible to the preprocessor. Otherwise, it should not |
| be defined. |
| |
| @findex SIGNED_CHAR_SPEC |
| @item 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 |
| @samp{-D__CHAR_UNSIGNED__} to CPP if @code{char} will be treated as |
| @code{unsigned char} by @code{cc1}. |
| |
| Do not define this macro unless you need to override the default |
| definition. |
| |
| @findex CC1_SPEC |
| @item CC1_SPEC |
| A C string constant that tells the GNU CC driver program options to |
| pass to @code{cc1}. It can also specify how to translate options you |
| give to GNU CC into options for GNU CC to pass to the @code{cc1}. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @findex CC1PLUS_SPEC |
| @item CC1PLUS_SPEC |
| A C string constant that tells the GNU CC driver program options to |
| pass to @code{cc1plus}. It can also specify how to translate options you |
| give to GNU CC into options for GNU CC to pass to the @code{cc1plus}. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @findex ASM_SPEC |
| @item 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 @file{sun3.h} for an example of this. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @findex ASM_FINAL_SPEC |
| @item 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 @file{mips.h} for |
| an example of this. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @findex LINK_SPEC |
| @item 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. |
| |
| @findex LIB_SPEC |
| @item LIB_SPEC |
| Another C string constant used much like @code{LINK_SPEC}. The difference |
| between the two is that @code{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 @file{gcc.c}. |
| |
| @findex LIBGCC_SPEC |
| @item LIBGCC_SPEC |
| Another C string constant that tells the GNU CC driver program |
| how and when to place a reference to @file{libgcc.a} into the |
| linker command line. This constant is placed both before and after |
| the value of @code{LIB_SPEC}. |
| |
| If this macro is not defined, the GNU CC driver provides a default that |
| passes the string @samp{-lgcc} to the linker unless the @samp{-shared} |
| option is specified. |
| |
| @findex STARTFILE_SPEC |
| @item STARTFILE_SPEC |
| Another C string constant used much like @code{LINK_SPEC}. The |
| difference between the two is that @code{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 @file{gcc.c}. |
| |
| @findex ENDFILE_SPEC |
| @item ENDFILE_SPEC |
| Another C string constant used much like @code{LINK_SPEC}. The |
| difference between the two is that @code{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. |
| |
| @findex EXTRA_SPECS |
| @item EXTRA_SPECS |
| Define this macro to provide additional specifications to put in the |
| @file{specs} file that can be used in various specifications like |
| @code{CC1_SPEC}. |
| |
| The definition should be an initializer for an array of structures, |
| containing a string constant, that defines the specification name, and a |
| string constant that provides the specification. |
| |
| Do not define this macro if it does not need to do anything. |
| |
| @code{EXTRA_SPECS} is useful when an architecture contains several |
| related targets, which have various @code{..._SPECS} which are similar |
| to each other, and the maintainer would like one central place to keep |
| these definitions. |
| |
| For example, the PowerPC System V.4 targets use @code{EXTRA_SPECS} to |
| define either @code{_CALL_SYSV} when the System V calling sequence is |
| used or @code{_CALL_AIX} when the older AIX-based calling sequence is |
| used. |
| |
| The @file{config/rs6000/rs6000.h} target file defines: |
| |
| @example |
| #define EXTRA_SPECS \ |
| @{ "cpp_sysv_default", CPP_SYSV_DEFAULT @}, |
| |
| #define CPP_SYS_DEFAULT "" |
| @end example |
| |
| The @file{config/rs6000/sysv.h} target file defines: |
| @smallexample |
| #undef CPP_SPEC |
| #define CPP_SPEC \ |
| "%@{posix: -D_POSIX_SOURCE @} \ |
| %@{mcall-sysv: -D_CALL_SYSV @} %@{mcall-aix: -D_CALL_AIX @} \ |
| %@{!mcall-sysv: %@{!mcall-aix: %(cpp_sysv_default) @}@} \ |
| %@{msoft-float: -D_SOFT_FLOAT@} %@{mcpu=403: -D_SOFT_FLOAT@}" |
| |
| #undef CPP_SYSV_DEFAULT |
| #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" |
| @end smallexample |
| |
| while the @file{config/rs6000/eabiaix.h} target file defines |
| @code{CPP_SYSV_DEFAULT} as: |
| |
| @smallexample |
| #undef CPP_SYSV_DEFAULT |
| #define CPP_SYSV_DEFAULT "-D_CALL_AIX" |
| @end smallexample |
| |
| @findex LINK_LIBGCC_SPECIAL |
| @item LINK_LIBGCC_SPECIAL |
| Define this macro if the driver program should find the library |
| @file{libgcc.a} itself and should not pass @samp{-L} options to the |
| linker. If you do not define this macro, the driver program will pass |
| the argument @samp{-lgcc} to tell the linker to do the search and will |
| pass @samp{-L} options to it. |
| |
| @findex LINK_LIBGCC_SPECIAL_1 |
| @item LINK_LIBGCC_SPECIAL_1 |
| Define this macro if the driver program should find the library |
| @file{libgcc.a}. If you do not define this macro, the driver program will pass |
| the argument @samp{-lgcc} to tell the linker to do the search. |
| This macro is similar to @code{LINK_LIBGCC_SPECIAL}, except that it does |
| not affect @samp{-L} options. |
| |
| @findex MULTILIB_DEFAULTS |
| @item MULTILIB_DEFAULTS |
| Define this macro as a C expression for the initializer of an array of |
| string to tell the driver program which options are defaults for this |
| target and thus do not need to be handled specially when using |
| @code{MULTILIB_OPTIONS}. |
| |
| Do not define this macro if @code{MULTILIB_OPTIONS} is not defined in |
| the target makefile fragment or if none of the options listed in |
| @code{MULTILIB_OPTIONS} are set by default. |
| @xref{Target Fragment}. |
| |
| @findex RELATIVE_PREFIX_NOT_LINKDIR |
| @item RELATIVE_PREFIX_NOT_LINKDIR |
| Define this macro to tell @code{gcc} that it should only translate |
| a @samp{-B} prefix into a @samp{-L} linker option if the prefix |
| indicates an absolute file name. |
| |
| @findex STANDARD_EXEC_PREFIX |
| @item STANDARD_EXEC_PREFIX |
| Define this macro as a C string constant if you wish to override the |
| standard choice of @file{/usr/local/lib/gcc-lib/} as the default prefix to |
| try when searching for the executable files of the compiler. |
| |
| @findex MD_EXEC_PREFIX |
| @item MD_EXEC_PREFIX |
| If defined, this macro is an additional prefix to try after |
| @code{STANDARD_EXEC_PREFIX}. @code{MD_EXEC_PREFIX} is not searched |
| when the @samp{-b} option is used, or the compiler is built as a cross |
| compiler. |
| |
| @findex STANDARD_STARTFILE_PREFIX |
| @item STANDARD_STARTFILE_PREFIX |
| Define this macro as a C string constant if you wish to override the |
| standard choice of @file{/usr/local/lib/} as the default prefix to |
| try when searching for startup files such as @file{crt0.o}. |
| |
| @findex MD_STARTFILE_PREFIX |
| @item MD_STARTFILE_PREFIX |
| If defined, this macro supplies an additional prefix to try after the |
| standard prefixes. @code{MD_EXEC_PREFIX} is not searched when the |
| @samp{-b} option is used, or when the compiler is built as a cross |
| compiler. |
| |
| @findex MD_STARTFILE_PREFIX_1 |
| @item MD_STARTFILE_PREFIX_1 |
| If defined, this macro supplies yet another prefix to try after the |
| standard prefixes. It is not searched when the @samp{-b} option is |
| used, or when the compiler is built as a cross compiler. |
| |
| @findex INIT_ENVIRONMENT |
| @item INIT_ENVIRONMENT |
| Define this macro as a C string constant if you wish to set environment |
| variables for programs called by the driver, such as the assembler and |
| loader. The driver passes the value of this macro to @code{putenv} to |
| initialize the necessary environment variables. |
| |
| @findex LOCAL_INCLUDE_DIR |
| @item LOCAL_INCLUDE_DIR |
| Define this macro as a C string constant if you wish to override the |
| standard choice of @file{/usr/local/include} as the default prefix to |
| try when searching for local header files. @code{LOCAL_INCLUDE_DIR} |
| comes before @code{SYSTEM_INCLUDE_DIR} in the search order. |
| |
| Cross compilers do not use this macro and do not search either |
| @file{/usr/local/include} or its replacement. |
| |
| @findex SYSTEM_INCLUDE_DIR |
| @item 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. @code{SYSTEM_INCLUDE_DIR} comes before |
| @code{STANDARD_INCLUDE_DIR} in the search order. |
| |
| Cross compilers do not use this macro and do not search the directory |
| specified. |
| |
| @findex STANDARD_INCLUDE_DIR |
| @item STANDARD_INCLUDE_DIR |
| Define this macro as a C string constant if you wish to override the |
| standard choice of @file{/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 |
| @file{/usr/include} or its replacement. |
| |
| @findex STANDARD_INCLUDE_COMPONENT |
| @item STANDARD_INCLUDE_COMPONENT |
| The ``component'' corresponding to @code{STANDARD_INCLUDE_DIR}. |
| See @code{INCLUDE_DEFAULTS}, below, for the description of components. |
| If you do not define this macro, no component is used. |
| |
| @findex INCLUDE_DEFAULTS |
| @item INCLUDE_DEFAULTS |
| Define this macro if you wish to override the entire default search path |
| for include files. For a native compiler, the default search path |
| usually consists of @code{GCC_INCLUDE_DIR}, @code{LOCAL_INCLUDE_DIR}, |
| @code{SYSTEM_INCLUDE_DIR}, @code{GPLUSPLUS_INCLUDE_DIR}, and |
| @code{STANDARD_INCLUDE_DIR}. In addition, @code{GPLUSPLUS_INCLUDE_DIR} |
| and @code{GCC_INCLUDE_DIR} are defined automatically by @file{Makefile}, |
| and specify private search areas for GCC. The directory |
| @code{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 four elements: the directory name (a |
| string constant), the component name, and flag for C++-only directories, |
| and a flag showing that the includes in the directory don't need to be |
| wrapped in @code{extern @samp{C}} when compiling C++. Mark the end of |
| the array with a null element. |
| |
| The component name denotes what GNU package the include file is part of, |
| if any, in all upper-case letters. For example, it might be @samp{GCC} |
| or @samp{BINUTILS}. If the package is part of the a vendor-supplied |
| operating system, code the component name as @samp{0}. |
| |
| |
| For example, here is the definition used for VAX/VMS: |
| |
| @example |
| #define INCLUDE_DEFAULTS \ |
| @{ \ |
| @{ "GNU_GXX_INCLUDE:", "G++", 1, 1@}, \ |
| @{ "GNU_CC_INCLUDE:", "GCC", 0, 0@}, \ |
| @{ "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0@}, \ |
| @{ ".", 0, 0, 0@}, \ |
| @{ 0, 0, 0, 0@} \ |
| @} |
| @end example |
| @end table |
| |
| Here is the order of prefixes tried for exec files: |
| |
| @enumerate |
| @item |
| Any prefixes specified by the user with @samp{-B}. |
| |
| @item |
| The environment variable @code{GCC_EXEC_PREFIX}, if any. |
| |
| @item |
| The directories specified by the environment variable @code{COMPILER_PATH}. |
| |
| @item |
| The macro @code{STANDARD_EXEC_PREFIX}. |
| |
| @item |
| @file{/usr/lib/gcc/}. |
| |
| @item |
| The macro @code{MD_EXEC_PREFIX}, if any. |
| @end enumerate |
| |
| Here is the order of prefixes tried for startfiles: |
| |
| @enumerate |
| @item |
| Any prefixes specified by the user with @samp{-B}. |
| |
| @item |
| The environment variable @code{GCC_EXEC_PREFIX}, if any. |
| |
| @item |
| The directories specified by the environment variable @code{LIBRARY_PATH} |
| (native only, cross compilers do not use this). |
| |
| @item |
| The macro @code{STANDARD_EXEC_PREFIX}. |
| |
| @item |
| @file{/usr/lib/gcc/}. |
| |
| @item |
| The macro @code{MD_EXEC_PREFIX}, if any. |
| |
| @item |
| The macro @code{MD_STARTFILE_PREFIX}, if any. |
| |
| @item |
| The macro @code{STANDARD_STARTFILE_PREFIX}. |
| |
| @item |
| @file{/lib/}. |
| |
| @item |
| @file{/usr/lib/}. |
| @end enumerate |
| |
| @node Run-time Target |
| @section Run-time Target Specification |
| @cindex run-time target specification |
| @cindex predefined macros |
| @cindex target specifications |
| |
| @c prevent bad page break with this line |
| Here are run-time target specifications. |
| |
| @table @code |
| @findex CPP_PREDEFINES |
| @item CPP_PREDEFINES |
| Define this to be a string constant containing @samp{-D} options to |
| define the predefined macros that identify this machine and system. |
| These macros will be predefined unless the @samp{-ansi} option is |
| specified. |
| |
| In addition, a parallel set of macros are predefined, whose names are |
| made by appending @samp{__} at the beginning and at the end. These |
| @samp{__} macros are permitted by the ANSI standard, so they are |
| predefined regardless of whether @samp{-ansi} is specified. |
| |
| For example, on the Sun, one can use the following value: |
| |
| @smallexample |
| "-Dmc68000 -Dsun -Dunix" |
| @end smallexample |
| |
| The result is to define the macros @code{__mc68000__}, @code{__sun__} |
| and @code{__unix__} unconditionally, and the macros @code{mc68000}, |
| @code{sun} and @code{unix} provided @samp{-ansi} is not specified. |
| |
| @findex extern int target_flags |
| @item extern int target_flags; |
| This declaration should be present. |
| |
| @cindex optional hardware or system features |
| @cindex features, optional, in system conventions |
| @item TARGET_@dots{} |
| 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 @code{TARGET_68020} that tests a bit in |
| @code{target_flags}. |
| |
| Define a macro @code{TARGET_@var{featurename}} for each such option. |
| Its definition should test a bit in @code{target_flags}; for example: |
| |
| @smallexample |
| #define TARGET_68020 (target_flags & 1) |
| @end smallexample |
| |
| One place where these macros are used is in the condition-expressions |
| of instruction patterns. Note how @code{TARGET_68020} appears |
| frequently in the 68000 machine description file, @file{m68k.md}. |
| Another place they are used is in the definitions of the other |
| macros in the @file{@var{machine}.h} file. |
| |
| @findex TARGET_SWITCHES |
| @item TARGET_SWITCHES |
| This macro defines names of command options to set and clear |
| bits in @code{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 |
| @code{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 @samp{-m} to the specified name. |
| |
| One of the subgroupings should have a null string. The number in |
| this grouping is the default value for @code{target_flags}. Any |
| target options act starting with that value. |
| |
| Here is an example which defines @samp{-m68000} and @samp{-m68020} |
| with opposite meanings, and picks the latter as the default: |
| |
| @smallexample |
| #define TARGET_SWITCHES \ |
| @{ @{ "68020", 1@}, \ |
| @{ "68000", -1@}, \ |
| @{ "", 1@}@} |
| @end smallexample |
| |
| @findex TARGET_OPTIONS |
| @item TARGET_OPTIONS |
| This macro is similar to @code{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 |
| @code{char *}, is set to the variable part of the given option if the fixed |
| part matches. The actual option name is made by appending @samp{-m} to the |
| specified name. |
| |
| Here is an example which defines @samp{-mshort-data-@var{number}}. If the |
| given option is @samp{-mshort-data-512}, the variable @code{m88k_short_data} |
| will be set to the string @code{"512"}. |
| |
| @smallexample |
| extern char *m88k_short_data; |
| #define TARGET_OPTIONS \ |
| @{ @{ "short-data-", &m88k_short_data @} @} |
| @end smallexample |
| |
| @findex TARGET_VERSION |
| @item TARGET_VERSION |
| This macro is a C statement to print on @code{stderr} a string |
| describing the particular machine description choice. Every machine |
| description should define @code{TARGET_VERSION}. For example: |
| |
| @smallexample |
| #ifdef MOTOROLA |
| #define TARGET_VERSION \ |
| fprintf (stderr, " (68k, Motorola syntax)"); |
| #else |
| #define TARGET_VERSION \ |
| fprintf (stderr, " (68k, MIT syntax)"); |
| #endif |
| @end smallexample |
| |
| @findex OVERRIDE_OPTIONS |
| @item OVERRIDE_OPTIONS |
| Sometimes certain combinations of command options do not make sense on |
| a particular target machine. You can define a macro |
| @code{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 |
| @samp{-O}. That is what @code{OPTIMIZATION_OPTIONS} is for. |
| |
| @findex OPTIMIZATION_OPTIONS |
| @item OPTIMIZATION_OPTIONS (@var{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. |
| |
| @var{level} is the optimization level specified; 2 if @samp{-O2} is |
| specified, 1 if @samp{-O} is specified, and 0 if neither is specified. |
| |
| You should not use this macro to change options that are not |
| machine-specific. These should uniformly selected by the same |
| optimization level on all supported machines. Use this macro to enable |
| machine-specific optimizations. |
| |
| @strong{Do not examine @code{write_symbols} in |
| this macro!} The debugging options are not supposed to alter the |
| generated code. |
| |
| @findex CAN_DEBUG_WITHOUT_FP |
| @item CAN_DEBUG_WITHOUT_FP |
| Define this macro if debugging can be performed even without a frame |
| pointer. If this macro is defined, GNU CC will turn on the |
| @samp{-fomit-frame-pointer} option whenever @samp{-O} is specified. |
| @end table |
| |
| @node Storage Layout |
| @section Storage Layout |
| @cindex storage layout |
| |
| 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 @code{target_flags}. |
| @xref{Run-time Target}. |
| |
| @table @code |
| @findex BITS_BIG_ENDIAN |
| @item BITS_BIG_ENDIAN |
| Define this macro to have the value 1 if the most significant bit in a |
| byte has the lowest number; otherwise define it to have the value zero. |
| This means that bit-field instructions count from the most significant |
| bit. If the machine has no bit-field instructions, then this must still |
| be defined, but it doesn't matter which value it is defined to. This |
| macro need not be a constant. |
| |
| This macro does not affect the way structure fields are packed into |
| bytes or words; that is controlled by @code{BYTES_BIG_ENDIAN}. |
| |
| @findex BYTES_BIG_ENDIAN |
| @item BYTES_BIG_ENDIAN |
| Define this macro to have the value 1 if the most significant byte in a |
| word has the lowest number. This macro need not be a constant. |
| |
| @findex WORDS_BIG_ENDIAN |
| @item WORDS_BIG_ENDIAN |
| Define this macro to have the value 1 if, in a multiword object, the |
| most significant word has the lowest number. This applies to both |
| memory locations and registers; GNU CC fundamentally assumes that the |
| order of words in memory is the same as the order in registers. This |
| macro need not be a constant. |
| |
| @findex LIBGCC2_WORDS_BIG_ENDIAN |
| @item LIBGCC2_WORDS_BIG_ENDIAN |
| Define this macro if WORDS_BIG_ENDIAN is not constant. This must be a |
| constant value with the same meaning as WORDS_BIG_ENDIAN, which will be |
| used only when compiling libgcc2.c. Typically the value will be set |
| based on preprocessor defines. |
| |
| @findex FLOAT_WORDS_BIG_ENDIAN |
| @item FLOAT_WORDS_BIG_ENDIAN |
| Define this macro to have the value 1 if @code{DFmode}, @code{XFmode} or |
| @code{TFmode} floating point numbers are stored in memory with the word |
| containing the sign bit at the lowest address; otherwise define it to |
| have the value 0. This macro need not be a constant. |
| |
| You need not define this macro if the ordering is the same as for |
| multi-word integers. |
| |
| @findex BITS_PER_UNIT |
| @item BITS_PER_UNIT |
| Define this macro to be the number of bits in an addressable storage |
| unit (byte); normally 8. |
| |
| @findex BITS_PER_WORD |
| @item BITS_PER_WORD |
| Number of bits in a word; normally 32. |
| |
| @findex MAX_BITS_PER_WORD |
| @item MAX_BITS_PER_WORD |
| Maximum number of bits in a word. If this is undefined, the default is |
| @code{BITS_PER_WORD}. Otherwise, it is the constant value that is the |
| largest value that @code{BITS_PER_WORD} can have at run-time. |
| |
| @findex UNITS_PER_WORD |
| @item UNITS_PER_WORD |
| Number of storage units in a word; normally 4. |
| |
| @findex MIN_UNITS_PER_WORD |
| @item MIN_UNITS_PER_WORD |
| Minimum number of units in a word. If this is undefined, the default is |
| @code{UNITS_PER_WORD}. Otherwise, it is the constant value that is the |
| smallest value that @code{UNITS_PER_WORD} can have at run-time. |
| |
| @findex POINTER_SIZE |
| @item POINTER_SIZE |
| Width of a pointer, in bits. You must specify a value no wider than the |
| width of @code{Pmode}. If it is not equal to the width of @code{Pmode}, |
| you must define @code{POINTERS_EXTEND_UNSIGNED}. |
| |
| @findex POINTERS_EXTEND_UNSIGNED |
| @item POINTERS_EXTEND_UNSIGNED |
| A C expression whose value is nonzero if pointers that need to be |
| extended from being @code{POINTER_SIZE} bits wide to @code{Pmode} |
| are sign-extended and zero if they are zero-extended. |
| |
| You need not define this macro if the @code{POINTER_SIZE} is equal |
| to the width of @code{Pmode}. |
| |
| @findex PROMOTE_MODE |
| @item PROMOTE_MODE (@var{m}, @var{unsignedp}, @var{type}) |
| A macro to update @var{m} and @var{unsignedp} when an object whose type |
| is @var{type} and which has the specified mode and signedness is to be |
| stored in a register. This macro is only called when @var{type} is a |
| scalar type. |
| |
| On most RISC machines, which only have operations that operate on a full |
| register, define this macro to set @var{m} to @code{word_mode} if |
| @var{m} is an integer mode narrower than @code{BITS_PER_WORD}. In most |
| cases, only integer modes should be widened because wider-precision |
| floating-point operations are usually more expensive than their narrower |
| counterparts. |
| |
| For most machines, the macro definition does not change @var{unsignedp}. |
| However, some machines, have instructions that preferentially handle |
| either signed or unsigned quantities of certain modes. For example, on |
| the DEC Alpha, 32-bit loads from memory and 32-bit add instructions |
| sign-extend the result to 64 bits. On such machines, set |
| @var{unsignedp} according to which kind of extension is more efficient. |
| |
| Do not define this macro if it would never modify @var{m}. |
| |
| @findex PROMOTE_FUNCTION_ARGS |
| @item PROMOTE_FUNCTION_ARGS |
| Define this macro if the promotion described by @code{PROMOTE_MODE} |
| should also be done for outgoing function arguments. |
| |
| @findex PROMOTE_FUNCTION_RETURN |
| @item PROMOTE_FUNCTION_RETURN |
| Define this macro if the promotion described by @code{PROMOTE_MODE} |
| should also be done for the return value of functions. |
| |
| If this macro is defined, @code{FUNCTION_VALUE} must perform the same |
| promotions done by @code{PROMOTE_MODE}. |
| |
| @findex PROMOTE_FOR_CALL_ONLY |
| @item PROMOTE_FOR_CALL_ONLY |
| Define this macro if the promotion described by @code{PROMOTE_MODE} |
| should @emph{only} be performed for outgoing function arguments or |
| function return values, as specified by @code{PROMOTE_FUNCTION_ARGS} |
| and @code{PROMOTE_FUNCTION_RETURN}, respectively. |
| |
| @findex PARM_BOUNDARY |
| @item PARM_BOUNDARY |
| Normal alignment required for function parameters on the stack, in |
| bits. All stack parameters receive at least this much alignment |
| regardless of data type. On most machines, this is the same as the |
| size of an integer. |
| |
| @findex STACK_BOUNDARY |
| @item 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). |
| |
| @cindex @code{PUSH_ROUNDING}, interaction with @code{STACK_BOUNDARY} |
| If @code{PUSH_ROUNDING} is not defined, the stack will always be aligned |
| to the specified boundary. If @code{PUSH_ROUNDING} is defined and specifies a |
| less strict alignment than @code{STACK_BOUNDARY}, the stack may be |
| momentarily unaligned while pushing arguments. |
| |
| @findex FUNCTION_BOUNDARY |
| @item FUNCTION_BOUNDARY |
| Alignment required for a function entry point, in bits. |
| |
| @findex BIGGEST_ALIGNMENT |
| @item BIGGEST_ALIGNMENT |
| Biggest alignment that any data type can require on this machine, in bits. |
| |
| @findex MINIMUM_ATOMIC_ALIGNMENT |
| @item MINIMUM_ATOMIC_ALIGNMENT |
| If defined, the smallest alignment, in bits, that can be given to an |
| object that can be referenced in one operation, without disturbing any |
| nearby object. Normally, this is @code{BITS_PER_UNIT}, but may be larger |
| on machines that don't have byte or half-word store operations. |
| |
| @findex BIGGEST_FIELD_ALIGNMENT |
| @item BIGGEST_FIELD_ALIGNMENT |
| Biggest alignment that any structure field can require on this machine, |
| in bits. If defined, this overrides @code{BIGGEST_ALIGNMENT} for |
| structure fields only. |
| |
| @findex ADJUST_FIELD_ALIGN |
| @item ADJUST_FIELD_ALIGN (@var{field}, @var{computed}) |
| An expression for the alignment of a structure field @var{field} if the |
| alignment computed in the usual way is @var{computed}. GNU CC uses |
| this value instead of the value in @code{BIGGEST_ALIGNMENT} or |
| @code{BIGGEST_FIELD_ALIGNMENT}, if defined, for structure fields only. |
| |
| @findex MAX_OFILE_ALIGNMENT |
| @item 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 |
| @code{__attribute__ ((aligned (@var{n})))} construct. If not defined, |
| the default value is @code{BIGGEST_ALIGNMENT}. |
| |
| @findex DATA_ALIGNMENT |
| @item DATA_ALIGNMENT (@var{type}, @var{basic-align}) |
| If defined, a C expression to compute the alignment for a static |
| variable. @var{type} is the data type, and @var{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 @var{basic-align} is used. |
| |
| @findex strcpy |
| 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 @code{strcpy} calls that copy |
| constants to character arrays can be done inline. |
| |
| @findex CONSTANT_ALIGNMENT |
| @item CONSTANT_ALIGNMENT (@var{constant}, @var{basic-align}) |
| If defined, a C expression to compute the alignment given to a constant |
| that is being placed in memory. @var{constant} is the constant and |
| @var{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 @var{basic-align} is used. |
| |
| The typical use of this macro is to increase alignment for string |
| constants to be word aligned so that @code{strcpy} calls that copy |
| constants can be done inline. |
| |
| @findex EMPTY_FIELD_BOUNDARY |
| @item EMPTY_FIELD_BOUNDARY |
| Alignment in bits to be given to a structure bit field that follows an |
| empty field such as @code{int : 0;}. |
| |
| Note that @code{PCC_BITFIELD_TYPE_MATTERS} also affects the alignment |
| that results from an empty field. |
| |
| @findex STRUCTURE_SIZE_BOUNDARY |
| @item 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 |
| @code{BITS_PER_UNIT}. |
| |
| @findex STRICT_ALIGNMENT |
| @item 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. |
| |
| @findex PCC_BITFIELD_TYPE_MATTERS |
| @item 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 (@code{int}, |
| @code{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 @code{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 @samp{insv}, @samp{extv}, and |
| @samp{extzv} insns that can directly reference memory. |
| |
| The other known way of making bitfields work is to define |
| @code{STRUCTURE_SIZE_BOUNDARY} as large as @code{BIGGEST_ALIGNMENT}. |
| Then every structure can be accessed with fullwords. |
| |
| Unless the machine has bitfield instructions or you define |
| @code{STRUCTURE_SIZE_BOUNDARY} that way, you must define |
| @code{PCC_BITFIELD_TYPE_MATTERS} to have a nonzero value. |
| |
| If your aim is to make GNU CC use the same conventions for laying out |
| bitfields as are used by another compiler, here is how to investigate |
| what the other compiler does. Compile and run this program: |
| |
| @example |
| struct foo1 |
| @{ |
| char x; |
| char :0; |
| char y; |
| @}; |
| |
| struct foo2 |
| @{ |
| char x; |
| int :0; |
| char y; |
| @}; |
| |
| main () |
| @{ |
| printf ("Size of foo1 is %d\n", |
| sizeof (struct foo1)); |
| printf ("Size of foo2 is %d\n", |
| sizeof (struct foo2)); |
| exit (0); |
| @} |
| @end example |
| |
| If this prints 2 and 5, then the compiler's behavior is what you would |
| get from @code{PCC_BITFIELD_TYPE_MATTERS}. |
| |
| @findex BITFIELD_NBYTES_LIMITED |
| @item BITFIELD_NBYTES_LIMITED |
| Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to |
| aligning a bitfield within the structure. |
| |
| @findex ROUND_TYPE_SIZE |
| @item ROUND_TYPE_SIZE (@var{struct}, @var{size}, @var{align}) |
| Define this macro as an expression for the overall size of a structure |
| (given by @var{struct} as a tree node) when the size computed from the |
| fields is @var{size} and the alignment is @var{align}. |
| |
| The default is to round @var{size} up to a multiple of @var{align}. |
| |
| @findex ROUND_TYPE_ALIGN |
| @item ROUND_TYPE_ALIGN (@var{struct}, @var{computed}, @var{specified}) |
| Define this macro as an expression for the alignment of a structure |
| (given by @var{struct} as a tree node) if the alignment computed in the |
| usual way is @var{computed} and the alignment explicitly specified was |
| @var{specified}. |
| |
| The default is to use @var{specified} if it is larger; otherwise, use |
| the smaller of @var{computed} and @code{BIGGEST_ALIGNMENT} |
| |
| @findex MAX_FIXED_MODE_SIZE |
| @item 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, @code{GET_MODE_BITSIZE |
| (DImode)} is assumed. |
| |
| @findex CHECK_FLOAT_VALUE |
| @item CHECK_FLOAT_VALUE (@var{mode}, @var{value}, @var{overflow}) |
| A C statement to validate the value @var{value} (of type |
| @code{double}) for mode @var{mode}. This means that you check whether |
| @var{value} fits within the possible range of values for mode |
| @var{mode} on this target machine. The mode @var{mode} is always |
| a mode of class @code{MODE_FLOAT}. @var{overflow} is nonzero if |
| the value is already known to be out of range. |
| |
| If @var{value} is not valid or if @var{overflow} is nonzero, you should |
| set @var{overflow} to 1 and then assign some valid value to @var{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. |
| |
| @findex TARGET_FLOAT_FORMAT |
| @item TARGET_FLOAT_FORMAT |
| A code distinguishing the floating point format of the target machine. |
| There are three defined values: |
| |
| @table @code |
| @findex IEEE_FLOAT_FORMAT |
| @item 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. |
| |
| @findex VAX_FLOAT_FORMAT |
| @item VAX_FLOAT_FORMAT |
| This code indicates the peculiar format used on the Vax. |
| |
| @findex UNKNOWN_FLOAT_FORMAT |
| @item UNKNOWN_FLOAT_FORMAT |
| This code indicates any other format. |
| @end table |
| |
| The value of this macro is compared with @code{HOST_FLOAT_FORMAT} |
| (@pxref{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. |
| |
| The ordering of the component words of floating point values stored in |
| memory is controlled by @code{FLOAT_WORDS_BIG_ENDIAN} for the target |
| machine and @code{HOST_FLOAT_WORDS_BIG_ENDIAN} for the host. |
| |
| @findex DEFAULT_VTABLE_THUNKS |
| @item DEFAULT_VTABLE_THUNKS |
| GNU CC supports two ways of implementing C++ vtables: traditional or with |
| so-called ``thunks''. The flag @samp{-fvtable-thunk} chooses between them. |
| Define this macro to be a C expression for the default value of that flag. |
| If @code{DEFAULT_VTABLE_THUNKS} is 0, GNU CC uses the traditional |
| implementation by default. The ``thunk'' implementation is more efficient |
| (especially if you have provided an implementation of |
| @code{ASM_OUTPUT_MI_THUNK}, see @ref{Function Entry}), but is not binary |
| compatible with code compiled using the traditional implementation. |
| If you are writing a new ports, define @code{DEFAULT_VTABLE_THUNKS} to 1. |
| |
| If you do not define this macro, the default for @samp{-fvtable-thunk} is 0. |
| @end table |
| |
| @node Type Layout |
| @section 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. |
| |
| @table @code |
| @findex INT_TYPE_SIZE |
| @item INT_TYPE_SIZE |
| A C expression for the size in bits of the type @code{int} on the |
| target machine. If you don't define this, the default is one word. |
| |
| @findex MAX_INT_TYPE_SIZE |
| @item MAX_INT_TYPE_SIZE |
| Maximum number for the size in bits of the type @code{int} on the target |
| machine. If this is undefined, the default is @code{INT_TYPE_SIZE}. |
| Otherwise, it is the constant value that is the largest value that |
| @code{INT_TYPE_SIZE} can have at run-time. This is used in @code{cpp}. |
| |
| @findex SHORT_TYPE_SIZE |
| @item SHORT_TYPE_SIZE |
| A C expression for the size in bits of the type @code{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.) |
| |
| @findex LONG_TYPE_SIZE |
| @item LONG_TYPE_SIZE |
| A C expression for the size in bits of the type @code{long} on the |
| target machine. If you don't define this, the default is one word. |
| |
| @findex MAX_LONG_TYPE_SIZE |
| @item MAX_LONG_TYPE_SIZE |
| Maximum number for the size in bits of the type @code{long} on the |
| target machine. If this is undefined, the default is |
| @code{LONG_TYPE_SIZE}. Otherwise, it is the constant value that is the |
| largest value that @code{LONG_TYPE_SIZE} can have at run-time. This is |
| used in @code{cpp}. |
| |
| @findex LONG_LONG_TYPE_SIZE |
| @item LONG_LONG_TYPE_SIZE |
| A C expression for the size in bits of the type @code{long long} on the |
| target machine. If you don't define this, the default is two |
| words. If you want to support GNU Ada on your machine, the value of |
| macro must be at least 64. |
| |
| @findex CHAR_TYPE_SIZE |
| @item CHAR_TYPE_SIZE |
| A C expression for the size in bits of the type @code{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.) |
| |
| @findex MAX_CHAR_TYPE_SIZE |
| @item MAX_CHAR_TYPE_SIZE |
| Maximum number for the size in bits of the type @code{char} on the |
| target machine. If this is undefined, the default is |
| @code{CHAR_TYPE_SIZE}. Otherwise, it is the constant value that is the |
| largest value that @code{CHAR_TYPE_SIZE} can have at run-time. This is |
| used in @code{cpp}. |
| |
| @findex FLOAT_TYPE_SIZE |
| @item FLOAT_TYPE_SIZE |
| A C expression for the size in bits of the type @code{float} on the |
| target machine. If you don't define this, the default is one word. |
| |
| @findex DOUBLE_TYPE_SIZE |
| @item DOUBLE_TYPE_SIZE |
| A C expression for the size in bits of the type @code{double} on the |
| target machine. If you don't define this, the default is two |
| words. |
| |
| @findex LONG_DOUBLE_TYPE_SIZE |
| @item LONG_DOUBLE_TYPE_SIZE |
| A C expression for the size in bits of the type @code{long double} on |
| the target machine. If you don't define this, the default is two |
| words. |
| |
| @findex WIDEST_HARDWARE_FP_SIZE |
| @item WIDEST_HARDWARE_FP_SIZE |
| A C expression for the size in bits of the widest floating-point format |
| supported by the hardware. If you define this macro, you must specify a |
| value less than or equal to the value of @code{LONG_DOUBLE_TYPE_SIZE}. |
| If you do not define this macro, the value of @code{LONG_DOUBLE_TYPE_SIZE} |
| is the default. |
| |
| @findex DEFAULT_SIGNED_CHAR |
| @item DEFAULT_SIGNED_CHAR |
| An expression whose value is 1 or 0, according to whether the type |
| @code{char} should be signed or unsigned by default. The user can |
| always override this default with the options @samp{-fsigned-char} |
| and @samp{-funsigned-char}. |
| |
| @findex DEFAULT_SHORT_ENUMS |
| @item DEFAULT_SHORT_ENUMS |
| A C expression to determine whether to give an @code{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 |
| @code{enum} types should be allocated like @code{int}. |
| |
| If you don't define the macro, the default is 0. |
| |
| @findex SIZE_TYPE |
| @item SIZE_TYPE |
| A C expression for a string describing the name of the data type to use |
| for size values. The typedef name @code{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 @code{unsigned} if |
| appropriate, and finally @code{int}. The string must exactly match one |
| of the data type names defined in the function |
| @code{init_decl_processing} in the file @file{c-decl.c}. You may not |
| omit @code{int} or change the order---that would cause the compiler to |
| crash on startup. |
| |
| If you don't define this macro, the default is @code{"long unsigned |
| int"}. |
| |
| @findex PTRDIFF_TYPE |
| @item 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 |
| @code{ptrdiff_t} is defined using the contents of the string. See |
| @code{SIZE_TYPE} above for more information. |
| |
| If you don't define this macro, the default is @code{"long int"}. |
| |
| @findex WCHAR_TYPE |
| @item WCHAR_TYPE |
| A C expression for a string describing the name of the data type to use |
| for wide characters. The typedef name @code{wchar_t} is defined using |
| the contents of the string. See @code{SIZE_TYPE} above for more |
| information. |
| |
| If you don't define this macro, the default is @code{"int"}. |
| |
| @findex WCHAR_TYPE_SIZE |
| @item WCHAR_TYPE_SIZE |
| A C expression for the size in bits of the data type for wide |
| characters. This is used in @code{cpp}, which cannot make use of |
| @code{WCHAR_TYPE}. |
| |
| @findex MAX_WCHAR_TYPE_SIZE |
| @item MAX_WCHAR_TYPE_SIZE |
| Maximum number for the size in bits of the data type for wide |
| characters. If this is undefined, the default is |
| @code{WCHAR_TYPE_SIZE}. Otherwise, it is the constant value that is the |
| largest value that @code{WCHAR_TYPE_SIZE} can have at run-time. This is |
| used in @code{cpp}. |
| |
| @findex OBJC_INT_SELECTORS |
| @item OBJC_INT_SELECTORS |
| Define this macro if the type of Objective C selectors should be |
| @code{int}. |
| |
| If this macro is not defined, then selectors should have the type |
| @code{struct objc_selector *}. |
| |
| @findex OBJC_SELECTORS_WITHOUT_LABELS |
| @item 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. |
| |
| @findex TARGET_BELL |
| @item TARGET_BELL |
| A C constant expression for the integer value for escape sequence |
| @samp{\a}. |
| |
| @findex TARGET_TAB |
| @findex TARGET_BS |
| @findex TARGET_NEWLINE |
| @item TARGET_BS |
| @itemx TARGET_TAB |
| @itemx TARGET_NEWLINE |
| C constant expressions for the integer values for escape sequences |
| @samp{\b}, @samp{\t} and @samp{\n}. |
| |
| @findex TARGET_VT |
| @findex TARGET_FF |
| @findex TARGET_CR |
| @item TARGET_VT |
| @itemx TARGET_FF |
| @itemx TARGET_CR |
| C constant expressions for the integer values for escape sequences |
| @samp{\v}, @samp{\f} and @samp{\r}. |
| @end table |
| |
| @node Registers |
| @section Register Usage |
| @cindex 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 @ref{Register Classes}. For information |
| on using registers to access a stack frame, see @ref{Frame Registers}. |
| For passing values in registers, see @ref{Register Arguments}. |
| For returning values in registers, see @ref{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. |
| @end menu |
| |
| @node Register Basics |
| @subsection Basic Characteristics of Registers |
| |
| @c prevent bad page break with this line |
| Registers have various characteristics. |
| |
| @table @code |
| @findex FIRST_PSEUDO_REGISTER |
| @item FIRST_PSEUDO_REGISTER |
| Number of hardware registers known to the compiler. They receive |
| numbers 0 through @code{FIRST_PSEUDO_REGISTER-1}; thus, the first |
| pseudo register's number really is assigned the number |
| @code{FIRST_PSEUDO_REGISTER}. |
| |
| @item FIXED_REGISTERS |
| @findex FIXED_REGISTERS |
| @cindex fixed register |
| An initializer that says which registers are used for fixed purposes |
| all throughout the compiled code and are therefore not available for |
| general allocation. These would include the stack pointer, the frame |
| pointer (except on machines where that can be used as a general |
| register when no frame pointer is needed), the program counter on |
| machines where that is considered one of the addressable registers, |
| and any other numbered register with a standard use. |
| |
| This information is expressed as a sequence of numbers, separated by |
| commas and surrounded by braces. The @var{n}th number is 1 if |
| register @var{n} is fixed, 0 otherwise. |
| |
| The table initialized from this macro, and the table initialized by |
| the following one, may be overridden at run time either automatically, |
| by the actions of the macro @code{CONDITIONAL_REGISTER_USAGE}, or by |
| the user with the command options @samp{-ffixed-@var{reg}}, |
| @samp{-fcall-used-@var{reg}} and @samp{-fcall-saved-@var{reg}}. |
| |
| @findex CALL_USED_REGISTERS |
| @item CALL_USED_REGISTERS |
| @cindex call-used register |
| @cindex call-clobbered register |
| @cindex call-saved register |
| Like @code{FIXED_REGISTERS} but has 1 for each register that is |
| clobbered (in general) by function calls as well as for fixed |
| registers. This macro therefore identifies the registers that are not |
| available for general allocation of values that must live across |
| function calls. |
| |
| If a register has 0 in @code{CALL_USED_REGISTERS}, the compiler |
| automatically saves it on function entry and restores it on function |
| exit, if the register is used within the function. |
| |
| @findex CONDITIONAL_REGISTER_USAGE |
| @findex fixed_regs |
| @findex call_used_regs |
| @item CONDITIONAL_REGISTER_USAGE |
| Zero or more C statements that may conditionally modify two variables |
| @code{fixed_regs} and @code{call_used_regs} (both of type @code{char |
| []}) after they have been initialized from the two preceding macros. |
| |
| This is necessary in case the fixed or call-clobbered registers depend |
| on target flags. |
| |
| You need not define this macro if it has no work to do. |
| |
| @cindex disabling certain registers |
| @cindex controlling register usage |
| If the usage of an entire class of registers depends on the target |
| flags, you may indicate this to GCC by using this macro to modify |
| @code{fixed_regs} and @code{call_used_regs} to 1 for each of the |
| registers in the classes which should not be used by GCC. Also define |
| the macro @code{REG_CLASS_FROM_LETTER} to return @code{NO_REGS} if it |
| is called with a letter for a class that shouldn't be used. |
| |
| (However, if this class is not included in @code{GENERAL_REGS} and all |
| of the insn patterns whose constraints permit this class are |
| controlled by target switches, then GCC will automatically avoid using |
| these registers when the target switches are opposed to them.) |
| |
| @findex NON_SAVING_SETJMP |
| @item NON_SAVING_SETJMP |
| If this macro is defined and has a nonzero value, it means that |
| @code{setjmp} and related functions fail to save the registers, or that |
| @code{longjmp} fails to restore them. To compensate, the compiler |
| avoids putting variables in registers in functions that use |
| @code{setjmp}. |
| |
| @findex INCOMING_REGNO |
| @item INCOMING_REGNO (@var{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 @var{out} as seen by the calling |
| function. Return @var{out} if register number @var{out} is not an |
| outbound register. |
| |
| @findex OUTGOING_REGNO |
| @item OUTGOING_REGNO (@var{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 @var{in} as seen by the called |
| function. Return @var{in} if register number @var{in} is not an inbound |
| register. |
| |
| @ignore |
| @findex PC_REGNUM |
| @item PC_REGNUM |
| If the program counter has a register number, define this as that |
| register number. Otherwise, do not define it. |
| @end ignore |
| @end table |
| |
| @node Allocation Order |
| @subsection Order of Allocation of Registers |
| @cindex order of register allocation |
| @cindex register allocation order |
| |
| @c prevent bad page break with this line |
| Registers are allocated in order. |
| |
| @table @code |
| @findex REG_ALLOC_ORDER |
| @item REG_ALLOC_ORDER |
| If defined, an initializer for a vector of integers, containing the |
| numbers of hard registers in the order in which GNU CC should prefer |
| to use them (from most preferred to least). |
| |
| If this macro is not defined, registers are used lowest numbered first |
| (all else being equal). |
| |
| One use of this macro is on machines where the highest numbered |
| registers must always be saved and the save-multiple-registers |
| instruction supports only sequences of consecutive registers. On such |
| machines, define @code{REG_ALLOC_ORDER} to be an initializer that lists |
| the highest numbered allocable register first. |
| |
| @findex ORDER_REGS_FOR_LOCAL_ALLOC |
| @item ORDER_REGS_FOR_LOCAL_ALLOC |
| A C statement (sans semicolon) to choose the order in which to allocate |
| hard registers for pseudo-registers local to a basic block. |
| |
| Store the desired register order in the array @code{reg_alloc_order}. |
| Element 0 should be the register to allocate first; element 1, the next |
| register; and so on. |
| |
| The macro body should not assume anything about the contents of |
| @code{reg_alloc_order} before execution of the macro. |
| |
| On most machines, it is not necessary to define this macro. |
| @end table |
| |
| @node Values in Registers |
| @subsection How Values Fit in Registers |
| |
| This section discusses the macros that describe which kinds of values |
| (specifically, which machine modes) each register can hold, and how many |
| consecutive registers are needed for a given mode. |
| |
| @table @code |
| @findex HARD_REGNO_NREGS |
| @item HARD_REGNO_NREGS (@var{regno}, @var{mode}) |
| A C expression for the number of consecutive hard registers, starting |
| at register number @var{regno}, required to hold a value of mode |
| @var{mode}. |
| |
| On a machine where all registers are exactly one word, a suitable |
| definition of this macro is |
| |
| @smallexample |
| #define HARD_REGNO_NREGS(REGNO, MODE) \ |
| ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ |
| / UNITS_PER_WORD)) |
| @end smallexample |
| |
| @findex HARD_REGNO_MODE_OK |
| @item HARD_REGNO_MODE_OK (@var{regno}, @var{mode}) |
| A C expression that is nonzero if it is permissible to store a value |
| of mode @var{mode} in hard register number @var{regno} (or in several |
| registers starting with that one). For a machine where all registers |
| are equivalent, a suitable definition is |
| |
| @smallexample |
| #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 |
| @end smallexample |
| |
| You need not include code to check for the numbers of fixed registers, |
| because the allocation mechanism considers them to be always occupied. |
| |
| @cindex register pairs |
| On some machines, double-precision values must be kept in even/odd |
| register pairs. 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 |
| @samp{mov@var{mode}} 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 @code{word_mode} will work for |
| all narrower integer modes, it is not necessary on any machine for |
| @code{HARD_REGNO_MODE_OK} to distinguish between these modes, provided |
| you define patterns @samp{movhi}, etc., to take advantage of this. This |
| is useful because of the interaction between @code{HARD_REGNO_MODE_OK} |
| and @code{MODES_TIEABLE_P}; it is very desirable for all integer modes |
| to be tieable. |
| |
| Many machines have special registers for floating point arithmetic. |
| Often people assume that floating point machine modes are allowed only |
| in floating point registers. This is not true. Any registers that |
| can hold integers can safely @emph{hold} a floating point machine |
| mode, whether or not floating arithmetic can be done on it in those |
| registers. Integer move instructions can be used to move the values. |
| |
| On some machines, though, the converse is true: fixed-point machine |
| modes may not go in floating registers. This is true if the floating |
| registers normalize any value stored in them, because storing a |
| non-floating value there would garble it. In this case, |
| @code{HARD_REGNO_MODE_OK} should reject fixed-point machine modes in |
| floating registers. But if the floating registers do not automatically |
| normalize, if you can store any bit pattern in one and retrieve it |
| unchanged without a trap, then any machine mode may go in a floating |
| register, so you can define this macro to say so. |
| |
| The primary significance of special floating registers is rather that |
| they are the registers acceptable in floating point arithmetic |
| instructions. However, this is of no concern to |
| @code{HARD_REGNO_MODE_OK}. You handle it by writing the proper |
| constraints for those instructions. |
| |
| On some machines, the floating registers are especially slow to access, |
| so that it is better to store a value in a stack frame than in such a |
| register if floating point arithmetic is not being done. As long as the |
| floating registers are not in class @code{GENERAL_REGS}, they will not |
| be used unless some pattern's constraint asks for one. |
| |
| @findex MODES_TIEABLE_P |
| @item MODES_TIEABLE_P (@var{mode1}, @var{mode2}) |
| A C expression that is nonzero if a value of mode |
| @var{mode1} is accessible in mode @var{mode2} without copying. |
| |
| If @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode1})} and |
| @code{HARD_REGNO_MODE_OK (@var{r}, @var{mode2})} are always the same for |
| any @var{r}, then @code{MODES_TIEABLE_P (@var{mode1}, @var{mode2})} |
| should be nonzero. If they differ for any @var{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. |
| @end table |
| |
| @node Leaf Functions |
| @subsection Handling Leaf Functions |
| |
| @cindex leaf functions |
| @cindex functions, leaf |
| On some machines, a leaf function (i.e., one which makes no calls) can run |
| more efficiently if it does not make its own register window. Often this |
| means it is required to receive its arguments in the registers where they |
| are passed by the caller, instead of the registers where they would |
| normally arrive. |
| |
| The special treatment for leaf functions generally applies only when |
| other conditions are met; for example, often they may use only those |
| registers for its own variables and temporaries. We use the term ``leaf |
| function'' to mean a function that is suitable for this special |
| handling, so that functions with no calls are not necessarily ``leaf |
| functions''. |
| |
| GNU CC assigns register numbers before it knows whether the function is |
| suitable for leaf function treatment. So it needs to renumber the |
| registers in order to output a leaf function. The following macros |
| accomplish this. |
| |
| @table @code |
| @findex LEAF_REGISTERS |
| @item LEAF_REGISTERS |
| A C initializer for a vector, indexed by hard register number, which |
| contains 1 for a register that is allowable in a candidate for leaf |
| function treatment. |
| |
| If leaf function treatment involves renumbering the registers, then the |
| registers marked here should be the ones before renumbering---those that |
| GNU CC would ordinarily allocate. The registers which will actually be |
| used in the assembler code, after renumbering, should not be marked with 1 |
| in this vector. |
| |
| Define this macro only if the target machine offers a way to optimize |
| the treatment of leaf functions. |
| |
| @findex LEAF_REG_REMAP |
| @item LEAF_REG_REMAP (@var{regno}) |
| A C expression whose value is the register number to which @var{regno} |
| should be renumbered, when a function is treated as a leaf function. |
| |
| If @var{regno} is a register number which should not appear in a leaf |
| function before renumbering, then the expression should yield -1, which |
| will cause the compiler to abort. |
| |
| Define this macro only if the target machine offers a way to optimize the |
| treatment of leaf functions, and registers need to be renumbered to do |
| this. |
| @end table |
| |
| @findex leaf_function |
| Normally, @code{FUNCTION_PROLOGUE} and @code{FUNCTION_EPILOGUE} must |
| treat leaf functions specially. It can test the C variable |
| @code{leaf_function} which is nonzero for leaf functions. (The variable |
| @code{leaf_function} is defined only if @code{LEAF_REGISTERS} is |
| defined.) |
| @c changed this to fix overfull. ALSO: why the "it" at the beginning |
| @c of the next paragraph?! --mew 2feb93 |
| |
| @node Stack Registers |
| @subsection Registers That Form a Stack |
| |
| There are special features to handle computers where some of the |
| ``registers'' form a stack, as in the 80387 coprocessor for the 80386. |
| Stack registers are normally written by pushing onto the stack, and are |
| numbered relative to the top of the stack. |
| |
| Currently, GNU CC can only handle one group of stack-like registers, and |
| they must be consecutively numbered. |
| |
| @table @code |
| @findex STACK_REGS |
| @item STACK_REGS |
| Define this if the machine has any stack-like registers. |
| |
| @findex FIRST_STACK_REG |
| @item FIRST_STACK_REG |
| The number of the first stack-like register. This one is the top |
| of the stack. |
| |
| @findex LAST_STACK_REG |
| @item LAST_STACK_REG |
| The number of the last stack-like register. This one is the bottom of |
| the stack. |
| @end table |
| |
| @node Obsolete Register Macros |
| @subsection Obsolete Macros for Controlling Register Usage |
| |
| These features do not work very well. They exist because they used to |
| be required to generate correct code for the 80387 coprocessor of the |
| 80386. They are no longer used by that machine description and may be |
| removed in a later version of the compiler. Don't use them! |
| |
| @table @code |
| @findex OVERLAPPING_REGNO_P |
| @item OVERLAPPING_REGNO_P (@var{regno}) |
| If defined, this is a C expression whose value is nonzero if hard |
| register number @var{regno} is an overlapping register. This means a |
| hard register which overlaps a hard register with a different number. |
| (Such overlap is undesirable, but occasionally it allows a machine to |
| be supported which otherwise could not be.) This macro must return |
| nonzero for @emph{all} the registers which overlap each other. GNU CC |
| can use an overlapping register only in certain limited ways. It can |
| be used for allocation within a basic block, and may be spilled for |
| reloading; that is all. |
| |
| If this macro is not defined, it means that none of the hard registers |
| overlap each other. This is the usual situation. |
| |
| @findex INSN_CLOBBERS_REGNO_P |
| @item INSN_CLOBBERS_REGNO_P (@var{insn}, @var{regno}) |
| If defined, this is a C expression whose value should be nonzero if |
| the insn @var{insn} has the effect of mysteriously clobbering the |
| contents of hard register number @var{regno}. By ``mysterious'' we |
| mean that the insn's RTL expression doesn't describe such an effect. |
| |
| If this macro is not defined, it means that no insn clobbers registers |
| mysteriously. This is the usual situation; all else being equal, |
| it is best for the RTL expression to show all the activity. |
| |
| @cindex death notes |
| @findex PRESERVE_DEATH_INFO_REGNO_P |
| @item PRESERVE_DEATH_INFO_REGNO_P (@var{regno}) |
| If defined, this is a C expression whose value is nonzero if correct |
| @code{REG_DEAD} notes are needed for hard register number @var{regno} |
| after reload. |
| |
| You would arrange to preserve death info for a register when some of 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. |
| @end table |
| |
| @node Register Classes |
| @section Register Classes |
| @cindex register class definitions |
| @cindex class definitions, register |
| |
| On many machines, the numbered registers are not all equivalent. |
| For example, certain registers may not be allowed for indexed addressing; |
| certain registers may not be allowed in some instructions. These machine |
| restrictions are described to the compiler using @dfn{register classes}. |
| |
| You define a number of register classes, giving each one a name and saying |
| which of the registers belong to it. Then you can specify register classes |
| that are allowed as operands to particular instruction patterns. |
| |
| @findex ALL_REGS |
| @findex NO_REGS |
| In general, each register will belong to several classes. In fact, one |
| class must be named @code{ALL_REGS} and contain all the registers. Another |
| class must be named @code{NO_REGS} and contain no registers. Often the |
| union of two classes will be another class; however, this is not required. |
| |
| @findex GENERAL_REGS |
| One of the classes must be named @code{GENERAL_REGS}. There is nothing |
| terribly special about the name, but the operand constraint letters |
| @samp{r} and @samp{g} specify this class. If @code{GENERAL_REGS} is |
| the same as @code{ALL_REGS}, just define it as a macro which expands |
| to @code{ALL_REGS}. |
| |
| Order the classes so that if class @var{x} is contained in class @var{y} |
| then @var{x} has a lower class number than @var{y}. |
| |
| The way classes other than @code{GENERAL_REGS} are specified in operand |
| constraints is through machine-dependent operand constraint letters. |
| You can define such letters to correspond to various classes, then use |
| them in operand constraints. |
| |
| You should define a class for the union of two classes whenever some |
| instruction allows both classes. For example, if an instruction allows |
| either a floating point (coprocessor) register or a general register for a |
| certain operand, you should define a class @code{FLOAT_OR_GENERAL_REGS} |
| which includes both of them. Otherwise you will get suboptimal code. |
| |
| You must also specify certain redundant information about the register |
| classes: for each class, which classes contain it and which ones are |
| contained in it; for each pair of classes, the largest class contained |
| in their union. |
| |
| When a value occupying several consecutive registers is expected in a |
| certain class, all the registers used must belong to that class. |
| Therefore, register classes cannot be used to enforce a requirement for |
| a register pair to start with an even-numbered register. The way to |
| specify this requirement is with @code{HARD_REGNO_MODE_OK}. |
| |
| Register classes used for input-operands of bitwise-and or shift |
| instructions have a special requirement: each such class must have, for |
| each fixed-point machine mode, a subclass whose registers can transfer that |
| mode to or from memory. For example, on some machines, the operations for |
| single-byte values (@code{QImode}) are limited to certain registers. When |
| this is so, each register class that is used in a bitwise-and or shift |
| instruction must have a subclass consisting of registers from which |
| single-byte values can be loaded or stored. This is so that |
| @code{PREFERRED_RELOAD_CLASS} can always have a possible value to return. |
| |
| @table @code |
| @findex enum reg_class |
| @item enum reg_class |
| An enumeral type that must be defined with all the register class names |
| as enumeral values. @code{NO_REGS} must be first. @code{ALL_REGS} |
| must be the last register class, followed by one more enumeral value, |
| @code{LIM_REG_CLASSES}, which is not a register class but rather |
| tells how many classes there are. |
| |
| Each register class has a number, which is the value of casting |
| the class name to type @code{int}. The number serves as an index |
| in many of the tables described below. |
| |
| @findex N_REG_CLASSES |
| @item N_REG_CLASSES |
| The number of distinct register classes, defined as follows: |
| |
| @example |
| #define N_REG_CLASSES (int) LIM_REG_CLASSES |
| @end example |
| |
| @findex REG_CLASS_NAMES |
| @item REG_CLASS_NAMES |
| An initializer containing the names of the register classes as C string |
| constants. These names are used in writing some of the debugging dumps. |
| |
| @findex REG_CLASS_CONTENTS |
| @item REG_CLASS_CONTENTS |
| An initializer containing the contents of the register classes, as integers |
| which are bit masks. The @var{n}th integer specifies the contents of class |
| @var{n}. The way the integer @var{mask} is interpreted is that |
| register @var{r} is in the class if @code{@var{mask} & (1 << @var{r})} is 1. |
| |
| When the machine has more than 32 registers, an integer does not suffice. |
| Then the integers are replaced by sub-initializers, braced groupings containing |
| several integers. Each sub-initializer must be suitable as an initializer |
| for the type @code{HARD_REG_SET} which is defined in @file{hard-reg-set.h}. |
| |
| @findex REGNO_REG_CLASS |
| @item REGNO_REG_CLASS (@var{regno}) |
| A C expression whose value is a register class containing hard register |
| @var{regno}. In general there is more than one such class; choose a class |
| which is @dfn{minimal}, meaning that no smaller class also contains the |
| register. |
| |
| @findex BASE_REG_CLASS |
| @item BASE_REG_CLASS |
| A macro whose definition is the name of the class to which a valid |
| base register must belong. A base register is one used in an address |
| which is the register value plus a displacement. |
| |
| @findex INDEX_REG_CLASS |
| @item INDEX_REG_CLASS |
| A macro whose definition is the name of the class to which a valid |
| index register must belong. An index register is one used in an |
| address where its value is either multiplied by a scale factor or |
| added to another register (as well as added to a displacement). |
| |
| @findex REG_CLASS_FROM_LETTER |
| @item REG_CLASS_FROM_LETTER (@var{char}) |
| A C expression which defines the machine-dependent operand constraint |
| letters for register classes. If @var{char} is such a letter, the |
| value should be the register class corresponding to it. Otherwise, |
| the value should be @code{NO_REGS}. The register letter @samp{r}, |
| corresponding to class @code{GENERAL_REGS}, will not be passed |
| to this macro; you do not need to handle it. |
| |
| @findex REGNO_OK_FOR_BASE_P |
| @item REGNO_OK_FOR_BASE_P (@var{num}) |
| A C expression which is nonzero if register number @var{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. |
| |
| @findex REGNO_MODE_OK_FOR_BASE_P |
| @item REGNO_MODE_OK_FOR_BASE_P (@var{num}, @var{mode}) |
| A C expression that is just like @code{REGNO_OK_FOR_BASE_P}, except that |
| that expression may examine the mode of the memory reference in |
| @var{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 |
| @code{REGNO_OK_FOR_BASE_P}. |
| |
| @findex REGNO_OK_FOR_INDEX_P |
| @item REGNO_OK_FOR_INDEX_P (@var{num}) |
| A C expression which is nonzero if register number @var{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. |
| |
| @findex PREFERRED_RELOAD_CLASS |
| @item PREFERRED_RELOAD_CLASS (@var{x}, @var{class}) |
| A C expression that places additional restrictions on the register class |
| to use when it is necessary to copy value @var{x} into a register in class |
| @var{class}. The value is a register class; perhaps @var{class}, or perhaps |
| another, smaller class. On many machines, the following definition is |
| safe: |
| |
| @example |
| #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS |
| @end example |
| |
| Sometimes returning a more restrictive class makes better code. For |
| example, on the 68000, when @var{x} is an integer constant that is in range |
| for a @samp{moveq} instruction, the value of this macro is always |
| @code{DATA_REGS} as long as @var{class} includes the data registers. |
| Requiring a data register guarantees that a @samp{moveq} will be used. |
| |
| If @var{x} is a @code{const_double}, by returning @code{NO_REGS} |
| you can force @var{x} into a memory constant. This is useful on |
| certain machines where immediate floating values cannot be loaded into |
| certain kinds of registers. |
| |
| @findex PREFERRED_OUTPUT_RELOAD_CLASS |
| @item PREFERRED_OUTPUT_RELOAD_CLASS (@var{x}, @var{class}) |
| Like @code{PREFERRED_RELOAD_CLASS}, but for output reloads instead of |
| input reloads. If you don't define this macro, the default is to use |
| @var{class}, unchanged. |
| |
| @findex LIMIT_RELOAD_CLASS |
| @item LIMIT_RELOAD_CLASS (@var{mode}, @var{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 |
| @var{mode} in a reload register for which class @var{class} would |
| ordinarily be used. |
| |
| Unlike @code{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 @var{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. |
| |
| @findex SECONDARY_RELOAD_CLASS |
| @findex SECONDARY_INPUT_RELOAD_CLASS |
| @findex SECONDARY_OUTPUT_RELOAD_CLASS |
| @item SECONDARY_RELOAD_CLASS (@var{class}, @var{mode}, @var{x}) |
| @itemx SECONDARY_INPUT_RELOAD_CLASS (@var{class}, @var{mode}, @var{x}) |
| @itemx SECONDARY_OUTPUT_RELOAD_CLASS (@var{class}, @var{mode}, @var{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 |
| @samp{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 @var{x} to a |
| register @var{class} in @var{mode} requires an intermediate register, |
| you should define @code{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 @var{class} in @var{mode} to @var{x} requires an |
| intermediate or scratch register, @code{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 |
| @code{SECONDARY_RELOAD_CLASS} should be used instead of defining both |
| macros identically. |
| |
| The values returned by these macros are often @code{GENERAL_REGS}. |
| Return @code{NO_REGS} if no spare register is needed; i.e., if @var{x} |
| can be directly copied to or from a register of @var{class} in |
| @var{mode} without requiring a scratch register. Do not define this |
| macro if it would always return @code{NO_REGS}. |
| |
| If a scratch register is required (either with or without an |
| intermediate register), you should define patterns for |
| @samp{reload_in@var{m}} or @samp{reload_out@var{m}}, as required |
| (@pxref{Standard Names}. These patterns, which will normally be |
| implemented with a @code{define_expand}, should be similar to the |
| @samp{mov@var{m}} 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 @var{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. |
| |
| @var{x} might be a pseudo-register or a @code{subreg} of a |
| pseudo-register, which could either be in a hard register or in memory. |
| Use @code{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 @code{mov@var{m}} pattern should use memory as a |
| intermediate storage. This case often occurs between floating-point and |
| general registers. |
| |
| @findex SECONDARY_MEMORY_NEEDED |
| @item SECONDARY_MEMORY_NEEDED (@var{class1}, @var{class2}, @var{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 |
| @var{m} in registers of @var{class1} can only be copied to registers of |
| class @var{class2} by storing a register of @var{class1} into memory |
| and loading that memory location into a register of @var{class2}. |
| |
| Do not define this macro if its value would always be zero. |
| |
| @findex SECONDARY_MEMORY_NEEDED_RTX |
| @item SECONDARY_MEMORY_NEEDED_RTX (@var{mode}) |
| Normally when @code{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 |
| @code{SECONDARY_MEMORY_NEEDED}. |
| |
| @findex SECONDARY_MEMORY_NEEDED_MODE |
| @item SECONDARY_MEMORY_NEEDED_MODE (@var{mode}) |
| When the compiler needs a secondary memory location to copy between two |
| registers of mode @var{mode}, it normally allocates sufficient memory to |
| hold a quantity of @code{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 @var{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 @file{alpha.h} for |
| details. |
| |
| Do not define this macro if you do not define |
| @code{SECONDARY_MEMORY_NEEDED} or if widening @var{mode} to a mode that |
| is @code{BITS_PER_WORD} bits wide is correct for your machine. |
| |
| @findex SMALL_REGISTER_CLASSES |
| @item 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 @code{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. |
| |
| @findex CLASS_LIKELY_SPILLED_P |
| @item CLASS_LIKELY_SPILLED_P (@var{class}) |
| A C expression whose value is nonzero if pseudos that have been assigned |
| to registers of class @var{class} would likely be spilled because |
| registers of @var{class} are needed for spill registers. |
| |
| The default value of this macro returns 1 if @var{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 @file{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 |
| @file{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. |
| |
| @findex CLASS_MAX_NREGS |
| @item CLASS_MAX_NREGS (@var{class}, @var{mode}) |
| A C expression for the maximum number of consecutive registers |
| of class @var{class} needed to hold a value of mode @var{mode}. |
| |
| This is closely related to the macro @code{HARD_REGNO_NREGS}. In fact, |
| the value of the macro @code{CLASS_MAX_NREGS (@var{class}, @var{mode})} |
| should be the maximum value of @code{HARD_REGNO_NREGS (@var{regno}, |
| @var{mode})} for all @var{regno} values in the class @var{class}. |
| |
| This macro helps control the handling of multiple-word values |
| in the reload pass. |
| |
| @item 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, @file{alpha.h} defines this macro as |
| @code{FLOAT_REGS}. |
| @end table |
| |
| Three other special macros describe which operands fit which constraint |
| letters. |
| |
| @table @code |
| @findex CONST_OK_FOR_LETTER_P |
| @item CONST_OK_FOR_LETTER_P (@var{value}, @var{c}) |
| A C expression that defines the machine-dependent operand constraint |
| letters (@samp{I}, @samp{J}, @samp{K}, @dots{} @samp{P}) that specify |
| particular ranges of integer values. If @var{c} is one of those |
| letters, the expression should check that @var{value}, an integer, is in |
| the appropriate range and return 1 if so, 0 otherwise. If @var{c} is |
| not one of those letters, the value should be 0 regardless of |
| @var{value}. |
| |
| @findex CONST_DOUBLE_OK_FOR_LETTER_P |
| @item CONST_DOUBLE_OK_FOR_LETTER_P (@var{value}, @var{c}) |
| A C expression that defines the machine-dependent operand constraint |
| letters that specify particular ranges of @code{const_double} values |
| (@samp{G} or @samp{H}). |
| |
| If @var{c} is one of those letters, the expression should check that |
| @var{value}, an RTX of code @code{const_double}, is in the appropriate |
| range and return 1 if so, 0 otherwise. If @var{c} is not one of those |
| letters, the value should be 0 regardless of @var{value}. |
| |
| @code{const_double} is used for all floating-point constants and for |
| @code{DImode} fixed-point constants. A given letter can accept either |
| or both kinds of values. It can use @code{GET_MODE} to distinguish |
| between these kinds. |
| |
| @findex EXTRA_CONSTRAINT |
| @item EXTRA_CONSTRAINT (@var{value}, @var{c}) |
| A C expression that defines the optional machine-dependent constraint |
| letters (@item @samp{Q}, @samp{R}, @samp{S}, @samp{T}, @samp{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 @var{value} corresponds to the operand type represented by |
| the constraint letter @var{c}. If @var{c} is not defined as an extra |
| constraint, the value returned should be 0 regardless of @var{value}. |
| |
| For example, on the ROMP, load instructions cannot have their output in r0 if |
| the memory reference contains a symbolic address. Constraint letter |
| @samp{Q} is defined as representing a memory address that does |
| @emph{not} contain a symbolic address. An alternative is specified with |
| a @samp{Q} constraint on the input and @samp{r} on the output. The next |
| alternative specifies @samp{m} on the input and a register class that |
| does not include r0 on the output. |
| @end table |
| |
| @node Stack and Calling |
| @section Stack Layout and Calling Conventions |
| @cindex calling conventions |
| |
| @c prevent bad page break with this line |
| 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:: |
| @end menu |
| |
| @node Frame Layout |
| @subsection Basic Stack Layout |
| @cindex stack frame layout |
| @cindex frame layout |
| |
| @c prevent bad page break with this line |
| Here is the basic stack layout. |
| |
| @table @code |
| @findex STACK_GROWS_DOWNWARD |
| @item 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 @dots{},'' it means that the |
| compiler checks this macro only with @code{#ifdef} so the precise |
| definition used does not matter. |
| |
| @findex FRAME_GROWS_DOWNWARD |
| @item FRAME_GROWS_DOWNWARD |
| Define this macro if the addresses of local variable slots are at negative |
| offsets from the frame pointer. |
| |
| @findex ARGS_GROW_DOWNWARD |
| @item ARGS_GROW_DOWNWARD |
| Define this macro if successive arguments to a function occupy decreasing |
| addresses on the stack. |
| |
| @findex STARTING_FRAME_OFFSET |
| @item STARTING_FRAME_OFFSET |
| Offset from the frame pointer to the first local variable slot to be allocated. |
| |
| If @code{FRAME_GROWS_DOWNWARD}, find the next slot's offset by |
| subtracting the first slot's length from @code{STARTING_FRAME_OFFSET}. |
| Otherwise, it is found by adding the length of the first slot to the |
| value @code{STARTING_FRAME_OFFSET}. |
| @c i'm not sure if the above is still correct.. had to change it to get |
| @c rid of an overfull. --mew 2feb93 |
| |
| @findex STACK_POINTER_OFFSET |
| @item 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 @code{ARGS_GROW_DOWNWARD}, this is the offset to the location above |
| the first location at which outgoing arguments are placed. |
| |
| @findex FIRST_PARM_OFFSET |
| @item FIRST_PARM_OFFSET (@var{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 @code{ARGS_GROW_DOWNWARD}, this is the offset to the location above |
| the first argument's address. |
| |
| @findex STACK_DYNAMIC_OFFSET |
| @item STACK_DYNAMIC_OFFSET (@var{fundecl}) |
| Offset from the stack pointer register to an item dynamically allocated |
| on the stack, e.g., by @code{alloca}. |
| |
| The default value for this macro is @code{STACK_POINTER_OFFSET} plus the |
| length of the outgoing arguments. The default is correct for most |
| machines. See @file{function.c} for details. |
| |
| @findex DYNAMIC_CHAIN_ADDRESS |
| @item DYNAMIC_CHAIN_ADDRESS (@var{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 |
| @var{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 @var{frameaddr}---that is, the stack frame address is also the |
| address of the stack word that points to the previous frame. |
| |
| @findex SETUP_FRAME_ADDRESSES |
| @item 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. |
| |
| @findex RETURN_ADDR_RTX |
| @item RETURN_ADDR_RTX (@var{count}, @var{frameaddr}) |
| A C expression whose value is RTL representing the value of the return |
| address for the frame @var{count} steps up from the current frame, after |
| the prologue. @var{frameaddr} is the frame pointer of the @var{count} |
| frame, or the frame pointer of the @var{count} @minus{} 1 frame if |
| @code{RETURN_ADDR_IN_PREVIOUS_FRAME} is defined. |
| |
| The value of the expression must always be the correct address when |
| @var{count} is zero, but may be @code{NULL_RTX} if there is not way to |
| determine the return address of other frames. |
| |
| @findex RETURN_ADDR_IN_PREVIOUS_FRAME |
| @item 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. |
| |
| @findex INCOMING_RETURN_ADDR_RTX |
| @item 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 @code{REG}, indicating that the return |
| value is saved in @samp{REG}, or a @code{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. |
| |
| @findex INCOMING_FRAME_SP_OFFSET |
| @item 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. |
| @end table |
| |
| @node Stack Checking |
| @subsection Specifying How Stack Checking is Done |
| |
| GNU CC will check that stack references are within the boundaries of |
| the stack, if the @samp{-fstack-check} is specified, in one of three ways: |
| |
| @enumerate |
| @item |
| If the value of the @code{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 |
| @code{FUNCTION_PROLOGUE}. GNU CC will do not other special processing. |
| |
| @item |
| If @code{STACK_CHECK_BUILTIN} is zero and you defined a named pattern |
| called @code{check_stack} in your @file{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. |
| |
| @item |
| 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. |
| @end enumerate |
| |
| Normally, you will use the default values of these macros, so GNU CC |
| will use the third approach. |
| |
| @table @code |
| @findex STACK_CHECK_BUILTIN |
| @item 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. |
| |
| @findex STACK_CHECK_PROBE_INTERVAL |
| @item 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. |
| |
| @findex STACK_CHECK_PROBE_LOAD |
| @item 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. |
| |
| @findex STACK_CHECK_PROTECT |
| @item 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. |
| |
| @findex STACK_CHECK_MAX_FRAME_SIZE |
| @item 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. |
| |
| @findex STACK_CHECK_FIXED_FRAME_SIZE |
| @item 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. |
| |
| @findex STACK_CHECK_MAX_VAR_SIZE |
| @item 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 |
| @samp{-fstack-check}. |
| GNU CC computed the default from the values of the above macros and you will |
| normally not need to override that default. |
| @end table |
| |
| @need 2000 |
| @node Frame Registers |
| @subsection Registers That Address the Stack Frame |
| |
| @c prevent bad page break with this line |
| This discusses registers that address the stack frame. |
| |
| @table @code |
| @findex STACK_POINTER_REGNUM |
| @item STACK_POINTER_REGNUM |
| The register number of the stack pointer register, which must also be a |
| fixed register according to @code{FIXED_REGISTERS}. On most machines, |
| the hardware determines which register this is. |
| |
| @findex FRAME_POINTER_REGNUM |
| @item 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. |
| |
| @findex HARD_FRAME_POINTER_REGNUM |
| @item HARD_FRAME_POINTER_REGNUM |
| On some machines the offset between the frame pointer and starting |
| offset of the automatic variables is not known until after register |
| allocation has been done (for example, because the saved registers are |
| between these two locations). On those machines, define |
| @code{FRAME_POINTER_REGNUM} the number of a special, fixed register to |
| be used internally until the offset is known, and define |
| @code{HARD_FRAME_POINTER_REGNUM} to be actual the hard register number |
| used for the frame pointer. |
| |
| You should define this macro only in the very rare circumstances when it |
| is not possible to calculate the offset between the frame pointer and |
| the automatic variables until after register allocation has been |
| completed. When this macro is defined, you must also indicate in your |
| definition of @code{ELIMINABLE_REGS} how to eliminate |
| @code{FRAME_POINTER_REGNUM} into either @code{HARD_FRAME_POINTER_REGNUM} |
| or @code{STACK_POINTER_REGNUM}. |
| |
| Do not define this macro if it would be the same as |
| @code{FRAME_POINTER_REGNUM}. |
| |
| @findex ARG_POINTER_REGNUM |
| @item 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 |
| @code{FIXED_REGISTERS}, or arrange to be able to eliminate it |
| (@pxref{Elimination}). |
| |
| @findex RETURN_ADDRESS_POINTER_REGNUM |
| @item RETURN_ADDRESS_POINTER_REGNUM |
| The register number of the return address pointer register, which is used to |
| access the current function's return address from the stack. On some |
| machines, the return address is not at a fixed offset from the frame |
| pointer or stack pointer or argument pointer. This register can be defined |
| to point to the return address on the stack, and then be converted by |
| @code{ELIMINABLE_REGS} into either the frame pointer or stack pointer. |
| |
| Do not define this macro unless there is no other way to get the return |
| address from the stack. |
| |
| @findex STATIC_CHAIN_REGNUM |
| @findex STATIC_CHAIN_INCOMING_REGNUM |
| @item STATIC_CHAIN_REGNUM |
| @itemx STATIC_CHAIN_INCOMING_REGNUM |
| Register numbers used for passing a function's static chain pointer. If |
| register windows are used, the register number as seen by the called |
| function is @code{STATIC_CHAIN_INCOMING_REGNUM}, while the register |
| number as seen by the calling function is @code{STATIC_CHAIN_REGNUM}. If |
| these registers are the same, @code{STATIC_CHAIN_INCOMING_REGNUM} need |
| not be defined.@refill |
| |
| 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. |
| |
| @findex STATIC_CHAIN |
| @findex STATIC_CHAIN_INCOMING |
| @item STATIC_CHAIN |
| @itemx STATIC_CHAIN_INCOMING |
| If the static chain is passed in memory, these macros provide rtx giving |
| @code{mem} expressions that denote where they are stored. |
| @code{STATIC_CHAIN} and @code{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.@refill |
| |
| @findex stack_pointer_rtx |
| @findex frame_pointer_rtx |
| @findex arg_pointer_rtx |
| The variables @code{stack_pointer_rtx}, @code{frame_pointer_rtx}, and |
| @code{arg_pointer_rtx} will have been initialized prior to the use of these |
| macros and should be used to refer to those items. |
| |
| If the static chain is passed in a register, the two previous macros should |
| be defined instead. |
| @end table |
| |
| @node Elimination |
| @subsection Eliminating Frame Pointer and Arg Pointer |
| |
| @c prevent bad page break with this line |
| This is about eliminating the frame pointer and arg pointer. |
| |
| @table @code |
| @findex FRAME_POINTER_REQUIRED |
| @item 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 |
| @code{FRAME_POINTER_REQUIRED} says. You don't need to worry about |
| them.@refill |
| |
| 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 @code{FIXED_REGISTERS} for more information. |
| |
| @findex INITIAL_FRAME_POINTER_OFFSET |
| @findex get_frame_size |
| @item INITIAL_FRAME_POINTER_OFFSET (@var{depth-var}) |
| A C statement to store in the variable @var{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 @code{get_frame_size ()} and the tables of |
| registers @code{regs_ever_live} and @code{call_used_regs}. |
| |
| If @code{ELIMINABLE_REGS} is defined, this macro will be not be used and |
| need not be defined. Otherwise, it must be defined even if |
| @code{FRAME_POINTER_REQUIRED} is defined to always be true; in that |
| case, you may set @var{depth-var} to anything. |
| |
| @findex ELIMINABLE_REGS |
| @item 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: |
| @example |
| #define ELIMINABLE_REGS \ |
| @{@{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM@}, \ |
| @{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM@}, \ |
| @{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM@}@} |
| @end example |
| |
| Note that the elimination of the argument pointer with the stack pointer is |
| specified first since that is the preferred elimination. |
| |
| @findex CAN_ELIMINATE |
| @item CAN_ELIMINATE (@var{from-reg}, @var{to-reg}) |
| A C expression that returns non-zero if the compiler is allowed to try |
| to replace register number @var{from-reg} with register number |
| @var{to-reg}. This macro need only be defined if @code{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. |
| |
| @findex INITIAL_ELIMINATION_OFFSET |
| @item INITIAL_ELIMINATION_OFFSET (@var{from-reg}, @var{to-reg}, @var{offset-var}) |
| This macro is similar to @code{INITIAL_FRAME_POINTER_OFFSET}. It |
| specifies the initial difference between the specified pair of |
| registers. This macro must be defined if @code{ELIMINABLE_REGS} is |
| defined. |
| |
| @findex LONGJMP_RESTORE_FROM_STACK |
| @item LONGJMP_RESTORE_FROM_STACK |
| Define this macro if the @code{longjmp} function restores registers from |
| the stack frames, rather than from those saved specifically by |
| @code{setjmp}. Certain quantities must not be kept in registers across |
| a call to @code{setjmp} on such machines. |
| @end table |
| |
| @node Stack Arguments |
| @subsection Passing Function Arguments on the Stack |
| @cindex arguments on stack |
| @cindex stack arguments |
| |
| 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. |
| |
| @table @code |
| @findex PROMOTE_PROTOTYPES |
| @item PROMOTE_PROTOTYPES |
| Define this macro if an argument declared in a prototype as an |
| integral type smaller than @code{int} should actually be passed as an |
| @code{int}. In addition to avoiding errors in certain cases of |
| mismatch, it also makes for better code on certain machines. |
| |
| @findex PUSH_ROUNDING |
| @item PUSH_ROUNDING (@var{npushed}) |
| A C expression that is the number of bytes actually pushed onto the |
| stack when an instruction attempts to push @var{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 |
| |
| @example |
| #define PUSH_ROUNDING(BYTES) (BYTES) |
| @end example |
| |
| @noindent |
| 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 |
| |
| @example |
| #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) |
| @end example |
| |
| @findex ACCUMULATE_OUTGOING_ARGS |
| @findex current_function_outgoing_args_size |
| @item ACCUMULATE_OUTGOING_ARGS |
| If defined, the maximum amount of space required for outgoing arguments |
| will be computed and placed into the variable |
| @code{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. |
| |
| Defining both @code{PUSH_ROUNDING} and @code{ACCUMULATE_OUTGOING_ARGS} |
| is not proper. |
| |
| @findex REG_PARM_STACK_SPACE |
| @item REG_PARM_STACK_SPACE (@var{fndecl}) |
| 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 for the function represented by @var{fndecl}. |
| |
| This space can be allocated by the caller, or be a part of the |
| machine-dependent stack frame: @code{OUTGOING_REG_PARM_STACK_SPACE} says |
| which. |
| @c above is overfull. not sure what to do. --mew 5feb93 did |
| @c something, not sure if it looks good. --mew 10feb93 |
| |
| @findex MAYBE_REG_PARM_STACK_SPACE |
| @findex FINAL_REG_PARM_STACK_SPACE |
| @item MAYBE_REG_PARM_STACK_SPACE |
| @itemx FINAL_REG_PARM_STACK_SPACE (@var{const_size}, @var{var_size}) |
| Define these macros in addition to the one above if functions might |
| allocate stack space for arguments even when their values are passed |
| in registers. These should be used when the stack space allocated |
| for arguments in registers is not a simple constant independent of the |
| function declaration. |
| |
| The value of the first macro is the size, in bytes, of the area that |
| we should initially assume would be reserved for arguments passed in registers. |
| |
| The value of the second macro is the actual size, in bytes, of the area |
| that will be reserved for arguments passed in registers. This takes two |
| arguments: an integer representing the number of bytes of fixed sized |
| arguments on the stack, and a tree representing the number of bytes of |
| variable sized arguments on the stack. |
| |
| When these macros are defined, @code{REG_PARM_STACK_SPACE} will only be |
| called for libcall functions, the current function, or for a function |
| being called when it is known that such stack space must be allocated. |
| In each case this value can be easily computed. |
| |
| When deciding whether a called function needs such stack space, and how |
| much space to reserve, GNU CC uses these two macros instead of |
| @code{REG_PARM_STACK_SPACE}. |
| |
| @findex OUTGOING_REG_PARM_STACK_SPACE |
| @item 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 @code{ACCUMULATE_OUTGOING_ARGS} is defined, this macro controls |
| whether the space for these arguments counts in the value of |
| @code{current_function_outgoing_args_size}. |
| |
| @findex STACK_PARMS_IN_REG_PARM_AREA |
| @item STACK_PARMS_IN_REG_PARM_AREA |
| Define this macro if @code{REG_PARM_STACK_SPACE} is defined, but the |
| stack parameters don't skip the area specified by it. |
| @c i changed this, makes more sens and it should have taken care of the |
| @c overfull.. not as specific, tho. --mew 5feb93 |
| |
| Normally, when a parameter is not passed in registers, it is placed on the |
| stack beyond the @code{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. |
| |
| @findex RETURN_POPS_ARGS |
| @item RETURN_POPS_ARGS (@var{fundecl}, @var{funtype}, @var{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. |
| |
| @var{fundecl} is a C variable whose value is a tree node that describes |
| the function in question. Normally it is a node of type |
| @code{FUNCTION_DECL} that describes the declaration of the function. |
| From this you can obtain the DECL_MACHINE_ATTRIBUTES of the function. |
| |
| @var{funtype} is a C variable whose value is a tree node that |
| describes the function in question. Normally it is a node of type |
| @code{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, @var{fundecl} |
| 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. |
| |
| @var{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. |
| |
| On the Vax, all functions always pop their arguments, so the definition |
| of this macro is @var{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 @code{printf}) pop |
| nothing (the caller pops all). When this convention is in use, |
| @var{funtype} is examined to determine whether a function takes a fixed |
| number of arguments. |
| @end table |
| |
| @node Register Arguments |
| @subsection Passing Arguments in Registers |
| @cindex arguments in registers |
| @cindex registers arguments |
| |
| 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. |
| |
| @table @code |
| @findex FUNCTION_ARG |
| @item FUNCTION_ARG (@var{cum}, @var{mode}, @var{type}, @var{named}) |
| A C expression that controls whether a function argument is passed |
| in a register, and which register. |
| |
| The arguments are @var{cum}, which summarizes all the previous |
| arguments; @var{mode}, the machine mode of the argument; @var{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 @var{named}, |
| which is 1 for an ordinary argument and 0 for nameless arguments that |
| correspond to @samp{@dots{}} in the called function's prototype. |
| |
| The value of the expression is usually either a @code{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 value of the expression can also be a @code{parallel} RTX. This is |
| used when an argument is passed in multiple locations. The mode of the |
| of the @code{parallel} should be the mode of the entire argument. The |
| @code{parallel} holds any number of @code{expr_list} pairs; each one |
| describes where part of the argument is passed. In each @code{expr_list}, |
| the first operand can be either a @code{reg} RTX for the hard register |
| in which to pass this part of the argument, or zero to pass the argument |
| on the stack. If this operand is a @code{reg}, then the mode indicates |
| how large this part of the argument is. The second operand of the |
| @code{expr_list} is a @code{const_int} which gives the offset in bytes |
| into the entire argument where this part starts. |
| |
| @cindex @file{stdarg.h} and register arguments |
| The usual way to make the ANSI library @file{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 @code{FUNCTION_ARG} return 0 whenever @var{named} is 0. |
| |
| @cindex @code{MUST_PASS_IN_STACK}, and @code{FUNCTION_ARG} |
| @cindex @code{REG_PARM_STACK_SPACE}, and @code{FUNCTION_ARG} |
| You may use the macro @code{MUST_PASS_IN_STACK (@var{mode}, @var{type})} |
| in the definition of this macro to determine if this argument is of a |
| type that must be passed in the stack. If @code{REG_PARM_STACK_SPACE} |
| is not defined and @code{FUNCTION_ARG} returns non-zero for such an |
| argument, the compiler will abort. If @code{REG_PARM_STACK_SPACE} is |
| defined, the argument will be computed in the stack and then loaded into |
| a register. |
| |
| @findex FUNCTION_INCOMING_ARG |
| @item FUNCTION_INCOMING_ARG (@var{cum}, @var{mode}, @var{type}, @var{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, @code{FUNCTION_ARG} computes the register in which |
| the caller passes the value, and @code{FUNCTION_INCOMING_ARG} should |
| be defined in a similar fashion to tell the function being called |
| where the arguments will arrive. |
| |
| If @code{FUNCTION_INCOMING_ARG} is not defined, @code{FUNCTION_ARG} |
| serves both purposes.@refill |
| |
| @findex FUNCTION_ARG_PARTIAL_NREGS |
| @item FUNCTION_ARG_PARTIAL_NREGS (@var{cum}, @var{mode}, @var{type}, @var{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 @var{n} words of arguments are passed in registers, and the rest |
| on the stack. If a multi-word argument (a @code{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. |
| |
| @code{FUNCTION_ARG} for these arguments should return the first |
| register to be used by the caller for this argument; likewise |
| @code{FUNCTION_INCOMING_ARG}, for the called function. |
| |
| @findex FUNCTION_ARG_PASS_BY_REFERENCE |
| @item FUNCTION_ARG_PASS_BY_REFERENCE (@var{cum}, @var{mode}, @var{type}, @var{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 @code{REG_PARM_STACK_SPACE} is not defined, a suitable |
| definition of this macro might be |
| @smallexample |
| #define FUNCTION_ARG_PASS_BY_REFERENCE\ |
| (CUM, MODE, TYPE, NAMED) \ |
| MUST_PASS_IN_STACK (MODE, TYPE) |
| @end smallexample |
| @c this is *still* too long. --mew 5feb93 |
| |
| @findex FUNCTION_ARG_CALLEE_COPIES |
| @item FUNCTION_ARG_CALLEE_COPIES (@var{cum}, @var{mode}, @var{type}, @var{named}) |
| If defined, a C expression that indicates when it is the called function's |
| responsibility to make a copy of arguments passed by invisible reference. |
| Normally, the caller makes a copy and passes the address of the copy to the |
| routine being called. When FUNCTION_ARG_CALLEE_COPIES is defined and is |
| nonzero, the caller does not make a copy. Instead, it passes a pointer to the |
| ``live'' value. The called function must not modify this value. If it can be |
| determined that the value won't be modified, it need not make a copy; |
| otherwise a copy must be made. |
| |
| @findex CUMULATIVE_ARGS |
| @item CUMULATIVE_ARGS |
| A C type for declaring a variable that is used as the first argument of |
| @code{FUNCTION_ARG} and other related values. For some target machines, |
| the type @code{int} suffices and can hold the number of bytes of |
| argument so far. |
| |
| There is no need to record in @code{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 |
| @code{CUMULATIVE_ARGS}; however, the data structure must exist and |
| should not be empty, so use @code{int}. |
| |
| @findex INIT_CUMULATIVE_ARGS |
| @item INIT_CUMULATIVE_ARGS (@var{cum}, @var{fntype}, @var{libname}, @var{indirect}) |
| A C statement (sans semicolon) for initializing the variable @var{cum} |
| for the state at the beginning of the argument list. The variable has |
| type @code{CUMULATIVE_ARGS}. The value of @var{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. The value of |
| @var{indirect} is nonzero when processing an indirect call, for example |
| a call through a function pointer. The value of @var{indirect} is zero |
| for a call to an explicitly named function, a library function call, or when |
| @code{INIT_CUMULATIVE_ARGS} is used to find arguments for the function |
| being compiled. |
| |
| When processing a call to a compiler support library function, |
| @var{libname} identifies which one. It is a @code{symbol_ref} rtx which |
| contains the name of the function, as a string. @var{libname} is 0 when |
| an ordinary C function call is being processed. Thus, each time this |
| macro is called, either @var{libname} or @var{fntype} is nonzero, but |
| never both of them at once. |
| |
| @findex INIT_CUMULATIVE_INCOMING_ARGS |
| @item INIT_CUMULATIVE_INCOMING_ARGS (@var{cum}, @var{fntype}, @var{libname}) |
| Like @code{INIT_CUMULATIVE_ARGS} but overrides it for the purposes of |
| finding the arguments for the function being compiled. If this macro is |
| undefined, @code{INIT_CUMULATIVE_ARGS} is used instead. |
| |
| The value passed for @var{libname} is always 0, since library routines |
| with special calling conventions are never compiled with GNU CC. The |
| argument @var{libname} exists for symmetry with |
| @code{INIT_CUMULATIVE_ARGS}. |
| @c could use "this macro" in place of @code{INIT_CUMULATIVE_ARGS}, maybe. |
| @c --mew 5feb93 i switched the order of the sentences. --mew 10feb93 |
| |
| @findex FUNCTION_ARG_ADVANCE |
| @item FUNCTION_ARG_ADVANCE (@var{cum}, @var{mode}, @var{type}, @var{named}) |
| A C statement (sans semicolon) to update the summarizer variable |
| @var{cum} to advance past an argument in the argument list. The |
| values @var{mode}, @var{type} and @var{named} describe that argument. |
| Once this is done, the variable @var{cum} is suitable for analyzing |
| the @emph{following} argument with @code{FUNCTION_ARG}, etc.@refill |
| |
| 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. |
| |
| @findex FUNCTION_ARG_PADDING |
| @item FUNCTION_ARG_PADDING (@var{mode}, @var{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 |
| @code{enum direction}: either @code{upward} to pad above the argument, |
| @code{downward} to pad below, or @code{none} to inhibit padding. |
| |
| The @emph{amount} of padding is always just enough to reach the next |
| multiple of @code{FUNCTION_ARG_BOUNDARY}; this macro does not control |
| it. |
| |
| 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 @code{int}, and upward otherwise. |
| |
| @findex FUNCTION_ARG_BOUNDARY |
| @item FUNCTION_ARG_BOUNDARY (@var{mode}, @var{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, |
| @code{PARM_BOUNDARY} is used for all arguments. |
| |
| @findex FUNCTION_ARG_REGNO_P |
| @item FUNCTION_ARG_REGNO_P (@var{regno}) |
| A C expression that is nonzero if @var{regno} is the number of a hard |
| register in which function arguments are sometimes passed. This does |
| @emph{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. |
| @end table |
| |
| @node Scalar Return |
| @subsection How Scalar Function Values Are Returned |
| @cindex return values in registers |
| @cindex values, returned by functions |
| @cindex scalars, returned as values |
| |
| This section discusses the macros that control returning scalars as |
| values---values that can fit in registers. |
| |
| @table @code |
| @findex TRADITIONAL_RETURN_FLOAT |
| @item TRADITIONAL_RETURN_FLOAT |
| Define this macro if @samp{-traditional} should not cause functions |
| declared to return @code{float} to convert the value to @code{double}. |
| |
| @findex FUNCTION_VALUE |
| @item FUNCTION_VALUE (@var{valtype}, @var{func}) |
| A C expression to create an RTX representing the place where a |
| function returns a value of data type @var{valtype}. @var{valtype} is |
| a tree node representing a data type. Write @code{TYPE_MODE |
| (@var{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).@refill |
| |
| The value of the expression is usually a @code{reg} RTX for the hard |
| register where the return value is stored. The value can also be a |
| @code{parallel} RTX, if the return value is in multiple places. See |
| @code{FUNCTION_ARG} for an explanation of the @code{parallel} form. |
| |
| If @code{PROMOTE_FUNCTION_RETURN} is defined, you must apply the same |
| promotion rules specified in @code{PROMOTE_MODE} if @var{valtype} is a |
| scalar type. |
| |
| If the precise function being called is known, @var{func} is a tree |
| node (@code{FUNCTION_DECL}) for it; otherwise, @var{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.@refill |
| |
| @code{FUNCTION_VALUE} is not used for return vales with aggregate data |
| types, because these are returned in another way. See |
| @code{STRUCT_VALUE_REGNUM} and related macros, below. |
| |
| @findex FUNCTION_OUTGOING_VALUE |
| @item FUNCTION_OUTGOING_VALUE (@var{valtype}, @var{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, @code{FUNCTION_VALUE} computes the register in which |
| the caller will see the value. @code{FUNCTION_OUTGOING_VALUE} should be |
| defined in a similar fashion to tell the function where to put the |
| value.@refill |
| |
| If @code{FUNCTION_OUTGOING_VALUE} is not defined, |
| @code{FUNCTION_VALUE} serves both purposes.@refill |
| |
| @code{FUNCTION_OUTGOING_VALUE} is not used for return vales with |
| aggregate data types, because these are returned in another way. See |
| @code{STRUCT_VALUE_REGNUM} and related macros, below. |
| |
| @findex LIBCALL_VALUE |
| @item LIBCALL_VALUE (@var{mode}) |
| A C expression to create an RTX representing the place where a library |
| function returns a value of mode @var{mode}. If the precise function |
| being called is known, @var{func} is a tree node |
| (@code{FUNCTION_DECL}) for it; otherwise, @var{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.@refill |
| |
| 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 @code{LIBRARY_VALUE} need not be concerned aggregate |
| data types, because none of the library functions returns such types. |
| |
| @findex FUNCTION_VALUE_REGNO_P |
| @item FUNCTION_VALUE_REGNO_P (@var{regno}) |
| A C expression that is nonzero if @var{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 @code{double}, say) need not be |
| recognized by this macro. So for most machines, this definition |
| suffices: |
| |
| @example |
| #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) |
| @end example |
| |
| 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. |
| |
| @findex APPLY_RESULT_SIZE |
| @item APPLY_RESULT_SIZE |
| Define this macro if @samp{untyped_call} and @samp{untyped_return} |
| need more space than is implied by @code{FUNCTION_VALUE_REGNO_P} for |
| saving and restoring an arbitrary return value. |
| @end table |
| |
| @node Aggregate Return |
| @subsection How Large Values Are Returned |
| @cindex aggregates as return values |
| @cindex large return values |
| @cindex returning aggregate values |
| @cindex structure value address |
| |
| When a function value's mode is @code{BLKmode} (and in some other |
| cases), the value is not returned according to @code{FUNCTION_VALUE} |
| (@pxref{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 @dfn{structure value address}. |
| |
| This section describes how to control returning structure values in |
| memory. |
| |
| @table @code |
| @findex RETURN_IN_MEMORY |
| @item RETURN_IN_MEMORY (@var{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 @var{type} will be a C expression of type |
| @code{tree}, representing the data type of the value. |
| |
| Note that values of mode @code{BLKmode} must be explicitly handled |
| by this macro. Also, the option @samp{-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 1 for @code{BLKmode} |
| values, and 0 otherwise. |
| |
| Do not use this macro to indicate that structures and unions should always |
| be returned in memory. You should instead use @code{DEFAULT_PCC_STRUCT_RETURN} |
| to indicate this. |
| |
| @findex DEFAULT_PCC_STRUCT_RETURN |
| @item DEFAULT_PCC_STRUCT_RETURN |
| Define this macro to be 1 if all structure and union return values must be |
| in memory. Since this results in slower code, this should be defined |
| only if needed for compatibility with other compilers or with an ABI. |
| If you define this macro to be 0, then the conventions used for structure |
| and union return values are decided by the @code{RETURN_IN_MEMORY} macro. |
| |
| If not defined, this defaults to the value 1. |
| |
| @findex STRUCT_VALUE_REGNUM |
| @item STRUCT_VALUE_REGNUM |
| If the structure value address is passed in a register, then |
| @code{STRUCT_VALUE_REGNUM} should be the number of that register. |
| |
| @findex STRUCT_VALUE |
| @item STRUCT_VALUE |
| If the structure value address is not passed in a register, define |
| @code{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. |
| |
| @findex STRUCT_VALUE_INCOMING_REGNUM |
| @item 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. |
| |
| @findex STRUCT_VALUE_INCOMING |
| @item STRUCT_VALUE_INCOMING |
| If the incoming location is not a register, then you should define |
| @code{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 @code{mem} which refers to the frame |
| pointer. A definition of 0 means that the address is passed as an |
| ``invisible'' first argument. |
| |
| @findex PCC_STATIC_STRUCT_RETURN |
| @item 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. |
| |
| Do not define this if the usual system convention is for the caller to |
| pass an address to the subroutine. |
| |
| This macro has effect in @samp{-fpcc-struct-return} mode, but it does |
| nothing when you use @samp{-freg-struct-return} mode. |
| @end table |
| |
| @node Caller Saves |
| @subsection Caller-Saves Register Allocation |
| |
| 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. |
| |
| @table @code |
| @findex DEFAULT_CALLER_SAVES |
| @item DEFAULT_CALLER_SAVES |
| Define this macro if function calls on the target machine do not preserve |
| any registers; in other words, if @code{CALL_USED_REGISTERS} has 1 |
| for all registers. This macro enables @samp{-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. |
| |
| @findex CALLER_SAVE_PROFITABLE |
| @item CALLER_SAVE_PROFITABLE (@var{refs}, @var{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. |
| |
| If you don't define this macro, a default is used which is good on most |
| machines: @code{4 * @var{calls} < @var{refs}}. |
| @end table |
| |
| @node Function Entry |
| @subsection Function Entry and Exit |
| @cindex function entry and exit |
| @cindex prologue |
| @cindex epilogue |
| |
| This section describes the macros that output function entry |
| (@dfn{prologue}) and exit (@dfn{epilogue}) code. |
| |
| @table @code |
| @findex FUNCTION_PROLOGUE |
| @item FUNCTION_PROLOGUE (@var{file}, @var{size}) |
| A C compound statement that outputs the assembler code for entry to a |
| function. The prologue is responsible for setting up the stack frame, |
| initializing the frame pointer register, saving registers that must be |
| saved, and allocating @var{size} additional bytes of storage for the |
| local variables. @var{size} is an integer. @var{file} is a stdio |
| stream to which the assembler code should be output. |
| |
| The label for the beginning of the function need not be output by this |
| macro. That has already been done when the macro is run. |
| |
| @findex regs_ever_live |
| To determine which registers to save, the macro can refer to the array |
| @code{regs_ever_live}: element @var{r} is nonzero if hard register |
| @var{r} is used anywhere within the function. This implies the function |
| prologue should save register @var{r}, provided it is not one of the |
| call-used registers. (@code{FUNCTION_EPILOGUE} must likewise use |
| @code{regs_ever_live}.) |
| |
| On machines that have ``register windows'', the function entry code does |
| not save on the stack the registers that are in the windows, even if |
| they are supposed to be preserved by function calls; instead it takes |
| appropriate steps to ``push'' the register stack, if any non-call-used |
| registers are used in the function. |
| |
| @findex frame_pointer_needed |
| On machines where functions may or may not have frame-pointers, the |
| function entry code must vary accordingly; it must set up the frame |
| pointer if one is wanted, and not otherwise. To determine whether a |
| frame pointer is in wanted, the macro can refer to the variable |
| @code{frame_pointer_needed}. The variable's value will be 1 at run |
| time in a function that needs a frame pointer. @xref{Elimination}. |
| |
| The function entry code is responsible for allocating any stack space |
| required for the function. This stack space consists of the regions |
| listed below. In most cases, these regions are allocated in the |
| order listed, with the last listed region closest to the top of the |
| stack (the lowest address if @code{STACK_GROWS_DOWNWARD} is defined, and |
| the highest address if it is not defined). You can use a different order |
| for a machine if doing so is more convenient or required for |
| compatibility reasons. Except in cases where required by standard |
| or by a debugger, there is no reason why the stack layout used by GCC |
| need agree with that used by other compilers for a machine. |
| |
| @itemize @bullet |
| @item |
| @findex current_function_pretend_args_size |
| A region of @code{current_function_pretend_args_size} bytes of |
| uninitialized space just underneath the first argument arriving on the |
| stack. (This may not be at the very start of the allocated stack region |
| if the calling sequence has pushed anything else since pushing the stack |
| arguments. But usually, on such machines, nothing else has been pushed |
| yet, because the function prologue itself does all the pushing.) This |
| region is used on machines where an argument may be passed partly in |
| registers and partly in memory, and, in some cases to support the |
| features in @file{varargs.h} and @file{stdargs.h}. |
| |
| @item |
| An area of memory used to save certain registers used by the function. |
| The size of this area, which may also include space for such things as |
| the return address and pointers to previous stack frames, is |
| machine-specific and usually depends on which registers have been used |
| in the function. Machines with register windows often do not require |
| a save area. |
| |
| @item |
| A region of at least @var{size} bytes, possibly rounded up to an allocation |
| boundary, to contain the local variables of the function. On some machines, |
| this region and the save area may occur in the opposite order, with the |
| save area closer to the top of the stack. |
| |
| @item |
| @cindex @code{ACCUMULATE_OUTGOING_ARGS} and stack frames |
| Optionally, when @code{ACCUMULATE_OUTGOING_ARGS} is defined, a region of |
| @code{current_function_outgoing_args_size} bytes to be used for outgoing |
| argument lists of the function. @xref{Stack Arguments}. |
| @end itemize |
| |
| Normally, it is necessary for the macros @code{FUNCTION_PROLOGUE} and |
| @code{FUNCTION_EPILOGUE} to treat leaf functions specially. The C |
| variable @code{leaf_function} is nonzero for such a function. |
| |
| @findex EXIT_IGNORE_STACK |
| @item EXIT_IGNORE_STACK |
| Define this macro as a C expression that is nonzero if the return |
| instruction or the function epilogue ignores the value of the stack |
| pointer; in other words, if it is safe to delete an instruction to |
| adjust the stack pointer before a return from the function. |
| |
| Note that this macro's value is relevant only for functions for which |
| frame pointers are maintained. It is never safe to delete a final |
| stack adjustment in a function that has no frame pointer, and the |
| compiler knows this regardless of @code{EXIT_IGNORE_STACK}. |
| |
| @findex EPILOGUE_USES |
| @item EPILOGUE_USES (@var{regno}) |
| Define this macro as a C expression that is nonzero for registers are |
| used by the epilogue or the @samp{return} pattern. The stack and frame |
| pointer registers are already be assumed to be used as needed. |
| |
| @findex FUNCTION_EPILOGUE |
| @item FUNCTION_EPILOGUE (@var{file}, @var{size}) |
| A C compound statement that outputs the assembler code for exit from a |
| function. The epilogue is responsible for restoring the saved |
| registers and stack pointer to their values when the function was |
| called, and returning control to the caller. This macro takes the |
| same arguments as the macro @code{FUNCTION_PROLOGUE}, and the |
| registers to restore are determined from @code{regs_ever_live} and |
| @code{CALL_USED_REGISTERS} in the same way. |
| |
| On some machines, there is a single instruction that does all the work |
| of returning from the function. On these machines, give that |
| instruction the name @samp{return} and do not define the macro |
| @code{FUNCTION_EPILOGUE} at all. |
| |
| Do not define a pattern named @samp{return} if you want the |
| @code{FUNCTION_EPILOGUE} to be used. If you want the target switches |
| to control whether return instructions or epilogues are used, define a |
| @samp{return} pattern with a validity condition that tests the target |
| switches appropriately. If the @samp{return} pattern's validity |
| condition is false, epilogues will be used. |
| |
| On machines where functions may or may not have frame-pointers, the |
| function exit code must vary accordingly. Sometimes the code for these |
| two cases is completely different. To determine whether a frame pointer |
| is wanted, the macro can refer to the variable |
| @code{frame_pointer_needed}. The variable's value will be 1 when compiling |
| a function that needs a frame pointer. |
| |
| Normally, @code{FUNCTION_PROLOGUE} and @code{FUNCTION_EPILOGUE} must |
| treat leaf functions specially. The C variable @code{leaf_function} is |
| nonzero for such a function. @xref{Leaf Functions}. |
| |
| On some machines, some functions pop their arguments on exit while |
| others leave that for the caller to do. For example, the 68020 when |
| given @samp{-mrtd} pops arguments in functions that take a fixed |
| number of arguments. |
| |
| @findex current_function_pops_args |
| Your definition of the macro @code{RETURN_POPS_ARGS} decides which |
| functions pop their own arguments. @code{FUNCTION_EPILOGUE} needs to |
| know what was decided. The variable that is called |
| @code{current_function_pops_args} is the number of bytes of its |
| arguments that a function should pop. @xref{Scalar Return}. |
| @c what is the "its arguments" in the above sentence referring to, pray |
| @c tell? --mew 5feb93 |
| |
| @findex DELAY_SLOTS_FOR_EPILOGUE |
| @item DELAY_SLOTS_FOR_EPILOGUE |
| Define this macro if the function epilogue contains delay slots to which |
| instructions from the rest of the function can be ``moved''. The |
| definition should be a C expression whose value is an integer |
| representing the number of delay slots there. |
| |
| @findex ELIGIBLE_FOR_EPILOGUE_DELAY |
| @item ELIGIBLE_FOR_EPILOGUE_DELAY (@var{insn}, @var{n}) |
| A C expression that returns 1 if @var{insn} can be placed in delay |
| slot number @var{n} of the epilogue. |
| |
| The argument @var{n} is an integer which identifies the delay slot now |
| being considered (since different slots may have different rules of |
| eligibility). It is never negative and is always less than the number |
| of epilogue delay slots (what @code{DELAY_SLOTS_FOR_EPILOGUE} returns). |
| If you reject a particular insn for a given delay slot, in principle, it |
| may be reconsidered for a subsequent delay slot. Also, other insns may |
| (at least in principle) be considered for the so far unfilled delay |
| slot. |
| |
| @findex current_function_epilogue_delay_list |
| @findex final_scan_insn |
| The insns accepted to fill the epilogue delay slots are put in an RTL |
| list made with @code{insn_list} objects, stored in the variable |
| @code{current_function_epilogue_delay_list}. The insn for the first |
| delay slot comes first in the list. Your definition of the macro |
| @code{FUNCTION_EPILOGUE} should fill the delay slots by outputting the |
| insns in this list, usually by calling @code{final_scan_insn}. |
| |
| You need not define this macro if you did not define |
| @code{DELAY_SLOTS_FOR_EPILOGUE}. |
| |
| @findex ASM_OUTPUT_MI_THUNK |
| @item ASM_OUTPUT_MI_THUNK (@var{file}, @var{thunk_fndecl}, @var{delta}, @var{function}) |
| A C compound statement that outputs the assembler code for a thunk |
| function, used to implement C++ virtual function calls with multiple |
| inheritance. The thunk acts as a wrapper around a virtual function, |
| adjusting the implicit object parameter before handing control off to |
| the real function. |
| |
| First, emit code to add the integer @var{delta} to the location that |
| contains the incoming first argument. Assume that this argument |
| contains a pointer, and is the one used to pass the @code{this} pointer |
| in C++. This is the incoming argument @emph{before} the function prologue, |
| e.g. @samp{%o0} on a sparc. The addition must preserve the values of |
| all other incoming arguments. |
| |
| After the addition, emit code to jump to @var{function}, which is a |
| @code{FUNCTION_DECL}. This is a direct pure jump, not a call, and does |
| not touch the return address. Hence returning from @var{FUNCTION} will |
| return to whoever called the current @samp{thunk}. |
| |
| The effect must be as if @var{function} had been called directly with |
| the adjusted first argument. This macro is responsible for emitting all |
| of the code for a thunk function; @code{FUNCTION_PROLOGUE} and |
| @code{FUNCTION_EPILOGUE} are not invoked. |
| |
| The @var{thunk_fndecl} is redundant. (@var{delta} and @var{function} |
| have already been extracted from it.) It might possibly be useful on |
| some targets, but probably not. |
| |
| If you do not define this macro, the target-independent code in the C++ |
| frontend will generate a less efficient heavyweight thunk that calls |
| @var{function} instead of jumping to it. The generic approach does |
| not support varargs. |
| @end table |
| |
| @node Profiling |
| @subsection Generating Code for Profiling |
| @cindex profiling, code generation |
| |
| These macros will help you generate code for profiling. |
| |
| @table @code |
| @findex FUNCTION_PROFILER |
| @item FUNCTION_PROFILER (@var{file}, @var{labelno}) |
| A C statement or compound statement to output to @var{file} some |
| assembler code to call the profiling subroutine @code{mcount}. |
| Before calling, the assembler code must load the address of a |
| counter variable into a register where @code{mcount} expects to |
| find the address. The name of this variable is @samp{LP} followed |
| by the number @var{labelno}, so you would generate the name using |
| @samp{LP%d} in a @code{fprintf}. |
| |
| @findex mcount |
| The details of how the address should be passed to @code{mcount} are |
| determined by your operating system environment, not by GNU CC. To |
| figure them out, compile a small program for profiling using the |
| system's installed C compiler and look at the assembler code that |
| results. |
| |
| @findex PROFILE_BEFORE_PROLOGUE |
| @item PROFILE_BEFORE_PROLOGUE |
| Define this macro if the code for function profiling should come before |
| the function prologue. Normally, the profiling code comes after. |
| |
| @findex FUNCTION_BLOCK_PROFILER |
| @vindex profile_block_flag |
| @item FUNCTION_BLOCK_PROFILER (@var{file}, @var{labelno}) |
| A C statement or compound statement to output to @var{file} some |
| assembler code to initialize basic-block profiling for the current |
| object module. The global compile flag @code{profile_block_flag} |
| distinguishes two profile modes. |
| |
| @table @code |
| @findex __bb_init_func |
| @item profile_block_flag != 2 |
| Output code to call the subroutine @code{__bb_init_func} once per |
| object module, passing it as its sole argument the address of a block |
| allocated in the object module. |
| |
| The name of the block is a local symbol made with this statement: |
| |
| @smallexample |
| ASM_GENERATE_INTERNAL_LABEL (@var{buffer}, "LPBX", 0); |
| @end smallexample |
| |
| Of course, since you are writing the definition of |
| @code{ASM_GENERATE_INTERNAL_LABEL} as well as that of this macro, you |
| can take a short cut in the definition of this macro and use the name |
| that you know will result. |
| |
| The first word of this block is a flag which will be nonzero if the |
| object module has already been initialized. So test this word first, |
| and do not call @code{__bb_init_func} if the flag is |
| nonzero. BLOCK_OR_LABEL contains a unique number which may be used to |
| generate a label as a branch destination when @code{__bb_init_func} |
| will not be called. |
| |
| Described in assembler language, the code to be output looks like: |
| |
| @example |
| cmp (LPBX0),0 |
| bne local_label |
| parameter1 <- LPBX0 |
| call __bb_init_func |
| local_label: |
| @end example |
| |
| @findex __bb_init_trace_func |
| @item profile_block_flag == 2 |
| Output code to call the subroutine @code{__bb_init_trace_func} |
| and pass two parameters to it. The first parameter is the same as |
| for @code{__bb_init_func}. The second parameter is the number of the |
| first basic block of the function as given by BLOCK_OR_LABEL. Note |
| that @code{__bb_init_trace_func} has to be called, even if the object |
| module has been initialized already. |
| |
| Described in assembler language, the code to be output looks like: |
| @example |
| parameter1 <- LPBX0 |
| parameter2 <- BLOCK_OR_LABEL |
| call __bb_init_trace_func |
| @end example |
| @end table |
| |
| @findex BLOCK_PROFILER |
| @vindex profile_block_flag |
| @item BLOCK_PROFILER (@var{file}, @var{blockno}) |
| A C statement or compound statement to output to @var{file} some |
| assembler code to increment the count associated with the basic |
| block number @var{blockno}. The global compile flag |
| @code{profile_block_flag} distinguishes two profile modes. |
| |
| @table @code |
| @item profile_block_flag != 2 |
| Output code to increment the counter directly. Basic blocks are |
| numbered separately from zero within each compilation. The count |
| associated with block number @var{blockno} is at index |
| @var{blockno} in a vector of words; the name of this array is a local |
| symbol made with this statement: |
| |
| @smallexample |
| ASM_GENERATE_INTERNAL_LABEL (@var{buffer}, "LPBX", 2); |
| @end smallexample |
| |
| @c This paragraph is the same as one a few paragraphs up. |
| @c That is not an error. |
| Of course, since you are writing the definition of |
| @code{ASM_GENERATE_INTERNAL_LABEL} as well as that of this macro, you |
| can take a short cut in the definition of this macro and use the name |
| that you know will result. |
| |
| Described in assembler language, the code to be output looks like: |
| |
| @smallexample |
| inc (LPBX2+4*BLOCKNO) |
| @end smallexample |
| |
| @vindex __bb |
| @findex __bb_trace_func |
| @item profile_block_flag == 2 |
| Output code to initialize the global structure @code{__bb} and |
| call the function @code{__bb_trace_func}, which will increment the |
| counter. |
| |
| @code{__bb} consists of two words. In the first word, the current |
| basic block number, as given by BLOCKNO, has to be stored. In |
| the second word, the address of a block allocated in the object |
| module has to be stored. The address is given by the label created |
| with this statement: |
| |
| @smallexample |
| ASM_GENERATE_INTERNAL_LABEL (@var{buffer}, "LPBX", 0); |
| @end smallexample |
| |
| Described in assembler language, the code to be output looks like: |
| @example |
| move BLOCKNO -> (__bb) |
| move LPBX0 -> (__bb+4) |
| call __bb_trace_func |
| @end example |
| @end table |
| |
| @findex FUNCTION_BLOCK_PROFILER_EXIT |
| @findex __bb_trace_ret |
| @vindex profile_block_flag |
| @item FUNCTION_BLOCK_PROFILER_EXIT (@var{file}) |
| A C statement or compound statement to output to @var{file} |
| assembler code to call function @code{__bb_trace_ret}. The |
| assembler code should only be output |
| if the global compile flag @code{profile_block_flag} == 2. This |
| macro has to be used at every place where code for returning from |
| a function is generated (e.g. @code{FUNCTION_EPILOGUE}). Although |
| you have to write the definition of @code{FUNCTION_EPILOGUE} |
| as well, you have to define this macro to tell the compiler, that |
| the proper call to @code{__bb_trace_ret} is produced. |
| |
| @findex MACHINE_STATE_SAVE |
| @findex __bb_init_trace_func |
| @findex __bb_trace_func |
| @findex __bb_trace_ret |
| @item MACHINE_STATE_SAVE (@var{id}) |
| A C statement or compound statement to save all registers, which may |
| be clobbered by a function call, including condition codes. The |
| @code{asm} statement will be mostly likely needed to handle this |
| task. Local labels in the assembler code can be concatenated with the |
| string @var{id}, to obtain a unique lable name. |
| |
| Registers or condition codes clobbered by @code{FUNCTION_PROLOGUE} or |
| @code{FUNCTION_EPILOGUE} must be saved in the macros |
| @code{FUNCTION_BLOCK_PROFILER}, @code{FUNCTION_BLOCK_PROFILER_EXIT} and |
| @code{BLOCK_PROFILER} prior calling @code{__bb_init_trace_func}, |
| @code{__bb_trace_ret} and @code{__bb_trace_func} respectively. |
| |
| @findex MACHINE_STATE_RESTORE |
| @findex __bb_init_trace_func |
| @findex __bb_trace_func |
| @findex __bb_trace_ret |
| @item MACHINE_STATE_RESTORE (@var{id}) |
| A C statement or compound statement to restore all registers, including |
| condition codes, saved by @code{MACHINE_STATE_SAVE}. |
| |
| Registers or condition codes clobbered by @code{FUNCTION_PROLOGUE} or |
| @code{FUNCTION_EPILOGUE} must be restored in the macros |
| @code{FUNCTION_BLOCK_PROFILER}, @code{FUNCTION_BLOCK_PROFILER_EXIT} and |
| @code{BLOCK_PROFILER} after calling @code{__bb_init_trace_func}, |
| @code{__bb_trace_ret} and @code{__bb_trace_func} respectively. |
| |
| @findex BLOCK_PROFILER_CODE |
| @item BLOCK_PROFILER_CODE |
| A C function or functions which are needed in the library to |
| support block profiling. |
| @end table |
| |
| @node Varargs |
| @section Implementing the Varargs Macros |
| @cindex varargs implementation |
| |
| GNU CC comes with an implementation of @file{varargs.h} and |
| @file{stdarg.h} that work without change on machines that pass arguments |
| on the stack. Other machines require their own implementations of |
| varargs, and the two machine independent header files must have |
| conditionals to include it. |
| |
| ANSI @file{stdarg.h} differs from traditional @file{varargs.h} mainly in |
| the calling convention for @code{va_start}. The traditional |
| implementation takes just one argument, which is the variable in which |
| to store the argument pointer. The ANSI implementation of |
| @code{va_start} takes an additional second argument. The user is |
| supposed to write the last named argument of the function here. |
| |
| However, @code{va_start} should not use this argument. The way to find |
| the end of the named arguments is with the built-in functions described |
| below. |
| |
| @table @code |
| @findex __builtin_saveregs |
| @item __builtin_saveregs () |
| Use this built-in function to save the argument registers in memory so |
| that the varargs mechanism can access them. Both ANSI and traditional |
| versions of @code{va_start} must use @code{__builtin_saveregs}, unless |
| you use @code{SETUP_INCOMING_VARARGS} (see below) instead. |
| |
| On some machines, @code{__builtin_saveregs} is open-coded under the |
| control of the macro @code{EXPAND_BUILTIN_SAVEREGS}. On other machines, |
| it calls a routine written in assembler language, found in |
| @file{libgcc2.c}. |
| |
| Code generated for the call to @code{__builtin_saveregs} appears at the |
| beginning of the function, as opposed to where the call to |
| @code{__builtin_saveregs} is written, regardless of what the code is. |
| This is because the registers must be saved before the function starts |
| to use them for its own purposes. |
| @c i rewrote the first sentence above to fix an overfull hbox. --mew |
| @c 10feb93 |
| |
| @findex __builtin_args_info |
| @item __builtin_args_info (@var{category}) |
| Use this built-in function to find the first anonymous arguments in |
| registers. |
| |
| In general, a machine may have several categories of registers used for |
| arguments, each for a particular category of data types. (For example, |
| on some machines, floating-point registers are used for floating-point |
| arguments while other arguments are passed in the general registers.) |
| To make non-varargs functions use the proper calling convention, you |
| have defined the @code{CUMULATIVE_ARGS} data type to record how many |
| registers in each category have been used so far |
| |
| @code{__builtin_args_info} accesses the same data structure of type |
| @code{CUMULATIVE_ARGS} after the ordinary argument layout is finished |
| with it, with @var{category} specifying which word to access. Thus, the |
| value indicates the first unused register in a given category. |
| |
| Normally, you would use @code{__builtin_args_info} in the implementation |
| of @code{va_start}, accessing each category just once and storing the |
| value in the @code{va_list} object. This is because @code{va_list} will |
| have to update the values, and there is no way to alter the |
| values accessed by @code{__builtin_args_info}. |
| |
| @findex __builtin_next_arg |
| @item __builtin_next_arg (@var{lastarg}) |
| This is the equivalent of @code{__builtin_args_info}, for stack |
| arguments. It returns the address of the first anonymous stack |
| argument, as type @code{void *}. If @code{ARGS_GROW_DOWNWARD}, it |
| returns the address of the location above the first anonymous stack |
| argument. Use it in @code{va_start} to initialize the pointer for |
| fetching arguments from the stack. Also use it in @code{va_start} to |
| verify that the second parameter @var{lastarg} is the last named argument |
| of the current function. |
| |
| @findex __builtin_classify_type |
| @item __builtin_classify_type (@var{object}) |
| Since each machine has its own conventions for which data types are |
| passed in which kind of register, your implementation of @code{va_arg} |
| has to embody these conventions. The easiest way to categorize the |
| specified data type is to use @code{__builtin_classify_type} together |
| with @code{sizeof} and @code{__alignof__}. |
| |
| @code{__builtin_classify_type} ignores the value of @var{object}, |
| considering only its data type. It returns an integer describing what |
| kind of type that is---integer, floating, pointer, structure, and so on. |
| |
| The file @file{typeclass.h} defines an enumeration that you can use to |
| interpret the values of @code{__builtin_classify_type}. |
| @end table |
| |
| These machine description macros help implement varargs: |
| |
| @table @code |
| @findex EXPAND_BUILTIN_SAVEREGS |
| @item EXPAND_BUILTIN_SAVEREGS (@var{args}) |
| If defined, is a C expression that produces the machine-specific code |
| for a call to @code{__builtin_saveregs}. This code will be moved to the |
| very beginning of the function, before any parameter access are made. |
| The return value of this function should be an RTX that contains the |
| value to use as the return of @code{__builtin_saveregs}. |
| |
| The argument @var{args} is a @code{tree_list} containing the arguments |
| that were passed to @code{__builtin_saveregs}. |
| |
| If this macro is not defined, the compiler will output an ordinary |
| call to the library function @samp{__builtin_saveregs}. |
| |
| @c !!! a bug in texinfo; how to make the entry on the @item line allow |
| @c more than one line of text... help... --mew 10feb93 |
| @findex SETUP_INCOMING_VARARGS |
| @item SETUP_INCOMING_VARARGS (@var{args_so_far}, @var{mode}, @var{type}, |
| @var{pretend_args_size}, @var{second_time}) |
| This macro offers an alternative to using @code{__builtin_saveregs} and |
| defining the macro @code{EXPAND_BUILTIN_SAVEREGS}. Use it to store the |
| anonymous register arguments into the stack so that all the arguments |
| appear to have been passed consecutively on the stack. Once this is |
| done, you can use the standard implementation of varargs that works for |
| machines that pass all their arguments on the stack. |
| |
| The argument @var{args_so_far} is the @code{CUMULATIVE_ARGS} data |
| structure, containing the values that obtain after processing of the |
| named arguments. The arguments @var{mode} and @var{type} describe the |
| last named argument---its machine mode and its data type as a tree node. |
| |
| The macro implementation should do two things: first, push onto the |
| stack all the argument registers @emph{not} used for the named |
| arguments, and second, store the size of the data thus pushed into the |
| @code{int}-valued variable whose name is supplied as the argument |
| @var{pretend_args_size}. The value that you store here will serve as |
| additional offset for setting up the stack frame. |
| |
| Because you must generate code to push the anonymous arguments at |
| compile time without knowing their data types, |
| @code{SETUP_INCOMING_VARARGS} is only useful on machines that have just |
| a single category of argument register and use it uniformly for all data |
| types. |
| |
| If the argument @var{second_time} is nonzero, it means that the |
| arguments of the function are being analyzed for the second time. This |
| happens for an inline function, which is not actually compiled until the |
| end of the source file. The macro @code{SETUP_INCOMING_VARARGS} should |
| not generate any instructions in this case. |
| |
| @findex STRICT_ARGUMENT_NAMING |
| @item STRICT_ARGUMENT_NAMING |
| Define this macro if the location where a function argument is passed |
| depends on whether or not it is a named argument. |
| |
| This macro controls how the @var{named} argument to @code{FUNCTION_ARG} |
| is set for varargs and stdarg functions. With this macro defined, |
| the @var{named} argument is always true for named arguments, and false for |
| unnamed arguments. If this is not defined, but @code{SETUP_INCOMING_VARARGS} |
| is defined, then all arguments are treated as named. Otherwise, all named |
| arguments except the last are treated as named. |
| @end table |
| |
| @node Trampolines |
| @section Trampolines for Nested Functions |
| @cindex trampolines for nested functions |
| @cindex nested functions, trampolines for |
| |
| A @dfn{trampoline} is a small piece of code that is created at run time |
| when the address of a nested function is taken. It normally resides on |
| the stack, in the stack frame of the containing function. These macros |
| tell GNU CC how to generate code to allocate and initialize a |
| trampoline. |
| |
| The instructions in the trampoline must do two things: load a constant |
| address into the static chain register, and jump to the real address of |
| the nested function. On CISC machines such as the m68k, this requires |
| two instructions, a move immediate and a jump. Then the two addresses |
| exist in the trampoline as word-long immediate operands. On RISC |
| machines, it is often necessary to load each address into a register in |
| two parts. Then pieces of each address form separate immediate |
| operands. |
| |
| The code generated to initialize the trampoline must store the variable |
| parts---the static chain value and the function address---into the |
| immediate operands of the instructions. On a CISC machine, this is |
| simply a matter of copying each address to a memory reference at the |
| proper offset from the start of the trampoline. On a RISC machine, it |
| may be necessary to take out pieces of the address and store them |
| separately. |
| |
| @table @code |
| @findex TRAMPOLINE_TEMPLATE |
| @item TRAMPOLINE_TEMPLATE (@var{file}) |
| A C statement to output, on the stream @var{file}, assembler code for a |
| block of data that contains the constant parts of a trampoline. This |
| code should not include a label---the label is taken care of |
| automatically. |
| |
| If you do not define this macro, it means no template is needed |
| for the target. Do not define this macro on systems where the block move |
| code to copy the trampoline into place would be larger than the code |
| to generate it on the spot. |
| |
| @findex TRAMPOLINE_SECTION |
| @item TRAMPOLINE_SECTION |
| The name of a subroutine to switch to the section in which the |
| trampoline template is to be placed (@pxref{Sections}). The default is |
| a value of @samp{readonly_data_section}, which places the trampoline in |
| the section containing read-only data. |
| |
| @findex TRAMPOLINE_SIZE |
| @item TRAMPOLINE_SIZE |
| A C expression for the size in bytes of the trampoline, as an integer. |
| |
| @findex TRAMPOLINE_ALIGNMENT |
| @item TRAMPOLINE_ALIGNMENT |
| Alignment required for trampolines, in bits. |
| |
| If you don't define this macro, the value of @code{BIGGEST_ALIGNMENT} |
| is used for aligning trampolines. |
| |
| @findex INITIALIZE_TRAMPOLINE |
| @item INITIALIZE_TRAMPOLINE (@var{addr}, @var{fnaddr}, @var{static_chain}) |
| A C statement to initialize the variable parts of a trampoline. |
| @var{addr} is an RTX for the address of the trampoline; @var{fnaddr} is |
| an RTX for the address of the nested function; @var{static_chain} is an |
| RTX for the static chain value that should be passed to the function |
| when it is called. |
| |
| @findex ALLOCATE_TRAMPOLINE |
| @item ALLOCATE_TRAMPOLINE (@var{fp}) |
| A C expression to allocate run-time space for a trampoline. The |
| expression value should be an RTX representing a memory reference to the |
| space for the trampoline. |
| |
| @cindex @code{FUNCTION_EPILOGUE} and trampolines |
| @cindex @code{FUNCTION_PROLOGUE} and trampolines |
| If this macro is not defined, by default the trampoline is allocated as |
| a stack slot. This default is right for most machines. The exceptions |
| are machines where it is impossible to execute instructions in the stack |
| area. On such machines, you may have to implement a separate stack, |
| using this macro in conjunction with @code{FUNCTION_PROLOGUE} and |
| @code{FUNCTION_EPILOGUE}. |
| |
| @var{fp} points to a data structure, a @code{struct function}, which |
| describes the compilation status of the immediate containing function of |
| the function which the trampoline is for. Normally (when |
| @code{ALLOCATE_TRAMPOLINE} is not defined), the stack slot for the |
| trampoline is in the stack frame of this containing function. Other |
| allocation strategies probably must do something analogous with this |
| information. |
| @end table |
| |
| Implementing trampolines is difficult on many machines because they have |
| separate instruction and data caches. Writing into a stack location |
| fails to clear the memory in the instruction cache, so when the program |
| jumps to that location, it executes the old contents. |
| |
| Here are two possible solutions. One is to clear the relevant parts of |
| the instruction cache whenever a trampoline is set up. The other is to |
| make all trampolines identical, by having them jump to a standard |
| subroutine. The former technique makes trampoline execution faster; the |
| latter makes initialization faster. |
| |
| To clear the instruction cache when a trampoline is initialized, define |
| the following macros which describe the shape of the cache. |
| |
| @table @code |
| @findex INSN_CACHE_SIZE |
| @item INSN_CACHE_SIZE |
| The total size in bytes of the cache. |
| |
| @findex INSN_CACHE_LINE_WIDTH |
| @item INSN_CACHE_LINE_WIDTH |
| The length in bytes of each cache line. The cache is divided into cache |
| lines which are disjoint slots, each holding a contiguous chunk of data |
| fetched from memory. Each time data is brought into the cache, an |
| entire line is read at once. The data loaded into a cache line is |
| always aligned on a boundary equal to the line size. |
| |
| @findex INSN_CACHE_DEPTH |
| @item INSN_CACHE_DEPTH |
| The number of alternative cache lines that can hold any particular memory |
| location. |
| @end table |
| |
| Alternatively, if the machine has system calls or instructions to clear |
| the instruction cache directly, you can define the following macro. |
| |
| @table @code |
| @findex CLEAR_INSN_CACHE |
| @item CLEAR_INSN_CACHE (@var{BEG}, @var{END}) |
| If defined, expands to a C expression clearing the @emph{instruction |
| cache} in the specified interval. If it is not defined, and the macro |
| INSN_CACHE_SIZE is defined, some generic code is generated to clear the |
| cache. The definition of this macro would typically be a series of |
| @code{asm} statements. Both @var{BEG} and @var{END} are both pointer |
| expressions. |
| @end table |
| |
| To use a standard subroutine, define the following macro. In addition, |
| you must make sure that the instructions in a trampoline fill an entire |
| cache line with identical instructions, or else ensure that the |
| beginning of the trampoline code is always aligned at the same point in |
| its cache line. Look in @file{m68k.h} as a guide. |
| |
| @table @code |
| @findex TRANSFER_FROM_TRAMPOLINE |
| @item TRANSFER_FROM_TRAMPOLINE |
| Define this macro if trampolines need a special subroutine to do their |
| work. The macro should expand to a series of @code{asm} statements |
| which will be compiled with GNU CC. They go in a library function named |
| @code{__transfer_from_trampoline}. |
| |
| If you need to avoid executing the ordinary prologue code of a compiled |
| C function when you jump to the subroutine, you can do so by placing a |
| special label of your own in the assembler code. Use one @code{asm} |
| statement to generate an assembler label, and another to make the label |
| global. Then trampolines can use that label to jump directly to your |
| special assembler code. |
| @end table |
| |
| @node Library Calls |
| @section Implicit Calls to Library Routines |
| @cindex library subroutine names |
| @cindex @file{libgcc.a} |
| |
| @c prevent bad page break with this line |
| Here is an explanation of implicit calls to library routines. |
| |
| @table @code |
| @findex MULSI3_LIBCALL |
| @item MULSI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| multiplication of one signed full-word by another. If you do not |
| define this macro, the default name is used, which is @code{__mulsi3}, |
| a function defined in @file{libgcc.a}. |
| |
| @findex DIVSI3_LIBCALL |
| @item DIVSI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| division of one signed full-word by another. If you do not define |
| this macro, the default name is used, which is @code{__divsi3}, a |
| function defined in @file{libgcc.a}. |
| |
| @findex UDIVSI3_LIBCALL |
| @item UDIVSI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| division of one unsigned full-word by another. If you do not define |
| this macro, the default name is used, which is @code{__udivsi3}, a |
| function defined in @file{libgcc.a}. |
| |
| @findex MODSI3_LIBCALL |
| @item MODSI3_LIBCALL |
| A C string constant giving the name of the function to call for the |
| remainder in division of one signed full-word by another. If you do |
| not define this macro, the default name is used, which is |
| @code{__modsi3}, a function defined in @file{libgcc.a}. |
| |
| @findex UMODSI3_LIBCALL |
| @item UMODSI3_LIBCALL |
| A C string constant giving the name of the function to call for the |
| remainder in division of one unsigned full-word by another. If you do |
| not define this macro, the default name is used, which is |
| @code{__umodsi3}, a function defined in @file{libgcc.a}. |
| |
| @findex MULDI3_LIBCALL |
| @item MULDI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| multiplication of one signed double-word by another. If you do not |
| define this macro, the default name is used, which is @code{__muldi3}, |
| a function defined in @file{libgcc.a}. |
| |
| @findex DIVDI3_LIBCALL |
| @item DIVDI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| division of one signed double-word by another. If you do not define |
| this macro, the default name is used, which is @code{__divdi3}, a |
| function defined in @file{libgcc.a}. |
| |
| @findex UDIVDI3_LIBCALL |
| @item UDIVDI3_LIBCALL |
| A C string constant giving the name of the function to call for |
| division of one unsigned full-word by another. If you do not define |
| this macro, the default name is used, which is @code{__udivdi3}, a |
| function defined in @file{libgcc.a}. |
| |
| @findex MODDI3_LIBCALL |
| @item MODDI3_LIBCALL |
| A C string constant giving the name of the function to call for the |
| remainder in division of one signed double-word by another. If you do |
| not define this macro, the default name is used, which is |
| @code{__moddi3}, a function defined in @file{libgcc.a}. |
| |
| @findex UMODDI3_LIBCALL |
| @item UMODDI3_LIBCALL |
| A C string constant giving the name of the function to call for the |
| remainder in division of one unsigned full-word by another. If you do |
| not define this macro, the default name is used, which is |
| @code{__umoddi3}, a function defined in @file{libgcc.a}. |
| |
| @findex INIT_TARGET_OPTABS |
| @item INIT_TARGET_OPTABS |
| Define this macro as a C statement that declares additional library |
| routines renames existing ones. @code{init_optabs} calls this macro after |
| initializing all the normal library routines. |
| |
| @findex TARGET_EDOM |
| @cindex @code{EDOM}, implicit usage |
| @item TARGET_EDOM |
| The value of @code{EDOM} on the target machine, as a C integer constant |
| expression. If you don't define this macro, GNU CC does not attempt to |
| deposit the value of @code{EDOM} into @code{errno} directly. Look in |
| @file{/usr/include/errno.h} to find the value of @code{EDOM} on your |
| system. |
| |
| If you do not define @code{TARGET_EDOM}, then compiled code reports |
| domain errors by calling the library function and letting it report the |
| error. If mathematical functions on your system use @code{matherr} when |
| there is an error, then you should leave @code{TARGET_EDOM} undefined so |
| that @code{matherr} is used normally. |
| |
| @findex GEN_ERRNO_RTX |
| @cindex @code{errno}, implicit usage |
| @item GEN_ERRNO_RTX |
| Define this macro as a C expression to create an rtl expression that |
| refers to the global ``variable'' @code{errno}. (On certain systems, |
| @code{errno} may not actually be a variable.) If you don't define this |
| macro, a reasonable default is used. |
| |
| @findex TARGET_MEM_FUNCTIONS |
| @cindex @code{bcopy}, implicit usage |
| @cindex @code{memcpy}, implicit usage |
| @cindex @code{bzero}, implicit usage |
| @cindex @code{memset}, implicit usage |
| @item TARGET_MEM_FUNCTIONS |
| Define this macro if GNU CC should generate calls to the System V |
| (and ANSI C) library functions @code{memcpy} and @code{memset} |
| rather than the BSD functions @code{bcopy} and @code{bzero}. |
| |
| @findex LIBGCC_NEEDS_DOUBLE |
| @item LIBGCC_NEEDS_DOUBLE |
| Define this macro if only @code{float} arguments cannot be passed to |
| library routines (so they must be converted to @code{double}). This |
| macro affects both how library calls are generated and how the library |
| routines in @file{libgcc1.c} accept their arguments. It is useful on |
| machines where floating and fixed point arguments are passed |
| differently, such as the i860. |
| |
| @findex FLOAT_ARG_TYPE |
| @item FLOAT_ARG_TYPE |
| Define this macro to override the type used by the library routines to |
| pick up arguments of type @code{float}. (By default, they use a union |
| of @code{float} and @code{int}.) |
| |
| The obvious choice would be @code{float}---but that won't work with |
| traditional C compilers that expect all arguments declared as @code{float} |
| to arrive as @code{double}. To avoid this conversion, the library routines |
| ask for the value as some other type and then treat it as a @code{float}. |
| |
| On some systems, no other type will work for this. For these systems, |
| you must use @code{LIBGCC_NEEDS_DOUBLE} instead, to force conversion of |
| the values @code{double} before they are passed. |
| |
| @findex FLOATIFY |
| @item FLOATIFY (@var{passed-value}) |
| Define this macro to override the way library routines redesignate a |
| @code{float} argument as a @code{float} instead of the type it was |
| passed as. The default is an expression which takes the @code{float} |
| field of the union. |
| |
| @findex FLOAT_VALUE_TYPE |
| @item FLOAT_VALUE_TYPE |
| Define this macro to override the type used by the library routines to |
| return values that ought to have type @code{float}. (By default, they |
| use @code{int}.) |
| |
| The obvious choice would be @code{float}---but that won't work with |
| traditional C compilers gratuitously convert values declared as |
| @code{float} into @code{double}. |
| |
| @findex INTIFY |
| @item INTIFY (@var{float-value}) |
| Define this macro to override the way the value of a |
| @code{float}-returning library routine should be packaged in order to |
| return it. These functions are actually declared to return type |
| @code{FLOAT_VALUE_TYPE} (normally @code{int}). |
| |
| These values can't be returned as type @code{float} because traditional |
| C compilers would gratuitously convert the value to a @code{double}. |
| |
| A local variable named @code{intify} is always available when the macro |
| @code{INTIFY} is used. It is a union of a @code{float} field named |
| @code{f} and a field named @code{i} whose type is |
| @code{FLOAT_VALUE_TYPE} or @code{int}. |
| |
| If you don't define this macro, the default definition works by copying |
| the value through that union. |
| |
| @findex nongcc_SI_type |
| @item nongcc_SI_type |
| Define this macro as the name of the data type corresponding to |
| @code{SImode} in the system's own C compiler. |
| |
| You need not define this macro if that type is @code{long int}, as it usually |
| is. |
| |
| @findex nongcc_word_type |
| @item nongcc_word_type |
| Define this macro as the name of the data type corresponding to the |
| word_mode in the system's own C compiler. |
| |
| You need not define this macro if that type is @code{long int}, as it usually |
| is. |
| |
| @findex perform_@dots{} |
| @item perform_@dots{} |
| Define these macros to supply explicit C statements to carry out various |
| arithmetic operations on types @code{float} and @code{double} in the |
| library routines in @file{libgcc1.c}. See that file for a full list |
| of these macros and their arguments. |
| |
| On most machines, you don't need to define any of these macros, because |
| the C compiler that comes with the system takes care of doing them. |
| |
| @findex NEXT_OBJC_RUNTIME |
| @item NEXT_OBJC_RUNTIME |
| Define this macro to generate code for Objective C message sending using |
| the calling convention of the NeXT system. This calling convention |
| involves passing the object, the selector and the method arguments all |
| at once to the method-lookup library function. |
| |
| The default calling convention passes just the object and the selector |
| to the lookup function, which returns a pointer to the method. |
| @end table |
| |
| @node Addressing Modes |
| @section Addressing Modes |
| @cindex addressing modes |
| |
| @c prevent bad page break with this line |
| This is about addressing modes. |
| |
| @table @code |
| @findex HAVE_POST_INCREMENT |
| @item HAVE_POST_INCREMENT |
| Define this macro if the machine supports post-increment addressing. |
| |
| @findex HAVE_PRE_INCREMENT |
| @findex HAVE_POST_DECREMENT |
| @findex HAVE_PRE_DECREMENT |
| @item HAVE_PRE_INCREMENT |
| @itemx HAVE_POST_DECREMENT |
| @itemx HAVE_PRE_DECREMENT |
| Similar for other kinds of addressing. |
| |
| @findex CONSTANT_ADDRESS_P |
| @item CONSTANT_ADDRESS_P (@var{x}) |
| A C expression that is 1 if the RTX @var{x} is a constant which |
| is a valid address. On most machines, this can be defined as |
| @code{CONSTANT_P (@var{x})}, but a few machines are more restrictive |
| in which constant addresses are supported. |
| |
| @findex CONSTANT_P |
| @code{CONSTANT_P} accepts integer-values expressions whose values are |
| not explicitly known, such as @code{symbol_ref}, @code{label_ref}, and |
| @code{high} expressions and @code{const} arithmetic expressions, in |
| addition to @code{const_int} and @code{const_double} expressions. |
| |
| @findex MAX_REGS_PER_ADDRESS |
| @item MAX_REGS_PER_ADDRESS |
| A number, the maximum number of registers that can appear in a valid |
| memory address. Note that it is up to you to specify a value equal to |
| the maximum number that @code{GO_IF_LEGITIMATE_ADDRESS} would ever |
| accept. |
| |
| @findex GO_IF_LEGITIMATE_ADDRESS |
| @item GO_IF_LEGITIMATE_ADDRESS (@var{mode}, @var{x}, @var{label}) |
| A C compound statement with a conditional @code{goto @var{label};} |
| executed if @var{x} (an RTX) is a legitimate memory address on the |
| target machine for a memory operand of mode @var{mode}. |
| |
| It usually pays to define several simpler macros to serve as |
| subroutines for this one. Otherwise it may be too complicated to |
| understand. |
| |
| This macro must exist in two variants: a strict variant and a |
| non-strict one. The strict variant is used in the reload pass. It |
| must be defined so that any pseudo-register that has not been |
| allocated a hard register is considered a memory reference. In |
| contexts where some kind of register is required, a pseudo-register |
| with no hard register must be rejected. |
| |
| The non-strict variant is used in other passes. It must be defined to |
| accept all pseudo-registers in every context where some kind of |
| register is required. |
| |
| @findex REG_OK_STRICT |
| Compiler source files that want to use the strict variant of this |
| macro define the macro @code{REG_OK_STRICT}. You should use an |
| @code{#ifdef REG_OK_STRICT} conditional to define the strict variant |
| in that case and the non-strict variant otherwise. |
| |
| Subroutines to check for acceptable registers for various purposes (one |
| for base registers, one for index registers, and so on) are typically |
| among the subroutines used to define @code{GO_IF_LEGITIMATE_ADDRESS}. |
| Then only these subroutine macros need have two variants; the higher |
| levels of macros may be the same whether strict or not.@refill |
| |
| Normally, constant addresses which are the sum of a @code{symbol_ref} |
| and an integer are stored inside a @code{const} RTX to mark them as |
| constant. Therefore, there is no need to recognize such sums |
| specifically as legitimate addresses. Normally you would simply |
| recognize any @code{const} as legitimate. |
| |
| Usually @code{PRINT_OPERAND_ADDRESS} is not prepared to handle constant |
| sums that are not marked with @code{const}. It assumes that a naked |
| @code{plus} indicates indexing. If so, then you @emph{must} reject such |
| naked constant sums as illegitimate addresses, so that none of them will |
| be given to @code{PRINT_OPERAND_ADDRESS}. |
| |
| @cindex @code{ENCODE_SECTION_INFO} and address validation |
| On some machines, whether a symbolic address is legitimate depends on |
| the section that the address refers to. On these machines, define the |
| macro @code{ENCODE_SECTION_INFO} to store the information into the |
| @code{symbol_ref}, and then check for it here. When you see a |
| @code{const}, you will have to look inside it to find the |
| @code{symbol_ref} in order to determine the section. @xref{Assembler |
| Format}. |
| |
| @findex saveable_obstack |
| The best way to modify the name string is by adding text to the |
| beginning, with suitable punctuation to prevent any ambiguity. Allocate |
| the new name in @code{saveable_obstack}. You will have to modify |
| @code{ASM_OUTPUT_LABELREF} to remove and decode the added text and |
| output the name accordingly, and define @code{STRIP_NAME_ENCODING} to |
| access the original name string. |
| |
| You can check the information stored here into the @code{symbol_ref} in |
| the definitions of the macros @code{GO_IF_LEGITIMATE_ADDRESS} and |
| @code{PRINT_OPERAND_ADDRESS}. |
| |
| @findex REG_OK_FOR_BASE_P |
| @item REG_OK_FOR_BASE_P (@var{x}) |
| A C expression that is nonzero if @var{x} (assumed to be a @code{reg} |
| RTX) is valid for use as a base register. For hard registers, it |
| should always accept those which the hardware permits and reject the |
| others. Whether the macro accepts or rejects pseudo registers must be |
| controlled by @code{REG_OK_STRICT} as described above. This usually |
| requires two variant definitions, of which @code{REG_OK_STRICT} |
| controls the one actually used. |
| |
| @findex REG_MODE_OK_FOR_BASE_P |
| @item REG_MODE_OK_FOR_BASE_P (@var{x}, @var{mode}) |
| A C expression that is just like @code{REG_OK_FOR_BASE_P}, except that |
| that expression may examine the mode of the memory reference in |
| @var{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 |
| @code{REG_OK_FOR_BASE_P}. |
| |
| @findex REG_OK_FOR_INDEX_P |
| @item REG_OK_FOR_INDEX_P (@var{x}) |
| A C expression that is nonzero if @var{x} (assumed to be a @code{reg} |
| RTX) is valid for use as an index 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. |
| |
| @findex LEGITIMIZE_ADDRESS |
| @item LEGITIMIZE_ADDRESS (@var{x}, @var{oldx}, @var{mode}, @var{win}) |
| |