+`STACK_CHECK_PROBE_INTERVAL'
+ An integer representing the interval at which GCC must generate
+ stack probe instructions. You will normally define this macro to
+ be no larger than the size of the "guard pages" at the end of a
+ stack area. The default value of 4096 is suitable for most
+ systems.
+
+`STACK_CHECK_PROBE_LOAD'
+ A integer which is nonzero if GCC should perform the stack probe
+ as a load instruction and zero if GCC should use a store
+ instruction. The default is zero, which is the most efficient
+ choice on most systems.
+
+`STACK_CHECK_PROTECT'
+ The number of bytes of stack needed to recover from a stack
+ overflow, for languages where such a recovery is supported. The
+ default value of 75 words should be adequate for most machines.
+
+`STACK_CHECK_MAX_FRAME_SIZE'
+ The maximum size of a stack frame, in bytes. GCC 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 GCC will
+ issue a warning. The default is chosen so that GCC only generates
+ one instruction on most systems. You should normally not change
+ the default value of this macro.
+
+`STACK_CHECK_FIXED_FRAME_SIZE'
+ GCC uses this value to generate the above warning message. It
+ represents the amount of fixed frame used by a function, not
+ including space for any callee-saved registers, temporaries and
+ user variables. You need only specify an upper bound for this
+ amount and will normally use the default of four words.
+
+`STACK_CHECK_MAX_VAR_SIZE'
+ The maximum size, in bytes, of an object that GCC will place in the
+ fixed area of the stack frame when the user specifies
+ `-fstack-check'. GCC computed the default from the values of the
+ above macros and you will normally not need to override that
+ default.
+
+\1f
+File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
+
+10.10.4 Registers That Address the Stack Frame
+----------------------------------------------
+
+This discusses registers that address the stack frame.
+
+`STACK_POINTER_REGNUM'
+ The register number of the stack pointer register, which must also
+ be a fixed register according to `FIXED_REGISTERS'. On most
+ machines, the hardware determines which register this is.
+
+`FRAME_POINTER_REGNUM'
+ The register number of the frame pointer register, which is used to
+ access automatic variables in the stack frame. On some machines,
+ the hardware determines which register this is. On other
+ machines, you can choose any register you wish for this purpose.
+
+`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
+ `FRAME_POINTER_REGNUM' the number of a special, fixed register to
+ be used internally until the offset is known, and define
+ `HARD_FRAME_POINTER_REGNUM' to be the actual 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 `ELIMINABLE_REGS' how to
+ eliminate `FRAME_POINTER_REGNUM' into either
+ `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
+
+ Do not define this macro if it would be the same as
+ `FRAME_POINTER_REGNUM'.
+
+`ARG_POINTER_REGNUM'
+ The register number of the arg pointer register, which is used to
+ access the function's argument list. On some machines, this is
+ the same as the frame pointer register. On some machines, the
+ hardware determines which register this is. On other machines,
+ you can choose any register you wish for this purpose. If this is
+ not the same register as the frame pointer register, then you must
+ mark it as a fixed register according to `FIXED_REGISTERS', or
+ arrange to be able to eliminate it (*note Elimination::).
+
+`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 `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.
+
+`STATIC_CHAIN_REGNUM'
+`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 `STATIC_CHAIN_INCOMING_REGNUM',
+ while the register number as seen by the calling function is
+ `STATIC_CHAIN_REGNUM'. If these registers are the same,
+ `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
+
+ The static chain register need not be a fixed register.
+
+ If the static chain is passed in memory, these macros should not be
+ defined; instead, the next two macros should be defined.
+
+`STATIC_CHAIN'
+`STATIC_CHAIN_INCOMING'
+ If the static chain is passed in memory, these macros provide rtx
+ giving `mem' expressions that denote where they are stored.
+ `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
+ seen by the calling and called functions, respectively. Often the
+ former will be at an offset from the stack pointer and the latter
+ at an offset from the frame pointer.
+
+ The variables `stack_pointer_rtx', `frame_pointer_rtx', and
+ `arg_pointer_rtx' will have been initialized prior to the use of
+ these macros and should be used to refer to those items.
+
+ If the static chain is passed in a register, the two previous
+ macros should be defined instead.
+
+`DWARF_FRAME_REGISTERS'
+ This macro specifies the maximum number of hard registers that can
+ be saved in a call frame. This is used to size data structures
+ used in DWARF2 exception handling.
+
+ Prior to GCC 3.0, this macro was needed in order to establish a
+ stable exception handling ABI in the face of adding new hard
+ registers for ISA extensions. In GCC 3.0 and later, the EH ABI is
+ insulated from changes in the number of hard registers.
+ Nevertheless, this macro can still be used to reduce the runtime
+ memory requirements of the exception handling routines, which can
+ be substantial if the ISA contains a lot of registers that are not
+ call-saved.
+
+ If this macro is not defined, it defaults to
+ `FIRST_PSEUDO_REGISTER'.
+
+`PRE_GCC3_DWARF_FRAME_REGISTERS'
+ This macro is similar to `DWARF_FRAME_REGISTERS', but is provided
+ for backward compatibility in pre GCC 3.0 compiled code.
+
+ If this macro is not defined, it defaults to
+ `DWARF_FRAME_REGISTERS'.
+
+
+\1f
+File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
+
+10.10.5 Eliminating Frame Pointer and Arg Pointer
+-------------------------------------------------
+
+This is about eliminating the frame pointer and arg pointer.
+
+`FRAME_POINTER_REQUIRED'
+ A C expression which is nonzero if a function must have and use a
+ frame pointer. This expression is evaluated in the reload pass.
+ If its value is nonzero the function will have a frame pointer.
+
+ The expression can in principle examine the current function and
+ decide according to the facts, but on most machines the constant 0
+ or the constant 1 suffices. Use 0 when the machine allows code to
+ be generated with no frame pointer, and doing so saves some time
+ or space. Use 1 when there is no possible advantage to avoiding a
+ frame pointer.
+
+ In certain cases, the compiler does not know how to produce valid
+ code without a frame pointer. The compiler recognizes those cases
+ and automatically gives the function a frame pointer regardless of
+ what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
+ them.
+
+ In a function that does not require a frame pointer, the frame
+ pointer register can be allocated for ordinary usage, unless you
+ mark it as a fixed register. See `FIXED_REGISTERS' for more
+ information.
+
+`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
+ A C statement to store in the variable DEPTH-VAR the difference
+ between the frame pointer and the stack pointer values immediately
+ after the function prologue. The value would be computed from
+ information such as the result of `get_frame_size ()' and the
+ tables of registers `regs_ever_live' and `call_used_regs'.
+
+ If `ELIMINABLE_REGS' is defined, this macro will be not be used and
+ need not be defined. Otherwise, it must be defined even if
+ `FRAME_POINTER_REQUIRED' is defined to always be true; in that
+ case, you may set DEPTH-VAR to anything.
+
+`ELIMINABLE_REGS'
+ If defined, this macro specifies a table of register pairs used to
+ eliminate unneeded registers that point into the stack frame. If
+ it is not defined, the only elimination attempted by the compiler
+ is to replace references to the frame pointer with references to
+ the stack pointer.
+
+ The definition of this macro is a list of structure
+ initializations, each of which specifies an original and
+ replacement register.
+
+ On some machines, the position of the argument pointer is not
+ known until the compilation is completed. In such a case, a
+ separate hard register must be used for the argument pointer.
+ This register can be eliminated by replacing it with either the
+ frame pointer or the argument pointer, depending on whether or not
+ the frame pointer has been eliminated.
+
+ In this case, you might specify:
+ #define ELIMINABLE_REGS \
+ {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
+ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
+ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
+
+ Note that the elimination of the argument pointer with the stack
+ pointer is specified first since that is the preferred elimination.
+
+`CAN_ELIMINATE (FROM-REG, TO-REG)'
+ A C expression that returns nonzero if the compiler is allowed to
+ try to replace register number FROM-REG with register number
+ TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
+ defined, and will usually be the constant 1, since most of the
+ cases preventing register elimination are things that the compiler
+ already knows about.
+
+`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
+ This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
+ specifies the initial difference between the specified pair of
+ registers. This macro must be defined if `ELIMINABLE_REGS' is
+ defined.
+
+\1f
+File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
+
+10.10.6 Passing Function Arguments on the Stack
+-----------------------------------------------
+
+The macros in this section control how arguments are passed on the
+stack. See the following section for other macros that control passing
+certain arguments in registers.
+
+`PROMOTE_PROTOTYPES'
+ A C expression whose value is nonzero if an argument declared in a
+ prototype as an integral type smaller than `int' should actually
+ be passed as an `int'. In addition to avoiding errors in certain
+ cases of mismatch, it also makes for better code on certain
+ machines. If the macro is not defined in target header files, it
+ defaults to 0.
+
+`PUSH_ARGS'
+ A C expression. If nonzero, push insns will be used to pass
+ outgoing arguments. If the target machine does not have a push
+ instruction, set it to zero. That directs GCC to use an alternate
+ strategy: to allocate the entire argument block and then store the
+ arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING'
+ must be defined too.
+
+`PUSH_ROUNDING (NPUSHED)'
+ A C expression that is the number of bytes actually pushed onto the
+ stack when an instruction attempts to push NPUSHED bytes.
+
+ On some machines, the definition
+
+ #define PUSH_ROUNDING(BYTES) (BYTES)
+
+ will suffice. But on other machines, instructions that appear to
+ push one byte actually push two bytes in an attempt to maintain
+ alignment. Then the definition should be
+
+ #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
+
+`ACCUMULATE_OUTGOING_ARGS'
+ A C expression. If nonzero, the maximum amount of space required
+ for outgoing arguments will be computed and placed into the
+ variable `current_function_outgoing_args_size'. No space will be
+ pushed onto the stack for each call; instead, the function
+ prologue should increase the stack frame size by this amount.
+
+ Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not
+ proper.
+
+`REG_PARM_STACK_SPACE (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 FNDECL, which can be zero if GCC is calling a
+ library function.
+
+ This space can be allocated by the caller, or be a part of the
+ machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
+ which.
+
+`MAYBE_REG_PARM_STACK_SPACE'
+`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, 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, `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, GCC uses these two macros instead of
+ `REG_PARM_STACK_SPACE'.
+
+`OUTGOING_REG_PARM_STACK_SPACE'
+ Define this if it is the responsibility of the caller to allocate
+ the area reserved for arguments passed in registers.
+
+ If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
+ whether the space for these arguments counts in the value of
+ `current_function_outgoing_args_size'.
+
+`STACK_PARMS_IN_REG_PARM_AREA'
+ Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
+ stack parameters don't skip the area specified by it.
+
+ Normally, when a parameter is not passed in registers, it is
+ placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
+ Defining this macro suppresses this behavior and causes the
+ parameter to be passed on the stack in its natural location.
+
+`RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
+ A C expression that should indicate the number of bytes of its own
+ arguments that a function pops on returning, or 0 if the function
+ pops no arguments and the caller must therefore pop them all after
+ the function returns.
+
+ FUNDECL is a C variable whose value is a tree node that describes
+ the function in question. Normally it is a node of type
+ `FUNCTION_DECL' that describes the declaration of the function.
+ From this you can obtain the `DECL_ATTRIBUTES' of the function.
+
+ FUNTYPE is a C variable whose value is a tree node that describes
+ the function in question. Normally it is a node of type
+ `FUNCTION_TYPE' that describes the data type of the function.
+ From this it is possible to obtain the data types of the value and
+ arguments (if known).
+
+ When a call to a library function is being considered, 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.
+
+ 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 STACK-SIZE. On the 68000, using the
+ standard calling convention, no functions pop their arguments, so
+ the value of the macro is always 0 in this case. But an
+ alternative calling convention is available in which functions
+ that take a fixed number of arguments pop them but other functions
+ (such as `printf') pop nothing (the caller pops all). When this
+ convention is in use, FUNTYPE is examined to determine whether a
+ function takes a fixed number of arguments.
+
+`CALL_POPS_ARGS (CUM)'
+ A C expression that should indicate the number of bytes a call
+ sequence pops off the stack. It is added to the value of
+ `RETURN_POPS_ARGS' when compiling a function call.
+
+ CUM is the variable in which all arguments to the called function
+ have been accumulated.
+
+ On certain architectures, such as the SH5, a call trampoline is
+ used that pops certain registers off the stack, depending on the
+ arguments that have been passed to the function. Since this is a
+ property of the call site, not of the called function,
+ `RETURN_POPS_ARGS' is not appropriate.
+
+
+\1f
+File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
+
+10.10.7 Passing Arguments in Registers
+--------------------------------------
+
+This section describes the macros which let you control how various
+types of arguments are passed in registers or how they are arranged in
+the stack.
+
+`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
+ A C expression that controls whether a function argument is passed
+ in a register, and which register.
+
+ The arguments are CUM, which summarizes all the previous
+ arguments; MODE, the machine mode of the argument; TYPE, the data
+ type of the argument as a tree node or 0 if that is not known
+ (which happens for C support library functions); and NAMED, which
+ is 1 for an ordinary argument and 0 for nameless arguments that
+ correspond to `...' in the called function's prototype. TYPE can
+ be an incomplete type if a syntax error has previously occurred.
+
+ The value of the expression is usually either a `reg' RTX for the
+ hard register in which to pass the argument, or zero to pass the
+ argument on the stack.
+
+ For machines like the VAX and 68000, where normally all arguments
+ are pushed, zero suffices as a definition.
+
+ The value of the expression can also be a `parallel' RTX. This is
+ used when an argument is passed in multiple locations. The mode
+ of the of the `parallel' should be the mode of the entire
+ argument. The `parallel' holds any number of `expr_list' pairs;
+ each one describes where part of the argument is passed. In each
+ `expr_list' the first operand must be a `reg' RTX for the hard
+ register in which to pass this part of the argument, and the mode
+ of the register RTX indicates how large this part of the argument
+ is. The second operand of the `expr_list' is a `const_int' which
+ gives the offset in bytes into the entire argument of where this
+ part starts. As a special exception the first `expr_list' in the
+ `parallel' RTX may have a first operand of zero. This indicates
+ that the entire argument is also stored on the stack.
+
+ The last time this macro is called, it is called with `MODE ==
+ VOIDmode', and its result is passed to the `call' or `call_value'
+ pattern as operands 2 and 3 respectively.
+
+ The usual way to make the ISO library `stdarg.h' work on a machine
+ where some arguments are usually passed in registers, is to cause
+ nameless arguments to be passed on the stack instead. This is done
+ by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
+
+ You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
+ definition of this macro to determine if this argument is of a
+ type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
+ is not defined and `FUNCTION_ARG' returns nonzero for such an
+ argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
+ defined, the argument will be computed in the stack and then
+ loaded into a register.
+
+`MUST_PASS_IN_STACK (MODE, TYPE)'
+ Define as a C expression that evaluates to nonzero if we do not
+ know how to pass TYPE solely in registers. The file `expr.h'
+ defines a definition that is usually appropriate, refer to
+ `expr.h' for additional documentation.
+
+`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
+ Define this macro if the target machine has "register windows", so
+ that the register in which a function sees an arguments is not
+ necessarily the same as the one in which the caller passed the
+ argument.
+
+ For such machines, `FUNCTION_ARG' computes the register in which
+ the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
+ defined in a similar fashion to tell the function being called
+ where the arguments will arrive.
+
+ If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
+ both purposes.
+
+`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
+ A C expression for the number of words, at the beginning of an
+ argument, that must be put in registers. The value must be zero
+ for arguments that are passed entirely in registers or that are
+ entirely pushed on the stack.
+
+ On some machines, certain arguments must be passed partially in
+ registers and partially in memory. On these machines, typically
+ the first N words of arguments are passed in registers, and the
+ rest on the stack. If a multi-word argument (a `double' or a
+ structure) crosses that boundary, its first few words must be
+ passed in registers and the rest must be pushed. This macro tells
+ the compiler when this occurs, and how many of the words should go
+ in registers.
+
+ `FUNCTION_ARG' for these arguments should return the first
+ register to be used by the caller for this argument; likewise
+ `FUNCTION_INCOMING_ARG', for the called function.
+
+`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
+ A C expression that indicates when an argument must be passed by
+ reference. If nonzero for an argument, a copy of that argument is
+ made in memory and a pointer to the argument is passed instead of
+ the argument itself. The pointer is passed in whatever way is
+ appropriate for passing a pointer to that type.
+
+ On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
+ definition of this macro might be
+ #define FUNCTION_ARG_PASS_BY_REFERENCE\
+ (CUM, MODE, TYPE, NAMED) \
+ MUST_PASS_IN_STACK (MODE, TYPE)
+
+`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, 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.
+
+`FUNCTION_ARG_REG_LITTLE_ENDIAN'
+ If defined TRUE on a big-endian system then structure arguments
+ passed (and returned) in registers are passed in a little-endian
+ manner instead of the big-endian manner. On the HP-UX IA64 and
+ PA64 platforms structures are aligned differently then integral
+ values and setting this value to true will allow for the special
+ handling of structure arguments and return values.
+
+`CUMULATIVE_ARGS'
+ A C type for declaring a variable that is used as the first
+ argument of `FUNCTION_ARG' and other related values. For some
+ target machines, the type `int' suffices and can hold the number
+ of bytes of argument so far.
+
+ There is no need to record in `CUMULATIVE_ARGS' anything about the
+ arguments that have been passed on the stack. The compiler has
+ other variables to keep track of that. For target machines on
+ which all arguments are passed on the stack, there is no need to
+ store anything in `CUMULATIVE_ARGS'; however, the data structure
+ must exist and should not be empty, so use `int'.
+
+`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)'
+ A C statement (sans semicolon) for initializing the variable CUM
+ for the state at the beginning of the argument list. The variable
+ has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
+ for the data type of the function which will receive the args, or 0
+ if the args are to a compiler support library function. The value
+ of INDIRECT is nonzero when processing an indirect call, for
+ example a call through a function pointer. The value of INDIRECT
+ is zero for a call to an explicitly named function, a library
+ function call, or when `INIT_CUMULATIVE_ARGS' is used to find
+ arguments for the function being compiled.
+
+ When processing a call to a compiler support library function,
+ LIBNAME identifies which one. It is a `symbol_ref' rtx which
+ contains the name of the function, as a string. LIBNAME is 0 when
+ an ordinary C function call is being processed. Thus, each time
+ this macro is called, either LIBNAME or FNTYPE is nonzero, but
+ never both of them at once.
+
+`INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)'
+ Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls,
+ it gets a `MODE' argument instead of FNTYPE, that would be `NULL'.
+ INDIRECT would always be zero, too. If this macro is not defined,
+ `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead.
+
+`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
+ Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
+ finding the arguments for the function being compiled. If this
+ macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
+
+ The value passed for LIBNAME is always 0, since library routines
+ with special calling conventions are never compiled with GCC. The
+ argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'.
+
+`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
+ A C statement (sans semicolon) to update the summarizer variable
+ CUM to advance past an argument in the argument list. The values
+ MODE, TYPE and NAMED describe that argument. Once this is done,
+ the variable CUM is suitable for analyzing the _following_
+ argument with `FUNCTION_ARG', etc.
+
+ This macro need not do anything if the argument in question was
+ passed on the stack. The compiler knows how to track the amount
+ of stack space used for arguments without any special help.
+
+`FUNCTION_ARG_PADDING (MODE, TYPE)'
+ If defined, a C expression which determines whether, and in which
+ direction, to pad out an argument with extra space. The value
+ should be of type `enum direction': either `upward' to pad above
+ the argument, `downward' to pad below, or `none' to inhibit
+ padding.
+
+ The _amount_ of padding is always just enough to reach the next
+ multiple of `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 `int', and upward
+ otherwise.
+
+`PAD_VARARGS_DOWN'
+ If defined, a C expression which determines whether the default
+ implementation of va_arg will attempt to pad down before reading
+ the next argument, if that argument is smaller than its aligned
+ space as controlled by `PARM_BOUNDARY'. If this macro is not
+ defined, all such arguments are padded down if `BYTES_BIG_ENDIAN'
+ is true.
+
+`FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
+ If defined, a C expression that gives the alignment boundary, in
+ bits, of an argument with the specified mode and type. If it is
+ not defined, `PARM_BOUNDARY' is used for all arguments.
+
+`FUNCTION_ARG_REGNO_P (REGNO)'
+ A C expression that is nonzero if REGNO is the number of a hard
+ register in which function arguments are sometimes passed. This
+ does _not_ include implicit arguments such as the static chain and
+ the structure-value address. On many machines, no registers can be
+ used for this purpose since all function arguments are pushed on
+ the stack.
+
+`LOAD_ARGS_REVERSED'
+ If defined, the order in which arguments are loaded into their
+ respective argument registers is reversed so that the last
+ argument is loaded first. This macro only affects arguments
+ passed in registers.
+
+
+\1f
+File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
+
+10.10.8 How Scalar Function Values Are Returned
+-----------------------------------------------
+
+This section discusses the macros that control returning scalars as
+values--values that can fit in registers.
+
+`TRADITIONAL_RETURN_FLOAT'
+ Define this macro if `-traditional' should not cause functions
+ declared to return `float' to convert the value to `double'.
+
+`FUNCTION_VALUE (VALTYPE, FUNC)'
+ A C expression to create an RTX representing the place where a
+ function returns a value of data type VALTYPE. VALTYPE is a tree
+ node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
+ the machine mode used to represent that type. On many machines,
+ only the mode is relevant. (Actually, on most machines, scalar
+ values are returned in the same place regardless of mode).
+
+ The value of the expression is usually a `reg' RTX for the hard
+ register where the return value is stored. The value can also be a
+ `parallel' RTX, if the return value is in multiple places. See
+ `FUNCTION_ARG' for an explanation of the `parallel' form.
+
+ If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same
+ promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar
+ type.
+
+ If the precise function being called is known, FUNC is a tree node
+ (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
+ makes it possible to use a different value-returning convention
+ for specific functions when all their calls are known.
+
+ `FUNCTION_VALUE' is not used for return vales with aggregate data
+ types, because these are returned in another way. See
+ `STRUCT_VALUE_REGNUM' and related macros, below.
+
+`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
+ Define this macro if the target machine has "register windows" so
+ that the register in which a function returns its value is not the
+ same as the one in which the caller sees the value.
+
+ For such machines, `FUNCTION_VALUE' computes the register in which
+ the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
+ defined in a similar fashion to tell the function where to put the
+ value.
+
+ If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
+ serves both purposes.
+
+ `FUNCTION_OUTGOING_VALUE' is not used for return vales with
+ aggregate data types, because these are returned in another way.
+ See `STRUCT_VALUE_REGNUM' and related macros, below.
+
+`LIBCALL_VALUE (MODE)'
+ A C expression to create an RTX representing the place where a
+ library function returns a value of mode MODE. If the precise
+ function being called is known, FUNC is a tree node
+ (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
+ makes it possible to use a different value-returning convention
+ for specific functions when all their calls are known.
+
+ Note that "library function" in this context means a compiler
+ support routine, used to perform arithmetic, whose name is known
+ specially by the compiler and was not mentioned in the C code being
+ compiled.
+
+ The definition of `LIBRARY_VALUE' need not be concerned aggregate
+ data types, because none of the library functions returns such
+ types.
+
+`FUNCTION_VALUE_REGNO_P (REGNO)'
+ A C expression that is nonzero if REGNO is the number of a hard
+ register in which the values of called function may come back.
+
+ A register whose use for returning values is limited to serving as
+ the second of a pair (for a value of type `double', say) need not
+ be recognized by this macro. So for most machines, this definition
+ suffices:
+
+ #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
+
+ If the machine has register windows, so that the caller and the
+ called function use different registers for the return value, this
+ macro should recognize only the caller's register numbers.
+
+`APPLY_RESULT_SIZE'
+ Define this macro if `untyped_call' and `untyped_return' need more
+ space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
+ restoring an arbitrary return value.
+
+\1f
+File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
+
+10.10.9 How Large Values Are Returned
+-------------------------------------
+
+When a function value's mode is `BLKmode' (and in some other cases),
+the value is not returned according to `FUNCTION_VALUE' (*note Scalar
+Return::). Instead, the caller passes the address of a block of memory
+in which the value should be stored. This address is called the
+"structure value address".
+
+ This section describes how to control returning structure values in
+memory.
+
+`RETURN_IN_MEMORY (TYPE)'
+ A C expression which can inhibit the returning of certain function
+ values in registers, based on the type of value. A nonzero value
+ says to return the function value in memory, just as large
+ structures are always returned. Here TYPE will be a C expression
+ of type `tree', representing the data type of the value.
+
+ Note that values of mode `BLKmode' must be explicitly handled by
+ this macro. Also, the option `-fpcc-struct-return' takes effect
+ regardless of this macro. On most systems, it is possible to
+ leave the macro undefined; this causes a default definition to be
+ used, whose value is the constant 1 for `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
+ `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
+
+`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 `RETURN_IN_MEMORY' macro.
+
+ If not defined, this defaults to the value 1.
+
+`STRUCT_VALUE_REGNUM'
+ If the structure value address is passed in a register, then
+ `STRUCT_VALUE_REGNUM' should be the number of that register.
+
+`STRUCT_VALUE'
+ If the structure value address is not passed in a register, define
+ `STRUCT_VALUE' as an expression returning an RTX for the place
+ where the address is passed. If it returns 0, the address is
+ passed as an "invisible" first argument.
+
+`STRUCT_VALUE_INCOMING_REGNUM'
+ On some architectures the place where the structure value address
+ is found by the called function is not the same place that the
+ caller put it. This can be due to register windows, or it could
+ be because the function prologue moves it to a different place.
+
+ If the incoming location of the structure value address is in a
+ register, define this macro as the register number.
+
+`STRUCT_VALUE_INCOMING'
+ If the incoming location is not a register, then you should define
+ `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
+ called function should find the value. If it should find the
+ value on the stack, define this to create a `mem' which refers to
+ the frame pointer. A definition of 0 means that the address is
+ passed as an "invisible" first argument.
+
+`PCC_STATIC_STRUCT_RETURN'
+ Define this macro if the usual system convention on the target
+ machine for returning structures and unions is for the called
+ function to return the address of a static variable containing the
+ value.
+
+ 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 `-fpcc-struct-return' mode, but it does
+ nothing when you use `-freg-struct-return' mode.
+
+\1f
+File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
+
+10.10.10 Caller-Saves Register Allocation
+-----------------------------------------
+
+If you enable it, GCC can save registers around function calls. This
+makes it possible to use call-clobbered registers to hold variables that
+must live across calls.
+
+`DEFAULT_CALLER_SAVES'
+ Define this macro if function calls on the target machine do not
+ preserve any registers; in other words, if `CALL_USED_REGISTERS'
+ has 1 for all registers. When defined, this macro enables
+ `-fcaller-saves' by default for all optimization levels. It has
+ no effect for optimization levels 2 and higher, where
+ `-fcaller-saves' is the default.
+
+`CALLER_SAVE_PROFITABLE (REFS, CALLS)'
+ A C expression to determine whether it is worthwhile to consider
+ placing a pseudo-register in a call-clobbered hard register and
+ saving and restoring it around each function call. The expression
+ should be 1 when this is worth doing, and 0 otherwise.
+
+ If you don't define this macro, a default is used which is good on
+ most machines: `4 * CALLS < REFS'.
+
+`HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)'
+ A C expression specifying which mode is required for saving NREGS
+ of a pseudo-register in call-clobbered hard register REGNO. If
+ REGNO is unsuitable for caller save, `VOIDmode' should be
+ returned. For most machines this macro need not be defined since
+ GCC will select the smallest suitable mode.
+
+\1f
+File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
+
+10.10.11 Function Entry and Exit
+--------------------------------
+
+This section describes the macros that output function entry
+("prologue") and exit ("epilogue") code.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
+ HOST_WIDE_INT SIZE)
+ If defined, a function 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 SIZE additional bytes
+ of storage for the local variables. SIZE is an integer. 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.
+
+ To determine which registers to save, the macro can refer to the
+ array `regs_ever_live': element R is nonzero if hard register R is
+ used anywhere within the function. This implies the function
+ prologue should save register R, provided it is not one of the
+ call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must
+ likewise use `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.
+
+ 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
+ `frame_pointer_needed'. The variable's value will be 1 at run
+ time in a function that needs a frame pointer. *Note
+ 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 `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.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
+ If defined, a function that outputs assembler code at the end of a
+ prologue. This should be used when the function prologue is being
+ emitted as RTL, and you have some extra assembler that needs to be
+ emitted. *Note prologue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
+ If defined, a function that outputs assembler code at the start of
+ an epilogue. This should be used when the function epilogue is
+ being emitted as RTL, and you have some extra assembler that needs
+ to be emitted. *Note epilogue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
+ HOST_WIDE_INT SIZE)
+ If defined, a function 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
+ `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are
+ determined from `regs_ever_live' and `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 `return' and do not define the macro
+ `TARGET_ASM_FUNCTION_EPILOGUE' at all.
+
+ Do not define a pattern named `return' if you want the
+ `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target
+ switches to control whether return instructions or epilogues are
+ used, define a `return' pattern with a validity condition that
+ tests the target switches appropriately. If the `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
+ `frame_pointer_needed'. The variable's value will be 1 when
+ compiling a function that needs a frame pointer.
+
+ Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and
+ `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
+ The C variable `current_function_is_leaf' is nonzero for such a
+ function. *Note 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 `-mrtd' pops arguments in functions that take a fixed
+ number of arguments.
+
+ Your definition of the macro `RETURN_POPS_ARGS' decides which
+ functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE'
+ needs to know what was decided. The variable that is called
+ `current_function_pops_args' is the number of bytes of its
+ arguments that a function should pop. *Note Scalar Return::.
+
+ * A region of `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 `<varargs.h>' and
+ `<stdarg.h>'.
+
+ * 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.
+
+ * A region of at least 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.
+
+ * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a
+ region of `current_function_outgoing_args_size' bytes to be
+ used for outgoing argument lists of the function. *Note
+ Stack Arguments::.
+
+ Normally, it is necessary for the macros
+ `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
+ to treat leaf functions specially. The C variable
+ `current_function_is_leaf' is nonzero for such a function.
+
+`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 `EXIT_IGNORE_STACK'.
+
+`EPILOGUE_USES (REGNO)'
+ Define this macro as a C expression that is nonzero for registers
+ that are used by the epilogue or the `return' pattern. The stack
+ and frame pointer registers are already be assumed to be used as
+ needed.
+
+`EH_USES (REGNO)'
+ Define this macro as a C expression that is nonzero for registers
+ that are used by the exception handling mechanism, and so should
+ be considered live on entry to an exception edge.
+
+`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.
+
+`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
+ A C expression that returns 1 if INSN can be placed in delay slot
+ number N of the epilogue.
+
+ The argument 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 `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.
+
+ The insns accepted to fill the epilogue delay slots are put in an
+ RTL list made with `insn_list' objects, stored in the variable
+ `current_function_epilogue_delay_list'. The insn for the first
+ delay slot comes first in the list. Your definition of the macro
+ `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
+ outputting the insns in this list, usually by calling
+ `final_scan_insn'.
+
+ You need not define this macro if you did not define
+ `DELAY_SLOTS_FOR_EPILOGUE'.
+
+`ASM_OUTPUT_MI_THUNK (FILE, THUNK_FNDECL, DELTA, 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 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 `this' pointer
+ in C++. This is the incoming argument _before_ the function
+ prologue, e.g. `%o0' on a sparc. The addition must preserve the
+ values of all other incoming arguments.
+
+ After the addition, emit code to jump to FUNCTION, which is a
+ `FUNCTION_DECL'. This is a direct pure jump, not a call, and does
+ not touch the return address. Hence returning from FUNCTION will
+ return to whoever called the current `thunk'.
+
+ The effect must be as if FUNCTION had been called directly with
+ the adjusted first argument. This macro is responsible for
+ emitting all of the code for a thunk function;
+ `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
+ are not invoked.
+
+ The THUNK_FNDECL is redundant. (DELTA and 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++ front end will generate a less efficient heavyweight thunk
+ that calls FUNCTION instead of jumping to it. The generic
+ approach does not support varargs.
+
+\1f
+File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling
+
+10.10.12 Generating Code for Profiling
+--------------------------------------
+
+These macros will help you generate code for profiling.
+
+`FUNCTION_PROFILER (FILE, LABELNO)'
+ A C statement or compound statement to output to FILE some
+ assembler code to call the profiling subroutine `mcount'.
+
+ The details of how `mcount' expects to be called are determined by
+ your operating system environment, not by GCC. 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.
+
+ Older implementations of `mcount' expect the address of a counter
+ variable to be loaded into some register. The name of this
+ variable is `LP' followed by the number LABELNO, so you would
+ generate the name using `LP%d' in a `fprintf'.
+
+`PROFILE_HOOK'
+ A C statement or compound statement to output to FILE some assembly
+ code to call the profiling subroutine `mcount' even the target does
+ not support profiling.
+
+`NO_PROFILE_COUNTERS'
+ Define this macro if the `mcount' subroutine on your system does
+ not need a counter variable allocated for each function. This is
+ true for almost all modern implementations. If you define this
+ macro, you must not use the LABELNO argument to
+ `FUNCTION_PROFILER'.
+
+`PROFILE_BEFORE_PROLOGUE'
+ Define this macro if the code for function profiling should come
+ before the function prologue. Normally, the profiling code comes
+ after.
+
+`TARGET_ALLOWS_PROFILING_WITHOUT_FRAME_POINTER'
+ On some targets, it is impossible to use profiling when the frame
+ pointer has been omitted. For example, on x86 GNU/Linux systems,
+ the `mcount' routine provided by the GNU C Library finds the
+ address of the routine that called the routine that called `mcount'
+ by looking in the immediate caller's stack frame. If the immediate
+ caller has no frame pointer, this lookup will fail.
+
+ By default, GCC assumes that the target does allow profiling when
+ the frame pointer is omitted. This macro should be defined to a C
+ expression that evaluates to `false' if the target does not allow
+ profiling when the frame pointer is omitted.
+
+
+\1f
+File: gccint.info, Node: Tail Calls, Prev: Profiling, Up: Stack and Calling
+
+10.10.13 Permitting tail calls
+------------------------------
+
+`FUNCTION_OK_FOR_SIBCALL (DECL)'
+ A C expression that evaluates to true if it is ok to perform a
+ sibling call to DECL from the current function.
+
+ It is not uncommon for limitations of calling conventions to
+ prevent tail calls to functions outside the current unit of
+ translation, or during PIC compilation. Use this macro to enforce
+ these restrictions, as the `sibcall' md pattern can not fail, or
+ fall over to a "normal" call.
+
+\1f
+File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
+
+10.11 Implementing the Varargs Macros
+=====================================
+
+GCC comes with an implementation of `<varargs.h>' and `<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.
+
+ ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in
+the calling convention for `va_start'. The traditional implementation
+takes just one argument, which is the variable in which to store the
+argument pointer. The ISO implementation of `va_start' takes an
+additional second argument. The user is supposed to write the last
+named argument of the function here.
+
+ However, `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.
+
+`__builtin_saveregs ()'
+ Use this built-in function to save the argument registers in
+ memory so that the varargs mechanism can access them. Both ISO
+ and traditional versions of `va_start' must use
+ `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see
+ below) instead.
+
+ On some machines, `__builtin_saveregs' is open-coded under the
+ control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines,
+ it calls a routine written in assembler language, found in
+ `libgcc2.c'.
+
+ Code generated for the call to `__builtin_saveregs' appears at the
+ beginning of the function, as opposed to where the call to
+ `__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.
+
+`__builtin_args_info (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 `CUMULATIVE_ARGS'
+ data type to record how many registers in each category have been
+ used so far
+
+ `__builtin_args_info' accesses the same data structure of type
+ `CUMULATIVE_ARGS' after the ordinary argument layout is finished
+ with it, with CATEGORY specifying which word to access. Thus, the
+ value indicates the first unused register in a given category.
+
+ Normally, you would use `__builtin_args_info' in the implementation
+ of `va_start', accessing each category just once and storing the
+ value in the `va_list' object. This is because `va_list' will
+ have to update the values, and there is no way to alter the values
+ accessed by `__builtin_args_info'.
+
+`__builtin_next_arg (LASTARG)'
+ This is the equivalent of `__builtin_args_info', for stack
+ arguments. It returns the address of the first anonymous stack
+ argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
+ the address of the location above the first anonymous stack
+ argument. Use it in `va_start' to initialize the pointer for
+ fetching arguments from the stack. Also use it in `va_start' to
+ verify that the second parameter LASTARG is the last named argument
+ of the current function.
+
+`__builtin_classify_type (OBJECT)'
+ Since each machine has its own conventions for which data types are
+ passed in which kind of register, your implementation of `va_arg'
+ has to embody these conventions. The easiest way to categorize the
+ specified data type is to use `__builtin_classify_type' together
+ with `sizeof' and `__alignof__'.
+
+ `__builtin_classify_type' ignores the value of 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 `typeclass.h' defines an enumeration that you can use to
+ interpret the values of `__builtin_classify_type'.
+
+ These machine description macros help implement varargs:
+
+`EXPAND_BUILTIN_SAVEREGS ()'
+ If defined, is a C expression that produces the machine-specific
+ code for a call to `__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 `__builtin_saveregs'.
+
+`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)'
+ This macro offers an alternative to using `__builtin_saveregs' and
+ defining the macro `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 ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure,
+ containing the values that are obtained after processing the named
+ arguments. The arguments MODE and 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 _not_ used for the named
+ arguments, and second, store the size of the data thus pushed into
+ the `int'-valued variable whose name is supplied as the argument
+ 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,
+ `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 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
+ `SETUP_INCOMING_VARARGS' should not generate any instructions in
+ this case.
+
+`STRICT_ARGUMENT_NAMING'
+ Define this macro to be a nonzero value if the location where a
+ function argument is passed depends on whether or not it is a
+ named argument.
+
+ This macro controls how the NAMED argument to `FUNCTION_ARG' is
+ set for varargs and stdarg functions. If this macro returns a
+ nonzero value, the NAMED argument is always true for named
+ arguments, and false for unnamed arguments. If it returns a value
+ of zero, but `SETUP_INCOMING_VARARGS' is defined, then all
+ arguments are treated as named. Otherwise, all named arguments
+ except the last are treated as named.
+
+ You need not define this macro if it always returns zero.
+
+`PRETEND_OUTGOING_VARARGS_NAMED'
+ If you need to conditionally change ABIs so that one works with
+ `SETUP_INCOMING_VARARGS', but the other works like neither
+ `SETUP_INCOMING_VARARGS' nor `STRICT_ARGUMENT_NAMING' was defined,
+ then define this macro to return nonzero if
+ `SETUP_INCOMING_VARARGS' is used, zero otherwise. Otherwise, you
+ should not define this macro.
+
+\1f
+File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
+
+10.12 Trampolines for Nested Functions
+======================================
+
+A "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 GCC 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.
+
+`TRAMPOLINE_TEMPLATE (FILE)'
+ A C statement to output, on the stream 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.
+
+`TRAMPOLINE_SECTION'
+ The name of a subroutine to switch to the section in which the
+ trampoline template is to be placed (*note Sections::). The
+ default is a value of `readonly_data_section', which places the
+ trampoline in the section containing read-only data.
+
+`TRAMPOLINE_SIZE'
+ A C expression for the size in bytes of the trampoline, as an
+ integer.
+
+`TRAMPOLINE_ALIGNMENT'
+ Alignment required for trampolines, in bits.
+
+ If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
+ is used for aligning trampolines.
+
+`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)'
+ A C statement to initialize the variable parts of a trampoline.
+ ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
+ for the address of the nested function; STATIC_CHAIN is an RTX for
+ the static chain value that should be passed to the function when
+ it is called.
+
+`TRAMPOLINE_ADJUST_ADDRESS (ADDR)'
+ A C statement that should perform any machine-specific adjustment
+ in the address of the trampoline. Its argument contains the
+ address that was passed to `INITIALIZE_TRAMPOLINE'. In case the
+ address to be used for a function call should be different from
+ the address in which the template was stored, the different
+ address should be assigned to ADDR. If this macro is not defined,
+ ADDR will be used for function calls.
+
+`ALLOCATE_TRAMPOLINE (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.
+
+ 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 `TARGET_ASM_FUNCTION_PROLOGUE' and
+ `TARGET_ASM_FUNCTION_EPILOGUE'.
+
+ FP points to a data structure, a `struct function', which
+ describes the compilation status of the immediate containing
+ function of the function which the trampoline is for. Normally
+ (when `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.
+
+ 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.
+
+`INSN_CACHE_SIZE'
+ The total size in bytes of the cache.
+
+`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.
+
+`INSN_CACHE_DEPTH'
+ The number of alternative cache lines that can hold any particular
+ memory location.
+
+ Alternatively, if the machine has system calls or instructions to
+clear the instruction cache directly, you can define the following
+macro.
+
+`CLEAR_INSN_CACHE (BEG, END)'
+ If defined, expands to a C expression clearing the _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 `asm' statements. Both BEG and END are both pointer
+ expressions.
+
+ 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 `m68k.h' as a guide.
+
+`TRANSFER_FROM_TRAMPOLINE'
+ Define this macro if trampolines need a special subroutine to do
+ their work. The macro should expand to a series of `asm'
+ statements which will be compiled with GCC. They go in a library
+ function named `__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 `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.
+
+\1f
+File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
+
+10.13 Implicit Calls to Library Routines
+========================================
+
+Here is an explanation of implicit calls to library routines.
+
+`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 `__mulsi3',
+ a function defined in `libgcc.a'.
+
+`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 `__divsi3', a
+ function defined in `libgcc.a'.
+
+`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 `__udivsi3',
+ a function defined in `libgcc.a'.
+
+`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
+ `__modsi3', a function defined in `libgcc.a'.
+
+`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
+ `__umodsi3', a function defined in `libgcc.a'.
+
+`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 `__muldi3',
+ a function defined in `libgcc.a'.
+
+`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 `__divdi3', a
+ function defined in `libgcc.a'.
+
+`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 `__udivdi3',
+ a function defined in `libgcc.a'.
+
+`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
+ `__moddi3', a function defined in `libgcc.a'.
+
+`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
+ `__umoddi3', a function defined in `libgcc.a'.
+
+`INIT_TARGET_OPTABS'
+ Define this macro as a C statement that declares additional library
+ routines renames existing ones. `init_optabs' calls this macro
+ after initializing all the normal library routines.
+
+`FLOAT_LIB_COMPARE_RETURNS_BOOL'
+ Define this macro as a C statement that returns nonzero if a call
+ to the floating point comparison library function will return a
+ boolean value that indicates the result of the comparison. It
+ should return zero if one of gcc's own libgcc functions is called.
+
+ Most ports don't need to define this macro.
+
+`TARGET_EDOM'
+ The value of `EDOM' on the target machine, as a C integer constant
+ expression. If you don't define this macro, GCC does not attempt
+ to deposit the value of `EDOM' into `errno' directly. Look in
+ `/usr/include/errno.h' to find the value of `EDOM' on your system.
+
+ If you do not define `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
+ `matherr' when there is an error, then you should leave
+ `TARGET_EDOM' undefined so that `matherr' is used normally.
+
+`GEN_ERRNO_RTX'
+ Define this macro as a C expression to create an rtl expression
+ that refers to the global "variable" `errno'. (On certain systems,
+ `errno' may not actually be a variable.) If you don't define this
+ macro, a reasonable default is used.
+
+`TARGET_MEM_FUNCTIONS'
+ Define this macro if GCC should generate calls to the ISO C (and
+ System V) library functions `memcpy', `memmove' and `memset'
+ rather than the BSD functions `bcopy' and `bzero'.
+
+`LIBGCC_NEEDS_DOUBLE'
+ Define this macro if `float' arguments cannot be passed to library
+ routines (so they must be converted to `double'). This macro
+ affects both how library calls are generated and how the library
+ routines in `libgcc.a' accept their arguments. It is useful on
+ machines where floating and fixed point arguments are passed
+ differently, such as the i860.
+
+`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.
+
+\1f
+File: gccint.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
+
+10.14 Addressing Modes
+======================
+
+This is about addressing modes.
+
+`HAVE_PRE_INCREMENT'
+`HAVE_PRE_DECREMENT'
+`HAVE_POST_INCREMENT'
+`HAVE_POST_DECREMENT'
+ A C expression that is nonzero if the machine supports
+ pre-increment, pre-decrement, post-increment, or post-decrement
+ addressing respectively.
+
+`HAVE_PRE_MODIFY_DISP'
+`HAVE_POST_MODIFY_DISP'
+ A C expression that is nonzero if the machine supports pre- or
+ post-address side-effect generation involving constants other than
+ the size of the memory operand.
+
+`HAVE_PRE_MODIFY_REG'
+`HAVE_POST_MODIFY_REG'
+ A C expression that is nonzero if the machine supports pre- or
+ post-address side-effect generation involving a register
+ displacement.
+
+`CONSTANT_ADDRESS_P (X)'
+ A C expression that is 1 if the RTX X is a constant which is a
+ valid address. On most machines, this can be defined as
+ `CONSTANT_P (X)', but a few machines are more restrictive in which
+ constant addresses are supported.
+
+ `CONSTANT_P' accepts integer-values expressions whose values are
+ not explicitly known, such as `symbol_ref', `label_ref', and
+ `high' expressions and `const' arithmetic expressions, in addition
+ to `const_int' and `const_double' expressions.
+
+`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 `GO_IF_LEGITIMATE_ADDRESS'
+ would ever accept.
+
+`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
+ A C compound statement with a conditional `goto LABEL;' executed
+ if X (an RTX) is a legitimate memory address on the target machine
+ for a memory operand of mode 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.
+
+ Compiler source files that want to use the strict variant of this
+ macro define the macro `REG_OK_STRICT'. You should use an `#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
+ `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.
+
+ Normally, constant addresses which are the sum of a `symbol_ref'
+ and an integer are stored inside a `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 `const' as legitimate.
+
+ Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
+ sums that are not marked with `const'. It assumes that a naked
+ `plus' indicates indexing. If so, then you _must_ reject such
+ naked constant sums as illegitimate addresses, so that none of
+ them will be given to `PRINT_OPERAND_ADDRESS'.
+
+ On some machines, whether a symbolic address is legitimate depends
+ on the section that the address refers to. On these machines,
+ define the macro `ENCODE_SECTION_INFO' to store the information
+ into the `symbol_ref', and then check for it here. When you see a
+ `const', you will have to look inside it to find the `symbol_ref'
+ in order to determine the section. *Note Assembler Format::.
+
+ 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 `saveable_obstack'. You will have to
+ modify `ASM_OUTPUT_LABELREF' to remove and decode the added text
+ and output the name accordingly, and define `STRIP_NAME_ENCODING'
+ to access the original name string.
+
+ You can check the information stored here into the `symbol_ref' in
+ the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and
+ `PRINT_OPERAND_ADDRESS'.
+
+`REG_OK_FOR_BASE_P (X)'
+ A C expression that is nonzero if X (assumed to be a `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 `REG_OK_STRICT' as described above. This
+ usually requires two variant definitions, of which `REG_OK_STRICT'
+ controls the one actually used.
+
+`REG_MODE_OK_FOR_BASE_P (X, MODE)'
+ A C expression that is just like `REG_OK_FOR_BASE_P', except that
+ that expression may examine the mode of the memory reference in
+ MODE. You should define this macro if the mode of the memory
+ reference affects whether a register may be used as a base
+ register. If you define this macro, the compiler will use it
+ instead of `REG_OK_FOR_BASE_P'.
+
+`REG_OK_FOR_INDEX_P (X)'
+ A C expression that is nonzero if X (assumed to be a `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.
+
+`FIND_BASE_TERM (X)'
+ A C expression to determine the base term of address X. This
+ macro is used in only one place: `find_base_term' in alias.c.
+
+ It is always safe for this macro to not be defined. It exists so
+ that alias analysis can understand machine-dependent addresses.
+
+ The typical use of this macro is to handle addresses containing a
+ label_ref or symbol_ref within an UNSPEC.
+
+`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
+ A C compound statement that attempts to replace X with a valid
+ memory address for an operand of mode MODE. WIN will be a C
+ statement label elsewhere in the code; the macro definition may use
+
+ GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
+
+ to avoid further processing if the address has become legitimate.
+
+ X will always be the result of a call to `break_out_memory_refs',
+ and OLDX will be the operand that was given to that function to
+ produce X.
+
+ The code generated by this macro should not alter the substructure
+ of X. If it transforms X into a more legitimate form, it should
+ assign X (which will always be a C variable) a new value.
+
+ It is not necessary for this macro to come up with a legitimate
+ address. The compiler has standard ways of doing so in all cases.
+ In fact, it is safe for this macro to do nothing. But often a
+ machine-dependent strategy can generate better code.
+
+`LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)'
+ A C compound statement that attempts to replace X, which is an
+ address that needs reloading, with a valid memory address for an
+ operand of mode MODE. WIN will be a C statement label elsewhere
+ in the code. It is not necessary to define this macro, but it
+ might be useful for performance reasons.
+
+ For example, on the i386, it is sometimes possible to use a single
+ reload register instead of two by reloading a sum of two pseudo
+ registers into a register. On the other hand, for number of RISC
+ processors offsets are limited so that often an intermediate
+ address needs to be generated in order to address a stack slot.
+ By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
+ intermediate addresses generated for adjacent some stack slots can
+ be made identical, and thus be shared.
+
+ _Note_: This macro should be used with caution. It is necessary
+ to know something of how reload works in order to effectively use
+ this, and it is quite easy to produce macros that build in too
+ much knowledge of reload internals.
+
+ _Note_: This macro must be able to reload an address created by a
+ previous invocation of this macro. If it fails to handle such
+ addresses then the compiler may generate incorrect code or abort.
+
+ The macro definition should use `push_reload' to indicate parts
+ that need reloading; OPNUM, TYPE and IND_LEVELS are usually
+ suitable to be passed unaltered to `push_reload'.
+
+ The code generated by this macro must not alter the substructure of
+ X. If it transforms X into a more legitimate form, it should
+ assign X (which will always be a C variable) a new value. This
+ also applies to parts that you change indirectly by calling
+ `push_reload'.
+
+ The macro definition may use `strict_memory_address_p' to test if
+ the address has become legitimate.
+
+ If you want to change only a part of X, one standard way of doing
+ this is to use `copy_rtx'. Note, however, that is unshares only a
+ single level of rtl. Thus, if the part to be changed is not at the
+ top level, you'll need to replace first the top level. It is not
+ necessary for this macro to come up with a legitimate address;
+ but often a machine-dependent strategy can generate better code.
+
+`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
+ A C statement or compound statement with a conditional `goto
+ LABEL;' executed if memory address X (an RTX) can have different
+ meanings depending on the machine mode of the memory reference it
+ is used for or if the address is valid for some modes but not
+ others.
+
+ Autoincrement and autodecrement addresses typically have
+ mode-dependent effects because the amount of the increment or
+ decrement is the size of the operand being addressed. Some
+ machines have other mode-dependent addresses. Many RISC machines
+ have no mode-dependent addresses.
+
+ You may assume that ADDR is a valid address for the machine.
+
+`LEGITIMATE_CONSTANT_P (X)'
+ A C expression that is nonzero if X is a legitimate constant for
+ an immediate operand on the target machine. You can assume that X
+ satisfies `CONSTANT_P', so you need not check this. In fact, `1'
+ is a suitable definition for this macro on machines where anything
+ `CONSTANT_P' is valid.
+
+\1f
+File: gccint.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
+
+10.15 Condition Code Status
+===========================
+
+This describes the condition code status.
+
+ The file `conditions.h' defines a variable `cc_status' to describe
+how the condition code was computed (in case the interpretation of the
+condition code depends on the instruction that it was set by). This
+variable contains the RTL expressions on which the condition code is
+currently based, and several standard flags.
+
+ Sometimes additional machine-specific flags must be defined in the
+machine description header file. It can also add additional
+machine-specific information by defining `CC_STATUS_MDEP'.
+
+`CC_STATUS_MDEP'
+ C code for a data type which is used for declaring the `mdep'
+ component of `cc_status'. It defaults to `int'.
+
+ This macro is not used on machines that do not use `cc0'.
+
+`CC_STATUS_MDEP_INIT'
+ A C expression to initialize the `mdep' field to "empty". The
+ default definition does nothing, since most machines don't use the
+ field anyway. If you want to use the field, you should probably
+ define this macro to initialize it.
+
+ This macro is not used on machines that do not use `cc0'.
+
+`NOTICE_UPDATE_CC (EXP, INSN)'
+ A C compound statement to set the components of `cc_status'
+ appropriately for an insn INSN whose body is EXP. It is this
+ macro's responsibility to recognize insns that set the condition
+ code as a byproduct of other activity as well as those that
+ explicitly set `(cc0)'.
+
+ This macro is not used on machines that do not use `cc0'.
+
+ If there are insns that do not set the condition code but do alter
+ other machine registers, this macro must check to see whether they
+ invalidate the expressions that the condition code is recorded as
+ reflecting. For example, on the 68000, insns that store in address
+ registers do not set the condition code, which means that usually
+ `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
+ But suppose that the previous insn set the condition code based on
+ location `a4@(102)' and the current insn stores a new value in
+ `a4'. Although the condition code is not changed by this, it will
+ no longer be true that it reflects the contents of `a4@(102)'.
+ Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
+ to say that nothing is known about the condition code value.
+
+ The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
+ the results of peephole optimization: insns whose patterns are
+ `parallel' RTXs containing various `reg', `mem' or constants which
+ are just the operands. The RTL structure of these insns is not
+ sufficient to indicate what the insns actually do. What
+ `NOTICE_UPDATE_CC' should do when it sees one is just to run
+ `CC_STATUS_INIT'.
+
+ A possible definition of `NOTICE_UPDATE_CC' is to call a function
+ that looks at an attribute (*note Insn Attributes::) named, for
+ example, `cc'. This avoids having detailed information about
+ patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
+
+`EXTRA_CC_MODES'
+ A list of additional modes for condition code values in registers
+ (*note Jump Patterns::). This macro should expand to a sequence of
+ calls of the macro `CC' separated by white space. `CC' takes two
+ arguments. The first is the enumeration name of the mode, which
+ should begin with `CC' and end with `mode'. The second is a C
+ string giving the printable name of the mode; it should be the
+ same as the first argument, but with the trailing `mode' removed.
+
+ You should only define this macro if additional modes are required.
+
+ A sample definition of `EXTRA_CC_MODES' is:
+ #define EXTRA_CC_MODES \
+ CC(CC_NOOVmode, "CC_NOOV") \
+ CC(CCFPmode, "CCFP") \
+ CC(CCFPEmode, "CCFPE")
+
+`SELECT_CC_MODE (OP, X, Y)'
+ Returns a mode from class `MODE_CC' to be used when comparison
+ operation code OP is applied to rtx X and Y. For example, on the
+ Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::
+ for a description of the reason for this definition)
+
+ #define SELECT_CC_MODE(OP,X,Y) \
+ (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
+ ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
+ : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
+ || GET_CODE (X) == NEG) \
+ ? CC_NOOVmode : CCmode))
+
+ You need not define this macro if `EXTRA_CC_MODES' is not defined.
+
+`CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
+ On some machines not all possible comparisons are defined, but you
+ can convert an invalid comparison into a valid one. For example,
+ the Alpha does not have a `GT' comparison, but you can use an `LT'
+ comparison instead and swap the order of the operands.
+
+ On such machines, define this macro to be a C statement to do any
+ required conversions. CODE is the initial comparison code and OP0
+ and OP1 are the left and right operands of the comparison,
+ respectively. You should modify CODE, OP0, and OP1 as required.
+
+ GCC will not assume that the comparison resulting from this macro
+ is valid but will see if the resulting insn matches a pattern in
+ the `md' file.
+
+ You need not define this macro if it would never change the
+ comparison code or operands.
+
+`REVERSIBLE_CC_MODE (MODE)'
+ A C expression whose value is one if it is always safe to reverse a
+ comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
+ return MODE for a floating-point inequality comparison, then
+ `REVERSIBLE_CC_MODE (MODE)' must be zero.
+
+ You need not define this macro if it would always returns zero or
+ if the floating-point format is anything other than
+ `IEEE_FLOAT_FORMAT'. For example, here is the definition used on
+ the Sparc, where floating-point inequality comparisons are always
+ given `CCFPEmode':
+
+ #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
+
+ A C expression whose value is reversed condition code of the CODE
+ for comparison done in CC_MODE MODE. The macro is used only in
+ case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in
+ case machine has some non-standard way how to reverse certain
+ conditionals. For instance in case all floating point conditions
+ are non-trapping, compiler may freely convert unordered compares
+ to ordered one. Then definition may look like:
+
+ #define REVERSE_CONDITION(CODE, MODE) \
+ ((MODE) != CCFPmode ? reverse_condition (CODE) \
+ : reverse_condition_maybe_unordered (CODE))
+
+`REVERSE_CONDEXEC_PREDICATES_P (CODE1, CODE2)'
+ A C expression that returns true if the conditional execution
+ predicate CODE1 is the inverse of CODE2 and vice versa. Define
+ this to return 0 if the target has conditional execution
+ predicates that cannot be reversed safely. If no expansion is
+ specified, this macro is defined as follows:
+
+ #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
+ ((x) == reverse_condition (y))
+
+
+\1f
+File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros
+
+10.16 Describing Relative Costs of Operations
+=============================================
+
+These macros let you describe the relative speed of various operations
+on the target machine.
+
+`CONST_COSTS (X, CODE, OUTER_CODE)'
+ A part of a C `switch' statement that describes the relative costs
+ of constant RTL expressions. It must contain `case' labels for
+ expression codes `const_int', `const', `symbol_ref', `label_ref'
+ and `const_double'. Each case must ultimately reach a `return'
+ statement to return the relative cost of the use of that kind of
+ constant value in an expression. The cost may depend on the
+ precise value of the constant, which is available for examination
+ in X, and the rtx code of the expression in which it is contained,
+ found in OUTER_CODE.
+
+ CODE is the expression code--redundant, since it can be obtained
+ with `GET_CODE (X)'.
+
+`RTX_COSTS (X, CODE, OUTER_CODE)'
+ Like `CONST_COSTS' but applies to nonconstant RTL expressions.
+ This can be used, for example, to indicate how costly a multiply
+ instruction is. In writing this macro, you can use the construct
+ `COSTS_N_INSNS (N)' to specify a cost equal to N fast
+ instructions. OUTER_CODE is the code of the expression in which X
+ is contained.
+
+ This macro is optional; do not define it if the default cost
+ assumptions are adequate for the target machine.
+
+`DEFAULT_RTX_COSTS (X, CODE, OUTER_CODE)'
+ This macro, if defined, is called for any case not handled by the
+ `RTX_COSTS' or `CONST_COSTS' macros. This eliminates the need to
+ put case labels into the macro, but the code, or any functions it
+ calls, must assume that the RTL in X could be of any type that has
+ not already been handled. The arguments are the same as for
+ `RTX_COSTS', and the macro should execute a return statement giving
+ the cost of any RTL expressions that it can handle. The default
+ cost calculation is used for any RTL for which this macro does not
+ return a value.
+
+ This macro is optional; do not define it if the default cost
+ assumptions are adequate for the target machine.
+
+`ADDRESS_COST (ADDRESS)'
+ An expression giving the cost of an addressing mode that contains
+ ADDRESS. If not defined, the cost is computed from the ADDRESS
+ expression and the `CONST_COSTS' values.
+
+ For most CISC machines, the default cost is a good approximation
+ of the true cost of the addressing mode. However, on RISC
+ machines, all instructions normally have the same length and
+ execution time. Hence all addresses will have equal costs.
+
+ In cases where more than one form of an address is known, the form
+ with the lowest cost will be used. If multiple forms have the
+ same, lowest, cost, the one that is the most complex will be used.
+
+ For example, suppose an address that is equal to the sum of a
+ register and a constant is used twice in the same basic block.
+ When this macro is not defined, the address will be computed in a
+ register and memory references will be indirect through that
+ register. On machines where the cost of the addressing mode
+ containing the sum is no higher than that of a simple indirect
+ reference, this will produce an additional instruction and
+ possibly require an additional register. Proper specification of
+ this macro eliminates this overhead for such machines.
+
+ Similar use of this macro is made in strength reduction of loops.
+
+ ADDRESS need not be valid as an address. In such a case, the cost
+ is not relevant and can be any value; invalid addresses need not be
+ assigned a different cost.
+
+ On machines where an address involving more than one register is as
+ cheap as an address computation involving only one register,
+ defining `ADDRESS_COST' to reflect this can cause two registers to
+ be live over a region of code where only one would have been if
+ `ADDRESS_COST' were not defined in that manner. This effect should
+ be considered in the definition of this macro. Equivalent costs
+ should probably only be given to addresses with different numbers
+ of registers on machines with lots of registers.
+
+ This macro will normally either not be defined or be defined as a
+ constant.
+
+`REGISTER_MOVE_COST (MODE, FROM, TO)'
+ A C expression for the cost of moving data of mode MODE from a
+ register in class FROM to one in class TO. The classes are
+ expressed using the enumeration values such as `GENERAL_REGS'. A
+ value of 2 is the default; other values are interpreted relative to
+ that.
+
+ It is not required that the cost always equal 2 when FROM is the
+ same as TO; on some machines it is expensive to move between
+ registers if they are not general registers.
+
+ If reload sees an insn consisting of a single `set' between two
+ hard registers, and if `REGISTER_MOVE_COST' applied to their
+ classes returns a value of 2, reload does not check to ensure that
+ the constraints of the insn are met. Setting a cost of other than
+ 2 will allow reload to verify that the constraints are met. You
+ should do this if the `movM' pattern's constraints do not allow
+ such copying.
+
+`MEMORY_MOVE_COST (MODE, CLASS, IN)'
+ A C expression for the cost of moving data of mode MODE between a
+ register of class CLASS and memory; IN is zero if the value is to
+ be written to memory, nonzero if it is to be read in. This cost
+ is relative to those in `REGISTER_MOVE_COST'. If moving between
+ registers and memory is more expensive than between two registers,
+ you should define this macro to express the relative cost.
+
+ If you do not define this macro, GCC uses a default cost of 4 plus
+ the cost of copying via a secondary reload register, if one is
+ needed. If your machine requires a secondary reload register to
+ copy between memory and a register of CLASS but the reload
+ mechanism is more complex than copying via an intermediate, define
+ this macro to reflect the actual cost of the move.
+
+ GCC defines the function `memory_move_secondary_cost' if secondary
+ reloads are needed. It computes the costs due to copying via a
+ secondary register. If your machine copies from memory using a
+ secondary register in the conventional way but the default base
+ value of 4 is not correct for your machine, define this macro to
+ add some other value to the result of that function. The
+ arguments to that function are the same as to this macro.
+
+`BRANCH_COST'
+ A C expression for the cost of a branch instruction. A value of 1
+ is the default; other values are interpreted relative to that.
+
+ Here are additional macros which do not specify precise relative
+costs, but only that certain actions are more expensive than GCC would
+ordinarily expect.
+
+`SLOW_BYTE_ACCESS'
+ Define this macro as a C expression which is nonzero if accessing
+ less than a word of memory (i.e. a `char' or a `short') is no
+ faster than accessing a word of memory, i.e., if such access
+ require more than one instruction or if there is no difference in
+ cost between byte and (aligned) word loads.
+
+ When this macro is not defined, the compiler will access a field by
+ finding the smallest containing object; when it is defined, a
+ fullword load will be used if alignment permits. Unless bytes
+ accesses are faster than word accesses, using word accesses is
+ preferable since it may eliminate subsequent memory access if
+ subsequent accesses occur to other fields in the same word of the
+ structure, but to different bytes.
+
+`SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)'
+ Define this macro to be the value 1 if memory accesses described
+ by the MODE and ALIGNMENT parameters have a cost many times greater
+ than aligned accesses, for example if they are emulated in a trap
+ handler.
+
+ When this macro is nonzero, the compiler will act as if
+ `STRICT_ALIGNMENT' were nonzero when generating code for block
+ moves. This can cause significantly more instructions to be
+ produced. Therefore, do not set this macro nonzero if unaligned
+ accesses only add a cycle or two to the time for a memory access.
+
+ If the value of this macro is always zero, it need not be defined.
+ If this macro is defined, it should produce a nonzero value when
+ `STRICT_ALIGNMENT' is nonzero.
+
+`DONT_REDUCE_ADDR'
+ Define this macro to inhibit strength reduction of memory
+ addresses. (On some machines, such strength reduction seems to do
+ harm rather than good.)
+
+`MOVE_RATIO'
+ The threshold of number of scalar memory-to-memory move insns,
+ _below_ which a sequence of insns should be generated instead of a
+ string move insn or a library call. Increasing the value will
+ always make code faster, but eventually incurs high cost in
+ increased code size.
+
+ Note that on machines where the corresponding move insn is a
+ `define_expand' that emits a sequence of insns, this macro counts
+ the number of such sequences.
+
+ If you don't define this, a reasonable default is used.
+
+`MOVE_BY_PIECES_P (SIZE, ALIGNMENT)'
+ A C expression used to determine whether `move_by_pieces' will be
+ used to copy a chunk of memory, or whether some other block move
+ mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
+ returns less than `MOVE_RATIO'.
+
+`MOVE_MAX_PIECES'
+ A C expression used by `move_by_pieces' to determine the largest
+ unit a load or store used to copy memory is. Defaults to
+ `MOVE_MAX'.
+
+`USE_LOAD_POST_INCREMENT (MODE)'
+ A C expression used to determine whether a load postincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_INCREMENT'.
+
+`USE_LOAD_POST_DECREMENT (MODE)'
+ A C expression used to determine whether a load postdecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_DECREMENT'.
+
+`USE_LOAD_PRE_INCREMENT (MODE)'
+ A C expression used to determine whether a load preincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_INCREMENT'.
+
+`USE_LOAD_PRE_DECREMENT (MODE)'
+ A C expression used to determine whether a load predecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_DECREMENT'.
+
+`USE_STORE_POST_INCREMENT (MODE)'
+ A C expression used to determine whether a store postincrement is
+ a good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_INCREMENT'.
+
+`USE_STORE_POST_DECREMENT (MODE)'
+ A C expression used to determine whether a store postdecrement is
+ a good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_DECREMENT'.
+
+`USE_STORE_PRE_INCREMENT (MODE)'
+ This macro is used to determine whether a store preincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_INCREMENT'.
+
+`USE_STORE_PRE_DECREMENT (MODE)'
+ This macro is used to determine whether a store predecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_DECREMENT'.
+
+`NO_FUNCTION_CSE'
+ Define this macro if it is as good or better to call a constant
+ function address than to call an address kept in a register.
+
+`NO_RECURSIVE_FUNCTION_CSE'
+ Define this macro if it is as good or better for a function to call
+ itself with an explicit address than to call an address kept in a
+ register.
+
+\1f
+File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros
+
+10.17 Adjusting the Instruction Scheduler
+=========================================
+
+The instruction scheduler may need a fair amount of machine-specific
+adjustment in order to produce good code. GCC provides several target
+hooks for this purpose. It is usually enough to define just a few of
+them: try the first ones in this list first.
+
+ -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
+ This hook returns the maximum number of instructions that can ever
+ issue at the same time on the target machine. The default is one.
+ This value must be constant over the entire compilation. If you
+ need it to vary depending on what the instructions are, you must
+ use `TARGET_SCHED_VARIABLE_ISSUE'.
+
+ -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
+ VERBOSE, rtx INSN, int MORE)
+ This hook is executed by the scheduler after it has scheduled an
+ insn from the ready list. It should return the number of insns
+ which can still be issued in the current cycle. Normally this is
+ `MORE - 1'. You should define this hook if some insns take more
+ machine resources than others, so that fewer insns can follow them
+ in the same cycle. FILE is either a null pointer, or a stdio
+ stream to write any debug output to. VERBOSE is the verbose level
+ provided by `-fsched-verbose-N'. INSN is the instruction that was
+ scheduled.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
+ DEP_INSN, int COST)
+ This function corrects the value of COST based on the relationship
+ between INSN and DEP_INSN through the dependence LINK. It should
+ return the new value. The default is to make no adjustment to
+ COST. This can be used for example to specify to the scheduler
+ that an output- or anti-dependence does not incur the same cost as
+ a data-dependence.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
+ PRIORITY)
+ This hook adjusts the integer scheduling priority PRIORITY of
+ INSN. It should return the new priority. Reduce the priority to
+ execute INSN earlier, increase the priority to execute INSN later.
+ Do not define this hook if you do not need to adjust the
+ scheduling priorities of insns.
+
+ -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
+ *READY, int *N_READYP, int CLOCK)
+ This hook is executed by the scheduler after it has scheduled the
+ ready list, to allow the machine description to reorder it (for
+ example to combine two small instructions together on `VLIW'
+ machines). FILE is either a null pointer, or a stdio stream to
+ write any debug output to. VERBOSE is the verbose level provided
+ by `-fsched-verbose-N'. READY is a pointer to the ready list of
+ instructions that are ready to be scheduled. N_READYP is a
+ pointer to the number of elements in the ready list. The scheduler
+ reads the ready list in reverse order, starting with
+ READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick
+ of the scheduler. You may modify the ready list and the number of
+ ready insns. The return value is the number of insns that can
+ issue this cycle; normally this is just `issue_rate'. See also
+ `TARGET_SCHED_REORDER2'.
+
+ -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
+ rtx *READY, int *N_READY, CLOCK)
+ Like `TARGET_SCHED_REORDER', but called at a different time. That
+ function is called whenever the scheduler starts a new cycle.
+ This one is called once per iteration over a cycle, immediately
+ after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list
+ and return the number of insns to be scheduled in the same cycle.
+ Defining this hook can be useful if there are frequent situations
+ where scheduling one insn causes other insns to become ready in
+ the same cycle. These other insns can then be taken into account
+ properly.
+
+ -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
+ MAX_READY)
+ This hook is executed by the scheduler at the beginning of each
+ block of instructions that are to be scheduled. FILE is either a
+ null pointer, or a stdio stream to write any debug output to.
+ VERBOSE is the verbose level provided by `-fsched-verbose-N'.
+ MAX_READY is the maximum number of insns in the current scheduling
+ region that can be live at the same time. This can be used to
+ allocate scratch space if it is needed, e.g. by
+ `TARGET_SCHED_REORDER'.
+
+ -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
+ This hook is executed by the scheduler at the end of each block of
+ instructions that are to be scheduled. It can be used to perform
+ cleanup of any actions done by the other scheduling hooks. FILE
+ is either a null pointer, or a stdio stream to write any debug
+ output to. VERBOSE is the verbose level provided by
+ `-fsched-verbose-N'.
+
+ -- Target Hook: rtx TARGET_SCHED_CYCLE_DISPLAY (int CLOCK, rtx LAST)
+ This hook is called in verbose mode only, at the beginning of each
+ pass over a basic block. It should insert an insn into the chain
+ after LAST, which has no effect, but records the value CLOCK in
+ RTL dumps and assembly output. Define this hook only if you need
+ this level of detail about what the scheduler is doing.
+
+\1f
+File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros
+
+10.18 Dividing the Output into Sections (Texts, Data, ...)
+==========================================================
+
+An object file is divided into sections containing different types of
+data. In the most common case, there are three sections: the "text
+section", which holds instructions and read-only data; the "data
+section", which holds initialized writable data; and the "bss section",
+which holds uninitialized data. Some systems have other kinds of
+sections.
+
+ The compiler must tell the assembler when to switch sections. These
+macros control what commands to output to tell the assembler this. You
+can also define additional sections.
+
+`TEXT_SECTION_ASM_OP'
+ A C expression whose value is a string, including spacing,
+ containing the assembler operation that should precede
+ instructions and read-only data. Normally `"\t.text"' is right.
+
+`TEXT_SECTION'
+ A C statement that switches to the default section containing
+ instructions. Normally this is not needed, as simply defining
+ `TEXT_SECTION_ASM_OP' is enough. The MIPS port uses this to sort
+ all functions after all data declarations.
+
+`DATA_SECTION_ASM_OP'
+ A C expression whose value is a string, including spacing,
+ containing the assembler operation to identify the following data
+ as writable initialized data. Normally `"\t.data"' is right.
+
+`SHARED_SECTION_ASM_OP'
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as shared data. If not defined,
+ `DATA_SECTION_ASM_OP' will be used.
+
+`BSS_SECTION_ASM_OP'
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as uninitialized global data. If not defined, and
+ neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
+ uninitialized global data will be output in the data section if
+ `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
+ used.
+
+`SHARED_BSS_SECTION_ASM_OP'
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as uninitialized global shared data. If not
+ defined, and `BSS_SECTION_ASM_OP' is, the latter will be used.
+
+`INIT_SECTION_ASM_OP'
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as initialization code. If not defined, GCC will
+ assume such a section does not exist.
+
+`FINI_SECTION_ASM_OP'
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as finalization code. If not defined, GCC will
+ assume such a section does not exist.
+
+`CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)'
+ If defined, an ASM statement that switches to a different section
+ via SECTION_OP, calls FUNCTION, and switches back to the text
+ section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or
+ `FINI_SECTION_ASM_OP' to calls to initialization and finalization
+ functions from the init and fini sections. By default, this macro
+ uses a simple function call. Some ports need hand-crafted
+ assembly code to avoid dependencies on registers initialized in
+ the function prologue or to ensure that constant pools don't end
+ up too far way in the text section.
+
+`FORCE_CODE_SECTION_ALIGN'
+ If defined, an ASM statement that aligns a code section to some
+ arbitrary boundary. This is used to force all fragments of the
+ `.init' and `.fini' sections to have to same alignment and thus
+ prevent the linker from having to add any padding.
+
+`EXTRA_SECTIONS'
+ A list of names for sections other than the standard two, which are
+ `in_text' and `in_data'. You need not define this macro on a
+ system with no other sections (that GCC needs to use).
+
+`EXTRA_SECTION_FUNCTIONS'
+ One or more functions to be defined in `varasm.c'. These
+ functions should do jobs analogous to those of `text_section' and
+ `data_section', for your additional sections. Do not define this
+ macro if you do not define `EXTRA_SECTIONS'.
+
+`READONLY_DATA_SECTION'
+ On most machines, read-only variables, constants, and jump tables
+ are placed in the text section. If this is not the case on your
+ machine, this macro should be defined to be the name of a function
+ (either `data_section' or a function defined in `EXTRA_SECTIONS')
+ that switches to the section to be used for read-only items.
+
+ If these items should be placed in the text section, this macro
+ should not be defined.
+
+`SELECT_SECTION (EXP, RELOC, ALIGN)'
+ A C statement or statements to switch to the appropriate section
+ for output of EXP. You can assume that EXP is either a `VAR_DECL'
+ node or a constant of some sort. RELOC indicates whether the
+ initial value of EXP requires link-time relocations. Bit 1 is set
+ when variable contains local relocations only, while bit 2 is set
+ for global relocations. Select the section by calling
+ `text_section' or one of the alternatives for other sections.
+ ALIGN is the constant alignment in bits.
+
+ Do not define this macro if you put all read-only variables and
+ constants in the read-only data section (usually the text section).
+
+`SELECT_RTX_SECTION (MODE, RTX, ALIGN)'
+ A C statement or statements to switch to the appropriate section
+ for output of RTX in mode MODE. You can assume that RTX is some
+ kind of constant in RTL. The argument MODE is redundant except in
+ the case of a `const_int' rtx. Select the section by calling
+ `text_section' or one of the alternatives for other sections.
+ ALIGN is the constant alignment in bits.
+
+ Do not define this macro if you put all constants in the read-only
+ data section.
+
+`JUMP_TABLES_IN_TEXT_SECTION'
+ Define this macro to be an expression with a nonzero value if jump
+ tables (for `tablejump' insns) should be output in the text
+ section, along with the assembler instructions. Otherwise, the
+ readonly data section is used.
+
+ This macro is irrelevant if there is no separate readonly data
+ section.
+
+`ENCODE_SECTION_INFO (DECL)'
+ Define this macro if references to a symbol or a constant must be
+ treated differently depending on something about the variable or
+ function named by the symbol (such as what section it is in).
+
+ The macro definition, if any, is executed under two circumstances.
+ One is immediately after the rtl for DECL that represents a
+ variable or a function has been created and stored in `DECL_RTL
+ (DECL)'. The value of the rtl will be a `mem' whose address is a
+ `symbol_ref'. The other is immediately after the rtl for DECL
+ that represents a constant has been created and stored in
+ `TREE_CST_RTL (DECL)'. The macro is called once for each distinct
+ constant in a source file.
+
+ The usual thing for this macro to do is to record a flag in the
+ `symbol_ref' (such as `SYMBOL_REF_FLAG') or to store a modified
+ name string in the `symbol_ref' (if one bit is not enough
+ information).
+
+`STRIP_NAME_ENCODING (VAR, SYM_NAME)'
+ Decode SYM_NAME and store the real name part in VAR, sans the
+ characters that encode section info. Define this macro if
+ `ENCODE_SECTION_INFO' alters the symbol's name string.
+
+`UNIQUE_SECTION (DECL, RELOC)'
+ A C statement to build up a unique section name, expressed as a
+ `STRING_CST' node, and assign it to `DECL_SECTION_NAME (DECL)'.
+ RELOC indicates whether the initial value of EXP requires
+ link-time relocations. If you do not define this macro, GCC will
+ use the symbol name prefixed by `.' as the section name. Note -
+ this macro can now be called for uninitialized data items as well
+ as initialized data and functions.
+
+\1f
+File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros
+
+10.19 Position Independent Code
+===============================
+
+This section describes macros that help implement generation of position
+independent code. Simply defining these macros is not enough to
+generate valid PIC; you must also add support to the macros
+`GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as
+`LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do
+something appropriate when the source operand contains a symbolic
+address. You may also need to alter the handling of switch statements
+so that they use relative addresses.
+
+`PIC_OFFSET_TABLE_REGNUM'
+ The register number of the register used to address a table of
+ static data addresses in memory. In some cases this register is
+ defined by a processor's "application binary interface" (ABI).
+ When this macro is defined, RTL is generated for this register
+ once, as with the stack pointer and frame pointer registers. If
+ this macro is not defined, it is up to the machine-dependent files
+ to allocate such a register (if necessary). Note that this
+ register must be fixed when in use (e.g. when `flag_pic' is true).
+
+`PIC_OFFSET_TABLE_REG_CALL_CLOBBERED'
+ Define this macro if the register defined by
+ `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define
+ this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined.
+
+`FINALIZE_PIC'
+ By generating position-independent code, when two different
+ programs (A and B) share a common library (libC.a), the text of
+ the library can be shared whether or not the library is linked at
+ the same address for both programs. In some of these
+ environments, position-independent code requires not only the use
+ of different addressing modes, but also special code to enable the
+ use of these addressing modes.
+
+ The `FINALIZE_PIC' macro serves as a hook to emit these special
+ codes once the function is being compiled into assembly code, but
+ not before. (It is not done before, because in the case of
+ compiling an inline function, it would lead to multiple PIC
+ prologues being included in functions which used inline functions
+ and were compiled to assembly language.)
+
+`LEGITIMATE_PIC_OPERAND_P (X)'
+ A C expression that is nonzero if X is a legitimate immediate
+ operand on the target machine when generating position independent
+ code. You can assume that X satisfies `CONSTANT_P', so you need
+ not check this. You can also assume FLAG_PIC is true, so you need
+ not check it either. You need not define this macro if all
+ constants (including `SYMBOL_REF') can be immediate operands when
+ generating position independent code.
+
+\1f
+File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros
+
+10.20 Defining the Output Assembler Language
+============================================
+
+This section describes macros whose principal purpose is to describe how
+to write instructions in assembler language--rather than what the
+instructions do.