Go to the previous, next section.
In addition to the file `machine.md', a machine description includes a C header file conventionally given the name `machine.h'. This header file defines numerous macros that convey the information about the target machine that does not fit into the scheme of the `.md' file. The file `tm.h' should be a link to `machine.h'. The header file `config.h' includes `tm.h' and most compiler source files include `config.h'.
You can control the compilation driver.
SWITCH_TAKES_ARG (char)
By default, this macro is defined to handle the standard options properly. You need not define it unless you wish to add additional options which take arguments.
WORD_SWITCH_TAKES_ARG (name)
SWITCH_TAKES_ARG is used for multi-character option names.
By default, this macro is defined as
DEFAULT_WORD_SWITCH_TAKES_ARG, which handles the standard options
properly. You need not define WORD_SWITCH_TAKES_ARG unless you
wish to add additional options which take arguments. Any redefinition
should call DEFAULT_WORD_SWITCH_TAKES_ARG and then check for
additional options.
SWITCHES_NEED_SPACES
If this macro is not defined, the default value is 0.
CPP_SPEC
Do not define this macro if it does not need to do anything.
NO_BUILTIN_SIZE_TYPE
__SIZE_TYPE__. The macro __SIZE_TYPE__ must then be defined
by CPP_SPEC instead.
This should be defined if SIZE_TYPE depends on target dependent flags
which are not accessible to the preprocessor. Otherwise, it should not
be defined.
NO_BUILTIN_PTRDIFF_TYPE
__PTRDIFF_TYPE__. The macro __PTRDIFF_TYPE__ must then be
defined by CPP_SPEC instead.
This should be defined if PTRDIFF_TYPE depends on target dependent flags
which are not accessible to the preprocessor. Otherwise, it should not
be defined.
SIGNED_CHAR_SPEC
char will be treated as
unsigned char by cc1.
Do not define this macro unless you need to override the default definition.
CC1_SPEC
cc1. It can also specify how to translate options you
give to GNU CC into options for GNU CC to pass to the cc1.
Do not define this macro if it does not need to do anything.
CC1PLUS_SPEC
cc1plus. It can also specify how to translate options you
give to GNU CC into options for GNU CC to pass to the cc1plus.
Do not define this macro if it does not need to do anything.
ASM_SPEC
Do not define this macro if it does not need to do anything.
ASM_FINAL_SPEC
Do not define this macro if it does not need to do anything.
LINK_SPEC
Do not define this macro if it does not need to do anything.
LIB_SPEC
LINK_SPEC. The difference
between the two is that LIB_SPEC is used at the end of the
command given to the linker.
If this macro is not defined, a default is provided that loads the standard C library from the usual place. See `gcc.c'.
STARTFILE_SPEC
LINK_SPEC. The
difference between the two is that STARTFILE_SPEC is used at
the very beginning of the command given to the linker.
If this macro is not defined, a default is provided that loads the standard C startup file from the usual place. See `gcc.c'.
ENDFILE_SPEC
LINK_SPEC. The
difference between the two is that ENDFILE_SPEC is used at
the very end of the command given to the linker.
Do not define this macro if it does not need to do anything.
LINK_LIBGCC_SPECIAL
gcc should find the library
`libgcc.a' by hand, rather than passing the argument `-lgcc'
to tell the linker to do the search; also, gcc should not
generate `-L' options to pass to the linker (as it normally does).
LINK_LIBGCC_SPECIAL_1
gcc should find the
library `libgcc.a' by hand, rather than passing the argument
`-lgcc' to tell the linker to do the search.
RELATIVE_PREFIX_NOT_LINKDIR
gcc that it should only translate
a `-B' prefix into a `-L' linker option if the prefix
indicates an absolute file name.
STANDARD_EXEC_PREFIX
MD_EXEC_PREFIX
STANDARD_EXEC_PREFIX. MD_EXEC_PREFIX is not searched
when the `-b' option is used, or the compiler is built as a cross
compiler.
STANDARD_STARTFILE_PREFIX
MD_STARTFILE_PREFIX
MD_EXEC_PREFIX is not searched when the
`-b' option is used, or when the compiler is built as a cross
compiler.
MD_STARTFILE_PREFIX_1
LOCAL_INCLUDE_DIR
LOCAL_INCLUDE_DIR
comes before SYSTEM_INCLUDE_DIR in the search order.
Cross compilers do not use this macro and do not search either `/usr/local/include' or its replacement.
SYSTEM_INCLUDE_DIR
SYSTEM_INCLUDE_DIR comes before
STANDARD_INCLUDE_DIR in the search order.
Cross compilers do not use this macro and do not search the directory specified.
STANDARD_INCLUDE_DIR
Cross compilers do not use this macro and do not search either `/usr/include' or its replacement.
INCLUDE_DEFAULTS
GCC_INCLUDE_DIR, LOCAL_INCLUDE_DIR,
SYSTEM_INCLUDE_DIR, GPLUSPLUS_INCLUDE_DIR, and
STANDARD_INCLUDE_DIR. In addition, GPLUSPLUS_INCLUDE_DIR
and GCC_INCLUDE_DIR are defined automatically by `Makefile',
and specify private search areas for GCC. The directory
GPLUSPLUS_INCLUDE_DIR is used only for C++ programs.
The definition should be an initializer for an array of structures. Each array element should have two elements: the directory name (a string constant) and a flag for C++-only directories. Mark the end of the array with a null element. For example, here is the definition used for VMS:
#define INCLUDE_DEFAULTS \
{ \
{ "GNU_GXX_INCLUDE:", 1}, \
{ "GNU_CC_INCLUDE:", 0}, \
{ "SYS$SYSROOT:[SYSLIB.]", 0}, \
{ ".", 0}, \
{ 0, 0} \
}
Here is the order of prefixes tried for exec files:
GCC_EXEC_PREFIX, if any.
COMPILER_PATH.
STANDARD_EXEC_PREFIX.
MD_EXEC_PREFIX, if any.
Here is the order of prefixes tried for startfiles:
GCC_EXEC_PREFIX, if any.
LIBRARY_PATH.
STANDARD_EXEC_PREFIX.
MD_EXEC_PREFIX, if any.
MD_STARTFILE_PREFIX, if any.
STANDARD_STARTFILE_PREFIX.
Here are run-time target specifications.
CPP_PREDEFINES
In addition, a parallel set of macros are predefined, whose names are made by appending `__' at the beginning and at the end. These `__' macros are permitted by the ANSI standard, so they are predefined regardless of whether `-ansi' is specified.
For example, on the Sun, one can use the following value:
"-Dmc68000 -Dsun -Dunix"
The result is to define the macros __mc68000__, __sun__
and __unix__ unconditionally, and the macros mc68000,
sun and unix provided `-ansi' is not specified.
STDC_VALUE
__STDC__.
The default is the value `1'.
extern int target_flags;
TARGET_...
TARGET_68020 that tests a bit in
target_flags.
Define a macro TARGET_featurename for each such option.
Its definition should test a bit in target_flags; for example:
#define TARGET_68020 (target_flags & 1)
One place where these macros are used is in the condition-expressions
of instruction patterns. Note how TARGET_68020 appears
frequently in the 68000 machine description file, `m68k.md'.
Another place they are used is in the definitions of the other
macros in the `machine.h' file.
TARGET_SWITCHES
target_flags. Its definition is an initializer
with a subgrouping for each command option.
Each subgrouping contains a string constant, that defines the option
name, and a number, which contains the bits to set in
target_flags. A negative number says to clear bits instead;
the negative of the number is which bits to clear. The actual option
name is made by appending `-m' to the specified name.
One of the subgroupings should have a null string. The number in
this grouping is the default value for target_flags. Any
target options act starting with that value.
Here is an example which defines `-m68000' and `-m68020' with opposite meanings, and picks the latter as the default:
#define TARGET_SWITCHES \
{ { "68020", 1}, \
{ "68000", -1}, \
{ "", 1}}
TARGET_OPTIONS
TARGET_SWITCHES but defines names of command
options that have values. Its definition is an initializer with a
subgrouping for each command option.
Each subgrouping contains a string constant, that defines the fixed part
of the option name, and the address of a variable. The variable, type
char *, is set to the variable part of the given option if the fixed
part matches. The actual option name is made by appending `-m' to the
specified name.
Here is an example which defines `-mshort-data-number'. If the
given option is `-mshort-data-512', the variable m88k_short_data
will be set to the string "512".
extern char *m88k_short_data;
#define TARGET_OPTIONS \
{ { "short-data-", &m88k_short_data } }
TARGET_VERSION
stderr a string
describing the particular machine description choice. Every machine
description should define TARGET_VERSION. For example:
#ifdef MOTOROLA #define TARGET_VERSION \ fprintf (stderr, " (68k, Motorola syntax)"); #else #define TARGET_VERSION \ fprintf (stderr, " (68k, MIT syntax)"); #endif
OVERRIDE_OPTIONS
OVERRIDE_OPTIONS to take account of this. This macro, if
defined, is executed once just after all the command options have been
parsed.
Don't use this macro to turn on various extra optimizations for
`-O'. That is what OPTIMIZATION_OPTIONS is for.
OPTIMIZATION_OPTIONS (level)
level is the optimization level specified; 2 if `-O2' is specified, 1 if `-O' is specified, and 0 if neither is specified.
You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same optimization level on all supported machines. Use this macro to enable machbine-specific optimizations.
Do not examine write_symbols in
this macro! The debugging options are not supposed to alter the
generated code.
CAN_DEBUG_WITHOUT_FP
Note that the definitions of the macros in this table which are sizes or
alignments measured in bits do not need to be constant. They can be C
expressions that refer to static variables, such as the target_flags.
See section Run-time Target Specification.
BITS_BIG_ENDIAN
This macro does not affect the way structure fields are packed into
bytes or words; that is controlled by BYTES_BIG_ENDIAN.
BYTES_BIG_ENDIAN
WORDS_BIG_ENDIAN
FLOAT_WORDS_BIG_ENDIAN
DFmode, XFmode or
TFmode floating point numbers are stored in memory with the word
containing the sign bit at the lowest address; otherwise define it to be
0.
You need not define this macro if the ordering is the same as for multi-word integers.
BITS_PER_UNIT
BITS_PER_WORD
MAX_BITS_PER_WORD
BITS_PER_WORD. Otherwise, it is the constant value that is the
largest value that BITS_PER_WORD can have at run-time.
UNITS_PER_WORD
MAX_UNITS_PER_WORD
UNITS_PER_WORD. Otherwise, it is the constant value that is the
largest value that UNITS_PER_WORD can have at run-time.
POINTER_SIZE
PROMOTE_MODE (m, unsignedp, type)
On most RISC machines, which only have operations that operate on a full
register, define this macro to set m to word_mode if
m is an integer mode narrower than BITS_PER_WORD. In most
cases, only integer modes should be widened because wider-precision
floating-point operations are usually more expensive than their narrower
counterparts.
For most machines, the macro definition does not change unsignedp. However, some machines, have instructions that preferentially handle either signed or unsigned quantities of certain modes. For example, on the DEC Alpha, 32-bit loads from memory and 32-bit add instructions sign-extend the result to 64 bits. On such machines, set unsignedp according to which kind of extension is more efficient.
Do not define this macro if it would never modify m.
PROMOTE_FUNCTION_ARGS
PROMOTE_MODE
should also be done for outgoing function arguments.
PROMOTE_FUNCTION_RETURN
PROMOTE_MODE
should also be done for the return value of functions.
If this macro is defined, FUNCTION_VALUE must perform the same
promotions done by PROMOTE_MODE.
PROMOTE_FOR_CALL_ONLY
PROMOTE_MODE
should only be performed for outgoing function arguments or
function return values, as specified by PROMOTE_FUNCTION_ARGS
and PROMOTE_FUNCTION_RETURN, respectively.
PARM_BOUNDARY
STACK_BOUNDARY
If PUSH_ROUNDING is not defined, the stack will always be aligned
to the specified boundary. If PUSH_ROUNDING is defined and specifies a
less strict alignment than STACK_BOUNDARY, the stack may be
momentarily unaligned while pushing arguments.
FUNCTION_BOUNDARY
BIGGEST_ALIGNMENT
BIGGEST_FIELD_ALIGNMENT
BIGGEST_ALIGNMENT for
structure fields only.
MAX_OFILE_ALIGNMENT
__attribute__ ((aligned (n))) construct. If not defined,
the default value is BIGGEST_ALIGNMENT.
DATA_ALIGNMENT (type, basic-align)
If this macro is not defined, then basic-align is used.
One use of this macro is to increase alignment of medium-size data to
make it all fit in fewer cache lines. Another is to cause character
arrays to be word-aligned so that strcpy calls that copy
constants to character arrays can be done inline.
CONSTANT_ALIGNMENT (constant, basic-align)
If this macro is not defined, then basic-align is used.
The typical use of this macro is to increase alignment for string
constants to be word aligned so that strcpy calls that copy
constants can be done inline.
EMPTY_FIELD_BOUNDARY
int : 0;.
Note that PCC_BITFIELD_TYPE_MATTERS also affects the alignment
that results from an empty field.
STRUCTURE_SIZE_BOUNDARY
If you do not define this macro, the default is the same as
BITS_PER_UNIT.
STRICT_ALIGNMENT
PCC_BITFIELD_TYPE_MATTERS
The behavior is that the type written for a bitfield (int,
short, or other integer type) imposes an alignment for the
entire structure, as if the structure really did contain an ordinary
field of that type. In addition, the bitfield is placed within the
structure so that it would fit within such a field, not crossing a
boundary for it.
Thus, on most machines, a bitfield whose type is written as int
would not cross a four-byte boundary, and would force four-byte
alignment for the whole structure. (The alignment used may not be four
bytes; it is controlled by the other alignment parameters.)
If the macro is defined, its definition should be a C expression; a nonzero value for the expression enables this behavior.
Note that if this macro is not defined, or its value is zero, some bitfields may cross more than one alignment boundary. The compiler can support such references if there are `insv', `extv', and `extzv' insns that can directly reference memory.
The other known way of making bitfields work is to define
STRUCTURE_SIZE_BOUNDARY as large as BIGGEST_ALIGNMENT.
Then every structure can be accessed with fullwords.
Unless the machine has bitfield instructions or you define
STRUCTURE_SIZE_BOUNDARY that way, you must define
PCC_BITFIELD_TYPE_MATTERS to have a nonzero value.
If your aim is to make GNU CC use the same conventions for laying out bitfields as are used by another compiler, here is how to investigate what the other compiler does. Compile and run this program:
struct foo1
{
char x;
char :0;
char y;
};
struct foo2
{
char x;
int :0;
char y;
};
main ()
{
printf ("Size of foo1 is %d\n",
sizeof (struct foo1));
printf ("Size of foo2 is %d\n",
sizeof (struct foo2));
exit (0);
}
If this prints 2 and 5, then the compiler's behavior is what you would
get from PCC_BITFIELD_TYPE_MATTERS.
BITFIELD_NBYTES_LIMITED
ROUND_TYPE_SIZE (struct, size, align)
The default is to round size up to a multiple of align.
ROUND_TYPE_ALIGN (struct, computed, specified)
The default is to use specified if it is larger; otherwise, use
the smaller of computed and BIGGEST_ALIGNMENT
MAX_FIXED_MODE_SIZE
GET_MODE_BITSIZE
(DImode) is assumed.
CHECK_FLOAT_VALUE (mode, value, overflow)
double) for mode mode. This means that you check whether
value fits within the possible range of values for mode
mode on this target machine. The mode mode is always
a mode of class MODE_FLOAT. overflow is nonzero if
the value is already known to be out of range.
If value is not valid or if overflow is nonzero, you should set overflow to 1 and then assign some valid value to value. Allowing an invalid value to go through the compiler can produce incorrect assembler code which may even cause Unix assemblers to crash.
This macro need not be defined if there is no work for it to do.
TARGET_FLOAT_FORMAT
IEEE_FLOAT_FORMAT
VAX_FLOAT_FORMAT
UNKNOWN_FLOAT_FORMAT
The value of this macro is compared with HOST_FLOAT_FORMAT
(see section The Configuration File) to determine whether the target machine has the same
format as the host machine. If any other formats are actually in use on
supported machines, new codes should be defined for them.
The ordering of the component words of floating point values stored in
memory is controlled by FLOAT_WORDS_BIG_ENDIAN for the target
machine and HOST_FLOAT_WORDS_BIG_ENDIAN for the host.
These macros define the sizes and other characteristics of the standard basic data types used in programs being compiled. Unlike the macros in the previous section, these apply to specific features of C and related languages, rather than to fundamental aspects of storage layout.
INT_TYPE_SIZE
int on the
target machine. If you don't define this, the default is one word.
MAX_INT_TYPE_SIZE
int on the target
machine. If this is undefined, the default is INT_TYPE_SIZE.
Otherwise, it is the constant value that is the largest value that
INT_TYPE_SIZE can have at run-time. This is used in cpp.
SHORT_TYPE_SIZE
short on the
target machine. If you don't define this, the default is half a word.
(If this would be less than one storage unit, it is rounded up to one
unit.)
LONG_TYPE_SIZE
long on the
target machine. If you don't define this, the default is one word.
MAX_LONG_TYPE_SIZE
long on the
target machine. If this is undefined, the default is
LONG_TYPE_SIZE. Otherwise, it is the constant value that is the
largest value that LONG_TYPE_SIZE can have at run-time. This is
used in cpp.
LONG_LONG_TYPE_SIZE
long long on the
target machine. If you don't define this, the default is two
words.
CHAR_TYPE_SIZE
char on the
target machine. If you don't define this, the default is one quarter
of a word. (If this would be less than one storage unit, it is rounded up
to one unit.)
MAX_CHAR_TYPE_SIZE
char on the
target machine. If this is undefined, the default is
CHAR_TYPE_SIZE. Otherwise, it is the constant value that is the
largest value that CHAR_TYPE_SIZE can have at run-time. This is
used in cpp.
FLOAT_TYPE_SIZE
float on the
target machine. If you don't define this, the default is one word.
DOUBLE_TYPE_SIZE
double on the
target machine. If you don't define this, the default is two
words.
LONG_DOUBLE_TYPE_SIZE
long double on
the target machine. If you don't define this, the default is two
words.
DEFAULT_SIGNED_CHAR
char should be signed or unsigned by default. The user can
always override this default with the options `-fsigned-char'
and `-funsigned-char'.
DEFAULT_SHORT_ENUMS
enum type
only as many bytes as it takes to represent the range of possible values
of that type. A nonzero value means to do that; a zero value means all
enum types should be allocated like int.
If you don't define the macro, the default is 0.
SIZE_TYPE
size_t is defined using the
contents of the string.
The string can contain more than one keyword. If so, separate them with
spaces, and write first any length keyword, then unsigned if
appropriate, and finally int. The string must exactly match one
of the data type names defined in the function
init_decl_processing in the file `c-decl.c'. You may not
omit int or change the order--that would cause the compiler to
crash on startup.
If you don't define this macro, the default is "long unsigned
int".
PTRDIFF_TYPE
ptrdiff_t is defined using the contents of the string. See
SIZE_TYPE above for more information.
If you don't define this macro, the default is "long int".
WCHAR_TYPE
wchar_t is defined using
the contents of the string. See SIZE_TYPE above for more
information.
If you don't define this macro, the default is "int".
WCHAR_TYPE_SIZE
cpp, which cannot make use of
WCHAR_TYPE.
MAX_WCHAR_TYPE_SIZE
WCHAR_TYPE_SIZE. Otherwise, it is the constant value that is the
largest value that WCHAR_TYPE_SIZE can have at run-time. This is
used in cpp.
OBJC_INT_SELECTORS
int.
If this macro is not defined, then selectors should have the type
struct objc_selector *.
OBJC_SELECTORS_WITHOUT_LABELS
On certain machines, it is important to have a separate label for each selector because this enables the linker to eliminate duplicate selectors.
TARGET_BELL
TARGET_BS
TARGET_TAB
TARGET_NEWLINE
TARGET_VT
TARGET_FF
TARGET_CR
This section explains how to describe what registers the target machine has, and how (in general) they can be used.
The description of which registers a specific instruction can use is done with register classes; see section Register Classes. For information on using registers to access a stack frame, see section Registers That Address the Stack Frame. For passing values in registers, see section Passing Arguments in Registers. For returning values in registers, see section How Scalar Function Values Are Returned.
Registers have various characteristics.
FIRST_PSEUDO_REGISTER
FIRST_PSEUDO_REGISTER-1; thus, the first
pseudo register's number really is assigned the number
FIRST_PSEUDO_REGISTER.
FIXED_REGISTERS
This information is expressed as a sequence of numbers, separated by commas and surrounded by braces. The nth number is 1 if register n is fixed, 0 otherwise.
The table initialized from this macro, and the table initialized by
the following one, may be overridden at run time either automatically,
by the actions of the macro CONDITIONAL_REGISTER_USAGE, or by
the user with the command options `-ffixed-reg',
`-fcall-used-reg' and `-fcall-saved-reg'.
CALL_USED_REGISTERS
FIXED_REGISTERS but has 1 for each register that is
clobbered (in general) by function calls as well as for fixed
registers. This macro therefore identifies the registers that are not
available for general allocation of values that must live across
function calls.
If a register has 0 in CALL_USED_REGISTERS, the compiler
automatically saves it on function entry and restores it on function
exit, if the register is used within the function.
CONDITIONAL_REGISTER_USAGE
fixed_regs and call_used_regs (both of type char
[]) after they have been initialized from the two preceding macros.
This is necessary in case the fixed or call-clobbered registers depend on target flags.
You need not define this macro if it has no work to do.
If the usage of an entire class of registers depends on the target
flags, you may indicate this to GCC by using this macro to modify
fixed_regs and call_used_regs to 1 for each of the
registers in the classes which should not be used by GCC. Also define
the macro REG_CLASS_FROM_LETTER to return NO_REGS if it
is called with a letter for a class that shouldn't be used.
(However, if this class is not included in GENERAL_REGS and all
of the insn patterns whose constraints permit this class are
controlled by target switches, then GCC will automatically avoid using
these registers when the target switches are opposed to them.)
NON_SAVING_SETJMP
setjmp and related functions fail to save the registers, or that
longjmp fails to restore them. To compensate, the compiler
avoids putting variables in registers in functions that use
setjmp.
INCOMING_REGNO (out)
OUTGOING_REGNO (in)
Registers are allocated in order.
REG_ALLOC_ORDER
If this macro is not defined, registers are used lowest numbered first (all else being equal).
One use of this macro is on machines where the highest numbered
registers must always be saved and the save-multiple-registers
instruction supports only sequences of consecutive registers. On such
machines, define REG_ALLOC_ORDER to be an initializer that lists
the highest numbered allocatable register first.
ORDER_REGS_FOR_LOCAL_ALLOC
Store the desired register order in the array reg_alloc_order.
Element 0 should be the register to allocate first; element 1, the next
register; and so on.
The macro body should not assume anything about the contents of
reg_alloc_order before execution of the macro.
On most machines, it is not necessary to define this macro.
This section discusses the macros that describe which kinds of values (specifically, which machine modes) each register can hold, and how many consecutive registers are needed for a given mode.
HARD_REGNO_NREGS (regno, mode)
On a machine where all registers are exactly one word, a suitable definition of this macro is
#define HARD_REGNO_NREGS(REGNO, MODE) \
((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
/ UNITS_PER_WORD))
HARD_REGNO_MODE_OK (regno, mode)
#define HARD_REGNO_MODE_OK(REGNO, MODE) 1
It is not necessary for this macro to check for the numbers of fixed registers, because the allocation mechanism considers them to be always occupied.
On some machines, double-precision values must be kept in even/odd register pairs. The way to implement that is to define this macro to reject odd register numbers for such modes.
The minimum requirement for a mode to be OK in a register is that the `movmode' instruction pattern support moves between the register and any other hard register for which the mode is OK; and that moving a value into the register and back out not alter it.
Since the same instruction used to move SImode will work for all
narrower integer modes, it is not necessary on any machine for
HARD_REGNO_MODE_OK to distinguish between these modes, provided
you define patterns `movhi', etc., to take advantage of this. This
is useful because of the interaction between HARD_REGNO_MODE_OK
and MODES_TIEABLE_P; it is very desirable for all integer modes
to be tieable.
Many machines have special registers for floating point arithmetic. Often people assume that floating point machine modes are allowed only in floating point registers. This is not true. Any registers that can hold integers can safely hold a floating point machine mode, whether or not floating arithmetic can be done on it in those registers. Integer move instructions can be used to move the values.
On some machines, though, the converse is true: fixed-point machine
modes may not go in floating registers. This is true if the floating
registers normalize any value stored in them, because storing a
non-floating value there would garble it. In this case,
HARD_REGNO_MODE_OK should reject fixed-point machine modes in
floating registers. But if the floating registers do not automatically
normalize, if you can store any bit pattern in one and retrieve it
unchanged without a trap, then any machine mode may go in a floating
register, so you can define this macro to say so.
The primary significance of special floating registers is rather that
they are the registers acceptable in floating point arithmetic
instructions. However, this is of no concern to
HARD_REGNO_MODE_OK. You handle it by writing the proper
constraints for those instructions.
On some machines, the floating registers are especially slow to access,
so that it is better to store a value in a stack frame than in such a
register if floating point arithmetic is not being done. As long as the
floating registers are not in class GENERAL_REGS, they will not
be used unless some pattern's constraint asks for one.
MODES_TIEABLE_P (mode1, mode2)
If HARD_REGNO_MODE_OK (r, mode1) and
HARD_REGNO_MODE_OK (r, mode2) are ever different
for any r, then MODES_TIEABLE_P (mode1,
mode2) must be zero.
On some machines, a leaf function (i.e., one which makes no calls) can run more efficiently if it does not make its own register window. Often this means it is required to receive its arguments in the registers where they are passed by the caller, instead of the registers where they would normally arrive.
The special treatment for leaf functions generally applies only when other conditions are met; for example, often they may use only those registers for its own variables and temporaries. We use the term "leaf function" to mean a function that is suitable for this special handling, so that functions with no calls are not necessarily "leaf functions".
GNU CC assigns register numbers before it knows whether the function is suitable for leaf function treatment. So it needs to renumber the registers in order to output a leaf function. The following macros accomplish this.
LEAF_REGISTERS
If leaf function treatment involves renumbering the registers, then the registers marked here should be the ones before renumbering--those that GNU CC would ordinarily allocate. The registers which will actually be used in the assembler code, after renumbering, should not be marked with 1 in this vector.
Define this macro only if the target machine offers a way to optimize the treatment of leaf functions.
LEAF_REG_REMAP (regno)
If regno is a register number which should not appear in a leaf function before renumbering, then the expression should yield -1, which will cause the compiler to abort.
Define this macro only if the target machine offers a way to optimize the treatment of leaf functions, and registers need to be renumbered to do this.
Normally, FUNCTION_PROLOGUE and FUNCTION_EPILOGUE must
treat leaf functions specially. It can test the C variable
leaf_function which is nonzero for leaf functions. (The variable
leaf_function is defined only if LEAF_REGISTERS is
defined.)
There are special features to handle computers where some of the "registers" form a stack, as in the 80387 coprocessor for the 80386. Stack registers are normally written by pushing onto the stack, and are numbered relative to the top of the stack.
Currently, GNU CC can only handle one group of stack-like registers, and they must be consecutively numbered.
STACK_REGS
FIRST_STACK_REG
LAST_STACK_REG
These features do not work very well. They exist because they used to be required to generate correct code for the 80387 coprocessor of the 80386. They are no longer used by that machine description and may be removed in a later version of the compiler. Don't use them!
OVERLAPPING_REGNO_P (regno)
If this macro is not defined, it means that none of the hard registers overlap each other. This is the usual situation.
INSN_CLOBBERS_REGNO_P (insn, regno)
If this macro is not defined, it means that no insn clobbers registers mysteriously. This is the usual situation; all else being equal, it is best for the RTL expression to show all the activity.
PRESERVE_DEATH_INFO_REGNO_P (regno)
REG_DEAD notes are needed for hard register number regno
at the time of outputting the assembler code. When this is so, a few
optimizations that take place after register allocation and could
invalidate the death notes are not done when this register is
involved.
You would arrange to preserve death info for a register when some of the code in the machine description which is executed to write the assembler code looks at the death notes. This is necessary only when the actual hardware feature which GNU CC thinks of as a register is not actually a register of the usual sort. (It might, for example, be a hardware stack.)
If this macro is not defined, it means that no death notes need to be preserved. This is the usual situation.
On many machines, the numbered registers are not all equivalent. For example, certain registers may not be allowed for indexed addressing; certain registers may not be allowed in some instructions. These machine restrictions are described to the compiler using register classes.
You define a number of register classes, giving each one a name and saying which of the registers belong to it. Then you can specify register classes that are allowed as operands to particular instruction patterns.
In general, each register will belong to several classes. In fact, one
class must be named ALL_REGS and contain all the registers. Another
class must be named NO_REGS and contain no registers. Often the
union of two classes will be another class; however, this is not required.
One of the classes must be named GENERAL_REGS. There is nothing
terribly special about the name, but the operand constraint letters
`r' and `g' specify this class. If GENERAL_REGS is
the same as ALL_REGS, just define it as a macro which expands
to ALL_REGS.
Order the classes so that if class x is contained in class y then x has a lower class number than y.
The way classes other than GENERAL_REGS are specified in operand
constraints is through machine-dependent operand constraint letters.
You can define such letters to correspond to various classes, then use
them in operand constraints.
You should define a class for the union of two classes whenever some
instruction allows both classes. For example, if an instruction allows
either a floating point (coprocessor) register or a general register for a
certain operand, you should define a class FLOAT_OR_GENERAL_REGS
which includes both of them. Otherwise you will get suboptimal code.
You must also specify certain redundant information about the register classes: for each class, which classes contain it and which ones are contained in it; for each pair of classes, the largest class contained in their union.
When a value occupying several consecutive registers is expected in a
certain class, all the registers used must belong to that class.
Therefore, register classes cannot be used to enforce a requirement for
a register pair to start with an even-numbered register. The way to
specify this requirement is with HARD_REGNO_MODE_OK.
Register classes used for input-operands of bitwise-and or shift
instructions have a special requirement: each such class must have, for
each fixed-point machine mode, a subclass whose registers can transfer that
mode to or from memory. For example, on some machines, the operations for
single-byte values (QImode) are limited to certain registers. When
this is so, each register class that is used in a bitwise-and or shift
instruction must have a subclass consisting of registers from which
single-byte values can be loaded or stored. This is so that
PREFERRED_RELOAD_CLASS can always have a possible value to return.
enum reg_class
NO_REGS must be first. ALL_REGS
must be the last register class, followed by one more enumeral value,
LIM_REG_CLASSES, which is not a register class but rather
tells how many classes there are.
Each register class has a number, which is the value of casting
the class name to type int. The number serves as an index
in many of the tables described below.
N_REG_CLASSES
#define N_REG_CLASSES (int) LIM_REG_CLASSES
REG_CLASS_NAMES
REG_CLASS_CONTENTS
mask & (1 << r) is 1.
When the machine has more than 32 registers, an integer does not suffice.
Then the integers are replaced by sub-initializers, braced groupings containing
several integers. Each sub-initializer must be suitable as an initializer
for the type HARD_REG_SET which is defined in `hard-reg-set.h'.
REGNO_REG_CLASS (regno)
BASE_REG_CLASS
INDEX_REG_CLASS
REG_CLASS_FROM_LETTER (char)
NO_REGS. The register letter `r',
corresponding to class GENERAL_REGS, will not be passed
to this macro; you do not need to handle it.
REGNO_OK_FOR_BASE_P (num)
REGNO_OK_FOR_INDEX_P (num)
The difference between an index register and a base register is that the index register may be scaled. If an address involves the sum of two registers, neither one of them scaled, then either one may be labeled the "base" and the other the "index"; but whichever labeling is used must fit the machine's constraints of which registers may serve in each capacity. The compiler will try both labelings, looking for one that is valid, and will reload one or both registers only if neither labeling works.
PREFERRED_RELOAD_CLASS (x, class)
#define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
Sometimes returning a more restrictive class makes better code. For
example, on the 68000, when x is an integer constant that is in range
for a `moveq' instruction, the value of this macro is always
DATA_REGS as long as class includes the data registers.
Requiring a data register guarantees that a `moveq' will be used.
If x is a const_double, by returning NO_REGS
you can force x into a memory constant. This is useful on
certain machines where immediate floating values cannot be loaded into
certain kinds of registers.
PREFERRED_OUTPUT_RELOAD_CLASS (x, class)
PREFERRED_RELOAD_CLASS, but for output reloads instead of
input reloads. If you don't define this macro, the default is to use
class, unchanged.
LIMIT_RELOAD_CLASS (mode, class)
Unlike PREFERRED_RELOAD_CLASS, this macro should be used when
there are certain modes that simply can't go in certain reload classes.
The value is a register class; perhaps class, or perhaps another, smaller class.
Don't define this macro unless the target machine has limitations which require the macro to do something nontrivial.
SECONDARY_RELOAD_CLASS (class, mode, x)
SECONDARY_INPUT_RELOAD_CLASS (class, mode, x)
SECONDARY_OUTPUT_RELOAD_CLASS (class, mode, x)
You should define these macros to indicate to the reload phase that it may
need to allocate at least one register for a reload in addition to the
register to contain the data. Specifically, if copying x to a
register class in mode requires an intermediate register,
you should define SECONDARY_INPUT_RELOAD_CLASS to return the
largest register class all of whose registers can be used as
intermediate registers or scratch registers.
If copying a register class in mode to x requires an
intermediate or scratch register, SECONDARY_OUTPUT_RELOAD_CLASS
should be defined to return the largest register class required. If the
requirements for input and output reloads are the same, the macro
SECONDARY_RELOAD_CLASS should be used instead of defining both
macros identically.
The values returned by these macros are often GENERAL_REGS.
Return NO_REGS if no spare register is needed; i.e., if x
can be directly copied to or from a register of class in
mode without requiring a scratch register. Do not define this
macro if it would always return NO_REGS.
If a scratch register is required (either with or without an
intermediate register), you should define patterns for
`reload_inm' or `reload_outm', as required
(see section Standard Pattern Names For Generation. These patterns, which will normally be
implemented with a define_expand, should be similar to the
`movm' patterns, except that operand 2 is the scratch
register.
Define constraints for the reload register and scratch register that contain a single register class. If the original reload register (whose class is class) can meet the constraint given in the pattern, the value returned by these macros is used for the class of the scratch register. Otherwise, two additional reload registers are required. Their classes are obtained from the constraints in the insn pattern.
x might be a pseudo-register or a subreg of a
pseudo-register, which could either be in a hard register or in memory.
Use true_regnum to find out; it will return -1 if the pseudo is
in memory and the hard register number if it is in a register.
These macros should not be used in the case where a particular class of
registers can only be copied to memory and not to another class of
registers. In that case, secondary reload registers are not needed and
would not be helpful. Instead, a stack location must be used to perform
the copy and the movm pattern should use memory as a
intermediate storage. This case often occurs between floating-point and
general registers.
SECONDARY_MEMORY_NEEDED (class1, class2, m)
Do not define this macro if its value would always be zero.
SECONDARY_MEMORY_NEEDED_RTX (mode)
SECONDARY_MEMORY_NEEDED is defined, the compiler
allocates a stack slot for a memory location needed for register copies.
If this macro is defined, the compiler instead uses the memory location
defined by this macro.
Do not define this macro if you do not define
SECONDARY_MEMORY_NEEDED.
SECONDARY_MEMORY_NEEDED_MODE (mode)
BITS_PER_WORD bits and performs the store and
load operations in a mode that many bits wide and whose class is the
same as that of mode.
This is right thing to do on most machines because it ensures that all bits of the register are copied and prevents accesses to the registers in a narrower mode, which some machines prohibit for floating-point registers.
However, this default behavior is not correct on some machines, such as the DEC Alpha, that store short integers in floating-point registers differently than in integer registers. On those machines, the default widening will not work correctly and you must define this macro to suppress that widening in some cases. See the file `alpha.h' for details.
Do not define this macro if you do not define
SECONDARY_MEMORY_NEEDED or if widening mode to a mode that
is BITS_PER_WORD bits wide is correct for your machine.
SMALL_REGISTER_CLASSES
Define SMALL_REGISTER_CLASSES on these machines. When it is
defined, the compiler allows registers explicitly used in the rtl to be
used as spill registers but avoids extending the lifetime of these
registers.
It is always safe to define this macro, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not define this macro when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro.
CLASS_LIKELY_SPILLED_P (class)
The default value of this macro returns 1 if class has exactly one register and zero otherwise. On most machines, this default should be used. Only define this macro to some other expression if pseudo allocated by `local-alloc.c' end up in memory because their hard registers were needed for spill regisers. If this macro returns nonzero for those classes, those pseudos will only be allocated by `global.c', which knows how to reallocate the pseudo to another register. If there would not be another register available for reallocation, you should not change the definition of this macro since the only effect of such a definition would be to slow down register allocation.
CLASS_MAX_NREGS (class, mode)
This is closely related to the macro HARD_REGNO_NREGS. In fact,
the value of the macro CLASS_MAX_NREGS (class, mode)
should be the maximum value of HARD_REGNO_NREGS (regno,
mode) for all regno values in the class class.
This macro helps control the handling of multiple-word values in the reload pass.
CLASS_CANNOT_CHANGE_SIZE
For the example, loading 32-bit integer or floating-point objects into
floating-point registers on the Alpha extends them to 64-bits.
Therefore loading a 64-bit object and then storing it as a 32-bit object
does not store the low-order 32-bits, as would be the case for a normal
register. Therefore, `alpha.h' defines this macro as
FLOAT_REGS.
Three other special macros describe which operands fit which constraint letters.
CONST_OK_FOR_LETTER_P (value, c)
CONST_DOUBLE_OK_FOR_LETTER_P (value, c)
const_double values.
If c is one of those letters, the expression should check that
value, an RTX of code const_double, is in the appropriate
range and return 1 if so, 0 otherwise. If c is not one of those
letters, the value should be 0 regardless of value.
const_double is used for all floating-point constants and for
DImode fixed-point constants. A given letter can accept either
or both kinds of values. It can use GET_MODE to distinguish
between these kinds.
EXTRA_CONSTRAINT (value, c)
For example, on the ROMP, load instructions cannot have their output in r0 if the memory reference contains a symbolic address. Constraint letter `Q' is defined as representing a memory address that does not contain a symbolic address. An alternative is specified with a `Q' constraint on the input and `r' on the output. The next alternative specifies `m' on the input and a register class that does not include r0 on the output.
This describes the stack layout and calling conventions.
Here is the basic stack layout.
STACK_GROWS_DOWNWARD
When we say, "define this macro if ...," it means that the
compiler checks this macro only with #ifdef so the precise
definition used does not matter.
FRAME_GROWS_DOWNWARD
ARGS_GROW_DOWNWARD
STARTING_FRAME_OFFSET
If FRAME_GROWS_DOWNWARD, find the next slot's offset by
subtracting the first slot's length from STARTING_FRAME_OFFSET.
Otherwise, it is found by adding the length of the first slot to the
value STARTING_FRAME_OFFSET.
STACK_POINTER_OFFSET
If ARGS_GROW_DOWNWARD, this is the offset to the location above
the first location at which outgoing arguments are placed.
FIRST_PARM_OFFSET (fundecl)
If ARGS_GROW_DOWNWARD, this is the offset to the location above
the first argument's address.
STACK_DYNAMIC_OFFSET (fundecl)
alloca.
The default value for this macro is STACK_POINTER_OFFSET plus the
length of the outgoing arguments. The default is correct for most
machines. See `function.c' for details.
DYNAMIC_CHAIN_ADDRESS (frameaddr)
If you don't define this macro, the default is to return the value of frameaddr---that is, the stack frame address is also the address of the stack word that points to the previous frame.
SERTUP_FRAME_ADDRESSES ()
RETURN_ADDR_RTX (count, frameaddr)
RETURN_ADDR_IN_PREVIOUS_FRAME is defined.
RETURN_ADDR_IN_PREVIOUS_FRAME
This discusses registers that address the stack frame.
STACK_POINTER_REGNUM
FIXED_REGISTERS. On most machines,
the hardware determines which register this is.
FRAME_POINTER_REGNUM
HARD_FRAME_POINTER_REGNUM
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 actual the hard register number
used for the frame pointer.
You should define this macro only in the very rare circumstances when it
is not possible to calculate the offset between the frame pointer and
the automatic variables until after register allocation has been
completed. When this macro is defined, you must also indicate in your
definition of 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
FIXED_REGISTERS, or arrange to be able to eliminate it
(see section Eliminating Frame Pointer and Arg Pointer).
STATIC_CHAIN_REGNUM
STATIC_CHAIN_INCOMING_REGNUM
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
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.
This is about eliminating the frame pointer and arg pointer.
FRAME_POINTER_REQUIRED
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)
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
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)
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)
INITIAL_FRAME_POINTER_OFFSET. It
specifies the initial difference between the specified pair of
registers. This macro must be defined if ELIMINABLE_REGS is
defined.
LONGJMP_RESTORE_FROM_STACK
longjmp function restores registers from
the stack frames, rather than from those saved specifically by
setjmp. Certain quantities must not be kept in registers across
a call to setjmp on such machines.
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
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.
PUSH_ROUNDING (npushed)
If the target machine does not have a push instruction, do not define this macro. That directs GNU CC to use an alternate strategy: to allocate the entire argument block and then store the arguments into it.
On some machines, the definition
#define PUSH_ROUNDING(BYTES) (BYTES)
will suffice. But on other machines, instructions that appear to push one byte actually push two bytes in an attempt to maintain alignment. Then the definition should be
#define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
ACCUMULATE_OUTGOING_ARGS
current_function_outgoing_args_size. No space will be pushed
onto the stack for each call; instead, the function prologue should
increase the stack frame size by this amount.
Defining both PUSH_ROUNDING and ACCUMULATE_OUTGOING_ARGS
is not proper.
REG_PARM_STACK_SPACE (fndecl)
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.
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)
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, GNU CC uses these two macros instead of
REG_PARM_STACK_SPACE.
OUTGOING_REG_PARM_STACK_SPACE
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
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 (funtype, stack-size)
funtype is a C variable whose value is a tree node that
describes the function in question. Normally it is a node of type
FUNCTION_TYPE that describes the data type of the function.
From this it is possible to obtain the data types of the value and
arguments (if known).
When a call to a library function is being considered, funtype will contain an identifier node for the library function. Thus, if you need to distinguish among various library functions, you can do so by their names. Note that "library function" in this context means a function used to perform arithmetic, whose name is known specially in the compiler and was not mentioned in the C code being compiled.
stack-size is the number of bytes of arguments passed on the stack. If a variable number of bytes is passed, it is zero, and argument popping will always be the responsibility of the calling function.
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.
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)
The arguments are cum, which summarizes all the previous arguments; mode, the machine mode of the argument; type, the data type of the argument as a tree node or 0 if that is not known (which happens for C support library functions); and named, which is 1 for an ordinary argument and 0 for nameless arguments that correspond to `...' in the called function's prototype.
The value of the expression should either be a reg RTX for the
hard register in which to pass the argument, or zero to pass the
argument on the stack.
For machines like the Vax and 68000, where normally all arguments are pushed, zero suffices as a definition.
The usual way to make the ANSI library `stdarg.h' work on a machine
where some arguments are usually passed in registers, is to cause
nameless arguments to be passed on the stack instead. This is done
by making FUNCTION_ARG return 0 whenever named is 0.
You may use the macro MUST_PASS_IN_STACK (mode, type)
in the definition of this macro to determine if this argument is of a
type that must be passed in the stack. If REG_PARM_STACK_SPACE
is not defined and FUNCTION_ARG returns non-zero for such an
argument, the compiler will abort. If REG_PARM_STACK_SPACE is
defined, the argument will be computed in the stack and then loaded into
a register.
FUNCTION_INCOMING_ARG (cum, mode, type, named)
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)
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)
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)
CUMULATIVE_ARGS
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)
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.
When processing a call to a compiler support library function,
libname identifies which one. It is a symbol_ref rtx which
contains the name of the function, as a string. libname is 0 when
an ordinary C function call is being processed. Thus, each time this
macro is called, either libname or fntype is nonzero, but
never both of them at once.
INIT_CUMULATIVE_INCOMING_ARGS (cum, fntype, libname)
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 GNU CC. The
argument libname exists for symmetry with
INIT_CUMULATIVE_ARGS.
FUNCTION_ARG_ADVANCE (cum, mode, type, named)
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)
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.
FUNCTION_ARG_BOUNDARY (mode, type)
PARM_BOUNDARY is used for all arguments.
FUNCTION_ARG_REGNO_P (regno)
This section discusses the macros that control returning scalars as values--values that can fit in registers.
TRADITIONAL_RETURN_FLOAT
float to convert the value to double.
FUNCTION_VALUE (valtype, func)
TYPE_MODE
(valtype) to get the machine mode used to represent that type.
On many machines, only the mode is relevant. (Actually, on most
machines, scalar values are returned in the same place regardless of
mode).
If 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)
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)
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 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
FUNCTION_VALUE_REGNO_P for
saving and restoring an arbitrary return value.
When a function value's mode is BLKmode (and in some other
cases), the value is not returned according to FUNCTION_VALUE
(see section How Scalar Function Values Are Returned). 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)
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
RETURN_IN_MEMORY macro.
If not defined, this defaults to the value 1.
STRUCT_VALUE_REGNUM
STRUCT_VALUE_REGNUM should be the number of that register.
STRUCT_VALUE
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
If the incoming location of the structure value address is in a register, define this macro as the register number.
STRUCT_VALUE_INCOMING
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
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.
If you enable it, GNU CC can save registers around function calls. This makes it possible to use call-clobbered registers to hold variables that must live across calls.
DEFAULT_CALLER_SAVES
CALL_USED_REGISTERS has 1
for all registers. This macro enables `-fcaller-saves' by default.
Eventually that option will be enabled by default on all machines and both
the option and this macro will be eliminated.
CALLER_SAVE_PROFITABLE (refs, calls)
If you don't define this macro, a default is used which is good on most
machines: 4 * calls < refs.
This section describes the macros that output function entry (prologue) and exit (epilogue) code.
FUNCTION_PROLOGUE (file, size)
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. See section Eliminating Frame Pointer and Arg Pointer.
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.
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'.
ACCUMULATE_OUTGOING_ARGS is defined, a region of
current_function_outgoing_args_size bytes to be used for outgoing
argument lists of the function. See section Passing Function Arguments on the Stack.
Normally, it is necessary for the macros FUNCTION_PROLOGUE and
FUNCTION_EPILOGUE to treat leaf functions specially. The C
variable leaf_function is nonzero for such a function.
EXIT_IGNORE_STACK
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)
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 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, FUNCTION_PROLOGUE and FUNCTION_EPILOGUE must
treat leaf functions specially. The C variable leaf_function is
nonzero for such a function. See section Handling 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 that is called
current_function_pops_args is the number of bytes of its
arguments that a function should pop. See section How Scalar Function Values Are Returned.
DELAY_SLOTS_FOR_EPILOGUE
ELIGIBLE_FOR_EPILOGUE_DELAY (insn, n)
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.
These macros will help you generate code for profiling.
FUNCTION_PROFILER (file, labelno)
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
FUNCTION_BLOCK_PROFILER (file, labelno)
__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)
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.
BLOCK_PROFILER_CODE
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 ()
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)
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)
__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)
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)
__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,
__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.
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)
TRAMPOLINE_SECTION
TRAMPOLINE_SIZE
TRAMPOLINE_ALIGNMENT
If you don't define this macro, the value of BIGGEST_ALIGNMENT
is used for aligning trampolines.
INITIALIZE_TRAMPOLINE (addr, fnaddr, static_chain)
ALLOCATE_TRAMPOLINE (fp)
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
INSN_CACHE_LINE_WIDTH
INSN_CACHE_DEPTH
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)
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
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.
Here is an explanation of implicit calls to library routines.
MULSI3_LIBCALL
__mulsi3,
a function defined in `libgcc.a'.
DIVSI3_LIBCALL
__divsi3, a
function defined in `libgcc.a'.
UDIVSI3_LIBCALL
__udivsi3, a
function defined in `libgcc.a'.
MODSI3_LIBCALL
__modsi3, a function defined in `libgcc.a'.
UMODSI3_LIBCALL
__umodsi3, a function defined in `libgcc.a'.
MULDI3_LIBCALL
__muldi3,
a function defined in `libgcc.a'.
DIVDI3_LIBCALL
__divdi3, a
function defined in `libgcc.a'.
UDIVDI3_LIBCALL
__udivdi3, a
function defined in `libgcc.a'.
MODDI3_LIBCALL
__moddi3, a function defined in `libgcc.a'.
UMODDI3_LIBCALL
__umoddi3, a function defined in `libgcc.a'.
INIT_TARGET_OPTABS
init_optabs calls this macro after
initializing all the normal library routines.
TARGET_EDOM
EDOM on the target machine, as a C integer constant
expression. If you don't define this macro, GNU CC does not attempt to
deposit the value of 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
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
memcpy and memset
rather than the BSD functions bcopy and bzero.
LIBGCC_NEEDS_DOUBLE
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
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)
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
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)
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
SImode in the system's own C compiler.
You need not define this macro if that type is long int, as it usually
is.
nongcc_word_type
You need not define this macro if that type is long int, as it usually
is.
perform_...
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
The default calling convention passes just the object and the selector to the lookup function, which returns a pointer to the method.
This is about addressing modes.
HAVE_POST_INCREMENT
HAVE_PRE_INCREMENT
HAVE_POST_DECREMENT
HAVE_PRE_DECREMENT
CONSTANT_ADDRESS_P (x)
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
GO_IF_LEGITIMATE_ADDRESS would ever
accept.
GO_IF_LEGITIMATE_ADDRESS (mode, x, label)
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. See section Defining the Output Assembler Language.
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)
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)
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)
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)
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)
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.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
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
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)
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 (see section Instruction 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
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
EXTRA_CC_MODES. For example, the Sparc defines this macro and
EXTRA_CC_MODES as
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"
This macro is not required if EXTRA_CC_MODES is not defined.
SELECT_CC_MODE (op, x, y)
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
see section Defining Jump Instruction 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)
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.
GNU CC 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)
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)
These macros let you describe the relative speed of various operations on the target machine.
CONST_COSTS (x, code, outer_code)
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)
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.
ADDRESS_COST (address)
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 (from, to)
GENERAL_REGS. A value of 4 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 (m)
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.
BRANCH_COST
Here are additional macros which do not specify precise relative costs, but only that certain actions are more expensive than GNU CC would ordinarily expect.
SLOW_BYTE_ACCESS
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_ZERO_EXTEND
char or short
to an int) can be done faster if the destination is a register
that is known to be zero.
If you define this macro, you must have instruction patterns that recognize RTL structures like this:
(set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...)
SLOW_UNALIGNED_ACCESS
When this macro is non-zero, the compiler will act as if
STRICT_ALIGNMENT were non-zero when generating code for block
moves. This can cause significantly more instructions to be produced.
Therefore, do not set this macro non-zero 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.
DONT_REDUCE_ADDR
MOVE_RATIO
If you don't define this, a reasonable default is used.
NO_FUNCTION_CSE
NO_RECURSIVE_FUNCTION_CSE
ADJUST_COST (insn, link, dep_insn, cost)
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
".text" is right.
DATA_SECTION_ASM_OP
".data" is right.
SHARED_SECTION_ASM_OP
DATA_SECTION_ASM_OP will be used.
INIT_SECTION_ASM_OP
EXTRA_SECTIONS
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
text_section and
data_section, for your additional sections. Do not define this
macro if you do not define EXTRA_SECTIONS.
READONLY_DATA_SECTION
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)
VAR_DECL node or a constant of some sort. reloc
indicates whether the initial value of exp requires link-time
relocations. Select the section by calling text_section or one
of the alternatives for other sections.
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)
const_int rtx. Select the section by
calling text_section or one of the alternatives for other
sections.
Do not define this macro if you put all constants in the read-only data section.
JUMP_TABLES_IN_TEXT_SECTION
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)
The macro definition, if any, is executed immediately after the rtl for
decl 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 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)
ENCODE_SECTION_INFO alters the symbol's name string.
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
findex PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
PIC_OFFSET_TABLE_REGNUM is clobbered by calls. Do not define
this macro if PPIC_OFFSET_TABLE_REGNUM is not defined.
FINALIZE_PIC
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)
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.
This section describes macros whose principal purpose is to describe how to write instructions in assembler language--rather than what the instructions do.
This describes the overall framework of an assembler file.
ASM_FILE_START (stream)
Normally this macro is defined to output a line containing `#NO_APP', which is a comment that has no effect on most assemblers but tells the GNU assembler that it can save time by not checking for certain assembler constructs.
On systems that use SDB, it is necessary to output certain commands; see `attasm.h'.
ASM_FILE_END (stream)
If this macro is not defined, the default is to output nothing special at the end of the file. Most systems don't require any definition.
On systems that use SDB, it is necessary to output certain commands; see `attasm.h'.
ASM_IDENTIFY_GCC (file)
If you don't define this macro, the string `gcc_compiled.:' is output. This string is calculated to define a symbol which, on BSD systems, will never be defined for any other reason. GDB checks for the presence of this symbol when reading the symbol table of an executable.
On non-BSD systems, you must arrange communication with GDB in some other fashion. If GDB is not used on your system, you can define this macro with an empty body.
ASM_COMMENT_START
ASM_APP_ON
asm
statement or group of consecutive ones. Normally this is
"#APP", which is a comment that has no effect on most
assemblers but tells the GNU assembler that it must check the lines
that follow for all valid assembler constructs.
ASM_APP_OFF
asm
statement or group of consecutive ones. Normally this is
"#NO_APP", which tells the GNU assembler to resume making the
time-saving assumptions that are valid for ordinary compiler output.
ASM_OUTPUT_SOURCE_FILENAME (stream, name)
This macro need not be defined if the standard form of output for the file format in use is appropriate.
ASM_OUTPUT_SOURCE_LINE (stream, line)
This macro need not be defined if the standard form of debugging information for the debugger in use is appropriate.
ASM_OUTPUT_IDENT (stream, string)
ASM_OUTPUT_SECTION_NAME (stream, string)
At present this macro is only used to support section attributes. When this macro is undefined, section attributes are disabled.
OBJC_PROLOGUE
This describes data output.
ASM_OUTPUT_LONG_DOUBLE (stream, value)
ASM_OUTPUT_DOUBLE (stream, value)
ASM_OUTPUT_FLOAT (stream, value)
ASM_OUTPUT_THREE_QUARTER_FLOAT (stream, value)
ASM_OUTPUT_SHORT_FLOAT (stream, value)
ASM_OUTPUT_BYTE_FLOAT (stream, value)
TFmode,
DFmode, SFmode, TQFmode, HFmode, or
QFmode, respectively, whose value is value. value
will be a C expression of type REAL_VALUE_TYPE. Macros such as
REAL_VALUE_TO_TARGET_DOUBLE are useful for writing these
definitions.
ASM_OUTPUT_QUADRUPLE_INT (stream, exp)
ASM_OUTPUT_DOUBLE_INT (stream, exp)
ASM_OUTPUT_INT (stream, exp)
ASM_OUTPUT_SHORT (stream, exp)
ASM_OUTPUT_CHAR (stream, exp)
For sizes larger than UNITS_PER_WORD, if the action of a macro
would be identical to repeatedly calling the macro corresponding to
a size of UNITS_PER_WORD, once for each word, you need not define
the macro.
ASM_OUTPUT_BYTE (stream, value)
ASM_BYTE_OP
"byte".
ASM_OUTPUT_ASCII (stream, ptr, len)
char * and len a C expression of type int.
If the assembler has a .ascii pseudo-op as found in the
Berkeley Unix assembler, do not define the macro
ASM_OUTPUT_ASCII.
ASM_OUTPUT_POOL_PROLOGUE (file funname fundecl size)
If no constant-pool prefix is required, the usual case, this macro need not be defined.
ASM_OUTPUT_SPECIAL_POOL_ENTRY (file, x, mode, align, labelno, jumpto)
The argument file is the standard I/O stream to output the assembler code on. x is the RTL expression for the constant to output, and mode is the machine mode (in case x is a `const_int'). align is the required alignment for the value x; you should output an assembler directive to force this much alignment.
The argument labelno is a number to use in an internal label for the address of this pool entry. The definition of this macro is responsible for outputting the label definition at the proper place. Here is how to do this:
ASM_OUTPUT_INTERNAL_LABEL (file, "LC", labelno);
When you output a pool entry specially, you should end with a
goto to the label jumpto. This will prevent the same pool
entry from being output a second time in the usual manner.
You need not define this macro if it would do nothing.
IS_ASM_LOGICAL_LINE_SEPARATOR (C)
If you do not define this macro, the default is that only the character `;' is treated as a logical line separator.
ASM_OPEN_PAREN
ASM_CLOSE_PAREN
#define ASM_OPEN_PAREN "("
#define ASM_CLOSE_PAREN ")"
These macros are provided by `real.h' for writing the definitions
of ASM_OUTPUT_DOUBLE and the like:
REAL_VALUE_TO_TARGET_SINGLE (x, l)
REAL_VALUE_TO_TARGET_DOUBLE (x, l)
REAL_VALUE_TO_TARGET_LONG_DOUBLE (x, l)
REAL_VALUE_TYPE, to the target's
floating point representation, and store its bit pattern in the array of
long int whose address is l. The number of elements in the
output array is determined by the size of the desired target floating
point data type: 32 bits of it go in each long int array
element. Each array element holds 32 bits of the result, even if
long int is wider than 32 bits on the host machine.
The array element values are designed so that you can print them out
using fprintf in the order they should appear in the target
machine's memory.
REAL_VALUE_TO_DECIMAL (x, format, string)
REAL_VALUE_TYPE, to a
decimal number and stores it as a string into string.
You must pass, as string, the address of a long enough block
of space to hold the result.
The argument format is a printf-specification that serves
as a suggestion for how to format the output string.
Each of the macros in this section is used to do the whole job of outputting a single uninitialized variable.
ASM_OUTPUT_COMMON (stream, name, size, rounded)
Use the expression assemble_name (stream, name) to
output the name itself; before and after that, output the additional
assembler syntax for defining the name, and a newline.
This macro controls how the assembler definitions of uninitialized global variables are output.
ASM_OUTPUT_ALIGNED_COMMON (stream, name, size, alignment)
ASM_OUTPUT_COMMON except takes the required alignment as a
separate, explicit argument. If you define this macro, it is used in
place of ASM_OUTPUT_COMMON, and gives you more flexibility in
handling the required alignment of the variable. The alignment is specified
as the number of bits.
ASM_OUTPUT_SHARED_COMMON (stream, name, size, rounded)
ASM_OUTPUT_COMMON, except that it
is used when name is shared. If not defined, ASM_OUTPUT_COMMON
will be used.
ASM_OUTPUT_LOCAL (stream, name, size, rounded)
Use the expression assemble_name (stream, name) to
output the name itself; before and after that, output the additional
assembler syntax for defining the name, and a newline.
This macro controls how the assembler definitions of uninitialized static variables are output.
ASM_OUTPUT_ALIGNED_LOCAL (stream, name, size, alignment)
ASM_OUTPUT_LOCAL except takes the required alignment as a
separate, explicit argument. If you define this macro, it is used in
place of ASM_OUTPUT_LOCAL, and gives you more flexibility in
handling the required alignment of the variable. The alignment is specified
as the number of bits.
ASM_OUTPUT_SHARED_LOCAL (stream, name, size, rounded)
ASM_OUTPUT_LOCAL, except that it
is used when name is shared. If not defined, ASM_OUTPUT_LOCAL
will be used.
This is about outputting labels.
ASM_OUTPUT_LABEL (stream, name)
assemble_name (stream, name) to
output the name itself; before and after that, output the additional
assembler syntax for defining the name, and a newline.
ASM_DECLARE_FUNCTION_NAME (stream, name, decl)
ASM_OUTPUT_LABEL). The argument decl is the
FUNCTION_DECL tree node representing the function.
If this macro is not defined, then the function name is defined in the
usual manner as a label (by means of ASM_OUTPUT_LABEL).
ASM_DECLARE_FUNCTION_SIZE (stream, name, decl)
FUNCTION_DECL tree node
representing the function.
If this macro is not defined, then the function size is not defined.
ASM_DECLARE_OBJECT_NAME (stream, name, decl)
ASM_OUTPUT_LABEL). The argument
decl is the VAR_DECL tree node representing the variable.
If this macro is not defined, then the variable name is defined in the
usual manner as a label (by means of ASM_OUTPUT_LABEL).
ASM_FINISH_DECLARE_OBJECT (stream, decl, toplevel, atend)
If you don't define this macro, that is equivalent to defining it to do nothing.
ASM_GLOBALIZE_LABEL (stream, name)
assemble_name (stream, name) to output the name
itself; before and after that, output the additional assembler syntax
for making that name global, and a newline.
ASM_OUTPUT_EXTERNAL (stream, decl, name)
This macro need not be defined if it does not need to output anything. The GNU assembler and most Unix assemblers don't require anything.
ASM_OUTPUT_EXTERNAL_LIBCALL (stream, symref)
rtx and
is a symbol_ref.
This macro need not be defined if it does not need to output anything. The GNU assembler and most Unix assemblers don't require anything.
ASM_OUTPUT_LABELREF (stream, name)
assemble_name.
ASM_OUTPUT_INTERNAL_LABEL (stream, prefix, num)
It is absolutely essential that these labels be distinct from the labels used for user-level functions and variables. Otherwise, certain programs will have name conflicts with internal labels.
It is desirable to exclude internal labels from the symbol table of the object file. Most assemblers have a naming convention for labels that should be excluded; on many systems, the letter `L' at the beginning of a label has this effect. You should find out what convention your system uses, and follow it.
The usual definition of this macro is as follows:
fprintf (stream, "L%s%d:\n", prefix, num)
ASM_GENERATE_INTERNAL_LABEL (string, prefix, num)
This string, when output subsequently by assemble_name, should
produce the output that ASM_OUTPUT_INTERNAL_LABEL would produce
with the same prefix and num.
If the string begins with `*', then assemble_name will
output the rest of the string unchanged. It is often convenient for
ASM_GENERATE_INTERNAL_LABEL to use `*' in this way. If the
string doesn't start with `*', then ASM_OUTPUT_LABELREF gets
to output the string, and may change it. (Of course,
ASM_OUTPUT_LABELREF is also part of your machine description, so
you should know what it does on your machine.)
ASM_FORMAT_PRIVATE_NAME (outvar, name, number)
char *) a newly allocated string made from the string
name and the number number, with some suitable punctuation
added. Use alloca to get space for the string.
The string will be used as an argument to ASM_OUTPUT_LABELREF to
produce an assembler label for an internal static variable whose name is
name. Therefore, the string must be such as to result in valid
assembler code. The argument number is different each time this
macro is executed; it prevents conflicts between similarly-named
internal static variables in different scopes.
Ideally this string should not be a valid C identifier, to prevent any conflict with the user's own symbols. Most assemblers allow periods or percent signs in assembler symbols; putting at least one of these between the name and the number will suffice.
ASM_OUTPUT_DEF (stream, name, value)
If SET_ASM_OP is defined, a default definition is provided which is correct for most systems.
OBJC_GEN_METHOD_LABEL (buf, is_inst, class_name, cat_name, sel_name)
The default name is a unique method number followed by the name of the class (e.g. `_1_Foo'). For methods in categories, the name of the category is also included in the assembler name (e.g. `_1_Foo_Bar').
These names are safe on most systems, but make debugging difficult since the method's selector is not present in the name. Therefore, particular systems define other ways of computing names.
buf is an expression of type char * which gives you a
buffer in which to store the name; its length is as long as
class_name, cat_name and sel_name put together, plus
50 characters extra.
The argument is_inst specifies whether the method is an instance method or a class method; class_name is the name of the class; cat_name is the name of the category (or NULL if the method is not in a category); and sel_name is the name of the selector.
On systems where the assembler can handle quoted names, you can use this macro to provide more human-readable names.
The compiled code for certain languages includes constructors
(also called initialization routines)---functions to initialize
data in the program when the program is started. These functions need
to be called before the program is "started"---that is to say, before
main is called.
Compiling some languages generates destructors (also called termination routines) that should be called when the program terminates.
To make the initialization and termination functions work, the compiler must output something in the assembler code to cause those functions to be called at the appropriate time. When you port the compiler to a new system, you need to specify how to do this.
There are two major ways that GCC currently supports the execution of initialization and termination functions. Each way has two variants. Much of the structure is common to all four variations.
The linker must build two lists of these functions--a list of
initialization functions, called __CTOR_LIST__, and a list of
termination functions, called __DTOR_LIST__.
Each list always begins with an ignored function pointer (which may hold 0, -1, or a count of the function pointers after it, depending on the environment). This is followed by a series of zero or more function pointers to constructors (or destructors), followed by a function pointer containing zero.
Depending on the operating system and its executable file format, either `crtstuff.c' or `libgcc2.c' traverses these lists at startup time and exit time. Constructors are called in forward order of the list; destructors in reverse order.
The best way to handle static constructors works only for object file formats which provide arbitrarily-named sections. A section is set aside for a list of constructors, and another for a list of destructors. Traditionally these are called `.ctors' and `.dtors'. Each object file that defines an initialization function also puts a word in the constructor section to point to that function. The linker accumulates all these words into one contiguous `.ctors' section. Termination functions are handled similarly.
To use this method, you need appropriate definitions of the macros
ASM_OUTPUT_CONSTRUCTOR and ASM_OUTPUT_DESTRUCTOR. Usually
you can get them by including `svr4.h'.
When arbitrary sections are available, there are two variants, depending
upon how the code in `crtstuff.c' is called. On systems that
support an init section which is executed at program startup,
parts of `crtstuff.c' are compiled into that section. The
program is linked by the gcc driver like this:
ld -o output_file crtbegin.o ... crtend.o -lgcc
The head of a function (__do_global_ctors) appears in the init
section of `crtbegin.o'; the remainder of the function appears in
the init section of `crtend.o'. The linker will pull these two
parts of the section together, making a whole function. If any of the
user's object files linked into the middle of it contribute code, then that
code will be executed as part of the body of __do_global_ctors.
To use this variant, you must define the INIT_SECTION_ASM_OP
macro properly.
If no init section is available, do not define
INIT_SECTION_ASM_OP. Then __do_global_ctors is built into
the text section like all other functions, and resides in
`libgcc.a'. When GCC compiles any function called main, it
inserts a procedure call to __main as the first executable code
after the function prologue. The __main function, also defined
in `libgcc2.c', simply calls `__do_global_ctors'.
In file formats that don't support arbitrary sections, there are again
two variants. In the simplest variant, the GNU linker (GNU ld)
and an `a.out' format must be used. In this case,
ASM_OUTPUT_CONSTRUCTOR is defined to produce a .stabs
entry of type `N_SETT', referencing the name __CTOR_LIST__,
and with the address of the void function containing the initialization
code as its value. The GNU linker recognizes this as a request to add
the value to a "set"; the values are accumulated, and are eventually
placed in the executable as a vector in the format described above, with
a leading (ignored) count and a trailing zero element.
ASM_OUTPUT_DESTRUCTOR is handled similarly. Since no init
section is available, the absence of INIT_SECTION_ASM_OP causes
the compilation of main to call __main as above, starting
the initialization process.
The last variant uses neither arbitrary sections nor the GNU linker.
This is preferable when you want to do dynamic linking and when using
file formats which the GNU linker does not support, such as `ECOFF'. In
this case, ASM_OUTPUT_CONSTRUCTOR does not produce an
N_SETT symbol; initialization and termination functions are
recognized simply by their names. This requires an extra program in the
linkage step, called collect2. This program pretends to be the
linker, for use with GNU CC; it does its job by running the ordinary
linker, but also arranges to include the vectors of initialization and
termination functions. These functions are called via __main as
described above.
Choosing among these configuration options has been simplified by a set of operating-system-dependent files in the `config' subdirectory. These files define all of the relevant parameters. Usually it is sufficient to include one into your specific machine-dependent configuration file. These files are:
Here are the macros that control how the compiler handles initialization and termination functions:
INIT_SECTION_ASM_OP
HAS_INIT_SECTION
main will not call __main as described above.
This macro should be defined for systems that control the contents of the
init section on a symbol-by-symbol basis, such as OSF/1, and should not
be defined explicitly for systems that support
INIT_SECTION_ASM_OP.
INVOKE__main
main will call __main despite the presence of
INIT_SECTION_ASM_OP. This macro should be defined for systems
where the init section is not actually run automatically, but is still
useful for collecting the lists of constructors and destructors.
ASM_OUTPUT_CONSTRUCTOR (stream, name)
Assume that name is the name of a C function generated
automatically by the compiler. This function takes no arguments. Use
the function assemble_name to output the name name; this
performs any system-specific syntactic transformations such as adding an
underscore.
If you don't define this macro, nothing special is output to arrange to
call the function. This is correct when the function will be called in
some other manner--for example, by means of the collect2 program,
which looks through the symbol table to find these functions by their
names.
ASM_OUTPUT_DESTRUCTOR (stream, name)
ASM_OUTPUT_CONSTRUCTOR but used for termination
functions rather than initialization functions.
If your system uses collect2 as the means of processing
constructors, then that program normally uses nm to scan an
object file for constructor functions to be called. On certain kinds of
systems, you can define these macros to make collect2 work faster
(and, in some cases, make it work at all):
OBJECT_FORMAT_COFF
collect2 can assume this format and scan
object files directly for dynamic constructor/destructor functions.
OBJECT_FORMAT_ROSE
collect2 can assume this format and scan object files directly
for dynamic constructor/destructor functions.
REAL_NM_FILE_NAME
nm. The default is to search the path normally for
nm.
These macros are effective only in a native compiler; collect2 as
part of a cross compiler always uses nm for the target machine.
This describes assembler instruction output.
REGISTER_NAMES
ADDITIONAL_REGISTER_NAMES
asm option in declarations to refer
to registers using alternate names.
ASM_OUTPUT_OPCODE (stream, ptr)
The definition is a C statement or statements which output an
assembler instruction opcode to the stdio stream stream. The
macro-operand ptr is a variable of type char * which
points to the opcode name in its "internal" form--the form that is
written in the machine description. The definition should output the
opcode name to stream, performing any translation you desire, and
increment the variable ptr to point at the end of the opcode
so that it will not be output twice.
In fact, your macro definition may process less than the entire opcode name, or more than the opcode name; but if you want to process text that includes `%'-sequences to substitute operands, you must take care of the substitution yourself. Just be sure to increment ptr over whatever text should not be output normally.
If you need to look at the operand values, they can be found as the
elements of recog_operand.
If the macro definition does nothing, the instruction is output in the usual way.
FINAL_PRESCAN_INSN (insn, opvec, noperands)
Here the argument opvec is the vector containing the operands extracted from insn, and noperands is the number of elements of the vector which contain meaningful data for this insn. The contents of this vector are what will be used to convert the insn template into assembler code, so you can change the assembler output by changing the contents of the vector.
This macro is useful when various assembler syntaxes share a single file of instruction patterns; by defining this macro differently, you can cause a large class of instructions to be output differently (such as with rearranged operands). Naturally, variations in assembler syntax affecting individual insn patterns ought to be handled by writing conditional output routines in those patterns.
If this macro is not defined, it is equivalent to a null statement.
PRINT_OPERAND (stream, x, code)
code is a value that can be used to specify one of several ways of printing the operand. It is used when identical operands must be printed differently depending on the context. code comes from the `%' specification that was used to request printing of the operand. If the specification was just `%digit' then code is 0; if the specification was `%ltr digit' then code is the ASCII code for ltr.
If x is a register, this macro should print the register's name.
The names can be found in an array reg_names whose type is
char *[]. reg_names is initialized from
REGISTER_NAMES.
When the machine description has a specification `%punct' (a `%' followed by a punctuation character), this macro is called with a null pointer for x and the punctuation character for code.
PRINT_OPERAND_PUNCT_VALID_P (code)
PRINT_OPERAND macro. If
PRINT_OPERAND_PUNCT_VALID_P is not defined, it means that no
punctuation characters (except for the standard one, `%') are used
in this way.
PRINT_OPERAND_ADDRESS (stream, x)
On some machines, the syntax for a symbolic address 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. See section Defining the Output Assembler Language.
DBR_OUTPUT_SEQEND(file)
dbr_sequence_length to
determine the number of slots filled in a sequence (zero if not
currently outputting a sequence), to decide how many no-ops to output,
or whatever.
Don't define this macro if it has nothing to do, but it is helpful in reading assembly output if the extent of the delay sequence is made explicit (e.g. with white space).
Note that output routines for instructions with delay slots must be
prepared to deal with not being output as part of a sequence (i.e.
when the scheduling pass is not run, or when no slot fillers could be
found.) The variable final_sequence is null when not
processing a sequence, otherwise it contains the sequence rtx
being output.
REGISTER_PREFIX
LOCAL_LABEL_PREFIX
USER_LABEL_PREFIX
IMMEDIATE_PREFIX
asm_fprintf (see
`final.c'). These are useful when a single `md' file must
support multiple assembler formats. In that case, the various `tm.h'
files can define these macros differently.
ASSEMBLER_DIALECT
If this macro is defined, you may use
`{option0|option1|option2...}' constructs in the output
templates of patterns (see section Output Templates and Operand Substitution) or in the first argument
of asm_fprintf. This construct outputs `option0',
`option1' or `option2', etc., if the value of
ASSEMBLER_DIALECT is zero, one or two, etc. Any special
characters within these strings retain their usual meaning.
If you do not define this macro, the characters `{', `|' and
`}' do not have any special meaning when used in templates or
operands to asm_fprintf.
Define the macros REGISTER_PREFIX, LOCAL_LABEL_PREFIX,
USER_LABEL_PREFIX and IMMEDIATE_PREFIX if you can express
the variations in assemble language syntax with that mechanism. Define
ASSEMBLER_DIALECT and use the `{option0|option1}' syntax
if the syntax variant are larger and involve such things as different
opcodes or operand order.
ASM_OUTPUT_REG_PUSH (stream, regno)
ASM_OUTPUT_REG_POP (stream, regno)
This concerns dispatch tables.
ASM_OUTPUT_ADDR_DIFF_ELT (stream, value, rel)
The definition should be a C statement to output to the stdio stream
stream an assembler pseudo-instruction to generate a difference
between two labels. value and rel are the numbers of two
internal labels. The definitions of these labels are output using
ASM_OUTPUT_INTERNAL_LABEL, and they must be printed in the same
way here. For example,
fprintf (stream, "\t.word L%d-L%d\n",
value, rel)
ASM_OUTPUT_ADDR_VEC_ELT (stream, value)
The definition should be a C statement to output to the stdio stream
stream an assembler pseudo-instruction to generate a reference to
a label. value is the number of an internal label whose
definition is output using ASM_OUTPUT_INTERNAL_LABEL.
For example,
fprintf (stream, "\t.word L%d\n", value)
ASM_OUTPUT_CASE_LABEL (stream, prefix, num, table)
ASM_OUTPUT_INTERNAL_LABEL; the fourth argument is the
jump-table which follows (a jump_insn containing an
addr_vec or addr_diff_vec).
This feature is used on system V to output a swbeg statement
for the table.
If this macro is not defined, these labels are output with
ASM_OUTPUT_INTERNAL_LABEL.
ASM_OUTPUT_CASE_END (stream, num, table)
If this macro is not defined, nothing special is output at the end of the jump-table.
This describes commands for alignment.
ASM_OUTPUT_ALIGN_CODE (file)
This macro need not be defined if you don't want any special alignment to be done at such a time. Most machine descriptions do not currently define the macro.
ASM_OUTPUT_LOOP_ALIGN (file)
This macro need not be defined if you don't want any special alignment to be done at such a time. Most machine descriptions do not currently define the macro.
ASM_OUTPUT_SKIP (stream, nbytes)
int.
ASM_NO_SKIP_IN_TEXT
ASM_OUTPUT_SKIP should not be used in the
text section because it fails put zeros in the bytes that are skipped.
This is true on many Unix systems, where the pseudo--op to skip bytes
produces no-op instructions rather than zeros when used in the text
section.
ASM_OUTPUT_ALIGN (stream, power)
int.
This describes how to specify debugging information.
These macros affect all debugging formats.
DBX_REGISTER_NUMBER (regno)
If two registers have consecutive numbers inside GNU CC, and they can be
used as a pair to hold a multiword value, then they must have
consecutive numbers after renumbering with DBX_REGISTER_NUMBER.
Otherwise, debuggers will be unable to access such a pair, because they
expect register pairs to be consecutive in their own numbering scheme.
If you find yourself defining DBX_REGISTER_NUMBER in way that
does not preserve register pairs, then what you must do instead is
redefine the actual register numbering scheme.
DEBUGGER_AUTO_OFFSET (x)
DEBUGGER_ARG_OFFSET (offset, x)
PREFERRED_DEBUGGING_TYPE
DBX_DEBUG,
SDB_DEBUG, DWARF_DEBUG, and XCOFF_DEBUG.
The value of this macro only affects the default debugging output; the user can always get a specific type of output by using `-gstabs', `-gcoff', `-gdwarf', or `-gxcoff'.
These are specific options for DBX output.
DBX_DEBUGGING_INFO
XCOFF_DEBUGGING_INFO
DEFAULT_GDB_EXTENSIONS
DEBUG_SYMS_TEXT
.stabs commands should be output while
in the text section.
ASM_STABS_OP
.stabs to define an ordinary debugging symbol. If you don't
define this macro, .stabs is used. This macro applies only to
DBX debugging information format.
ASM_STABD_OP
.stabd to define a debugging symbol whose value is the current
location. If you don't define this macro, .stabd is used.
This macro applies only to DBX debugging information format.
ASM_STABN_OP
.stabn to define a debugging symbol with no name. If you don't
define this macro, .stabn is used. This macro applies only to
DBX debugging information format.
DBX_NO_XREFS
DBX_CONTIN_LENGTH
.stabs directives) when it
exceeds a certain length (by default, 80 characters). On some
operating systems, DBX requires this splitting; on others, splitting
must not be done. You can inhibit splitting by defining this macro
with the value zero. You can override the default splitting-length by
defining this macro as an expression for the length you desire.
DBX_CONTIN_CHAR
.stabs string when a continuation follows. To use
a different character instead, define this macro as a character
constant for the character you want to use. Do not define this macro
if backslash is correct for your system.
DBX_STATIC_STAB_DATA_SECTION
DBX_TYPE_DECL_STABS_CODE
.stabs directive
for a typedef. The default is N_LSYM.
DBX_STATIC_CONST_VAR_CODE
.stabs directive
for a static variable located in the text section. DBX format does not
provide any "right" way to do this. The default is N_FUN.
DBX_REGPARM_STABS_CODE
.stabs directive
for a parameter passed in registers. DBX format does not provide any
"right" way to do this. The default is N_RSYM.
DBX_REGPARM_STABS_LETTER
'P'.
DBX_MEMPARM_STABS_LETTER
'p'.
DBX_FUNCTION_FIRST
DBX_LBRAC_FIRST
N_LBRAC symbol for a block should
precede the debugging information for variables and functions defined in
that block. Normally, in DBX format, the N_LBRAC symbol comes
first.
DBX_BLOCKS_FUNCTION_RELATIVE
N_LBRAC or N_RBRAC) should be relative to the start
of the enclosing function. Normally, GNU C uses an absolute address.
These are hooks for DBX format.
DBX_OUTPUT_LBRAC (stream, name)
assemble_name) whose value is the address where the scope begins.
DBX_OUTPUT_RBRAC (stream, name)
DBX_OUTPUT_LBRAC, but for the end of a scope level.
DBX_OUTPUT_ENUM (stream, type)
DBX_OUTPUT_FUNCTION_END (stream, function)
FUNCTION_DECL node for
the function.
DBX_OUTPUT_STANDARD_TYPES (syms)
tree which is a chain of all the predefined
global symbols, including names of data types.
Normally, DBX output starts with definitions of the types for integers and characters, followed by all the other predefined types of the particular language in no particular order.
On some machines, it is necessary to output different particular types
first. To do this, define DBX_OUTPUT_STANDARD_TYPES to output
those symbols in the necessary order. Any predefined types that you
don't explicitly output will be output afterward in no particular order.
Be careful not to define this macro so that it works only for C. There are no global variables to access most of the built-in types, because another language may have another set of types. The way to output a particular type is to look through syms to see if you can find it. Here is an example:
{
tree decl;
for (decl = syms; decl; decl = TREE_CHAIN (decl))
if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)),
"long int"))
dbxout_symbol (decl);
...
}
This does nothing if the expected type does not exist.
See the function init_decl_processing in `c-decl.c' to find
the names to use for all the built-in C types.
Here is another way of finding a particular type:
{
tree decl;
for (decl = syms; decl; decl = TREE_CHAIN (decl))
if (TREE_CODE (decl) == TYPE_DECL
&& (TREE_CODE (TREE_TYPE (decl))
== INTEGER_CST)
&& TYPE_PRECISION (TREE_TYPE (decl)) == 16
&& TYPE_UNSIGNED (TREE_TYPE (decl)))
/* This must be unsigned short. */
dbxout_symbol (decl);
...
}
This describes file names in DBX format.
DBX_WORKING_DIRECTORY
Note that the working directory is always recorded if GDB extensions are enabled.
DBX_OUTPUT_MAIN_SOURCE_FILENAME (stream, name)
This macro need not be defined if the standard form of output for DBX debugging information is appropriate.
DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (stream, name)
This macro need not be defined if the standard form of output for DBX debugging information is appropriate.
DBX_OUTPUT_MAIN_SOURCE_FILE_END (stream, name)
If you don't define this macro, nothing special is output at the end of compilation, which is correct for most machines.
DBX_OUTPUT_SOURCE_FILENAME (stream, name)
This macro need not be defined if the standard form of output for DBX debugging information is appropriate.
Here are macros for SDB and DWARF output.
SDB_DEBUGGING_INFO
DWARF_DEBUGGING_INFO
PUT_SDB_...
SDB_DELIM
PUT_SDB_op macros if this is the only change
required.
SDB_GENERATE_FAKE
SDB_ALLOW_UNKNOWN_REFERENCES
SDB_ALLOW_FORWARD_REFERENCES
While all modern machines use 2's complement representation for integers, there are a variety of representations for floating point numbers. This means that in a cross-compiler the representation of floating point numbers in the compiled program may be different from that used in the machine doing the compilation.
Because different representation systems may offer different amounts of
range and precision, the cross compiler cannot safely use the host
machine's floating point arithmetic. Therefore, floating point constants
must be represented in the target machine's format. This means that the
cross compiler cannot use atof to parse a floating point constant;
it must have its own special routine to use instead. Also, constant
folding must emulate the target machine's arithmetic (or must not be done
at all).
The macros in the following table should be defined only if you are cross compiling between different floating point formats.
Otherwise, don't define them. Then default definitions will be set up which
use double as the data type, == to test for equality, etc.
You don't need to worry about how many times you use an operand of any of these macros. The compiler never uses operands which have side effects.
REAL_VALUE_TYPE
struct containing an array of int.
REAL_VALUES_EQUAL (x, y)
REAL_VALUE_TYPE.
REAL_VALUES_LESS (x, y)
REAL_VALUE_TYPE and
interpreted as floating point numbers in the target machine's
representation.
REAL_VALUE_LDEXP (x, scale)
ldexp, but using the target machine's floating point
representation. Both x and the value of the expression have
type REAL_VALUE_TYPE. The second argument, scale, is an
integer.
REAL_VALUE_FIX (x)
REAL_VALUE_TYPE.
REAL_VALUE_UNSIGNED_FIX (x)
REAL_VALUE_TYPE.
REAL_VALUE_RNDZINT (x)
REAL_VALUE_TYPE,
and so does the value.
REAL_VALUE_UNSIGNED_RNDZINT (x)
REAL_VALUE_TYPE, and so does the value.
REAL_VALUE_ATOF (string, mode)
char *, into a floating point number in the target machine's
representation for mode mode. The value has type
REAL_VALUE_TYPE.
REAL_INFINITY
REAL_VALUE_ISINF (x)
int.
By default, this is defined to call isinf.
REAL_VALUE_ISNAN (x)
int. By default, this is defined to call isnan.
Define the following additional macros if you want to make floating point constant folding work while cross compiling. If you don't define them, cross compilation is still possible, but constant folding will not happen for floating point values.
REAL_ARITHMETIC (output, code, x, y)
REAL_VALUE_TYPE in the target machine's representation, to
produce a result of the same type and representation which is stored
in output (which will be a variable).
The operation to be performed is specified by code, a tree code
which will always be one of the following: PLUS_EXPR,
MINUS_EXPR, MULT_EXPR, RDIV_EXPR,
MAX_EXPR, MIN_EXPR.
The expansion of this macro is responsible for checking for overflow.
If overflow happens, the macro expansion should execute the statement
return 0;, which indicates the inability to perform the
arithmetic operation requested.
REAL_VALUE_NEGATE (x)
REAL_VALUE_TYPE and are in the target machine's
floating point representation.
There is no way for this macro to report overflow, since overflow can't happen in the negation operation.
REAL_VALUE_TRUNCATE (mode, x)
Both x and the value of the expression are in the target machine's
floating point representation and have type REAL_VALUE_TYPE.
However, the value should have an appropriate bit pattern to be output
properly as a floating constant whose precision accords with mode
mode.
There is no way for this macro to report overflow.
REAL_VALUE_TO_INT (low, high, x)
REAL_VALUE_FROM_INT (x, low, high)
Here are several miscellaneous parameters.
PREDICATE_CODES
#define PREDICATE_CODES \
{"gen_reg_rtx_operand", {SUBREG, REG}}, \
{"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}},
Defining this macro does not affect the generated code (however, incorrect definitions that omit an rtl code that may be matched by the predicate can cause the compiler to malfunction). Instead, it allows the table built by `genrecog' to be more compact and efficient, thus speeding up the compiler. The most important predicates to include in the list specified by this macro are thoses used in the most insn patterns.
CASE_VECTOR_MODE
CASE_VECTOR_PC_RELATIVE
CASE_DROPS_THROUGH
case insn when the index
value is out of range. This means the specified default-label is
actually ignored by the case insn proper.
CASE_VALUES_THRESHOLD
casesi instruction and
five otherwise. This is best for most machines.
WORD_REGISTER_OPERATIONS
LOAD_EXTEND_OP (mode)
SIGN_EXTEND for values
of mode for which the
insn sign-extends, ZERO_EXTEND for which it zero-extends, and
NIL for other modes.
This macro is not called with mode non-integral or with a width
greater than or equal to BITS_PER_WORD, so you may return any
value in this case. Do not define this macro if it would always return
NIL. On machines where this macro is defined, you will normally
define it as the constant SIGN_EXTEND or ZERO_EXTEND.
IMPLICIT_FIX_EXPR
FIX_ROUND_EXPR is used.
FIXUNS_TRUNC_LIKE_FIX_TRUNC
EASY_DIV_EXPR
TRUNC_DIV_EXPR, FLOOR_DIV_EXPR, CEIL_DIV_EXPR or
ROUND_DIV_EXPR. These four division operators differ in how
they round the result to an integer. EASY_DIV_EXPR is used
when it is permissible to use any of those kinds of division and the
choice should be made on the basis of efficiency.
MOVE_MAX
MAX_MOVE_MAX
MOVE_MAX. Otherwise, it is the constant value that is the
largest value that MOVE_MAX can have at run-time.
SHIFT_COUNT_TRUNCATED
SHIFT_COUNT_TRUNCATED
also enables deletion of truncations of the values that serve as
arguments to bitfield instructions.
If both types of instructions truncate the count (for shifts) and position (for bitfield operations), or if no variable-position bitfield instructions exist, you should define this macro.
However, on some machines, such as the 80386 and the 680x0, truncation
only applies to shift operations and not the (real or pretended)
bitfield operations. Define SHIFT_COUNT_TRUNCATED to be zero on
such machines. Instead, add patterns to the `md' file that include
the implied truncation of the shift instructions.
You need not define this macro if it would always have the value of zero.
TRULY_NOOP_TRUNCATION (outprec, inprec)
On many machines, this expression can be 1.
When TRULY_NOOP_TRUNCATION returns 1 for a pair of sizes for
modes for which MODES_TIEABLE_P is 0, suboptimal code can result.
If this is the case, making TRULY_NOOP_TRUNCATION return 0 in
such cases may improve things.
STORE_FLAG_VALUE
MODE_INT mode.
A value of 1 or -1 means that the instruction implementing the
comparison operator returns exactly 1 or -1 when the comparison is true
and 0 when the comparison is false. Otherwise, the value indicates
which bits of the result are guaranteed to be 1 when the comparison is
true. This value is interpreted in the mode of the comparison
operation, which is given by the mode of the first operand in the
`scond' pattern. Either the low bit or the sign bit of
STORE_FLAG_VALUE be on. Presently, only those bits are used by
the compiler.
If STORE_FLAG_VALUE is neither 1 or -1, the compiler will
generate code that depends only on the specified bits. It can also
replace comparison operators with equivalent operations if they cause
the required bits to be set, even if the remaining bits are undefined.
For example, on a machine whose comparison operators return an
SImode value and where STORE_FLAG_VALUE is defined as
`0x80000000', saying that just the sign bit is relevant, the
expression
(ne:SI (and:SI x (const_int power-of-2)) (const_int 0))
can be converted to
(ashift:SI x (const_int n))
where n is the appropriate shift count to move the bit being tested into the sign bit.
There is no way to describe a machine that always sets the low-order bit for a true value, but does not guarantee the value of any other bits, but we do not know of any machine that has such an instruction. If you are trying to port GNU CC to such a machine, include an instruction to perform a logical-and of the result with 1 in the pattern for the comparison operators and let us know (see section How to Report Bugs).
Often, a machine will have multiple instructions that obtain a value
from a comparison (or the condition codes). Here are rules to guide the
choice of value for STORE_FLAG_VALUE, and hence the instructions
to be used:
STORE_FLAG_VALUE. It is more efficient for the compiler to
"normalize" the value (convert it to, e.g., 1 or 0) than for the
comparison operators to do so because there may be opportunities to
combine the normalization with other operations.
Many machines can produce both the value chosen for
STORE_FLAG_VALUE and its negation in the same number of
instructions. On those machines, you should also define a pattern for
those cases, e.g., one matching
(set A (neg:m (ne:m B C)))
Some machines can also perform and or plus operations on
condition code values with less instructions than the corresponding
`scond' insn followed by and or plus. On those
machines, define the appropriate patterns. Use the names incscc
and decscc, respectively, for the the patterns which perform
plus or minus operations on condition code values. See
`rs6000.md' for some examples. The GNU Superoptizer can be used to
find such instruction sequences on other machines.
You need not define STORE_FLAG_VALUE if the machine has no store-flag
instructions.
FLOAT_STORE_FLAG_VALUE
Pmode
#define Pmode SImode
FUNCTION_MODE
call RTL expressions. On most machines this
should be QImode.
INTEGRATE_THRESHOLD (decl)
FUNCTION_DECL node.
The default definition of this macro is 64 plus 8 times the number of arguments that the function accepts. Some people think a larger threshold should be used on RISC machines.
SCCS_DIRECTIVE
#sccs directives
and print no error message.
NO_IMPLICIT_EXTERN_C
HANDLE_PRAGMA (stream)
#pragma is seen. The
argument stream is the stdio input stream from which the source
text can be read.
It is generally a bad idea to implement new uses of #pragma. The
only reason to define this macro is for compatibility with other
compilers that do support #pragma for the sake of any user
programs which already use it.
VALID_MACHINE_ATTRIBUTE (type, attributes, identifier)
COMP_TYPE_ATTRIBUTES (type1, type2)
SET_DEFAULT_TYPE_ATTRIBUTES (type)
DOLLARS_IN_IDENTIFIERS
NO_DOLLAR_IN_LABEL
NO_DOT_IN_LABEL
DEFAULT_MAIN_RETURN
main
function to return a standard "success" value by default (if no other
value is explicitly returned).
The definition should be a C statement (sans semicolon) to generate the
appropriate rtl instructions. It is used only when compiling the end of
main.
HAVE_ATEXIT
atexit from the ANSI C standard. If this is not defined,
and INIT_SECTION_ASM_OP is not defined, a default
exit function will be provided to support C++.
EXIT_BODY
exit function needs to do something
besides calling an external function _cleanup before
terminating with _exit. The EXIT_BODY macro is
only needed if netiher HAVE_ATEXIT nor
INIT_SECTION_ASM_OP are defined.
INSN_SETS_ARE_DELAYED (insn)
jump_insn or an insn; GNU CC knows that
every call_insn has this behavior. On machines where some insn
or jump_insn is really a function call and hence has this behavior,
you should define this macro.
You need not define this macro if it would always return zero.
INSN_REFERENCES_ARE_DELAYED (insn)
jump_insn or an insn. On machines where
some insn or jump_insn is really a function call and its operands
are registers whose use is actually in the subroutine it calls, you should
define this macro. Doing so allows the delay slot scheduler to move
instructions which copy arguments into the argument registers into the delay
slot of insn.
You need not define this macro if it would always return zero.
MACHINE_DEPENDENT_REORG (insn)
Go to the previous, next section.