1003 lines
42 KiB
Plaintext
1003 lines
42 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||
|
||
INFO-DIR-SECTION Programming
|
||
START-INFO-DIR-ENTRY
|
||
* gcc: (gcc). The GNU Compiler Collection.
|
||
END-INFO-DIR-ENTRY
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||
Boston, MA 02111-1307 USA
|
||
|
||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||
1999 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the sections entitled "GNU General Public License" and "Funding
|
||
for Free Software" are included exactly as in the original, and
|
||
provided that the entire resulting derived work is distributed under
|
||
the terms of a permission notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the sections entitled "GNU General Public
|
||
License" and "Funding for Free Software", and this permission notice,
|
||
may be included in translations approved by the Free Software Foundation
|
||
instead of in the original English.
|
||
|
||
|
||
File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Target Macros
|
||
|
||
Storage Layout
|
||
==============
|
||
|
||
Note that the definitions of the macros in this table which are
|
||
sizes or alignments measured in bits do not need to be constant. They
|
||
can be C expressions that refer to static variables, such as the
|
||
`target_flags'. *Note Run-time Target::.
|
||
|
||
`BITS_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if the most significant bit
|
||
in a byte has the lowest number; otherwise define it to have the
|
||
value zero. This means that bit-field instructions count from the
|
||
most significant bit. If the machine has no bit-field
|
||
instructions, then this must still be defined, but it doesn't
|
||
matter which value it is defined to. This macro need not be a
|
||
constant.
|
||
|
||
This macro does not affect the way structure fields are packed into
|
||
bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
|
||
|
||
`BYTES_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if the most significant byte
|
||
in a word has the lowest number. This macro need not be a
|
||
constant.
|
||
|
||
`WORDS_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if, in a multiword object,
|
||
the most significant word has the lowest number. This applies to
|
||
both memory locations and registers; GNU CC fundamentally assumes
|
||
that the order of words in memory is the same as the order in
|
||
registers. This macro need not be a constant.
|
||
|
||
`LIBGCC2_WORDS_BIG_ENDIAN'
|
||
Define this macro if WORDS_BIG_ENDIAN is not constant. This must
|
||
be a constant value with the same meaning as WORDS_BIG_ENDIAN,
|
||
which will be used only when compiling libgcc2.c. Typically the
|
||
value will be set based on preprocessor defines.
|
||
|
||
`FLOAT_WORDS_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if `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'
|
||
Define this macro to be the number of bits in an addressable
|
||
storage unit (byte); normally 8.
|
||
|
||
`BITS_PER_WORD'
|
||
Number of bits in a word; normally 32.
|
||
|
||
`MAX_BITS_PER_WORD'
|
||
Maximum number of bits in a word. If this is undefined, the
|
||
default is `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'
|
||
Number of storage units in a word; normally 4.
|
||
|
||
`MIN_UNITS_PER_WORD'
|
||
Minimum number of units in a word. If this is undefined, the
|
||
default is `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'
|
||
Width of a pointer, in bits. You must specify a value no wider
|
||
than the width of `Pmode'. If it is not equal to the width of
|
||
`Pmode', you must define `POINTERS_EXTEND_UNSIGNED'.
|
||
|
||
`POINTERS_EXTEND_UNSIGNED'
|
||
A C expression whose value is nonzero if pointers that need to be
|
||
extended from being `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)'
|
||
A macro to update M and UNSIGNEDP when an object whose type is
|
||
TYPE and which has the specified mode and signedness is to be
|
||
stored in a register. This macro is only called when TYPE is a
|
||
scalar 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'
|
||
Define this macro if the promotion described by `PROMOTE_MODE'
|
||
should also be done for outgoing function arguments.
|
||
|
||
`PROMOTE_FUNCTION_RETURN'
|
||
Define this macro if the promotion described by `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'
|
||
Define this macro if the promotion described by `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'
|
||
Normal alignment required for function parameters on the stack, in
|
||
bits. All stack parameters receive at least this much alignment
|
||
regardless of data type. On most machines, this is the same as the
|
||
size of an integer.
|
||
|
||
`STACK_BOUNDARY'
|
||
Define this macro if there is a guaranteed alignment for the stack
|
||
pointer on this machine. The definition is a C expression for the
|
||
desired alignment (measured in bits). This value is used as a
|
||
default if PREFERRED_STACK_BOUNDARY is not defined.
|
||
|
||
`PREFERRED_STACK_BOUNDARY'
|
||
Define this macro if you wish to preserve a certain alignment for
|
||
the stack pointer. The definition is a C expression for the
|
||
desired alignment (measured in bits). If STACK_BOUNDARY is also
|
||
defined, this macro must evaluate to a value equal to or larger
|
||
than 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 `PREFERRED_STACK_BOUNDARY',
|
||
the stack may be momentarily unaligned while pushing arguments.
|
||
|
||
`FUNCTION_BOUNDARY'
|
||
Alignment required for a function entry point, in bits.
|
||
|
||
`BIGGEST_ALIGNMENT'
|
||
Biggest alignment that any data type can require on this machine,
|
||
in bits.
|
||
|
||
`MINIMUM_ATOMIC_ALIGNMENT'
|
||
If defined, the smallest alignment, in bits, that can be given to
|
||
an object that can be referenced in one operation, without
|
||
disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
|
||
but may be larger on machines that don't have byte or half-word
|
||
store operations.
|
||
|
||
`BIGGEST_FIELD_ALIGNMENT'
|
||
Biggest alignment that any structure field can require on this
|
||
machine, in bits. If defined, this overrides `BIGGEST_ALIGNMENT'
|
||
for structure fields only.
|
||
|
||
`ADJUST_FIELD_ALIGN (FIELD, COMPUTED)'
|
||
An expression for the alignment of a structure field FIELD if the
|
||
alignment computed in the usual way is COMPUTED. GNU CC uses this
|
||
value instead of the value in `BIGGEST_ALIGNMENT' or
|
||
`BIGGEST_FIELD_ALIGNMENT', if defined, for structure fields only.
|
||
|
||
`MAX_OFILE_ALIGNMENT'
|
||
Biggest alignment supported by the object file format of this
|
||
machine. Use this macro to limit the alignment which can be
|
||
specified using the `__attribute__ ((aligned (N)))' construct. If
|
||
not defined, the default value is `BIGGEST_ALIGNMENT'.
|
||
|
||
`DATA_ALIGNMENT (TYPE, BASIC-ALIGN)'
|
||
If defined, a C expression to compute the alignment for a
|
||
variables in the static store. TYPE is the data type, and
|
||
BASIC-ALIGN is the alignment that the object would ordinarily
|
||
have. The value of this macro is used instead of that alignment
|
||
to align the object.
|
||
|
||
If this macro is not defined, then 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 defined, a C expression to compute the alignment given to a
|
||
constant that is being placed in memory. CONSTANT is the constant
|
||
and BASIC-ALIGN is the alignment that the object would ordinarily
|
||
have. The value of this macro is used instead of that alignment to
|
||
align the object.
|
||
|
||
If this macro is not defined, then 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 defined, a C expression to compute the alignment for a
|
||
variables in the local store. TYPE is the data type, and
|
||
BASIC-ALIGN is the alignment that the object would ordinarily
|
||
have. The value of this macro is used instead of that alignment
|
||
to align the object.
|
||
|
||
If this macro is not defined, then 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'
|
||
Alignment in bits to be given to a structure bit field that
|
||
follows an empty field such as `int : 0;'.
|
||
|
||
Note that `PCC_BITFIELD_TYPE_MATTERS' also affects the alignment
|
||
that results from an empty field.
|
||
|
||
`STRUCTURE_SIZE_BOUNDARY'
|
||
Number of bits which any structure or union's size must be a
|
||
multiple of. Each structure or union's size is rounded up to a
|
||
multiple of this.
|
||
|
||
If you do not define this macro, the default is the same as
|
||
`BITS_PER_UNIT'.
|
||
|
||
`STRICT_ALIGNMENT'
|
||
Define this macro to be the value 1 if instructions will fail to
|
||
work if given data not on the nominal alignment. If instructions
|
||
will merely go slower in that case, define this macro as 0.
|
||
|
||
`PCC_BITFIELD_TYPE_MATTERS'
|
||
Define this if you wish to imitate the way many other C compilers
|
||
handle alignment of bitfields and the structures that contain them.
|
||
|
||
The behavior is that the type written for a bitfield (`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'
|
||
Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to
|
||
aligning a bitfield within the structure.
|
||
|
||
`ROUND_TYPE_SIZE (TYPE, COMPUTED, SPECIFIED)'
|
||
Define this macro as an expression for the overall size of a type
|
||
(given by TYPE as a tree node) when the size computed in the usual
|
||
way is COMPUTED and the alignment is SPECIFIED.
|
||
|
||
The default is to round COMPUTED up to a multiple of SPECIFIED.
|
||
|
||
`ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)'
|
||
Define this macro as an expression for the alignment of a type
|
||
(given by TYPE as a tree node) if the alignment computed in the
|
||
usual way is COMPUTED and the alignment explicitly specified was
|
||
SPECIFIED.
|
||
|
||
The default is to use SPECIFIED if it is larger; otherwise, use
|
||
the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
|
||
|
||
`MAX_FIXED_MODE_SIZE'
|
||
An integer expression for the size in bits of the largest integer
|
||
machine mode that should actually be used. All integer machine
|
||
modes of this size or smaller can be used for structures and
|
||
unions with the appropriate sizes. If this macro is undefined,
|
||
`GET_MODE_BITSIZE (DImode)' is assumed.
|
||
|
||
`STACK_SAVEAREA_MODE (SAVE_LEVEL)'
|
||
If defined, an expression of type `enum machine_mode' that
|
||
specifies the mode of the save area operand of a
|
||
`save_stack_LEVEL' named pattern (*note Standard Names::.).
|
||
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'
|
||
If defined, an expression of type `enum machine_mode' that
|
||
specifies the mode of the size increment operand of an
|
||
`allocate_stack' named pattern (*note Standard Names::.).
|
||
|
||
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)'
|
||
A C statement to validate the value VALUE (of type `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'
|
||
A code distinguishing the floating point format of the target
|
||
machine. There are three defined values:
|
||
|
||
`IEEE_FLOAT_FORMAT'
|
||
This code indicates IEEE floating point. It is the default;
|
||
there is no need to define this macro when the format is IEEE.
|
||
|
||
`VAX_FLOAT_FORMAT'
|
||
This code indicates the peculiar format used on the Vax.
|
||
|
||
`UNKNOWN_FLOAT_FORMAT'
|
||
This code indicates any other format.
|
||
|
||
The value of this macro is compared with `HOST_FLOAT_FORMAT'
|
||
(*note Config::.) to determine whether the target machine has the
|
||
same format as the host machine. If any other formats are
|
||
actually in use on supported machines, new codes should be defined
|
||
for them.
|
||
|
||
The ordering of the component words of floating point values
|
||
stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN' for the
|
||
target machine and `HOST_FLOAT_WORDS_BIG_ENDIAN' for the host.
|
||
|
||
`DEFAULT_VTABLE_THUNKS'
|
||
GNU CC supports two ways of implementing C++ vtables: traditional
|
||
or with so-called "thunks". The flag `-fvtable-thunk' chooses
|
||
between them. Define this macro to be a C expression for the
|
||
default value of that flag. If `DEFAULT_VTABLE_THUNKS' is 0, GNU
|
||
CC uses the traditional implementation by default. The "thunk"
|
||
implementation is more efficient (especially if you have provided
|
||
an implementation of `ASM_OUTPUT_MI_THUNK', see *Note Function
|
||
Entry::), but is not binary compatible with code compiled using
|
||
the traditional implementation. If you are writing a new ports,
|
||
define `DEFAULT_VTABLE_THUNKS' to 1.
|
||
|
||
If you do not define this macro, the default for `-fvtable-thunk'
|
||
is 0.
|
||
|
||
|
||
File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
|
||
|
||
Layout of Source Language Data Types
|
||
====================================
|
||
|
||
These macros define the sizes and other characteristics of the
|
||
standard basic data types used in programs being compiled. Unlike the
|
||
macros in the previous section, these apply to specific features of C
|
||
and related languages, rather than to fundamental aspects of storage
|
||
layout.
|
||
|
||
`INT_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `int' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`MAX_INT_TYPE_SIZE'
|
||
Maximum number for the size in bits of the type `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'
|
||
A C expression for the size in bits of the type `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'
|
||
A C expression for the size in bits of the type `long' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`MAX_LONG_TYPE_SIZE'
|
||
Maximum number for the size in bits of the type `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'
|
||
A C expression for the size in bits of the type `long long' on the
|
||
target machine. If you don't define this, the default is two
|
||
words. If you want to support GNU Ada on your machine, the value
|
||
of macro must be at least 64.
|
||
|
||
`CHAR_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `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'
|
||
Maximum number for the size in bits of the type `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'
|
||
A C expression for the size in bits of the type `float' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`DOUBLE_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `double' on the
|
||
target machine. If you don't define this, the default is two
|
||
words.
|
||
|
||
`LONG_DOUBLE_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `long double' on
|
||
the target machine. If you don't define this, the default is two
|
||
words.
|
||
|
||
`WIDEST_HARDWARE_FP_SIZE'
|
||
A C expression for the size in bits of the widest floating-point
|
||
format supported by the hardware. If you define this macro, you
|
||
must specify a value less than or equal to the value of
|
||
`LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
|
||
value of `LONG_DOUBLE_TYPE_SIZE' is the default.
|
||
|
||
`DEFAULT_SIGNED_CHAR'
|
||
An expression whose value is 1 or 0, according to whether the type
|
||
`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'
|
||
A C expression to determine whether to give an `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'
|
||
A C expression for a string describing the name of the data type
|
||
to use for size values. The typedef name `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'
|
||
A C expression for a string describing the name of the data type
|
||
to use for the result of subtracting two pointers. The typedef
|
||
name `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'
|
||
A C expression for a string describing the name of the data type
|
||
to use for wide characters. The typedef name `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'
|
||
A C expression for the size in bits of the data type for wide
|
||
characters. This is used in `cpp', which cannot make use of
|
||
`WCHAR_TYPE'.
|
||
|
||
`MAX_WCHAR_TYPE_SIZE'
|
||
Maximum number for the size in bits of the data type for wide
|
||
characters. If this is undefined, the default is
|
||
`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'
|
||
Define this macro if the type of Objective C selectors should be
|
||
`int'.
|
||
|
||
If this macro is not defined, then selectors should have the type
|
||
`struct objc_selector *'.
|
||
|
||
`OBJC_SELECTORS_WITHOUT_LABELS'
|
||
Define this macro if the compiler can group all the selectors
|
||
together into a vector and use just one label at the beginning of
|
||
the vector. Otherwise, the compiler must give each selector its
|
||
own assembler label.
|
||
|
||
On certain machines, it is important to have a separate label for
|
||
each selector because this enables the linker to eliminate
|
||
duplicate selectors.
|
||
|
||
`TARGET_BELL'
|
||
A C constant expression for the integer value for escape sequence
|
||
`\a'.
|
||
|
||
`TARGET_BS'
|
||
`TARGET_TAB'
|
||
`TARGET_NEWLINE'
|
||
C constant expressions for the integer values for escape sequences
|
||
`\b', `\t' and `\n'.
|
||
|
||
`TARGET_VT'
|
||
`TARGET_FF'
|
||
`TARGET_CR'
|
||
C constant expressions for the integer values for escape sequences
|
||
`\v', `\f' and `\r'.
|
||
|
||
|
||
File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
|
||
|
||
Register Usage
|
||
==============
|
||
|
||
This section explains how to describe what registers the target
|
||
machine has, and how (in general) they can be used.
|
||
|
||
The description of which registers a specific instruction can use is
|
||
done with register classes; see *Note Register Classes::. For
|
||
information on using registers to access a stack frame, see *Note Frame
|
||
Registers::. For passing values in registers, see *Note Register
|
||
Arguments::. For returning values in registers, see *Note Scalar
|
||
Return::.
|
||
|
||
* Menu:
|
||
|
||
* Register Basics:: Number and kinds of registers.
|
||
* Allocation Order:: Order in which registers are allocated.
|
||
* Values in Registers:: What kinds of values each reg can hold.
|
||
* Leaf Functions:: Renumbering registers for leaf functions.
|
||
* Stack Registers:: Handling a register stack such as 80387.
|
||
* Obsolete Register Macros:: Macros formerly used for the 80387.
|
||
|
||
|
||
File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers
|
||
|
||
Basic Characteristics of Registers
|
||
----------------------------------
|
||
|
||
Registers have various characteristics.
|
||
|
||
`FIRST_PSEUDO_REGISTER'
|
||
Number of hardware registers known to the compiler. They receive
|
||
numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
|
||
pseudo register's number really is assigned the number
|
||
`FIRST_PSEUDO_REGISTER'.
|
||
|
||
`FIXED_REGISTERS'
|
||
An initializer that says which registers are used for fixed
|
||
purposes all throughout the compiled code and are therefore not
|
||
available for general allocation. These would include the stack
|
||
pointer, the frame pointer (except on machines where that can be
|
||
used as a general register when no frame pointer is needed), the
|
||
program counter on machines where that is considered one of the
|
||
addressable registers, and any other numbered register with a
|
||
standard use.
|
||
|
||
This information is expressed as a sequence of numbers, separated
|
||
by commas and surrounded by braces. The 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'
|
||
Like `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)'
|
||
A C expression that is non-zero if it is not permissible to store a
|
||
value of mode MODE in hard register number REGNO across a call
|
||
without some part of it being clobbered. For most machines this
|
||
macro need not be defined. It is only required for machines that
|
||
do not preserve the entire contents of a register across a call.
|
||
|
||
`CONDITIONAL_REGISTER_USAGE'
|
||
Zero or more C statements that may conditionally modify four
|
||
variables `fixed_regs', `call_used_regs', `global_regs' (these
|
||
three are of type `char []') and `reg_class_contents' (of type
|
||
`HARD_REG_SET'). Before the macro is called `fixed_regs',
|
||
`call_used_regs' and `reg_class_contents' have been initialized
|
||
from `FIXED_REGISTERS', `CALL_USED_REGISTERS' and
|
||
`REG_CLASS_CONTENTS', 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'
|
||
If this macro is defined and has a nonzero value, it means that
|
||
`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)'
|
||
Define this macro if the target machine has register windows.
|
||
This C expression returns the register number as seen by the
|
||
called function corresponding to the register number OUT as seen
|
||
by the calling function. Return OUT if register number OUT is not
|
||
an outbound register.
|
||
|
||
`OUTGOING_REGNO (IN)'
|
||
Define this macro if the target machine has register windows.
|
||
This C expression returns the register number as seen by the
|
||
calling function corresponding to the register number IN as seen
|
||
by the called function. Return IN if register number IN is not an
|
||
inbound register.
|
||
|
||
|
||
File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
|
||
|
||
Order of Allocation of Registers
|
||
--------------------------------
|
||
|
||
Registers are allocated in order.
|
||
|
||
`REG_ALLOC_ORDER'
|
||
If defined, an initializer for a vector of integers, containing the
|
||
numbers of hard registers in the order in which GNU CC should
|
||
prefer to use them (from most preferred to least).
|
||
|
||
If this macro is not defined, registers are used lowest numbered
|
||
first (all else being equal).
|
||
|
||
One use of this macro is on machines where the highest numbered
|
||
registers must always be saved and the save-multiple-registers
|
||
instruction supports only sequences of consecutive registers. On
|
||
such machines, define `REG_ALLOC_ORDER' to be an initializer that
|
||
lists the highest numbered allocable register first.
|
||
|
||
`ORDER_REGS_FOR_LOCAL_ALLOC'
|
||
A C statement (sans semicolon) to choose the order in which to
|
||
allocate hard registers for pseudo-registers local to a basic
|
||
block.
|
||
|
||
Store the desired register order in the array `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.
|
||
|
||
|
||
File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
|
||
|
||
How Values Fit in Registers
|
||
---------------------------
|
||
|
||
This section discusses the macros that describe which kinds of values
|
||
(specifically, which machine modes) each register can hold, and how many
|
||
consecutive registers are needed for a given mode.
|
||
|
||
`HARD_REGNO_NREGS (REGNO, MODE)'
|
||
A C expression for the number of consecutive hard registers,
|
||
starting at register number REGNO, required to hold a value of mode
|
||
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)'
|
||
A C expression that returns an adjusted hard register number for
|
||
|
||
(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)'
|
||
A C expression that is nonzero if it is permissible to store a
|
||
value of mode MODE in hard register number REGNO (or in several
|
||
registers starting with that one). For a machine where all
|
||
registers are equivalent, a suitable definition is
|
||
|
||
#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)'
|
||
A C expression that is nonzero if a value of mode MODE1 is
|
||
accessible in mode MODE2 without copying.
|
||
|
||
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 GNU CC to perform better
|
||
register allocation.
|
||
|
||
`AVOID_CCMODE_COPIES'
|
||
Define this macro if the compiler should avoid copies to/from
|
||
`CCmode' registers. You should only define this macro if support
|
||
fo copying to/from `CCmode' is incomplete.
|
||
|
||
|
||
File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
|
||
|
||
Handling Leaf Functions
|
||
-----------------------
|
||
|
||
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'
|
||
A C initializer for a vector, indexed by hard register number,
|
||
which contains 1 for a register that is allowable in a candidate
|
||
for leaf function treatment.
|
||
|
||
If leaf function treatment involves renumbering the registers,
|
||
then the registers marked here should be the ones before
|
||
renumbering--those that GNU CC would ordinarily allocate. The
|
||
registers which will actually be used in the assembler code, after
|
||
renumbering, should not be marked with 1 in this vector.
|
||
|
||
Define this macro only if the target machine offers a way to
|
||
optimize the treatment of leaf functions.
|
||
|
||
`LEAF_REG_REMAP (REGNO)'
|
||
A C expression whose value is the register number to which REGNO
|
||
should be renumbered, when a function is treated as a leaf
|
||
function.
|
||
|
||
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.
|
||
|
||
|
||
File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers
|
||
|
||
Registers That Form a Stack
|
||
---------------------------
|
||
|
||
There are special features to handle computers where some of the
|
||
"registers" form a stack, as in the 80387 coprocessor for the 80386.
|
||
Stack registers are normally written by pushing onto the stack, and are
|
||
numbered relative to the top of the stack.
|
||
|
||
Currently, GNU CC can only handle one group of stack-like registers,
|
||
and they must be consecutively numbered.
|
||
|
||
`STACK_REGS'
|
||
Define this if the machine has any stack-like registers.
|
||
|
||
`FIRST_STACK_REG'
|
||
The number of the first stack-like register. This one is the top
|
||
of the stack.
|
||
|
||
`LAST_STACK_REG'
|
||
The number of the last stack-like register. This one is the
|
||
bottom of the stack.
|
||
|
||
|
||
File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
|
||
|
||
Obsolete Macros for Controlling Register Usage
|
||
----------------------------------------------
|
||
|
||
These features do not work very well. They exist because they used
|
||
to be required to generate correct code for the 80387 coprocessor of the
|
||
80386. They are no longer used by that machine description and may be
|
||
removed in a later version of the compiler. Don't use them!
|
||
|
||
`OVERLAPPING_REGNO_P (REGNO)'
|
||
If defined, this is a C expression whose value is nonzero if hard
|
||
register number REGNO is an overlapping register. This means a
|
||
hard register which overlaps a hard register with a different
|
||
number. (Such overlap is undesirable, but occasionally it allows
|
||
a machine to be supported which otherwise could not be.) This
|
||
macro must return nonzero for *all* the registers which overlap
|
||
each other. GNU CC can use an overlapping register only in
|
||
certain limited ways. It can be used for allocation within a
|
||
basic block, and may be spilled for reloading; that is all.
|
||
|
||
If this macro is not defined, it means that none of the hard
|
||
registers overlap each other. This is the usual situation.
|
||
|
||
`INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
|
||
If defined, this is a C expression whose value should be nonzero if
|
||
the insn INSN has the effect of mysteriously clobbering the
|
||
contents of hard register number REGNO. By "mysterious" we mean
|
||
that the insn's RTL expression doesn't describe such an effect.
|
||
|
||
If this macro is not defined, it means that no insn clobbers
|
||
registers mysteriously. This is the usual situation; all else
|
||
being equal, it is best for the RTL expression to show all the
|
||
activity.
|
||
|