| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
21.1 Controlling the Compilation Driver, `gcc' Controlling how the driver runs the compilation passes. 21.2 Run-time Target Specification Defining `-m' options like `-m68000' and `-m68020'. 21.3 Defining data structures for per-function information. 21.4 Storage Layout Defining sizes and alignments of data. 21.5 Layout of Source Language Data Types Defining sizes and properties of basic user data types. 21.6 Register Usage Naming and describing the hardware registers. 21.7 Register Classes Defining the classes of hardware registers. 21.8 Stack Layout and Calling Conventions Defining which way the stack grows and by how much. 21.9 Implementing the Varargs Macros Defining the varargs macros. 21.10 Trampolines for Nested Functions Code set up at run time to enter a nested function. 21.11 Implicit Calls to Library Routines Controlling how library routines are implicitly called. 21.12 Addressing Modes Defining addressing modes valid for memory operands. 21.13 Condition Code Status Defining how insns update the condition code. 21.14 Describing Relative Costs of Operations Defining relative costs of different operations. 21.15 Dividing the Output into Sections (Texts, Data, ...) Dividing storage into text, data, and other sections. 21.16 Position Independent Code Macros for position independent code. 21.17 Defining the Output Assembler Language Defining how to write insns and pseudo-ops to output. 21.18 Controlling Debugging Information Format Defining the format of debugging output. 21.19 Cross Compilation and Floating Point Handling floating point for cross-compilers. 21.20 Mode Switching Instructions Insertion of mode-switching instructions. 21.21 Miscellaneous Parameters Everything else.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can control the compilation driver.
SWITCH_TAKES_ARG (char)
By default, this macro is defined as
DEFAULT_SWITCH_TAKES_ARG, which handles the standard options
properly. You need not define SWITCH_TAKES_ARG unless you
wish to add additional options which take arguments. Any redefinition
should call DEFAULT_SWITCH_TAKES_ARG and then check for
additional options.
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.
SWITCH_CURTAILS_COMPILATION (char)
By default, this macro is defined as
DEFAULT_SWITCH_CURTAILS_COMPILATION, which handles the standard
options properly. You need not define
SWITCH_CURTAILS_COMPILATION unless you wish to add additional
options which affect the generation of an executable. Any redefinition
should call DEFAULT_SWITCH_CURTAILS_COMPILATION and then check
for additional options.
SWITCHES_NEED_SPACES
If this macro is not defined, the default value is "".
CPP_SPEC
Do not define this macro if it does not need to do anything.
CPLUSPLUS_CPP_SPEC
CPP_SPEC, but is used for C++, rather
than C. If you do not define this macro, then the value of
CPP_SPEC (if any) will be used instead.
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.
NO_BUILTIN_WCHAR_TYPE
__WCHAR_TYPE__. The macro __WCHAR_TYPE__ must then be
defined by CPP_SPEC instead.
This should be defined if WCHAR_TYPE depends on target dependent flags
which are not accessible to the preprocessor. Otherwise, it should not
be defined.
NO_BUILTIN_WINT_TYPE
__WINT_TYPE__. The macro __WINT_TYPE__ must then be
defined by CPP_SPEC instead.
This should be defined if WINT_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, cc1plus, f771, and the other language
front ends.
It can also specify how to translate options you give to GCC into options
for GCC to pass to front ends.
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 GCC into options for GCC to pass to the cc1plus.
Do not define this macro if it does not need to do anything.
Note that everything defined in CC1_SPEC is already passed to
cc1plus so there is no need to duplicate the contents of
CC1_SPEC in CC1PLUS_SPEC.
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'.
LIBGCC_SPEC
LIB_SPEC.
If this macro is not defined, the GCC driver provides a default that passes the string `-lgcc' to the linker.
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.
THREAD_MODEL_SPEC
-v will print the thread model GCC was configured to use.
However, this doesn't work on platforms that are multilibbed on thread
models, such as AIX 4.3. On such platforms, define
THREAD_MODEL_SPEC such that it evaluates to a string without
blanks that names one of the recognized thread models. %*, the
default value of this macro, will expand to the value of
thread_file set in `config.gcc'.
EXTRA_SPECS
CC1_SPEC.
The definition should be an initializer for an array of structures, containing a string constant, that defines the specification name, and a string constant that provides the specification.
Do not define this macro if it does not need to do anything.
EXTRA_SPECS is useful when an architecture contains several
related targets, which have various ..._SPECS which are similar
to each other, and the maintainer would like one central place to keep
these definitions.
For example, the PowerPC System V.4 targets use EXTRA_SPECS to
define either _CALL_SYSV when the System V calling sequence is
used or _CALL_AIX when the older AIX-based calling sequence is
used.
The `config/rs6000/rs6000.h' target file defines:
#define EXTRA_SPECS \
{ "cpp_sysv_default", CPP_SYSV_DEFAULT },
#define CPP_SYS_DEFAULT ""
|
The `config/rs6000/sysv.h' target file defines:
#undef CPP_SPEC
#define CPP_SPEC \
"%{posix: -D_POSIX_SOURCE } \
%{mcall-sysv: -D_CALL_SYSV } %{mcall-aix: -D_CALL_AIX } \
%{!mcall-sysv: %{!mcall-aix: %(cpp_sysv_default) }} \
%{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
#undef CPP_SYSV_DEFAULT
#define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
|
while the `config/rs6000/eabiaix.h' target file defines
CPP_SYSV_DEFAULT as:
#undef CPP_SYSV_DEFAULT #define CPP_SYSV_DEFAULT "-D_CALL_AIX" |
LINK_LIBGCC_SPECIAL
LINK_LIBGCC_SPECIAL_1
LINK_LIBGCC_SPECIAL, except that it does
not affect `-L' options.
LINK_COMMAND_SPEC
LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
MULTILIB_DEFAULTS
MULTILIB_OPTIONS.
Do not define this macro if MULTILIB_OPTIONS is not defined in
the target makefile fragment or if none of the options listed in
MULTILIB_OPTIONS are set by default.
See section 23.1 The Target Makefile Fragment.
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. If you define MD_EXEC_PREFIX, then be sure to add it
to the list of directories used to find the assembler in `configure.in'.
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
INIT_ENVIRONMENT
putenv to
initialize the necessary environment variables.
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.
MODIFY_TARGET_NAME
For each switch, you can include a string to be appended to the first
part of the configuration name or a string to be deleted from the
configuration name, if present. The definition should be an initializer
for an array of structures. Each array element should have three
elements: the switch name (a string constant, including the initial
dash), one of the enumeration codes ADD or DELETE to
indicate whether the string should be inserted or deleted, and the string
to be inserted or deleted (a string constant).
For example, on a machine where `64' at the end of the configuration name denotes a 64-bit target and you want the `-32' and `-64' switches to select between 32- and 64-bit targets, you would code
#define MODIFY_TARGET_NAME \
{ { "-32", DELETE, "64"}, \
{"-64", ADD, "64"}}
|
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.
STANDARD_INCLUDE_COMPONENT
STANDARD_INCLUDE_DIR.
See INCLUDE_DEFAULTS, below, for the description of components.
If you do not define this macro, no component is used.
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 four elements: the directory name (a
string constant), the component name (also a string constant), a flag
for C++-only directories,
and a flag showing that the includes in the directory don't need to be
wrapped in extern `C' when compiling C++. Mark the end of
the array with a null element.
The component name denotes what GNU package the include file is part of, if any, in all upper-case letters. For example, it might be `GCC' or `BINUTILS'. If the package is part of a vendor-supplied operating system, code the component name as `0'.
For example, here is the definition used for VAX/VMS:
#define INCLUDE_DEFAULTS \
{ \
{ "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
{ "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
{ "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
{ ".", 0, 0, 0}, \
{ 0, 0, 0, 0} \
}
|
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
(or port-specific name; native only, cross compilers do not use this).
STANDARD_EXEC_PREFIX.
MD_EXEC_PREFIX, if any.
MD_STARTFILE_PREFIX, if any.
STANDARD_STARTFILE_PREFIX.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 ISO standard, so they are predefined regardless of whether `-ansi' or a `-std' option 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.
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. It is
recommended that a helper macro TARGET_MASK_featurename
is defined for each bit-value to test, and used in
TARGET_featurename and TARGET_SWITCHES. For
example:
#define TARGET_MASK_68020 1 #define TARGET_68020 (target_flags & TARGET_MASK_68020) |
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, a number, which contains the bits to set in
target_flags, and a second string which is the description
displayed by `--help'. If the number is negative then the bits specified
by the number are cleared instead of being set. If the description
string is present but empty, then no help information will be displayed
for that option, but it will not count as an undocumented option. The
actual option name is made by appending `-m' to the specified name.
Non-empty description strings should be marked with N_(...) for
xgettext. In addition to the description for `--help',
more detailed documentation for each option should be added to
`invoke.texi'.
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", TARGET_MASK_68020, "" }, \
{ "68000", -TARGET_MASK_68020, \
N_("Compile for the 68000") }, \
{ "", TARGET_MASK_68020, "" }}
|
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, the address of a variable, and a description string
(which should again be marked with N_(...)).
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. Again, each option should
also be documented in `invoke.texi'.
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, \
N_("Specify the size of the short data section") } }
|
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, size)
level is the optimization level specified; 2 if `-O2' is specified, 1 if `-O' is specified, and 0 if neither is specified.
size is nonzero if `-Os' is specified and zero otherwise.
You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same optimization level on all supported machines. Use this macro to enable machine-specific optimizations.
Do not examine write_symbols in
this macro! The debugging options are not supposed to alter the
generated code.
CAN_DEBUG_WITHOUT_FP
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If the target needs to store information on a per-function basis, GCC provides a macro and a couple of variables to allow this. Note, just using statics to store the information is a bad idea, since GCC supports nested functions, so you can be halfway through encoding one function when another one comes along.
GCC defines a data structure called struct function which
contains all of the data specific to an individual function. This
structure contains a field called machine whose type is
struct machine_function *, which can be used by targets to point
to their own specific data.
If a target needs per-function specific data it should define the type
struct machine_function and also the macro
INIT_EXPANDERS. This macro should be used to initialise some or
all of the function pointers init_machine_status,
free_machine_status and mark_machine_status. These
pointers are explained below.
One typical use of per-function, target specific data is to create an
RTX to hold the register containing the function's return address. This
RTX can then be used to implement the __builtin_return_address
function, for level 0.
Note--earlier implementations of GCC used a single data area to hold
all of the per-function information. Thus when processing of a nested
function began the old per-function data had to be pushed onto a
stack, and when the processing was finished, it had to be popped off the
stack. GCC used to provide function pointers called
save_machine_status and restore_machine_status to handle
the saving and restoring of the target specific information. Since the
single data area approach is no longer used, these pointers are no
longer supported.
The macro and function pointers are described below.
INIT_EXPANDERS
init_machine_status
void (*)(struct function *) function pointer. If this
pointer is non-NULL it will be called once per function, before function
compilation starts, in order to allow the target to perform any target
specific initialisation of the struct function structure. It is
intended that this would be used to initialise the machine of
that structure.
free_machine_status
void (*)(struct function *) function pointer. If this
pointer is non-NULL it will be called once per function, after the
function has been compiled, in order to allow any memory allocated
during the init_machine_status function call to be freed.
mark_machine_status
void (*)(struct function *) function pointer. If this
pointer is non-NULL it will be called once per function in order to mark
any data items in the struct machine_function structure which
need garbage collection.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 21.2 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
LIBGCC2_WORDS_BIG_ENDIAN
WORDS_BIG_ENDIAN is not constant. This must be a
constant value with the same meaning as WORDS_BIG_ENDIAN, which will be
used only when compiling `libgcc2.c'. Typically the value will be set
based on preprocessor defines.
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
have the value 0. This macro need not be a constant.
You need not define this macro if the ordering is the same as for multi-word integers.
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
MIN_UNITS_PER_WORD
UNITS_PER_WORD. Otherwise, it is the constant value that is the
smallest value that UNITS_PER_WORD can have at run-time.
POINTER_SIZE
Pmode. If it is not equal to the width of Pmode,
you must define POINTERS_EXTEND_UNSIGNED.
POINTERS_EXTEND_UNSIGNED
POINTER_SIZE bits wide to Pmode are to
be zero-extended and zero if they are to be sign-extended.
You need not define this macro if the POINTER_SIZE is equal
to the width of Pmode.
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
PREFERRED_STACK_BOUNDARY is not defined.
PREFERRED_STACK_BOUNDARY
STACK_BOUNDARY is
also defined, this macro must evaluate to a value equal to or larger
than STACK_BOUNDARY.
FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
PREFERRED_STACK_BOUNDARY is
not guaranteed by the runtime and we should emit code to align the stack
at the beginning of main.
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 PREFERRED_STACK_BOUNDARY, the stack may
be momentarily unaligned while pushing arguments.
FUNCTION_BOUNDARY
BIGGEST_ALIGNMENT
MINIMUM_ATOMIC_ALIGNMENT
BITS_PER_UNIT, but may be larger
on machines that don't have byte or half-word store operations.
BIGGEST_FIELD_ALIGNMENT
BIGGEST_ALIGNMENT for
structure and union fields only, unless the field alignment has been set
by the __attribute__ ((aligned (n))) construct.
ADJUST_FIELD_ALIGN (field, computed)
BIGGEST_ALIGNMENT or
BIGGEST_FIELD_ALIGNMENT, if defined, 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.
LOCAL_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.
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 bit-field (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 bit-field 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 bit-field 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 bit-fields 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 bit-fields work is to define
STRUCTURE_SIZE_BOUNDARY as large as BIGGEST_ALIGNMENT.
Then every structure can be accessed with fullwords.
Unless the machine has bit-field 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 GCC use the same conventions for laying out bit-fields 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
STRUCT_FORCE_BLK (field)
BLKMODE.
Normally, this is not needed. See the file `c4x.h' for an example of how to use this macro to prevent a structure having a floating point field from being accessed in an integer mode.
ROUND_TYPE_SIZE (type, computed, specified)
The default is to round computed up to a multiple of specified.
ROUND_TYPE_SIZE_UNIT (type, computed, specified)
ROUND_TYPE_SIZE, but sizes and alignments are
specified in units (bytes). If you define ROUND_TYPE_SIZE,
you must also define this macro and they must be defined consistently
with each other.
ROUND_TYPE_ALIGN (type, 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.
VECTOR_MODE_SUPPORTED_P(mode)
STACK_SAVEAREA_MODE (save_level)
enum machine_mode that
specifies the mode of the save area operand of a
save_stack_level named pattern (see section 20.8 Standard Pattern Names For Generation).
save_level is one of SAVE_BLOCK, SAVE_FUNCTION, or
SAVE_NONLOCAL and selects which of the three named patterns is
having its mode specified.
You need not define this macro if it always returns Pmode. You
would most commonly define this macro if the
save_stack_level patterns need to support both a 32- and a
64-bit mode.
STACK_SIZE_MODE
enum machine_mode that
specifies the mode of the size increment operand of an
allocate_stack named pattern (see section 20.8 Standard Pattern Names For Generation).
You need not define this macro if it always returns word_mode.
You would most commonly define this macro if the allocate_stack
pattern needs to support both a 32- and a 64-bit mode.
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
IBM_FLOAT_FORMAT
C4X_FLOAT_FORMAT
UNKNOWN_FLOAT_FORMAT
The value of this macro is compared with HOST_FLOAT_FORMAT
(see section 22. 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.
DEFAULT_VTABLE_THUNKS
DEFAULT_VTABLE_THUNKS is 0, GCC uses the traditional
implementation by default. The "thunk" implementation is more efficient
(especially if you have provided an implementation of
ASM_OUTPUT_MI_THUNK, see 21.8.10 Function Entry and Exit), but is not binary
compatible with code compiled using the traditional implementation.
If you are writing a new port, define DEFAULT_VTABLE_THUNKS to 1.
If you do not define this macro, the default for `-fvtable-thunk' is 0.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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. If you want to support GNU Ada on your machine, the value of this
macro must be at least 64.
CHAR_TYPE_SIZE
char on the
target machine. If you don't define this, the default is
BITS_PER_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.
BOOL_TYPE_SIZE
bool on the
target machine. If you don't define this, the default is
CHAR_TYPE_SIZE.
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.
WIDEST_HARDWARE_FP_SIZE
LONG_DOUBLE_TYPE_SIZE.
If you do not define this macro, the value of LONG_DOUBLE_TYPE_SIZE
is the default.
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.
WINT_TYPE
printf and returned from
getwc. The typedef name wint_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 "unsigned int".
INTMAX_TYPE
intmax_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 the first of
"int", "long int", or "long long int" that has as
much precision as long long int.
UINTMAX_TYPE
uintmax_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 the first of
"unsigned int", "long unsigned int", or "long long
unsigned int" that has as much precision as long long unsigned
int.
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_PTRMEMFUNC_VBIT_LOCATION
struct {
union {
void (*fn)();
ptrdiff_t vtable_index;
};
ptrdiff_t delta;
};
|
The C++ compiler must use one bit to indicate whether the function that
will be called through a pointer-to-member-function is virtual.
Normally, we assume that the low-order bit of a function pointer must
always be zero. Then, by ensuring that the vtable_index is odd, we can
distinguish which variant of the union is in use. But, on some
platforms function pointers can be odd, and so this doesn't work. In
that case, we use the low-order bit of the delta field, and shift
the remainder of the delta field to the left.
GCC will automatically make the right selection about where to store
this bit using the FUNCTION_BOUNDARY setting for your platform.
However, some platforms such as ARM/Thumb have FUNCTION_BOUNDARY
set such that functions always start at even addresses, but the lowest
bit of pointers to functions indicate whether the function at that
address is in ARM or Thumb mode. If this is the case of your
architecture, you should define this macro to
ptrmemfunc_vbit_in_delta.
In general, you should not have to define this macro. On architectures
in which function addresses are always even, according to
FUNCTION_BOUNDARY, GCC will automatically define this macro to
ptrmemfunc_vbit_in_pfn.
TARGET_BELL
TARGET_BS
TARGET_TAB
TARGET_NEWLINE
TARGET_VT
TARGET_FF
TARGET_CR
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 21.7 Register Classes. For information on using registers to access a stack frame, see 21.8.3 Registers That Address the Stack Frame. For passing values in registers, see 21.8.6 Passing Arguments in Registers. For returning values in registers, see 21.8.7 How Scalar Function Values Are Returned.
21.6.1 Basic Characteristics of Registers Number and kinds of registers. 21.6.2 Order of Allocation of Registers Order in which registers are allocated. 21.6.3 How Values Fit in Registers What kinds of values each reg can hold. 21.6.4 Handling Leaf Functions Renumbering registers for leaf functions. 21.6.5 Registers That Form a Stack Handling a register stack such as 80387.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
HARD_REGNO_CALL_PART_CLOBBERED (regno, mode)
CONDITIONAL_REGISTER_USAGE
fixed_regs, call_used_regs, global_regs,
(these three are of type char []), reg_names (of type
const char * []) and reg_class_contents (of type
HARD_REG_SET).
Before the macro is called fixed_regs, call_used_regs
reg_class_contents and reg_names have been initialized
from FIXED_REGISTERS, CALL_USED_REGISTERS,
REG_CLASS_CONTENTS and REGISTER_NAMES, respectively,
global_regs has been cleared, and any `-ffixed-reg',
`-fcall-used-reg' and `-fcall-saved-reg' command
options have been applied.
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)
LOCAL_REGNO (regno)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 allocable 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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)
|
ALTER_HARD_SUBREG (tgt_mode, word, src_mode, regno)
(subreg:tgt_mode (reg:src_mode regno) word) |
This may be needed if the target machine has mixed sized big-endian registers, like Sparc v9.
HARD_REGNO_MODE_OK (regno, mode)
#define HARD_REGNO_MODE_OK(REGNO, MODE) 1 |
You need not include code 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. You can implement that by defining this macro to reject odd register numbers for such modes.
The minimum requirement for a mode to be OK in a register is that the `movmode' instruction pattern support moves between the register and other hard register in the same class and that moving a value into the register and back out not alter it.
Since the same instruction used to move word_mode 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 always the same for
any r, then MODES_TIEABLE_P (mode1, mode2)
should be nonzero. If they differ for any r, you should define
this macro to return zero unless some other mechanism ensures the
accessibility of the value in a narrower mode.
You should define this macro to return nonzero in as many cases as possible since doing so will allow GCC to perform better register allocation.
AVOID_CCMODE_COPIES
CCmode
registers. You should only define this macro if support for copying to/from
CCmode is incomplete.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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".
GCC 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 GCC 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. They can test the C variable
current_function_is_leaf which is nonzero for leaf functions.
current_function_is_leaf is set prior to local register allocation
and is valid for the remaining compiler passes. They can also test the C
variable current_function_uses_only_leaf_regs which is nonzero for
leaf functions which only use leaf registers.
current_function_uses_only_leaf_regs is valid after reload and is
only useful if LEAF_REGISTERS is defined.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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, GCC can only handle one group of stack-like registers, and they must be consecutively numbered.
STACK_REGS
FIRST_STACK_REG
LAST_STACK_REG
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
In this situation, the first integer in each sub-initializer corresponds to
registers 0 through 31, the second integer to registers 32 through 63, and
so on.
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_MODE_OK_FOR_BASE_P (num, mode)
REGNO_OK_FOR_BASE_P, except that
that expression may examine the mode of the memory reference in
mode. You should define this macro if the mode of the memory
reference affects whether a register may be used as a base register. If
you define this macro, the compiler will use it instead of
REGNO_OK_FOR_BASE_P.
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 20.8 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 to be an expression with a nonzero
value on these machines. When this macro has a nonzero value, the
compiler will try to minimize the lifetime of hard registers.
It is always safe to define this macro with a nonzero value, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not define this macro with a nonzero value when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro at all.
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 pseudos allocated by `local-alloc.c' end up in memory because their hard registers were needed for spill registers. If this macro returns nonzero for those classes, those pseudos will only be allocated by `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_MODE
CLASS_CANNOT_CHANGE_MODE_P(from, to)
CLASS_CANNOT_CHANGE_MODE, the requested mode punning is invalid.
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 CLASS_CANNOT_CHANGE_MODE
as FLOAT_REGS and CLASS_CANNOT_CHANGE_MODE_P restricts
mode changes to same-size modes.
Compare this to IA-64, which extends floating-point values to 82-bits,
and stores 64-bit integers in a different format than 64-bit doubles.
Therefore CLASS_CANNOT_CHANGE_MODE_P is always true.
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
(`G' or `H').
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)
REG_CLASS_FROM_LETTER
may be used. Normally this macro will not be defined.
If it is required for a particular target machine, it should return 1 if value corresponds to the operand type represented by the constraint letter c. If c is not defined as an extra constraint, the value returned should be 0 regardless of value.
For example, on the ROMP, load instructions cannot have their output in r0 if the memory reference contains a symbolic address. Constraint letter `Q' is defined as representing a memory address that does not contain a symbolic address. An alternative is specified with a `Q' constraint on the input and `r' on the output. The next alternative specifies `m' on the input and a register class that does not include r0 on the output.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This describes the stack layout and calling conventions.