930 lines
43 KiB
Plaintext
930 lines
43 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo-1.47 from the input
|
||
file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the sections entitled "GNU General Public License" and "Boycott"
|
||
are included exactly as in the original, and provided that the entire
|
||
resulting derived work is distributed under the terms of a permission
|
||
notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the sections entitled "GNU General Public
|
||
License" and "Boycott", and this permission notice, may be included in
|
||
translations approved by the Free Software Foundation instead of in the
|
||
original English.
|
||
|
||
|
||
File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
|
||
|
||
Function Entry and Exit
|
||
-----------------------
|
||
|
||
This section describes the macros that output function entry
|
||
("prologue") and exit ("epilogue") code.
|
||
|
||
`FUNCTION_PROLOGUE (FILE, SIZE)'
|
||
A C compound statement that outputs the assembler code for entry
|
||
to a function. The prologue is responsible for setting up the
|
||
stack frame, initializing the frame pointer register, saving
|
||
registers that must be saved, and allocating 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. (`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.
|
||
|
||
* 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 `stdargs.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, in the case that `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 `FUNCTION_PROLOGUE' and
|
||
`FUNCTION_EPILOGUE' to treat leaf functions specially. The C
|
||
variable `leaf_function' 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'.
|
||
|
||
`FUNCTION_EPILOGUE (FILE, SIZE)'
|
||
A C compound statement that outputs the assembler code for exit
|
||
from a function. The epilogue is responsible for restoring the
|
||
saved registers and stack pointer to their values when the
|
||
function was called, and returning control to the caller. This
|
||
macro takes the same arguments as the macro `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
|
||
`FUNCTION_EPILOGUE' at all.
|
||
|
||
Do not define a pattern named `return' if you want the
|
||
`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 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.
|
||
|
||
Normally, it is necessary for `FUNCTION_PROLOGUE' and
|
||
`FUNCTION_EPILOGUE' to treat leaf functions specially. The C
|
||
variable `leaf_function' 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. `FUNCTION_EPILOGUE' needs to
|
||
know what was decided. The variable `current_function_pops_args'
|
||
is the number of bytes of its arguments that a function should pop.
|
||
*Note Scalar Return::.
|
||
|
||
`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
|
||
`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'.
|
||
|
||
|
||
File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling
|
||
|
||
Generating 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'. Before
|
||
calling, the assembler code must load the address of a counter
|
||
variable into a register where `mcount' expects to find the
|
||
address. The name of this variable is `LP' followed by the number
|
||
LABELNO, so you would generate the name using `LP%d' in a
|
||
`fprintf'.
|
||
|
||
The details of how the address should be passed to `mcount' are
|
||
determined by your operating system environment, not by GNU CC. To
|
||
figure them out, compile a small program for profiling using the
|
||
system's installed C compiler and look at the assembler code that
|
||
results.
|
||
|
||
`PROFILE_BEFORE_PROLOGUE'
|
||
Define this macro if the code for function profiling should come
|
||
before the function prologue. Normally, the profiling code comes
|
||
after.
|
||
|
||
`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
|
||
A C statement or compound statement to output to FILE some
|
||
assembler code to initialize basic-block profiling for the current
|
||
object module. This code should call the subroutine
|
||
`__bb_init_func' once per object module, passing it as its sole
|
||
argument the address of a block allocated in the object module.
|
||
|
||
The name of the block is a local symbol made with this statement:
|
||
|
||
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
|
||
|
||
Of course, since you are writing the definition of
|
||
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
|
||
can take a short cut in the definition of this macro and use the
|
||
name that you know will result.
|
||
|
||
The first word of this block is a flag which will be nonzero if the
|
||
object module has already been initialized. So test this word
|
||
first, and do not call `__bb_init_func' if the flag is nonzero.
|
||
|
||
`BLOCK_PROFILER (FILE, BLOCKNO)'
|
||
A C statement or compound statement to increment the count
|
||
associated with the basic block number BLOCKNO. Basic blocks are
|
||
numbered separately from zero within each compilation. The count
|
||
associated with block number BLOCKNO is at index BLOCKNO in a
|
||
vector of words; the name of this array is a local symbol made
|
||
with this statement:
|
||
|
||
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
|
||
|
||
Of course, since you are writing the definition of
|
||
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
|
||
can take a short cut in the definition of this macro and use the
|
||
name that you know will result.
|
||
|
||
|
||
File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
|
||
|
||
Implementing the Varargs Macros
|
||
===============================
|
||
|
||
GNU CC 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.
|
||
|
||
ANSI `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 ANSI 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 ANSI
|
||
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'.
|
||
|
||
Regardless of what code is generated for the call to
|
||
`__builtin_saveregs', it appears at the beginning of the function,
|
||
not where the call to `__builtin_saveregs' is written. 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 ()'
|
||
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.
|
||
|
||
`__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 (ARGS)'
|
||
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'.
|
||
|
||
The argument ARGS is a `tree_list' containing the arguments that
|
||
were passed to `__builtin_saveregs'.
|
||
|
||
If this macro is not defined, the compiler will output an ordinary
|
||
call to the library function `__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 obtain after processing of 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.
|
||
|
||
|
||
File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
|
||
|
||
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 GNU CC how to generate code to allocate and initialize a
|
||
trampoline.
|
||
|
||
The instructions in the trampoline must do two things: load a
|
||
constant address into the static chain register, and jump to the real
|
||
address of the nested function. On CISC machines such as the m68k,
|
||
this requires two instructions, a move immediate and a jump. Then the
|
||
two addresses exist in the trampoline as word-long immediate operands.
|
||
On RISC machines, it is often necessary to load each address into a
|
||
register in two parts. Then pieces of each address form separate
|
||
immediate operands.
|
||
|
||
The code generated to initialize the trampoline must store the
|
||
variable parts--the static chain value and the function address--into
|
||
the immediate operands of the instructions. On a CISC machine, this is
|
||
simply a matter of copying each address to a memory reference at the
|
||
proper offset from the start of the trampoline. On a RISC machine, it
|
||
may be necessary to take out pieces of the address and store them
|
||
separately.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
`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 `FUNCTION_PROLOGUE' and `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.
|
||
|
||
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 GNU CC. 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.
|
||
|
||
|
||
File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
|
||
|
||
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'.
|
||
|
||
`TARGET_MEM_FUNCTIONS'
|
||
Define this macro if GNU CC should generate calls to the System V
|
||
(and ANSI C) library functions `memcpy' and `memset' rather than
|
||
the BSD functions `bcopy' and `bzero'.
|
||
|
||
`LIBGCC_NEEDS_DOUBLE'
|
||
Define this macro if only `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 `libgcc1.c' accept their arguments. It is
|
||
useful on machines where floating and fixed point arguments are
|
||
passed differently, such as the i860.
|
||
|
||
`FLOAT_ARG_TYPE'
|
||
Define this macro to override the type used by the library
|
||
routines to pick up arguments of type `float'. (By default, they
|
||
use a union of `float' and `int'.)
|
||
|
||
The obvious choice would be `float'--but that won't work with
|
||
traditional C compilers that expect all arguments declared as
|
||
`float' to arrive as `double'. To avoid this conversion, the
|
||
library routines ask for the value as some other type and then
|
||
treat it as a `float'.
|
||
|
||
On some systems, no other type will work for this. For these
|
||
systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force
|
||
conversion of the values `double' before they are passed.
|
||
|
||
`FLOATIFY (PASSED-VALUE)'
|
||
Define this macro to override the way library routines redesignate
|
||
a `float' argument as a `float' instead of the type it was passed
|
||
as. The default is an expression which takes the `float' field of
|
||
the union.
|
||
|
||
`FLOAT_VALUE_TYPE'
|
||
Define this macro to override the type used by the library
|
||
routines to return values that ought to have type `float'. (By
|
||
default, they use `int'.)
|
||
|
||
The obvious choice would be `float'--but that won't work with
|
||
traditional C compilers gratuitously convert values declared as
|
||
`float' into `double'.
|
||
|
||
`INTIFY (FLOAT-VALUE)'
|
||
Define this macro to override the way the value of a
|
||
`float'-returning library routine should be packaged in order to
|
||
return it. These functions are actually declared to return type
|
||
`FLOAT_VALUE_TYPE' (normally `int').
|
||
|
||
These values can't be returned as type `float' because traditional
|
||
C compilers would gratuitously convert the value to a `double'.
|
||
|
||
A local variable named `intify' is always available when the macro
|
||
`INTIFY' is used. It is a union of a `float' field named `f' and
|
||
a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'.
|
||
|
||
If you don't define this macro, the default definition works by
|
||
copying the value through that union.
|
||
|
||
`nongcc_SI_type'
|
||
Define this macro as the name of the data type corresponding to
|
||
`SImode' in the system's own C compiler.
|
||
|
||
You need not define this macro if that type is `int', as it usually
|
||
is.
|
||
|
||
`perform_...'
|
||
Define these macros to supply explicit C statements to carry out
|
||
various arithmetic operations on types `float' and `double' in the
|
||
library routines in `libgcc1.c'. See that file for a full list of
|
||
these macros and their arguments.
|
||
|
||
On most machines, you don't need to define any of these macros,
|
||
because the C compiler that comes with the system takes care of
|
||
doing them.
|
||
|
||
`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.
|
||
|
||
|
||
File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
|
||
|
||
Addressing Modes
|
||
================
|
||
|
||
`HAVE_POST_INCREMENT'
|
||
Define this macro if the machine supports post-increment
|
||
addressing.
|
||
|
||
`HAVE_PRE_INCREMENT'
|
||
`HAVE_POST_DECREMENT'
|
||
`HAVE_PRE_DECREMENT'
|
||
Similar for other kinds of addressing.
|
||
|
||
`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.
|
||
|
||
Typically among the subroutines used to define
|
||
`GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for acceptable
|
||
registers for various purposes (one for base registers, one for
|
||
index registers, and so on). 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.
|
||
|
||
You can check the information stored here into the `symbol_ref' in
|
||
the definitions of `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_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.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
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.
|
||
|
||
`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.
|
||
|
||
|
||
File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
|
||
|
||
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 names to be used for additional modes for condition code
|
||
values in registers (*note Jump Patterns::.). These names are
|
||
added to `enum machine_mode' and all have class `MODE_CC'. By
|
||
convention, they should start with `CC' and end with `mode'.
|
||
|
||
You should only define this macro if your machine does not use
|
||
`cc0' and only if additional modes are required.
|
||
|
||
`EXTRA_CC_NAMES'
|
||
A list of C strings giving the names for the modes listed in
|
||
`EXTRA_CC_MODES'. For example, the Sparc defines this macro and
|
||
`EXTRA_CC_MODES' as
|
||
|
||
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode
|
||
#define EXTRA_CC_NAMES "CC_NOOV", "CCFP"
|
||
|
||
This macro is not required if `EXTRA_CC_MODES' is not defined.
|
||
|
||
`SELECT_CC_MODE (OP, X)'
|
||
Returns a mode from class `MODE_CC' to be used when comparison
|
||
operation code OP is applied to rtx X. 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) \
|
||
(GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \
|
||
: (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
|
||
|| GET_CODE (X) == NEG) \
|
||
? CC_NOOVmode : CCmode)
|
||
|
||
This macro is not required if `EXTRA_CC_MODES' is not defined.
|
||
|
||
|