Remove extra spacing at the end of the line.
From-SVN: r173401
This commit is contained in:
parent
91e4938b8c
commit
ff2ce160cb
|
@ -626,7 +626,7 @@ may be used at a later point in the program. This information is
|
|||
used, for instance, during register allocation, as the pseudo
|
||||
registers only need to be assigned to a unique hard register or to a
|
||||
stack slot if they are live. The hard registers and stack slots may
|
||||
be freely reused for other values when a register is dead.
|
||||
be freely reused for other values when a register is dead.
|
||||
|
||||
Liveness information is available in the back end starting with
|
||||
@code{pass_df_initialize} and ending with @code{pass_df_finish}. Three
|
||||
|
@ -634,7 +634,7 @@ flavors of live analysis are available: With @code{LR}, it is possible
|
|||
to determine at any point @code{P} in the function if the register may be
|
||||
used on some path from @code{P} to the end of the function. With
|
||||
@code{UR}, it is possible to determine if there is a path from the
|
||||
beginning of the function to @code{P} that defines the variable.
|
||||
beginning of the function to @code{P} that defines the variable.
|
||||
@code{LIVE} is the intersection of the @code{LR} and @code{UR} and a
|
||||
variable is live at @code{P} if there is both an assignment that reaches
|
||||
it from the beginning of the function and a use that can be reached on
|
||||
|
@ -645,7 +645,7 @@ In general @code{LIVE} is the most useful of the three. The macros
|
|||
The macros take a basic block number and return a bitmap that is indexed
|
||||
by the register number. This information is only guaranteed to be up to
|
||||
date after calls are made to @code{df_analyze}. See the file
|
||||
@code{df-core.c} for details on using the dataflow.
|
||||
@code{df-core.c} for details on using the dataflow.
|
||||
|
||||
|
||||
@findex REG_DEAD, REG_UNUSED
|
||||
|
|
|
@ -934,8 +934,8 @@ Teemu Torma for thread safe exception handling support.
|
|||
Leonard Tower wrote parts of the parser, RTL generator, and RTL
|
||||
definitions, and of the VAX machine description.
|
||||
|
||||
@item
|
||||
Daniel Towner and Hariharan Sandanagobalane contributed and
|
||||
@item
|
||||
Daniel Towner and Hariharan Sandanagobalane contributed and
|
||||
maintain the picoChip port.
|
||||
|
||||
@item
|
||||
|
|
|
@ -1964,7 +1964,7 @@ generate unique identifiers. Care must be taken to ensure that
|
|||
which use it. Otherwise, the precompiled headers will not be used.
|
||||
|
||||
@item __GFORTRAN__
|
||||
The GNU Fortran compiler defines this.
|
||||
The GNU Fortran compiler defines this.
|
||||
|
||||
@item __GNUC__
|
||||
@itemx __GNUC_MINOR__
|
||||
|
|
|
@ -37,7 +37,7 @@ extensions, accepted by GCC in C90 mode and in C++.
|
|||
* Complex:: Data types for complex numbers.
|
||||
* Floating Types:: Additional Floating Types.
|
||||
* Half-Precision:: Half-Precision Floating Point.
|
||||
* Decimal Float:: Decimal Floating Types.
|
||||
* Decimal Float:: Decimal Floating Types.
|
||||
* Hex Floats:: Hexadecimal floating-point constants.
|
||||
* Fixed-Point:: Fixed-Point Types.
|
||||
* Named Address Spaces::Named address spaces.
|
||||
|
@ -455,7 +455,7 @@ does not refer to anything that has gone out of scope, you should be
|
|||
safe.
|
||||
|
||||
GCC implements taking the address of a nested function using a technique
|
||||
called @dfn{trampolines}. This technique was described in
|
||||
called @dfn{trampolines}. This technique was described in
|
||||
@cite{Lexical Closures for C++} (Thomas M. Breuel, USENIX
|
||||
C++ Conference Proceedings, October 17-21, 1988).
|
||||
|
||||
|
@ -619,7 +619,7 @@ myopen (const char *path, int oflag, ...)
|
|||
@}
|
||||
return open (path, oflag, __builtin_va_arg_pack ());
|
||||
@}
|
||||
|
||||
|
||||
if (__builtin_va_arg_pack_len () < 1)
|
||||
return __open_2 (path, oflag);
|
||||
|
||||
|
@ -942,7 +942,7 @@ The @code{__float128} type is supported on hppa HP-UX targets.
|
|||
@cindex @code{__fp16} data type
|
||||
|
||||
On ARM targets, GCC supports half-precision (16-bit) floating point via
|
||||
the @code{__fp16} type. You must enable this type explicitly
|
||||
the @code{__fp16} type. You must enable this type explicitly
|
||||
with the @option{-mfp16-format} command-line option in order to use it.
|
||||
|
||||
ARM supports two incompatible representations for half-precision
|
||||
|
@ -963,7 +963,7 @@ values in the range of @math{2^{-14}} to 131008.
|
|||
The @code{__fp16} type is a storage format only. For purposes
|
||||
of arithmetic and other operations, @code{__fp16} values in C or C++
|
||||
expressions are automatically promoted to @code{float}. In addition,
|
||||
you cannot declare a function with a return value or parameters
|
||||
you cannot declare a function with a return value or parameters
|
||||
of type @code{__fp16}.
|
||||
|
||||
Note that conversions from @code{double} to @code{__fp16}
|
||||
|
@ -971,14 +971,14 @@ involve an intermediate conversion to @code{float}. Because
|
|||
of rounding, this can sometimes produce a different result than a
|
||||
direct conversion.
|
||||
|
||||
ARM provides hardware support for conversions between
|
||||
ARM provides hardware support for conversions between
|
||||
@code{__fp16} and @code{float} values
|
||||
as an extension to VFP and NEON (Advanced SIMD). GCC generates
|
||||
code using these hardware instructions if you compile with
|
||||
options to select an FPU that provides them;
|
||||
options to select an FPU that provides them;
|
||||
for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
|
||||
in addition to the @option{-mfp16-format} option to select
|
||||
a half-precision format.
|
||||
a half-precision format.
|
||||
|
||||
Language-level support for the @code{__fp16} data type is
|
||||
independent of whether GCC generates code using hardware floating-point
|
||||
|
@ -1995,7 +1995,7 @@ The @code{aligned} attribute can also be used for variables and fields
|
|||
@cindex @code{alloc_size} attribute
|
||||
The @code{alloc_size} attribute is used to tell the compiler that the
|
||||
function return value points to memory, where the size is given by
|
||||
one or two of the functions parameters. GCC uses this
|
||||
one or two of the functions parameters. GCC uses this
|
||||
information to improve the correctness of @code{__builtin_object_size}.
|
||||
|
||||
The function parameter(s) denoting the allocated size are specified by
|
||||
|
@ -2004,7 +2004,7 @@ is either the value of the single function argument specified or the product
|
|||
of the two function arguments specified. Argument numbering starts at
|
||||
one.
|
||||
|
||||
For instance,
|
||||
For instance,
|
||||
|
||||
@smallexample
|
||||
void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
|
||||
|
@ -2213,7 +2213,7 @@ On systems that support the @code{visibility} attribute, this
|
|||
attribute also implies ``default'' visibility. It is an error to
|
||||
explicitly specify any other visibility.
|
||||
|
||||
In previous versions of GCC, the @code{dllexport} attribute was ignored
|
||||
In previous versions of GCC, the @code{dllexport} attribute was ignored
|
||||
for inlined functions, unless the @option{-fkeep-inline-functions} flag
|
||||
had been used. The default behaviour now is to emit all dllexported
|
||||
inline functions; however, this can cause object file-size bloat, in
|
||||
|
@ -2424,10 +2424,10 @@ standard modes, the X/Open function @code{strfmon} is also checked as
|
|||
are @code{printf_unlocked} and @code{fprintf_unlocked}.
|
||||
@xref{C Dialect Options,,Options Controlling C Dialect}.
|
||||
|
||||
For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
|
||||
For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
|
||||
recognized in the same context. Declarations including these format attributes
|
||||
will be parsed for correct syntax, however the result of checking of such format
|
||||
strings is not yet defined, and will not be carried out by this version of the
|
||||
strings is not yet defined, and will not be carried out by this version of the
|
||||
compiler.
|
||||
|
||||
The target may also provide additional types of format checks.
|
||||
|
@ -2752,7 +2752,7 @@ command-line switch. The @code{long_call} and @code{far} attributes are
|
|||
synonyms, and cause the compiler to always call
|
||||
the function by first loading its address into a register, and then using
|
||||
the contents of that register. The @code{near} attribute has the opposite
|
||||
effect; it specifies that non-PIC calls should be made using the more
|
||||
effect; it specifies that non-PIC calls should be made using the more
|
||||
efficient @code{jal} instruction.
|
||||
|
||||
@item malloc
|
||||
|
@ -2773,11 +2773,11 @@ value.
|
|||
|
||||
On MIPS targets, you can use the @code{mips16} and @code{nomips16}
|
||||
function attributes to locally select or turn off MIPS16 code generation.
|
||||
A function with the @code{mips16} attribute is emitted as MIPS16 code,
|
||||
while MIPS16 code generation is disabled for functions with the
|
||||
@code{nomips16} attribute. These attributes override the
|
||||
A function with the @code{mips16} attribute is emitted as MIPS16 code,
|
||||
while MIPS16 code generation is disabled for functions with the
|
||||
@code{nomips16} attribute. These attributes override the
|
||||
@option{-mips16} and @option{-mno-mips16} options on the command line
|
||||
(@pxref{MIPS Options}).
|
||||
(@pxref{MIPS Options}).
|
||||
|
||||
When compiling files containing mixed MIPS16 and non-MIPS16 code, the
|
||||
preprocessor symbol @code{__mips16} reflects the setting on the command line,
|
||||
|
@ -2854,11 +2854,11 @@ and newer.
|
|||
@cindex function without a prologue/epilogue code
|
||||
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
|
||||
the specified function does not need prologue/epilogue sequences generated by
|
||||
the compiler. It is up to the programmer to provide these sequences. The
|
||||
only statements that can be safely included in naked functions are
|
||||
the compiler. It is up to the programmer to provide these sequences. The
|
||||
only statements that can be safely included in naked functions are
|
||||
@code{asm} statements that do not have operands. All other statements,
|
||||
including declarations of local variables, @code{if} statements, and so
|
||||
forth, should be avoided. Naked functions should be used to implement the
|
||||
including declarations of local variables, @code{if} statements, and so
|
||||
forth, should be avoided. Naked functions should be used to implement the
|
||||
body of an assembly function, while allowing the compiler to construct
|
||||
the requisite function declaration for the assembler.
|
||||
|
||||
|
@ -3173,10 +3173,10 @@ regardless of whether they are used or not.
|
|||
@item save_volatiles
|
||||
@cindex save volatile registers on the MicroBlaze
|
||||
Use this attribute on the MicroBlaze to indicate that the function is
|
||||
an interrupt handler. All volatile registers (in addition to non-volatile
|
||||
registers) will be saved in the function prologue. If the function is a leaf
|
||||
function, only volatiles used by the function are saved. A normal function
|
||||
return is generated instead of a return from interrupt.
|
||||
an interrupt handler. All volatile registers (in addition to non-volatile
|
||||
registers) will be saved in the function prologue. If the function is a leaf
|
||||
function, only volatiles used by the function are saved. A normal function
|
||||
return is generated instead of a return from interrupt.
|
||||
|
||||
@item section ("@var{section-name}")
|
||||
@cindex @code{section} function attribute
|
||||
|
@ -4270,7 +4270,7 @@ up to a maximum of 8 byte alignment, then specifying @code{aligned(16)}
|
|||
in an @code{__attribute__} will still only provide you with 8 byte
|
||||
alignment. See your linker documentation for further information.
|
||||
|
||||
The @code{aligned} attribute can also be used for functions
|
||||
The @code{aligned} attribute can also be used for functions
|
||||
(@pxref{Function Attributes}.)
|
||||
|
||||
@item cleanup (@var{cleanup_function})
|
||||
|
@ -5162,7 +5162,7 @@ packed))}.
|
|||
Three attributes currently are defined for PowerPC configurations:
|
||||
@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
|
||||
|
||||
For full documentation of the @code{ms_struct} and @code{gcc_struct}
|
||||
For full documentation of the @code{ms_struct} and @code{gcc_struct}
|
||||
attributes please see the documentation in @ref{i386 Type Attributes}.
|
||||
|
||||
The @code{altivec} attribute allows one to declare AltiVec vector data
|
||||
|
@ -5832,7 +5832,7 @@ int frob(int x)
|
|||
|
||||
In this (inefficient) example, the @code{frob} instruction sets the
|
||||
carry bit to indicate an error. The @code{jc} instruction detects
|
||||
this and branches to the @code{error} label. Finally, the output
|
||||
this and branches to the @code{error} label. Finally, the output
|
||||
of the @code{frob} instruction (@code{%r5}) is stored into the memory
|
||||
for variable @code{y}, which is later read by the @code{return} statement.
|
||||
|
||||
|
@ -5888,7 +5888,7 @@ occasions we'd like to keep the overhead to the absolute minimum.
|
|||
The normal code path consists of a single @code{nop} instruction.
|
||||
However, we record the address of this @code{nop} together with the
|
||||
address of a label that calls the @code{trace} function. This allows
|
||||
the @code{nop} instruction to be patched at runtime to be an
|
||||
the @code{nop} instruction to be patched at runtime to be an
|
||||
unconditional branch to the stored label. It is assumed that an
|
||||
optimizing compiler will move the labeled block out of line, to
|
||||
optimize the fall through path from the @code{asm}.
|
||||
|
@ -12770,10 +12770,10 @@ bit-fields. See the Solaris man page for @code{cmn_err} for more information.
|
|||
@node Darwin Format Checks
|
||||
@subsection Darwin Format Checks
|
||||
|
||||
Darwin targets support the @code{CFString} (or @code{__CFString__}) in the format
|
||||
Darwin targets support the @code{CFString} (or @code{__CFString__}) in the format
|
||||
attribute context. Declarations made with such attribution will be parsed for correct syntax
|
||||
and format argument types. However, parsing of the format string itself is currently undefined
|
||||
and will not be carried out by this version of the compiler.
|
||||
and will not be carried out by this version of the compiler.
|
||||
|
||||
Additionally, @code{CFStringRefs} (defined by the @code{CoreFoundation} headers) may
|
||||
also be used as format arguments. Note that the relevant headers are only likely to be
|
||||
|
@ -13027,8 +13027,8 @@ adding a call to the @code{.init} section.
|
|||
|
||||
For compatibility with the Solaris and Tru64 UNIX system headers, GCC
|
||||
supports two @code{#pragma} directives which change the name used in
|
||||
assembly for a given declaration. @code{#pragma extern_prefix} is only
|
||||
available on platforms whose system headers need it. To get this effect
|
||||
assembly for a given declaration. @code{#pragma extern_prefix} is only
|
||||
available on platforms whose system headers need it. To get this effect
|
||||
on all platforms supported by GCC, use the asm labels extension (@pxref{Asm
|
||||
Labels}).
|
||||
|
||||
|
@ -13277,7 +13277,7 @@ For example:
|
|||
#undef X
|
||||
#define X -1
|
||||
#pragma pop_macro("X")
|
||||
int x [X];
|
||||
int x [X];
|
||||
@end smallexample
|
||||
|
||||
In this example, the definition of X as 1 is saved by @code{#pragma
|
||||
|
@ -14305,7 +14305,7 @@ If @code{type} is const qualified or is a reference type then the trait is
|
|||
false. Otherwise if @code{__has_trivial_assign (type)} is true then the trait
|
||||
is true, else if @code{type} is a cv class or union type with copy assignment
|
||||
operators that are known not to throw an exception then the trait is true,
|
||||
else it is false. Requires: @code{type} shall be a complete type,
|
||||
else it is false. Requires: @code{type} shall be a complete type,
|
||||
(possibly cv-qualified) @code{void}, or an array of unknown bound.
|
||||
|
||||
@item __has_nothrow_copy (type)
|
||||
|
@ -14319,8 +14319,8 @@ Requires: @code{type} shall be a complete type, (possibly cv-qualified)
|
|||
If @code{__has_trivial_constructor (type)} is true then the trait is
|
||||
true, else if @code{type} is a cv class or union type (or array
|
||||
thereof) with a default constructor that is known not to throw an
|
||||
exception then the trait is true, else it is false. Requires:
|
||||
@code{type} shall be a complete type, (possibly cv-qualified)
|
||||
exception then the trait is true, else it is false. Requires:
|
||||
@code{type} shall be a complete type, (possibly cv-qualified)
|
||||
@code{void}, or an array of unknown bound.
|
||||
|
||||
@item __has_trivial_assign (type)
|
||||
|
@ -14328,11 +14328,11 @@ If @code{type} is const qualified or is a reference type then the trait is
|
|||
false. Otherwise if @code{__is_pod (type)} is true then the trait is
|
||||
true, else if @code{type} is a cv class or union type with a trivial
|
||||
copy assignment ([class.copy]) then the trait is true, else it is
|
||||
false. Requires: @code{type} shall be a complete type, (possibly
|
||||
false. Requires: @code{type} shall be a complete type, (possibly
|
||||
cv-qualified) @code{void}, or an array of unknown bound.
|
||||
|
||||
@item __has_trivial_copy (type)
|
||||
If @code{__is_pod (type)} is true or @code{type} is a reference type
|
||||
If @code{__is_pod (type)} is true or @code{type} is a reference type
|
||||
then the trait is true, else if @code{type} is a cv class or union type
|
||||
with a trivial copy constructor ([class.copy]) then the trait
|
||||
is true, else it is false. Requires: @code{type} shall be a complete
|
||||
|
@ -14384,7 +14384,7 @@ Otherwise @code{type} is considered empty if and only if: @code{type}
|
|||
has no non-static data members, or all non-static data members, if
|
||||
any, are bit-fields of length 0, and @code{type} has no virtual
|
||||
members, and @code{type} has no virtual base classes, and @code{type}
|
||||
has no base classes @code{base_type} for which
|
||||
has no base classes @code{base_type} for which
|
||||
@code{__is_empty (base_type)} is false. Requires: @code{type} shall
|
||||
be a complete type, (possibly cv-qualified) @code{void}, or an array
|
||||
of unknown bound.
|
||||
|
|
|
@ -541,19 +541,19 @@ coverage files.
|
|||
@node Cross-profiling
|
||||
@section Data file relocation to support cross-profiling
|
||||
|
||||
Running the program will cause profile output to be generated. For each
|
||||
source file compiled with @option{-fprofile-arcs}, an accompanying @file{.gcda}
|
||||
file will be placed in the object file directory. That implicitly requires
|
||||
running the program on the same system as it was built or having the same
|
||||
Running the program will cause profile output to be generated. For each
|
||||
source file compiled with @option{-fprofile-arcs}, an accompanying @file{.gcda}
|
||||
file will be placed in the object file directory. That implicitly requires
|
||||
running the program on the same system as it was built or having the same
|
||||
absolute directory structure on the target system. The program will try
|
||||
to create the needed directory structure, if it is not already present.
|
||||
|
||||
To support cross-profiling, a program compiled with @option{-fprofile-arcs}
|
||||
can relocate the data files based on two environment variables:
|
||||
can relocate the data files based on two environment variables:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
GCOV_PREFIX contains the prefix to add to the absolute paths
|
||||
GCOV_PREFIX contains the prefix to add to the absolute paths
|
||||
in the object file. Prefix can be absolute, or relative. The
|
||||
default is no prefix.
|
||||
|
||||
|
|
|
@ -621,7 +621,7 @@ internal representation, except for declarations of functions
|
|||
@menu
|
||||
* Working with declarations:: Macros and functions that work on
|
||||
declarations.
|
||||
* Internal structure:: How declaration nodes are represented.
|
||||
* Internal structure:: How declaration nodes are represented.
|
||||
@end menu
|
||||
|
||||
@node Working with declarations
|
||||
|
@ -734,11 +734,11 @@ referenced in debug bind statements.
|
|||
|
||||
@item FIELD_DECL
|
||||
These nodes represent non-static data members. The @code{DECL_SIZE} and
|
||||
@code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.
|
||||
The position of the field within the parent record is specified by a
|
||||
@code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.
|
||||
The position of the field within the parent record is specified by a
|
||||
combination of three attributes. @code{DECL_FIELD_OFFSET} is the position,
|
||||
counting in bytes, of the @code{DECL_OFFSET_ALIGN}-bit sized word containing
|
||||
the bit of the field closest to the beginning of the structure.
|
||||
the bit of the field closest to the beginning of the structure.
|
||||
@code{DECL_FIELD_BIT_OFFSET} is the bit offset of the first bit of the field
|
||||
within this word; this may be nonzero even for fields that are not bit-fields,
|
||||
since @code{DECL_OFFSET_ALIGN} may be greater than the natural alignment
|
||||
|
@ -810,7 +810,7 @@ used to represent @code{CONST_DECL}.
|
|||
|
||||
@item struct tree_parm_decl
|
||||
This structure inherits from @code{struct tree_decl_with_rtl}. It is
|
||||
used to represent @code{PARM_DECL}.
|
||||
used to represent @code{PARM_DECL}.
|
||||
|
||||
@item struct tree_decl_with_vis
|
||||
This structure inherits from @code{struct tree_decl_with_rtl}. It
|
||||
|
@ -819,11 +819,11 @@ a section name and assembler name.
|
|||
|
||||
@item struct tree_var_decl
|
||||
This structure inherits from @code{struct tree_decl_with_vis}. It is
|
||||
used to represent @code{VAR_DECL}.
|
||||
used to represent @code{VAR_DECL}.
|
||||
|
||||
@item struct tree_function_decl
|
||||
This structure inherits from @code{struct tree_decl_with_vis}. It is
|
||||
used to represent @code{FUNCTION_DECL}.
|
||||
used to represent @code{FUNCTION_DECL}.
|
||||
|
||||
@end table
|
||||
@node Adding new DECL node types
|
||||
|
@ -1574,8 +1574,8 @@ function to call; it is always an expression whose type is a
|
|||
@code{POINTER_TYPE}.
|
||||
|
||||
The number of arguments to the call is returned by @code{call_expr_nargs},
|
||||
while the arguments themselves can be accessed with the @code{CALL_EXPR_ARG}
|
||||
macro. The arguments are zero-indexed and numbered left-to-right.
|
||||
while the arguments themselves can be accessed with the @code{CALL_EXPR_ARG}
|
||||
macro. The arguments are zero-indexed and numbered left-to-right.
|
||||
You can iterate over the arguments using @code{FOR_EACH_CALL_EXPR_ARG}, as in:
|
||||
|
||||
@smallexample
|
||||
|
@ -1695,7 +1695,7 @@ its sole argument yields the representation for @code{ap}.
|
|||
@tindex VEC_PACK_TRUNC_EXPR
|
||||
@tindex VEC_PACK_SAT_EXPR
|
||||
@tindex VEC_PACK_FIX_TRUNC_EXPR
|
||||
@tindex VEC_EXTRACT_EVEN_EXPR
|
||||
@tindex VEC_EXTRACT_EVEN_EXPR
|
||||
@tindex VEC_EXTRACT_ODD_EXPR
|
||||
@tindex VEC_INTERLEAVE_HIGH_EXPR
|
||||
@tindex VEC_INTERLEAVE_LOW_EXPR
|
||||
|
@ -1703,8 +1703,8 @@ its sole argument yields the representation for @code{ap}.
|
|||
@table @code
|
||||
@item VEC_LSHIFT_EXPR
|
||||
@itemx VEC_RSHIFT_EXPR
|
||||
These nodes represent whole vector left and right shifts, respectively.
|
||||
The first operand is the vector to shift; it will always be of vector type.
|
||||
These nodes represent whole vector left and right shifts, respectively.
|
||||
The first operand is the vector to shift; it will always be of vector type.
|
||||
The second operand is an expression for the number of bits by which to
|
||||
shift. Note that the result is undefined if the second operand is larger
|
||||
than or equal to the first operand's type size.
|
||||
|
@ -1712,9 +1712,9 @@ than or equal to the first operand's type size.
|
|||
@item VEC_WIDEN_MULT_HI_EXPR
|
||||
@itemx VEC_WIDEN_MULT_LO_EXPR
|
||||
These nodes represent widening vector multiplication of the high and low
|
||||
parts of the two input vectors, respectively. Their operands are vectors
|
||||
that contain the same number of elements (@code{N}) of the same integral type.
|
||||
The result is a vector that contains half as many elements, of an integral type
|
||||
parts of the two input vectors, respectively. Their operands are vectors
|
||||
that contain the same number of elements (@code{N}) of the same integral type.
|
||||
The result is a vector that contains half as many elements, of an integral type
|
||||
whose size is twice as wide. In the case of @code{VEC_WIDEN_MULT_HI_EXPR} the
|
||||
high @code{N/2} elements of the two vector are multiplied to produce the
|
||||
vector of @code{N/2} products. In the case of @code{VEC_WIDEN_MULT_LO_EXPR} the
|
||||
|
@ -1724,7 +1724,7 @@ vector of @code{N/2} products.
|
|||
@item VEC_UNPACK_HI_EXPR
|
||||
@itemx VEC_UNPACK_LO_EXPR
|
||||
These nodes represent unpacking of the high and low parts of the input vector,
|
||||
respectively. The single operand is a vector that contains @code{N} elements
|
||||
respectively. The single operand is a vector that contains @code{N} elements
|
||||
of the same integral or floating point type. The result is a vector
|
||||
that contains half as many elements, of an integral or floating point type
|
||||
whose size is twice as wide. In the case of @code{VEC_UNPACK_HI_EXPR} the
|
||||
|
@ -1770,19 +1770,19 @@ vector.
|
|||
|
||||
@item VEC_EXTRACT_EVEN_EXPR
|
||||
@itemx VEC_EXTRACT_ODD_EXPR
|
||||
These nodes represent extracting of the even/odd elements of the two input
|
||||
vectors, respectively. Their operands and result are vectors that contain the
|
||||
These nodes represent extracting of the even/odd elements of the two input
|
||||
vectors, respectively. Their operands and result are vectors that contain the
|
||||
same number of elements of the same type.
|
||||
|
||||
@item VEC_INTERLEAVE_HIGH_EXPR
|
||||
@itemx VEC_INTERLEAVE_LOW_EXPR
|
||||
These nodes represent merging and interleaving of the high/low elements of the
|
||||
two input vectors, respectively. The operands and the result are vectors that
|
||||
two input vectors, respectively. The operands and the result are vectors that
|
||||
contain the same number of elements (@code{N}) of the same type.
|
||||
In the case of @code{VEC_INTERLEAVE_HIGH_EXPR}, the high @code{N/2} elements of
|
||||
In the case of @code{VEC_INTERLEAVE_HIGH_EXPR}, the high @code{N/2} elements of
|
||||
the first input vector are interleaved with the high @code{N/2} elements of the
|
||||
second input vector. In the case of @code{VEC_INTERLEAVE_LOW_EXPR}, the low
|
||||
@code{N/2} elements of the first input vector are interleaved with the low
|
||||
@code{N/2} elements of the first input vector are interleaved with the low
|
||||
@code{N/2} elements of the second input vector.
|
||||
|
||||
@end table
|
||||
|
@ -2616,7 +2616,7 @@ language-dependent info about GENERIC types.
|
|||
|
||||
@item POINTER_TYPE
|
||||
Used to represent pointer types, and pointer to data member types. If
|
||||
@code{TREE_TYPE}
|
||||
@code{TREE_TYPE}
|
||||
is a pointer to data member type, then @code{TYPE_PTRMEM_P} will hold.
|
||||
For a pointer to data member type of the form @samp{T X::*},
|
||||
@code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -371,7 +371,7 @@ struct GTY((variable_size)) sorted_fields_type @{
|
|||
@};
|
||||
@end smallexample
|
||||
|
||||
Then the objects of @code{struct sorted_fields_type} are allocated in GC
|
||||
Then the objects of @code{struct sorted_fields_type} are allocated in GC
|
||||
memory as follows:
|
||||
@smallexample
|
||||
field_vec = ggc_alloc_sorted_fields_type (size);
|
||||
|
|
|
@ -214,15 +214,15 @@ initialization when a compilation driver is being initialized.
|
|||
@item HOST_LONG_LONG_FORMAT
|
||||
If defined, the string used to indicate an argument of type @code{long
|
||||
long} to functions like @code{printf}. The default value is
|
||||
@code{"ll"}.
|
||||
@code{"ll"}.
|
||||
|
||||
@item HOST_LONG_FORMAT
|
||||
If defined, the string used to indicate an argument of type @code{long}
|
||||
to functions like @code{printf}. The default value is @code{"l"}.
|
||||
to functions like @code{printf}. The default value is @code{"l"}.
|
||||
|
||||
@item HOST_PTR_PRINTF
|
||||
If defined, the string used to indicate an argument of type @code{void *}
|
||||
to functions like @code{printf}. The default value is @code{"%p"}.
|
||||
to functions like @code{printf}. The default value is @code{"%p"}.
|
||||
@end ftable
|
||||
|
||||
In addition, if @command{configure} generates an incorrect definition of
|
||||
|
|
|
@ -45,7 +45,7 @@
|
|||
@end ifset
|
||||
|
||||
@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
|
||||
@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
|
||||
@c 2010, 2011 Free Software Foundation, Inc.
|
||||
@c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
|
||||
|
||||
|
@ -461,7 +461,7 @@ included in releases.
|
|||
|
||||
@item @TeX{} (any working version)
|
||||
|
||||
Necessary for running @command{texi2dvi} and @command{texi2pdf}, which
|
||||
Necessary for running @command{texi2dvi} and @command{texi2pdf}, which
|
||||
are used when running @command{make dvi} or @command{make pdf} to create
|
||||
DVI or PDF files, respectively.
|
||||
|
||||
|
@ -1214,7 +1214,7 @@ On MIPS targets, make @option{-mno-llsc} the default when no
|
|||
On MIPS targets, make @option{-msynci} the default when no
|
||||
@option{-mno-synci} option is passed.
|
||||
|
||||
@item --without-synci
|
||||
@item --without-synci
|
||||
On MIPS targets, make @option{-mno-synci} the default when no
|
||||
@option{-msynci} option is passed. This is the default.
|
||||
|
||||
|
@ -1711,7 +1711,7 @@ the directory specified with @option{--with-sysroot}. This option is
|
|||
only useful when you are already using @option{--with-sysroot}. You
|
||||
can use @option{--with-build-sysroot} when you are configuring with
|
||||
@option{--prefix} set to a directory that is different from the one in
|
||||
which you are installing GCC and your target libraries.
|
||||
which you are installing GCC and your target libraries.
|
||||
|
||||
This option affects the system root for the compiler used to build
|
||||
target libraries (which runs on the build system); it does not affect
|
||||
|
@ -1903,8 +1903,8 @@ Note that if --enable-java-home is used, --with-arch-directory=ARCH must also
|
|||
be specified.
|
||||
|
||||
@item --with-arch-directory=ARCH
|
||||
Specifies the name to use for the @file{jre/lib/ARCH} directory in the SDK
|
||||
environment created when --enable-java-home is passed. Typical names for this
|
||||
Specifies the name to use for the @file{jre/lib/ARCH} directory in the SDK
|
||||
environment created when --enable-java-home is passed. Typical names for this
|
||||
directory include i386, amd64, ia64, etc.
|
||||
|
||||
@item --with-os-directory=DIR
|
||||
|
@ -1916,7 +1916,7 @@ Specifies the JPackage origin name. This defaults to the 'gcj' in
|
|||
java-1.5.0-gcj.
|
||||
|
||||
@item --with-arch-suffix=SUFFIX
|
||||
Specifies the suffix for the sdk directory. Defaults to the empty string.
|
||||
Specifies the suffix for the sdk directory. Defaults to the empty string.
|
||||
Examples include '.x86_64' in 'java-1.5.0-gcj-1.5.0.0.x86_64'.
|
||||
|
||||
@item --with-jvm-root-dir=DIR
|
||||
|
@ -1928,7 +1928,7 @@ Specifies where to install jars. Default is $(prefix)/lib/jvm-exports.
|
|||
@item --with-python-dir=DIR
|
||||
Specifies where to install the Python modules used for aot-compile. DIR should
|
||||
not include the prefix used in installation. For example, if the Python modules
|
||||
are to be installed in /usr/lib/python2.5/site-packages, then
|
||||
are to be installed in /usr/lib/python2.5/site-packages, then
|
||||
--with-python-dir=/lib/python2.5/site-packages should be passed. If this is
|
||||
not specified, then the Python modules are installed in $(prefix)/share/python.
|
||||
|
||||
|
@ -2344,7 +2344,7 @@ compilation options. Check your target's definition of
|
|||
|
||||
GNU Make 3.80 and above, which is necessary to build GCC, support
|
||||
building in parallel. To activate this, you can use @samp{make -j 2}
|
||||
instead of @samp{make}. You can also specify a bigger number, and
|
||||
instead of @samp{make}. You can also specify a bigger number, and
|
||||
in most cases using a value greater than the number of processors in
|
||||
your machine will result in fewer and shorter I/O latency hits, thus
|
||||
improving overall throughput; this is especially true for slow drives
|
||||
|
@ -4411,27 +4411,27 @@ respects, this target is the same as the
|
|||
@heading @anchor{windows}Microsoft Windows
|
||||
|
||||
@subheading Intel 16-bit versions
|
||||
The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not
|
||||
The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not
|
||||
supported.
|
||||
|
||||
However, the 32-bit port has limited support for Microsoft
|
||||
However, the 32-bit port has limited support for Microsoft
|
||||
Windows 3.11 in the Win32s environment, as a target only. See below.
|
||||
|
||||
@subheading Intel 32-bit versions
|
||||
|
||||
The 32-bit versions of Windows, including Windows 95, Windows NT, Windows
|
||||
XP, and Windows Vista, are supported by several different target
|
||||
platforms. These targets differ in which Windows subsystem they target
|
||||
The 32-bit versions of Windows, including Windows 95, Windows NT, Windows
|
||||
XP, and Windows Vista, are supported by several different target
|
||||
platforms. These targets differ in which Windows subsystem they target
|
||||
and which C libraries are used.
|
||||
|
||||
@itemize
|
||||
@item Cygwin @uref{#x-x-cygwin,,*-*-cygwin}: Cygwin provides a user-space
|
||||
@item Cygwin @uref{#x-x-cygwin,,*-*-cygwin}: Cygwin provides a user-space
|
||||
Linux API emulation layer in the Win32 subsystem.
|
||||
@item Interix @uref{#x-x-interix,,*-*-interix}: The Interix subsystem
|
||||
@item Interix @uref{#x-x-interix,,*-*-interix}: The Interix subsystem
|
||||
provides native support for POSIX.
|
||||
@item MinGW @uref{#x-x-mingw32,,*-*-mingw32}: MinGW is a native GCC port for
|
||||
@item MinGW @uref{#x-x-mingw32,,*-*-mingw32}: MinGW is a native GCC port for
|
||||
the Win32 subsystem that provides a subset of POSIX.
|
||||
@item MKS i386-pc-mks: NuTCracker from MKS. See
|
||||
@item MKS i386-pc-mks: NuTCracker from MKS. See
|
||||
@uref{http://www.mkssoftware.com/} for more information.
|
||||
@end itemize
|
||||
|
||||
|
@ -4445,19 +4445,19 @@ Presently Windows for Itanium is not supported.
|
|||
|
||||
@subheading Windows CE
|
||||
|
||||
Windows CE is supported as a target only on ARM (arm-wince-pe), Hitachi
|
||||
Windows CE is supported as a target only on ARM (arm-wince-pe), Hitachi
|
||||
SuperH (sh-wince-pe), and MIPS (mips-wince-pe).
|
||||
|
||||
@subheading Other Windows Platforms
|
||||
|
||||
GCC no longer supports Windows NT on the Alpha or PowerPC.
|
||||
|
||||
GCC no longer supports the Windows POSIX subsystem. However, it does
|
||||
GCC no longer supports the Windows POSIX subsystem. However, it does
|
||||
support the Interix subsystem. See above.
|
||||
|
||||
Old target names including *-*-winnt and *-*-windowsnt are no longer used.
|
||||
|
||||
PW32 (i386-pc-pw32) support was never completed, and the project seems to
|
||||
PW32 (i386-pc-pw32) support was never completed, and the project seems to
|
||||
be inactive. See @uref{http://pw32.sourceforge.net/} for more information.
|
||||
|
||||
UWIN support has been removed due to a lack of maintenance.
|
||||
|
@ -4484,9 +4484,9 @@ or version 2.20 or above if building your own.
|
|||
@end html
|
||||
@heading @anchor{x-x-interix}*-*-interix
|
||||
|
||||
The Interix target is used by OpenNT, Interix, Services For UNIX (SFU),
|
||||
and Subsystem for UNIX-based Applications (SUA). Applications compiled
|
||||
with this target run in the Interix subsystem, which is separate from
|
||||
The Interix target is used by OpenNT, Interix, Services For UNIX (SFU),
|
||||
and Subsystem for UNIX-based Applications (SUA). Applications compiled
|
||||
with this target run in the Interix subsystem, which is separate from
|
||||
the Win32 subsystem. This target was last known to work in GCC 3.3.
|
||||
|
||||
@html
|
||||
|
|
|
@ -3055,7 +3055,7 @@ promoted to @code{double}. CPUs with a 32-bit ``single-precision''
|
|||
floating-point unit implement @code{float} in hardware, but emulate
|
||||
@code{double} in software. On such a machine, doing computations
|
||||
using @code{double} values is much more expensive because of the
|
||||
overhead required for software emulation.
|
||||
overhead required for software emulation.
|
||||
|
||||
It is easy to accidentally do computations with @code{double} because
|
||||
floating-point literals are implicitly of type @code{double}. For
|
||||
|
@ -3064,7 +3064,7 @@ example, in:
|
|||
@group
|
||||
float area(float radius)
|
||||
@{
|
||||
return 3.14159 * radius * radius;
|
||||
return 3.14159 * radius * radius;
|
||||
@}
|
||||
@end group
|
||||
@end smallexample
|
||||
|
@ -3309,11 +3309,11 @@ look like this:
|
|||
@end group
|
||||
@end smallexample
|
||||
|
||||
Also warn for dangerous uses of the
|
||||
Also warn for dangerous uses of the
|
||||
?: with omitted middle operand GNU extension. When the condition
|
||||
in the ?: operator is a boolean expression the omitted value will
|
||||
be always 1. Often the user expects it to be a value computed
|
||||
inside the conditional expression instead.
|
||||
inside the conditional expression instead.
|
||||
|
||||
This warning is enabled by @option{-Wall}.
|
||||
|
||||
|
@ -3538,7 +3538,7 @@ For an automatic variable, if there exists a path from the function
|
|||
entry to a use of the variable that is initialized, but there exist
|
||||
some other paths the variable is not initialized, the compiler will
|
||||
emit a warning if it can not prove the uninitialized paths do not
|
||||
happen at runtime. These warnings are made optional because GCC is
|
||||
happen at runtime. These warnings are made optional because GCC is
|
||||
not smart enough to see all the reasons why the code might be correct
|
||||
despite appearing to have an error. Here is one example of how
|
||||
this can happen:
|
||||
|
@ -3758,7 +3758,7 @@ headers---for that, @option{-Wunknown-pragmas} must also be used.
|
|||
@opindex Wtrampolines
|
||||
@opindex Wno-trampolines
|
||||
Warn about trampolines generated for pointers to nested functions.
|
||||
|
||||
|
||||
A trampoline is a small piece of data or code that is created at run
|
||||
time on the stack when the address of a nested function is taken, and
|
||||
is used to call the nested function indirectly. For some targets, it
|
||||
|
@ -5875,7 +5875,7 @@ Not all optimizations are controlled directly by a flag. Only
|
|||
optimizations that have a flag are listed in this section.
|
||||
|
||||
Most optimizations are only enabled if an @option{-O} level is set on
|
||||
the command line. Otherwise they are disabled, even if individual
|
||||
the command line. Otherwise they are disabled, even if individual
|
||||
optimization flags are specified.
|
||||
|
||||
Depending on the target and how GCC was configured, a slightly different
|
||||
|
@ -6634,48 +6634,48 @@ This only makes sense when scheduling after register allocation, i.e.@: with
|
|||
|
||||
@item -fsched-group-heuristic
|
||||
@opindex fsched-group-heuristic
|
||||
Enable the group heuristic in the scheduler. This heuristic favors
|
||||
the instruction that belongs to a schedule group. This is enabled
|
||||
by default when scheduling is enabled, i.e.@: with @option{-fschedule-insns}
|
||||
Enable the group heuristic in the scheduler. This heuristic favors
|
||||
the instruction that belongs to a schedule group. This is enabled
|
||||
by default when scheduling is enabled, i.e.@: with @option{-fschedule-insns}
|
||||
or @option{-fschedule-insns2} or at @option{-O2} or higher.
|
||||
|
||||
@item -fsched-critical-path-heuristic
|
||||
@opindex fsched-critical-path-heuristic
|
||||
Enable the critical-path heuristic in the scheduler. This heuristic favors
|
||||
instructions on the critical path. This is enabled by default when
|
||||
scheduling is enabled, i.e.@: with @option{-fschedule-insns}
|
||||
Enable the critical-path heuristic in the scheduler. This heuristic favors
|
||||
instructions on the critical path. This is enabled by default when
|
||||
scheduling is enabled, i.e.@: with @option{-fschedule-insns}
|
||||
or @option{-fschedule-insns2} or at @option{-O2} or higher.
|
||||
|
||||
@item -fsched-spec-insn-heuristic
|
||||
@opindex fsched-spec-insn-heuristic
|
||||
Enable the speculative instruction heuristic in the scheduler. This
|
||||
heuristic favors speculative instructions with greater dependency weakness.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2}
|
||||
Enable the speculative instruction heuristic in the scheduler. This
|
||||
heuristic favors speculative instructions with greater dependency weakness.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2}
|
||||
or at @option{-O2} or higher.
|
||||
|
||||
@item -fsched-rank-heuristic
|
||||
@opindex fsched-rank-heuristic
|
||||
Enable the rank heuristic in the scheduler. This heuristic favors
|
||||
the instruction belonging to a basic block with greater size or frequency.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
Enable the rank heuristic in the scheduler. This heuristic favors
|
||||
the instruction belonging to a basic block with greater size or frequency.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
at @option{-O2} or higher.
|
||||
|
||||
@item -fsched-last-insn-heuristic
|
||||
@opindex fsched-last-insn-heuristic
|
||||
Enable the last-instruction heuristic in the scheduler. This heuristic
|
||||
Enable the last-instruction heuristic in the scheduler. This heuristic
|
||||
favors the instruction that is less dependent on the last instruction
|
||||
scheduled. This is enabled by default when scheduling is enabled,
|
||||
i.e.@: with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
scheduled. This is enabled by default when scheduling is enabled,
|
||||
i.e.@: with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
at @option{-O2} or higher.
|
||||
|
||||
@item -fsched-dep-count-heuristic
|
||||
@opindex fsched-dep-count-heuristic
|
||||
Enable the dependent-count heuristic in the scheduler. This heuristic
|
||||
favors the instruction that has more instructions depending on it.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
Enable the dependent-count heuristic in the scheduler. This heuristic
|
||||
favors the instruction that has more instructions depending on it.
|
||||
This is enabled by default when scheduling is enabled, i.e.@:
|
||||
with @option{-fschedule-insns} or @option{-fschedule-insns2} or
|
||||
at @option{-O2} or higher.
|
||||
|
||||
@item -freschedule-modulo-scheduled-loops
|
||||
|
@ -7636,7 +7636,7 @@ With the linker plugin enabled, the linker will extract the needed
|
|||
GIMPLE files from @file{libfoo.a} and pass them on to the running GCC
|
||||
to make them part of the aggregated GIMPLE image to be optimized.
|
||||
|
||||
If you are not using a linker with linker plugin support and/or do not
|
||||
If you are not using a linker with linker plugin support and/or do not
|
||||
enable linker plugin then the objects inside @file{libfoo.a}
|
||||
will be extracted and linked as usual, but they will not participate
|
||||
in the LTO optimization process.
|
||||
|
@ -7645,7 +7645,7 @@ Link time optimizations do not require the presence of the whole program to
|
|||
operate. If the program does not require any symbols to be exported, it is
|
||||
possible to combine @option{-flto} and with @option{-fwhole-program} to allow
|
||||
the interprocedural optimizers to use more aggressive assumptions which may
|
||||
lead to improved optimization opportunities.
|
||||
lead to improved optimization opportunities.
|
||||
Use of @option{-fwhole-program} is not needed when linker plugin is
|
||||
active (see @option{-fuse-linker-plugin}).
|
||||
|
||||
|
@ -7666,11 +7666,11 @@ parallel jobs by utilizing an installed @command{make} program. The
|
|||
environment variable @env{MAKE} may be used to override the program
|
||||
used. The default value for @var{n} is 1.
|
||||
|
||||
You can also specify @option{-flto=jobserver} to use GNU make's
|
||||
job server mode to determine the number of parallel jobs. This
|
||||
You can also specify @option{-flto=jobserver} to use GNU make's
|
||||
job server mode to determine the number of parallel jobs. This
|
||||
is useful when the Makefile calling GCC is already executing in parallel.
|
||||
The parent Makefile will need a @samp{+} prepended to the command recipe
|
||||
for this to work. This will likely only work if @env{MAKE} is
|
||||
for this to work. This will likely only work if @env{MAKE} is
|
||||
GNU make.
|
||||
|
||||
This option is disabled by default.
|
||||
|
@ -7707,7 +7707,7 @@ or in GNU ld 2.21 or newer.
|
|||
|
||||
This option enables the extraction of object files with GIMPLE bytecode out of
|
||||
library archives. This improves the quality of optimization by exposing more
|
||||
code the link time optimizer. This information specify what symbols
|
||||
code the link time optimizer. This information specify what symbols
|
||||
can be accessed externally (by non-LTO object or during dynamic linking).
|
||||
Resulting code quality improvements on binaries (and shared libraries that do
|
||||
use hidden visibility) is similar to @code{-fwhole-program}. See
|
||||
|
@ -12501,7 +12501,7 @@ in this case.
|
|||
@opindex mvzeroupper
|
||||
This option instructs GCC to emit a @code{vzeroupper} instruction
|
||||
before a transfer of control flow out of the function to minimize
|
||||
AVX to SSE transition penalty as well as remove unnecessary zeroupper
|
||||
AVX to SSE transition penalty as well as remove unnecessary zeroupper
|
||||
intrinsics.
|
||||
|
||||
@item -mcx16
|
||||
|
@ -13949,10 +13949,10 @@ This option is deprecated. Use @option{-fno-zero-initialized-in-bss} instead.
|
|||
@item -mcpu=@var{cpu-type}
|
||||
@opindex mcpu=
|
||||
Use features of and schedule code for given CPU.
|
||||
Supported values are in the format @samp{v@var{X}.@var{YY}.@var{Z}},
|
||||
where @var{X} is a major version, @var{YY} is the minor version, and
|
||||
Supported values are in the format @samp{v@var{X}.@var{YY}.@var{Z}},
|
||||
where @var{X} is a major version, @var{YY} is the minor version, and
|
||||
@var{Z} is compatibility code. Example values are @samp{v3.00.a},
|
||||
@samp{v4.00.b}, @samp{v5.00.a}, @samp{v5.00.b}, @samp{v5.00.b}, @samp{v6.00.a}.
|
||||
@samp{v4.00.b}, @samp{v5.00.a}, @samp{v5.00.b}, @samp{v5.00.b}, @samp{v6.00.a}.
|
||||
|
||||
@item -mxl-soft-mul
|
||||
@opindex mxl-soft-mul
|
||||
|
@ -13995,29 +13995,29 @@ Use hardware floating point conversion instructions.
|
|||
Use hardware floating point square root instruction.
|
||||
|
||||
@item -mxl-mode-@var{app-model}
|
||||
Select application model @var{app-model}. Valid models are
|
||||
Select application model @var{app-model}. Valid models are
|
||||
@table @samp
|
||||
@item executable
|
||||
normal executable (default), uses startup code @file{crt0.o}.
|
||||
|
||||
@item xmdstub
|
||||
for use with Xilinx Microprocessor Debugger (XMD) based
|
||||
software intrusive debug agent called xmdstub. This uses startup file
|
||||
for use with Xilinx Microprocessor Debugger (XMD) based
|
||||
software intrusive debug agent called xmdstub. This uses startup file
|
||||
@file{crt1.o} and sets the start address of the program to be 0x800.
|
||||
|
||||
@item bootstrap
|
||||
for applications that are loaded using a bootloader.
|
||||
This model uses startup file @file{crt2.o} which does not contain a processor
|
||||
reset vector handler. This is suitable for transferring control on a
|
||||
This model uses startup file @file{crt2.o} which does not contain a processor
|
||||
reset vector handler. This is suitable for transferring control on a
|
||||
processor reset to the bootloader rather than the application.
|
||||
|
||||
@item novectors
|
||||
for applications that do not require any of the
|
||||
for applications that do not require any of the
|
||||
MicroBlaze vectors. This option may be useful for applications running
|
||||
within a monitoring application. This model uses @file{crt3.o} as a startup file.
|
||||
@end table
|
||||
|
||||
Option @option{-xl-mode-@var{app-model}} is a deprecated alias for
|
||||
Option @option{-xl-mode-@var{app-model}} is a deprecated alias for
|
||||
@option{-mxl-mode-@var{app-model}}.
|
||||
|
||||
@end table
|
||||
|
@ -16784,7 +16784,7 @@ a small dividend to be unlikely, and inv20l assumes it to be likely.
|
|||
|
||||
@item -maccumulate-outgoing-args
|
||||
@opindex maccumulate-outgoing-args
|
||||
Reserve space once for outgoing arguments in the function prologue rather
|
||||
Reserve space once for outgoing arguments in the function prologue rather
|
||||
than around each call. Generally beneficial for performance and size. Also
|
||||
needed for unwinding to avoid changing the stack frame around conditional code.
|
||||
|
||||
|
|
|
@ -502,8 +502,8 @@ The software decimal floating point library implements IEEE 754-2008
|
|||
decimal floating point arithmetic and is only activated on selected
|
||||
targets.
|
||||
|
||||
The software decimal floating point library supports either DPD
|
||||
(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding
|
||||
The software decimal floating point library supports either DPD
|
||||
(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding
|
||||
as selected at configure time.
|
||||
|
||||
|
||||
|
|
|
@ -498,28 +498,28 @@ syntactic order is important in some classical data dependence tests,
|
|||
and mapping this order to the elements of this array avoids costly
|
||||
queries to the loop body representation.
|
||||
|
||||
Three types of data references are currently handled: ARRAY_REF,
|
||||
INDIRECT_REF and COMPONENT_REF@. The data structure for the data reference
|
||||
is @code{data_reference}, where @code{data_reference_p} is a name of a
|
||||
pointer to the data reference structure. The structure contains the
|
||||
Three types of data references are currently handled: ARRAY_REF,
|
||||
INDIRECT_REF and COMPONENT_REF@. The data structure for the data reference
|
||||
is @code{data_reference}, where @code{data_reference_p} is a name of a
|
||||
pointer to the data reference structure. The structure contains the
|
||||
following elements:
|
||||
|
||||
@itemize
|
||||
@item @code{base_object_info}: Provides information about the base object
|
||||
of the data reference and its access functions. These access functions
|
||||
represent the evolution of the data reference in the loop relative to
|
||||
its base, in keeping with the classical meaning of the data reference
|
||||
access function for the support of arrays. For example, for a reference
|
||||
@code{a.b[i][j]}, the base object is @code{a.b} and the access functions,
|
||||
one for each array subscript, are:
|
||||
@item @code{base_object_info}: Provides information about the base object
|
||||
of the data reference and its access functions. These access functions
|
||||
represent the evolution of the data reference in the loop relative to
|
||||
its base, in keeping with the classical meaning of the data reference
|
||||
access function for the support of arrays. For example, for a reference
|
||||
@code{a.b[i][j]}, the base object is @code{a.b} and the access functions,
|
||||
one for each array subscript, are:
|
||||
@code{@{i_init, + i_step@}_1, @{j_init, +, j_step@}_2}.
|
||||
|
||||
@item @code{first_location_in_loop}: Provides information about the first
|
||||
location accessed by the data reference in the loop and about the access
|
||||
function used to represent evolution relative to this location. This data
|
||||
is used to support pointers, and is not used for arrays (for which we
|
||||
@item @code{first_location_in_loop}: Provides information about the first
|
||||
location accessed by the data reference in the loop and about the access
|
||||
function used to represent evolution relative to this location. This data
|
||||
is used to support pointers, and is not used for arrays (for which we
|
||||
have base objects). Pointer accesses are represented as a one-dimensional
|
||||
access that starts from the first location accessed in the loop. For
|
||||
access that starts from the first location accessed in the loop. For
|
||||
example:
|
||||
|
||||
@smallexample
|
||||
|
@ -528,27 +528,27 @@ example:
|
|||
*((int *)p + i + j) = a[i][j];
|
||||
@end smallexample
|
||||
|
||||
The access function of the pointer access is @code{@{0, + 4B@}_for2}
|
||||
relative to @code{p + i}. The access functions of the array are
|
||||
@code{@{i_init, + i_step@}_for1} and @code{@{j_init, +, j_step@}_for2}
|
||||
The access function of the pointer access is @code{@{0, + 4B@}_for2}
|
||||
relative to @code{p + i}. The access functions of the array are
|
||||
@code{@{i_init, + i_step@}_for1} and @code{@{j_init, +, j_step@}_for2}
|
||||
relative to @code{a}.
|
||||
|
||||
Usually, the object the pointer refers to is either unknown, or we can't
|
||||
prove that the access is confined to the boundaries of a certain object.
|
||||
Usually, the object the pointer refers to is either unknown, or we can't
|
||||
prove that the access is confined to the boundaries of a certain object.
|
||||
|
||||
Two data references can be compared only if at least one of these two
|
||||
representations has all its fields filled for both data references.
|
||||
Two data references can be compared only if at least one of these two
|
||||
representations has all its fields filled for both data references.
|
||||
|
||||
The current strategy for data dependence tests is as follows:
|
||||
If both @code{a} and @code{b} are represented as arrays, compare
|
||||
The current strategy for data dependence tests is as follows:
|
||||
If both @code{a} and @code{b} are represented as arrays, compare
|
||||
@code{a.base_object} and @code{b.base_object};
|
||||
if they are equal, apply dependence tests (use access functions based on
|
||||
if they are equal, apply dependence tests (use access functions based on
|
||||
base_objects).
|
||||
Else if both @code{a} and @code{b} are represented as pointers, compare
|
||||
@code{a.first_location} and @code{b.first_location};
|
||||
if they are equal, apply dependence tests (use access functions based on
|
||||
Else if both @code{a} and @code{b} are represented as pointers, compare
|
||||
@code{a.first_location} and @code{b.first_location};
|
||||
if they are equal, apply dependence tests (use access functions based on
|
||||
first location).
|
||||
However, if @code{a} and @code{b} are represented differently, only try
|
||||
However, if @code{a} and @code{b} are represented differently, only try
|
||||
to prove that the bases are definitely different.
|
||||
|
||||
@item Aliasing information.
|
||||
|
@ -571,7 +571,7 @@ data references, and the description of this dependence relation is
|
|||
given in the @code{subscripts}, @code{dir_vects}, and @code{dist_vects}
|
||||
arrays,
|
||||
@item a boolean that determines whether the dependence relation can be
|
||||
represented by a classical distance vector,
|
||||
represented by a classical distance vector,
|
||||
@item an array @code{subscripts} that contains a description of each
|
||||
subscript of the data references. Given two array accesses a
|
||||
subscript is the tuple composed of the access functions for a given
|
||||
|
@ -652,4 +652,4 @@ for the common data dependence tests.
|
|||
|
||||
The interface used by the Omega solver for describing the linear
|
||||
programming problems is described in @file{omega.h}, and the solver is
|
||||
@code{omega_solve_problem}.
|
||||
@code{omega_solve_problem}.
|
||||
|
|
|
@ -1967,7 +1967,7 @@ Integer/Floating point constant that can be loaded into a register using
|
|||
three instructions
|
||||
|
||||
@item m
|
||||
Memory operand.
|
||||
Memory operand.
|
||||
Normally, @code{m} does not allow addresses that update the base register.
|
||||
If @samp{<} or @samp{>} constraint is also used, they are allowed and
|
||||
therefore on PowerPC targets in that case it is only safe
|
||||
|
@ -2142,7 +2142,7 @@ Signed 8-bit integer constant.
|
|||
0, 1, 2, or 3 (shifts for the @code{lea} instruction).
|
||||
|
||||
@item N
|
||||
Unsigned 8-bit integer constant (for @code{in} and @code{out}
|
||||
Unsigned 8-bit integer constant (for @code{in} and @code{out}
|
||||
instructions).
|
||||
|
||||
@ifset INTERNALS
|
||||
|
@ -3022,70 +3022,70 @@ Vector zero
|
|||
@item SPU---@file{config/spu/spu.h}
|
||||
@table @code
|
||||
@item a
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 64 bit value.
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 64 bit value.
|
||||
|
||||
@item c
|
||||
An immediate for and/xor/or instructions. const_int is treated as a 64 bit value.
|
||||
An immediate for and/xor/or instructions. const_int is treated as a 64 bit value.
|
||||
|
||||
@item d
|
||||
An immediate for the @code{iohl} instruction. const_int is treated as a 64 bit value.
|
||||
An immediate for the @code{iohl} instruction. const_int is treated as a 64 bit value.
|
||||
|
||||
@item f
|
||||
An immediate which can be loaded with @code{fsmbi}.
|
||||
An immediate which can be loaded with @code{fsmbi}.
|
||||
|
||||
@item A
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 32 bit value.
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 32 bit value.
|
||||
|
||||
@item B
|
||||
An immediate for most arithmetic instructions. const_int is treated as a 32 bit value.
|
||||
An immediate for most arithmetic instructions. const_int is treated as a 32 bit value.
|
||||
|
||||
@item C
|
||||
An immediate for and/xor/or instructions. const_int is treated as a 32 bit value.
|
||||
An immediate for and/xor/or instructions. const_int is treated as a 32 bit value.
|
||||
|
||||
@item D
|
||||
An immediate for the @code{iohl} instruction. const_int is treated as a 32 bit value.
|
||||
An immediate for the @code{iohl} instruction. const_int is treated as a 32 bit value.
|
||||
|
||||
@item I
|
||||
A constant in the range [@minus{}64, 63] for shift/rotate instructions.
|
||||
A constant in the range [@minus{}64, 63] for shift/rotate instructions.
|
||||
|
||||
@item J
|
||||
An unsigned 7-bit constant for conversion/nop/channel instructions.
|
||||
An unsigned 7-bit constant for conversion/nop/channel instructions.
|
||||
|
||||
@item K
|
||||
A signed 10-bit constant for most arithmetic instructions.
|
||||
A signed 10-bit constant for most arithmetic instructions.
|
||||
|
||||
@item M
|
||||
A signed 16 bit immediate for @code{stop}.
|
||||
A signed 16 bit immediate for @code{stop}.
|
||||
|
||||
@item N
|
||||
An unsigned 16-bit constant for @code{iohl} and @code{fsmbi}.
|
||||
An unsigned 16-bit constant for @code{iohl} and @code{fsmbi}.
|
||||
|
||||
@item O
|
||||
An unsigned 7-bit constant whose 3 least significant bits are 0.
|
||||
An unsigned 7-bit constant whose 3 least significant bits are 0.
|
||||
|
||||
@item P
|
||||
An unsigned 3-bit constant for 16-byte rotates and shifts
|
||||
An unsigned 3-bit constant for 16-byte rotates and shifts
|
||||
|
||||
@item R
|
||||
Call operand, reg, for indirect calls
|
||||
Call operand, reg, for indirect calls
|
||||
|
||||
@item S
|
||||
Call operand, symbol, for relative calls.
|
||||
Call operand, symbol, for relative calls.
|
||||
|
||||
@item T
|
||||
Call operand, const_int, for absolute calls.
|
||||
Call operand, const_int, for absolute calls.
|
||||
|
||||
@item U
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is sign extended to 128 bit.
|
||||
An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is sign extended to 128 bit.
|
||||
|
||||
@item W
|
||||
An immediate for shift and rotate instructions. const_int is treated as a 32 bit value.
|
||||
An immediate for shift and rotate instructions. const_int is treated as a 32 bit value.
|
||||
|
||||
@item Y
|
||||
An immediate for and/xor/or instructions. const_int is sign extended as a 128 bit.
|
||||
An immediate for and/xor/or instructions. const_int is sign extended as a 128 bit.
|
||||
|
||||
@item Z
|
||||
An immediate for the @code{iohl} instruction. const_int is sign extended to 128 bit.
|
||||
An immediate for the @code{iohl} instruction. const_int is sign extended to 128 bit.
|
||||
|
||||
@end table
|
||||
|
||||
|
@ -3435,7 +3435,7 @@ be specially marked, to give @code{reload} more information.
|
|||
Machine-specific constraints can be given names of arbitrary length,
|
||||
but they must be entirely composed of letters, digits, underscores
|
||||
(@samp{_}), and angle brackets (@samp{< >}). Like C identifiers, they
|
||||
must begin with a letter or underscore.
|
||||
must begin with a letter or underscore.
|
||||
|
||||
In order to avoid ambiguity in operand constraint strings, no
|
||||
constraint can have a name that begins with any other constraint's
|
||||
|
@ -3900,15 +3900,15 @@ specify field index and operand 0 place to store value into.
|
|||
|
||||
@cindex @code{vec_extract_even@var{m}} instruction pattern
|
||||
@item @samp{vec_extract_even@var{m}}
|
||||
Extract even elements from the input vectors (operand 1 and operand 2).
|
||||
Extract even elements from the input vectors (operand 1 and operand 2).
|
||||
The even elements of operand 2 are concatenated to the even elements of operand
|
||||
1 in their original order. The result is stored in operand 0.
|
||||
The output and input vectors should have the same modes.
|
||||
1 in their original order. The result is stored in operand 0.
|
||||
The output and input vectors should have the same modes.
|
||||
|
||||
@cindex @code{vec_extract_odd@var{m}} instruction pattern
|
||||
@item @samp{vec_extract_odd@var{m}}
|
||||
Extract odd elements from the input vectors (operand 1 and operand 2).
|
||||
The odd elements of operand 2 are concatenated to the odd elements of operand
|
||||
Extract odd elements from the input vectors (operand 1 and operand 2).
|
||||
The odd elements of operand 2 are concatenated to the odd elements of operand
|
||||
1 in their original order. The result is stored in operand 0.
|
||||
The output and input vectors should have the same modes.
|
||||
|
||||
|
@ -3923,7 +3923,7 @@ and input vectors should have the same modes (@code{N} elements). The high
|
|||
@item @samp{vec_interleave_low@var{m}}
|
||||
Merge low elements of the two input vectors into the output vector. The output
|
||||
and input vectors should have the same modes (@code{N} elements). The low
|
||||
@code{N/2} elements of the first input vector are interleaved with the low
|
||||
@code{N/2} elements of the first input vector are interleaved with the low
|
||||
@code{N/2} elements of the second input vector.
|
||||
|
||||
@cindex @code{vec_init@var{m}} instruction pattern
|
||||
|
@ -4053,17 +4053,17 @@ and the scalar result is stored in the least significant bits of operand 0
|
|||
@item @samp{sdot_prod@var{m}}
|
||||
@cindex @code{udot_prod@var{m}} instruction pattern
|
||||
@item @samp{udot_prod@var{m}}
|
||||
Compute the sum of the products of two signed/unsigned elements.
|
||||
Operand 1 and operand 2 are of the same mode. Their product, which is of a
|
||||
wider mode, is computed and added to operand 3. Operand 3 is of a mode equal or
|
||||
Compute the sum of the products of two signed/unsigned elements.
|
||||
Operand 1 and operand 2 are of the same mode. Their product, which is of a
|
||||
wider mode, is computed and added to operand 3. Operand 3 is of a mode equal or
|
||||
wider than the mode of the product. The result is placed in operand 0, which
|
||||
is of the same mode as operand 3.
|
||||
is of the same mode as operand 3.
|
||||
|
||||
@cindex @code{ssum_widen@var{m3}} instruction pattern
|
||||
@item @samp{ssum_widen@var{m3}}
|
||||
@cindex @code{usum_widen@var{m3}} instruction pattern
|
||||
@item @samp{usum_widen@var{m3}}
|
||||
Operands 0 and 2 are of the same mode, which is wider than the mode of
|
||||
Operands 0 and 2 are of the same mode, which is wider than the mode of
|
||||
operand 1. Add operand 1 to operand 2 and place the widened result in
|
||||
operand 0. (This is used express accumulation of elements into an accumulator
|
||||
of a wider mode.)
|
||||
|
@ -7761,7 +7761,7 @@ The forth construction (@samp{absence_set}) means that each functional
|
|||
unit in the first string can be reserved only if each pattern of units
|
||||
whose names are in the second string is not reserved. This is an
|
||||
asymmetric relation (actually @samp{exclusion_set} is analogous to
|
||||
this one but it is symmetric). For example it might be useful in a
|
||||
this one but it is symmetric). For example it might be useful in a
|
||||
@acronym{VLIW} description to say that @samp{slot0} cannot be reserved
|
||||
after either @samp{slot1} or @samp{slot2} have been reserved. This
|
||||
can be described as:
|
||||
|
|
|
@ -1029,7 +1029,7 @@ If you want your own collection object to be usable with fast
|
|||
enumeration, you need to have it implement the method
|
||||
|
||||
@smallexample
|
||||
- (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state
|
||||
- (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state
|
||||
objects: (id *)objects
|
||||
count: (unsigned long)len;
|
||||
@end smallexample
|
||||
|
@ -1138,7 +1138,7 @@ the method
|
|||
+ (BOOL) resolveInstanceMethod: (SEL)selector;
|
||||
@end smallexample
|
||||
|
||||
in the case of an instance method, or
|
||||
in the case of an instance method, or
|
||||
|
||||
@smallexample
|
||||
+ (BOOL) resolveClassMethod: (SEL)selector;
|
||||
|
|
|
@ -435,23 +435,23 @@ The optimizations also use various utility functions contained in
|
|||
|
||||
Vectorization. This pass transforms loops to operate on vector types
|
||||
instead of scalar types. Data parallelism across loop iterations is exploited
|
||||
to group data elements from consecutive iterations into a vector and operate
|
||||
on them in parallel. Depending on available target support the loop is
|
||||
to group data elements from consecutive iterations into a vector and operate
|
||||
on them in parallel. Depending on available target support the loop is
|
||||
conceptually unrolled by a factor @code{VF} (vectorization factor), which is
|
||||
the number of elements operated upon in parallel in each iteration, and the
|
||||
the number of elements operated upon in parallel in each iteration, and the
|
||||
@code{VF} copies of each scalar operation are fused to form a vector operation.
|
||||
Additional loop transformations such as peeling and versioning may take place
|
||||
to align the number of iterations, and to align the memory accesses in the
|
||||
to align the number of iterations, and to align the memory accesses in the
|
||||
loop.
|
||||
The pass is implemented in @file{tree-vectorizer.c} (the main driver),
|
||||
@file{tree-vect-loop.c} and @file{tree-vect-loop-manip.c} (loop specific parts
|
||||
and general loop utilities), @file{tree-vect-slp} (loop-aware SLP
|
||||
@file{tree-vect-loop.c} and @file{tree-vect-loop-manip.c} (loop specific parts
|
||||
and general loop utilities), @file{tree-vect-slp} (loop-aware SLP
|
||||
functionality), @file{tree-vect-stmts.c} and @file{tree-vect-data-refs.c}.
|
||||
Analysis of data references is in @file{tree-data-ref.c}.
|
||||
|
||||
SLP Vectorization. This pass performs vectorization of straight-line code. The
|
||||
pass is implemented in @file{tree-vectorizer.c} (the main driver),
|
||||
@file{tree-vect-slp.c}, @file{tree-vect-stmts.c} and
|
||||
@file{tree-vect-slp.c}, @file{tree-vect-stmts.c} and
|
||||
@file{tree-vect-data-refs.c}.
|
||||
|
||||
Autoparallelization. This pass splits the loop iteration space to run
|
||||
|
@ -470,7 +470,7 @@ This pass applies if-conversion to simple loops to help vectorizer.
|
|||
We identify if convertible loops, if-convert statements and merge
|
||||
basic blocks in one big block. The idea is to present loop in such
|
||||
form so that vectorizer can have one to one mapping between statements
|
||||
and available vector operations. This pass is located in
|
||||
and available vector operations. This pass is located in
|
||||
@file{tree-if-conv.c} and is described by @code{pass_if_conversion}.
|
||||
|
||||
@item Conditional constant propagation
|
||||
|
|
|
@ -14,7 +14,7 @@ Plugins are supported on platforms that support @option{-ldl
|
|||
and invoked at pre-determined locations in the compilation
|
||||
process.
|
||||
|
||||
Plugins are loaded with
|
||||
Plugins are loaded with
|
||||
|
||||
@option{-fplugin=/path/to/@var{name}.so} @option{-fplugin-arg-@var{name}-@var{key1}[=@var{value1}]}
|
||||
|
||||
|
@ -264,7 +264,7 @@ plugin_init (struct plugin_name_args *plugin_info,
|
|||
@end smallexample
|
||||
|
||||
|
||||
@section Interacting with the GCC Garbage Collector
|
||||
@section Interacting with the GCC Garbage Collector
|
||||
|
||||
Some plugins may want to be informed when GGC (the GCC Garbage
|
||||
Collector) is running. They can register callbacks for the
|
||||
|
@ -277,7 +277,7 @@ done by registering a callback (called with a null @code{gcc_data})
|
|||
for the @code{PLUGIN_GGC_MARKING} event. Such callbacks can call the
|
||||
@code{ggc_set_mark} routine, preferably thru the @code{ggc_mark} macro
|
||||
(and conversely, these routines should usually not be used in plugins
|
||||
outside of the @code{PLUGIN_GGC_MARKING} event).
|
||||
outside of the @code{PLUGIN_GGC_MARKING} event).
|
||||
|
||||
Some plugins may need to add extra GGC root tables, e.g. to handle their own
|
||||
@code{GTY}-ed data. This can be done with the @code{PLUGIN_REGISTER_GGC_ROOTS}
|
||||
|
@ -336,7 +336,7 @@ static struct attribute_spec user_attr =
|
|||
/* Plugin callback called during attribute registration.
|
||||
Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL)
|
||||
*/
|
||||
static void
|
||||
static void
|
||||
register_attributes (void *event_data, void *data)
|
||||
@{
|
||||
warning (0, G_("Callback to register attributes"));
|
||||
|
@ -356,8 +356,8 @@ pragmas.
|
|||
register_callback (plugin_name, PLUGIN_PRAGMAS,
|
||||
register_my_pragma, NULL);
|
||||
*/
|
||||
static void
|
||||
register_my_pragma (void *event_data, void *data)
|
||||
static void
|
||||
register_my_pragma (void *event_data, void *data)
|
||||
@{
|
||||
warning (0, G_("Callback to register pragmas"));
|
||||
c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
|
||||
|
@ -365,7 +365,7 @@ register_my_pragma (void *event_data, void *data)
|
|||
@end smallexample
|
||||
|
||||
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
|
||||
your plugin) as the ``space'' argument of your pragma.
|
||||
your plugin) as the ``space'' argument of your pragma.
|
||||
|
||||
|
||||
@section Recording information about pass execution
|
||||
|
|
|
@ -1394,7 +1394,7 @@ Algol or Pascal function variables including a static chain.
|
|||
@findex MODE_CC
|
||||
@item MODE_CC
|
||||
Modes representing condition code values. These are @code{CCmode} plus
|
||||
any @code{CC_MODE} modes listed in the @file{@var{machine}-modes.def}.
|
||||
any @code{CC_MODE} modes listed in the @file{@var{machine}-modes.def}.
|
||||
@xref{Jump Patterns},
|
||||
also see @ref{Condition Code}.
|
||||
|
||||
|
@ -1755,7 +1755,7 @@ a multi-part @code{reg} that actually refers to several registers.
|
|||
|
||||
Each pseudo register has a natural mode. If it is necessary to
|
||||
operate on it in a different mode, the register must be
|
||||
enclosed in a @code{subreg}.
|
||||
enclosed in a @code{subreg}.
|
||||
|
||||
There are currently three supported types for the first operand of a
|
||||
@code{subreg}:
|
||||
|
@ -1812,7 +1812,7 @@ When used as an lvalue, the low-order bits of the source value
|
|||
are stored in @var{reg} and the high-order bits are discarded.
|
||||
When used as an rvalue, the low-order bits of the @code{subreg} are
|
||||
taken from @var{reg} while the high-order bits may or may not be
|
||||
defined.
|
||||
defined.
|
||||
|
||||
The high-order bits of rvalues are in the following circumstances:
|
||||
|
||||
|
@ -1849,7 +1849,7 @@ would set the lower two bytes of @var{z} to @var{y} and set the upper
|
|||
two bytes to an unknown value assuming @code{SUBREG_PROMOTED_VAR_P} is
|
||||
false.
|
||||
|
||||
@item Normal subregs
|
||||
@item Normal subregs
|
||||
When @var{m1} is at least as narrow as @var{m2} the @code{subreg}
|
||||
expression is called @dfn{normal}.
|
||||
|
||||
|
@ -1898,7 +1898,7 @@ values. This works because they handle them solely as a collection of
|
|||
integer values, with no particular numerical value. Only real.c and
|
||||
the runtime libraries care about @code{FLOAT_WORDS_BIG_ENDIAN}.
|
||||
|
||||
Thus,
|
||||
Thus,
|
||||
|
||||
@smallexample
|
||||
(subreg:HI (reg:SI @var{x}) 2)
|
||||
|
@ -2624,9 +2624,9 @@ a set bit indicates it is taken from @var{vec1}.
|
|||
This describes an operation that selects parts of a vector. @var{vec1} is
|
||||
the source vector, and @var{selection} is a @code{parallel} that contains a
|
||||
@code{const_int} for each of the subparts of the result vector, giving the
|
||||
number of the source subpart that should be stored into it.
|
||||
number of the source subpart that should be stored into it.
|
||||
The result mode @var{m} is either the submode for a single element of
|
||||
@var{vec1} (if only one subpart is selected), or another vector mode
|
||||
@var{vec1} (if only one subpart is selected), or another vector mode
|
||||
with that element submode (if multiple subparts are selected).
|
||||
|
||||
@findex vec_concat
|
||||
|
@ -3697,7 +3697,7 @@ A list (chain of @code{insn_list} expressions) giving information about
|
|||
dependencies between instructions within a basic block. Neither a jump
|
||||
nor a label may come between the related insns. These are only used by
|
||||
the schedulers and by combine. This is a deprecated data structure.
|
||||
Def-use and use-def chains are now preferred.
|
||||
Def-use and use-def chains are now preferred.
|
||||
|
||||
@findex REG_NOTES
|
||||
@item REG_NOTES (@var{i})
|
||||
|
@ -3808,8 +3808,8 @@ construct. It is used when the optimization to partition basic blocks
|
|||
into hot and cold sections is turned on.
|
||||
|
||||
@findex REG_SETJMP
|
||||
@item REG_SETJMP
|
||||
Appears attached to each @code{CALL_INSN} to @code{setjmp} or a
|
||||
@item REG_SETJMP
|
||||
Appears attached to each @code{CALL_INSN} to @code{setjmp} or a
|
||||
related function.
|
||||
@end table
|
||||
|
||||
|
|
|
@ -366,7 +366,7 @@ A copy of @file{texinfo.tex} known to work with the GCC manuals.
|
|||
@end table
|
||||
|
||||
DVI-formatted manuals are generated by @samp{make dvi}, which uses
|
||||
@command{texi2dvi} (via the Makefile macro @code{$(TEXI2DVI)}).
|
||||
@command{texi2dvi} (via the Makefile macro @code{$(TEXI2DVI)}).
|
||||
PDF-formatted manuals are generated by @samp{make pdf}, which uses
|
||||
@command{texi2pdf} (via the Makefile macro @code{$(TEXI2PDF)}). HTML
|
||||
formatted manuals are generated by @samp{make html}. Info
|
||||
|
|
|
@ -532,7 +532,7 @@ Any prefixes specified by the user with @option{-B}.
|
|||
|
||||
@item
|
||||
The environment variable @code{GCC_EXEC_PREFIX} or, if @code{GCC_EXEC_PREFIX}
|
||||
is not set and the compiler has not been installed in the configure-time
|
||||
is not set and the compiler has not been installed in the configure-time
|
||||
@var{prefix}, the location in which the compiler has actually been installed.
|
||||
|
||||
@item
|
||||
|
@ -540,16 +540,16 @@ The directories specified by the environment variable @code{COMPILER_PATH}.
|
|||
|
||||
@item
|
||||
The macro @code{STANDARD_EXEC_PREFIX}, if the compiler has been installed
|
||||
in the configured-time @var{prefix}.
|
||||
in the configured-time @var{prefix}.
|
||||
|
||||
@item
|
||||
The location @file{/usr/libexec/gcc/}, but only if this is a native compiler.
|
||||
The location @file{/usr/libexec/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
compiler.
|
||||
@end enumerate
|
||||
|
||||
|
@ -569,21 +569,21 @@ The directories specified by the environment variable @code{LIBRARY_PATH}
|
|||
|
||||
@item
|
||||
The macro @code{STANDARD_EXEC_PREFIX}, but only if the toolchain is installed
|
||||
in the configured @var{prefix} or this is a native compiler.
|
||||
in the configured @var{prefix} or this is a native compiler.
|
||||
|
||||
@item
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_STARTFILE_PREFIX}, if defined, but only if this is a
|
||||
The macro @code{MD_STARTFILE_PREFIX}, if defined, but only if this is a
|
||||
native compiler, or we have a target system root.
|
||||
|
||||
@item
|
||||
The macro @code{MD_STARTFILE_PREFIX_1}, if defined, but only if this is a
|
||||
The macro @code{MD_STARTFILE_PREFIX_1}, if defined, but only if this is a
|
||||
native compiler, or we have a target system root.
|
||||
|
||||
@item
|
||||
|
@ -4413,10 +4413,10 @@ compiled.
|
|||
|
||||
@deftypefn {Target Hook} rtx TARGET_LIBCALL_VALUE (enum machine_mode @var{mode}, const_rtx @var{fun})
|
||||
Define this hook if the back-end needs to know the name of the libcall
|
||||
function in order to determine where the result should be returned.
|
||||
function in order to determine where the result should be returned.
|
||||
|
||||
The mode of the result is given by @var{mode} and the name of the called
|
||||
library function is given by @var{fun}. The hook should return an RTX
|
||||
library function is given by @var{fun}. The hook should return an RTX
|
||||
representing the place where the library function result will be returned.
|
||||
|
||||
If this hook is not defined, then LIBCALL_VALUE will be used.
|
||||
|
@ -5145,12 +5145,12 @@ when it is called.
|
|||
If the target defines @code{TARGET_ASM_TRAMPOLINE_TEMPLATE}, then the
|
||||
first thing this hook should do is emit a block move into @var{m_tramp}
|
||||
from the memory block returned by @code{assemble_trampoline_template}.
|
||||
Note that the block move need only cover the constant parts of the
|
||||
Note that the block move need only cover the constant parts of the
|
||||
trampoline. If the target isolates the variable parts of the trampoline
|
||||
to the end, not all @code{TRAMPOLINE_SIZE} bytes need be copied.
|
||||
|
||||
If the target requires any other actions, such as flushing caches or
|
||||
enabling stack execution, these actions should be performed after
|
||||
enabling stack execution, these actions should be performed after
|
||||
initializing the trampoline proper.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -5354,7 +5354,7 @@ A C expression that is 1 if the RTX @var{x} is a constant which
|
|||
is a valid address. On most machines the default definition of
|
||||
@code{(CONSTANT_P (@var{x}) && GET_CODE (@var{x}) != CONST_DOUBLE)}
|
||||
is acceptable, but a few machines are more restrictive as to which
|
||||
constant addresses are supported.
|
||||
constant addresses are supported.
|
||||
@end defmac
|
||||
|
||||
@defmac CONSTANT_P (@var{x})
|
||||
|
@ -5668,7 +5668,7 @@ preserved (e.g.@: used only by a reduction computation). Otherwise, the
|
|||
|
||||
@deftypefn {Target Hook} int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum vect_cost_for_stmt @var{type_of_cost}, tree @var{vectype}, int @var{misalign})
|
||||
Returns cost of different scalar or vector statements for vectorization cost model.
|
||||
For vector memory operations the cost may depend on type (@var{vectype}) and
|
||||
For vector memory operations the cost may depend on type (@var{vectype}) and
|
||||
misalignment value (@var{misalign}).
|
||||
@end deftypefn
|
||||
|
||||
|
@ -6266,7 +6266,7 @@ than @code{CLEAR_RATIO}.
|
|||
@defmac SET_RATIO (@var{speed})
|
||||
The threshold of number of scalar move insns, @emph{below} which a sequence
|
||||
of insns should be generated to set memory to a constant value, instead of
|
||||
a block set insn or a library call.
|
||||
a block set insn or a library call.
|
||||
Increasing the value will always make code faster, but
|
||||
eventually incurs high cost in increased code size.
|
||||
|
||||
|
@ -6278,8 +6278,8 @@ If you don't define this, it defaults to the value of @code{MOVE_RATIO}.
|
|||
|
||||
@defmac SET_BY_PIECES_P (@var{size}, @var{alignment})
|
||||
A C expression used to determine whether @code{store_by_pieces} will be
|
||||
used to set a chunk of memory to a constant value, or whether some
|
||||
other mechanism will be used. Used by @code{__builtin_memset} when
|
||||
used to set a chunk of memory to a constant value, or whether some
|
||||
other mechanism will be used. Used by @code{__builtin_memset} when
|
||||
storing values other than constant zero.
|
||||
Defaults to 1 if @code{move_by_pieces_ninsns} returns less
|
||||
than @code{SET_RATIO}.
|
||||
|
@ -7130,7 +7130,7 @@ must modify the definition of @samp{movsi} to do something appropriate
|
|||
when the source operand contains a symbolic address. You may also
|
||||
need to alter the handling of switch statements so that they use
|
||||
relative addresses.
|
||||
@c i rearranged the order of the macros above to try to force one of
|
||||
@c i rearranged the order of the macros above to try to force one of
|
||||
@c them to the next line, to eliminate an overfull hbox. --mew 10feb93
|
||||
|
||||
@defmac PIC_OFFSET_TABLE_REGNUM
|
||||
|
@ -7289,7 +7289,7 @@ for the file format in use is appropriate.
|
|||
|
||||
@deftypefn {Target Hook} void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *@var{file}, const char *@var{name})
|
||||
Output COFF information or DWARF debugging information which indicates that filename @var{name} is the current source file to the stdio stream @var{file}.
|
||||
|
||||
|
||||
This target hook need not be defined if the standard form of output for the file format in use is appropriate.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -7318,7 +7318,7 @@ this section is associated.
|
|||
@deftypefn {Target Hook} {section *} TARGET_ASM_FUNCTION_SECTION (tree @var{decl}, enum node_frequency @var{freq}, bool @var{startup}, bool @var{exit})
|
||||
Return preferred text (sub)section for function @var{decl}.
|
||||
Main purpose of this function is to separate cold, normal and hot
|
||||
functions. @var{startup} is true when function is known to be used only
|
||||
functions. @var{startup} is true when function is known to be used only
|
||||
at startup (from static constructors or it is @code{main()}).
|
||||
@var{exit} is true when function is known to be used only at exit
|
||||
(from static destructors).
|
||||
|
@ -10533,14 +10533,14 @@ given mode.
|
|||
@defmac CLZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
|
||||
@defmacx CTZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
|
||||
A C expression that indicates whether the architecture defines a value
|
||||
for @code{clz} or @code{ctz} with a zero operand.
|
||||
for @code{clz} or @code{ctz} with a zero operand.
|
||||
A result of @code{0} indicates the value is undefined.
|
||||
If the value is defined for only the RTL expression, the macro should
|
||||
evaluate to @code{1}; if the value applies also to the corresponding optab
|
||||
entry (which is normally the case if it expands directly into
|
||||
the corresponding RTL), then the macro should evaluate to @code{2}.
|
||||
the corresponding RTL), then the macro should evaluate to @code{2}.
|
||||
In the cases where the value is defined, @var{value} should be set to
|
||||
this value.
|
||||
this value.
|
||||
|
||||
If this macro is not defined, the value of @code{clz} or
|
||||
@code{ctz} at zero is assumed to be undefined.
|
||||
|
@ -10573,7 +10573,7 @@ to @code{Pmode}.
|
|||
@defmac FUNCTION_MODE
|
||||
An alias for the machine mode used for memory references to functions
|
||||
being called, in @code{call} RTL expressions. On most CISC machines,
|
||||
where an instruction can begin at any byte address, this should be
|
||||
where an instruction can begin at any byte address, this should be
|
||||
@code{QImode}. On most RISC machines, where all instructions have fixed
|
||||
size and alignment, this should be a mode with the same size and alignment
|
||||
as the machine instruction words - typically @code{SImode} or @code{HImode}.
|
||||
|
@ -10960,7 +10960,7 @@ passed along.
|
|||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} void TARGET_SET_CURRENT_FUNCTION (tree @var{decl})
|
||||
The compiler invokes this hook whenever it changes its current function
|
||||
The compiler invokes this hook whenever it changes its current function
|
||||
context (@code{cfun}). You can define this function if
|
||||
the back end needs to perform any initialization or reset actions on a
|
||||
per-function basis. For example, it may be used to implement function
|
||||
|
@ -11174,21 +11174,21 @@ the front end.
|
|||
|
||||
@deftypefn {Target Hook} {const char *} TARGET_INVALID_PARAMETER_TYPE (const_tree @var{type})
|
||||
If defined, this macro returns the diagnostic message when it is
|
||||
invalid for functions to include parameters of type @var{type},
|
||||
invalid for functions to include parameters of type @var{type},
|
||||
or @code{NULL} if validity should be determined by
|
||||
the front end. This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} {const char *} TARGET_INVALID_RETURN_TYPE (const_tree @var{type})
|
||||
If defined, this macro returns the diagnostic message when it is
|
||||
invalid for functions to have return type @var{type},
|
||||
invalid for functions to have return type @var{type},
|
||||
or @code{NULL} if validity should be determined by
|
||||
the front end. This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} tree TARGET_PROMOTED_TYPE (const_tree @var{type})
|
||||
If defined, this target hook returns the type to which values of
|
||||
@var{type} should be promoted when they appear in expressions,
|
||||
If defined, this target hook returns the type to which values of
|
||||
@var{type} should be promoted when they appear in expressions,
|
||||
analogous to the integer promotions, or @code{NULL_TREE} to use the
|
||||
front end's normal promotion rules. This hook is useful when there are
|
||||
target-specific types with special promotion rules.
|
||||
|
@ -11196,10 +11196,10 @@ This is currently used only by the C and C++ front ends.
|
|||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} tree TARGET_CONVERT_TO_TYPE (tree @var{type}, tree @var{expr})
|
||||
If defined, this hook returns the result of converting @var{expr} to
|
||||
@var{type}. It should return the converted expression,
|
||||
If defined, this hook returns the result of converting @var{expr} to
|
||||
@var{type}. It should return the converted expression,
|
||||
or @code{NULL_TREE} to apply the front end's normal conversion rules.
|
||||
This hook is useful when there are target-specific types with special
|
||||
This hook is useful when there are target-specific types with special
|
||||
conversion rules.
|
||||
This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
@ -11217,7 +11217,7 @@ NeXT runtime. By default, OBJC_JBLEN is defined to an innocuous value.
|
|||
|
||||
@defmac LIBGCC2_UNWIND_ATTRIBUTE
|
||||
Define this macro if any target-specific attributes need to be attached
|
||||
to the functions in @file{libgcc} that provide low-level support for
|
||||
to the functions in @file{libgcc} that provide low-level support for
|
||||
call stack unwinding. It is used in declarations in @file{unwind-generic.h}
|
||||
and the associated definitions of those functions.
|
||||
@end defmac
|
||||
|
|
|
@ -532,7 +532,7 @@ Any prefixes specified by the user with @option{-B}.
|
|||
|
||||
@item
|
||||
The environment variable @code{GCC_EXEC_PREFIX} or, if @code{GCC_EXEC_PREFIX}
|
||||
is not set and the compiler has not been installed in the configure-time
|
||||
is not set and the compiler has not been installed in the configure-time
|
||||
@var{prefix}, the location in which the compiler has actually been installed.
|
||||
|
||||
@item
|
||||
|
@ -540,16 +540,16 @@ The directories specified by the environment variable @code{COMPILER_PATH}.
|
|||
|
||||
@item
|
||||
The macro @code{STANDARD_EXEC_PREFIX}, if the compiler has been installed
|
||||
in the configured-time @var{prefix}.
|
||||
in the configured-time @var{prefix}.
|
||||
|
||||
@item
|
||||
The location @file{/usr/libexec/gcc/}, but only if this is a native compiler.
|
||||
The location @file{/usr/libexec/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
compiler.
|
||||
@end enumerate
|
||||
|
||||
|
@ -569,21 +569,21 @@ The directories specified by the environment variable @code{LIBRARY_PATH}
|
|||
|
||||
@item
|
||||
The macro @code{STANDARD_EXEC_PREFIX}, but only if the toolchain is installed
|
||||
in the configured @var{prefix} or this is a native compiler.
|
||||
in the configured @var{prefix} or this is a native compiler.
|
||||
|
||||
@item
|
||||
The location @file{/usr/lib/gcc/}, but only if this is a native compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
The macro @code{MD_EXEC_PREFIX}, if defined, but only if this is a native
|
||||
compiler.
|
||||
|
||||
@item
|
||||
The macro @code{MD_STARTFILE_PREFIX}, if defined, but only if this is a
|
||||
The macro @code{MD_STARTFILE_PREFIX}, if defined, but only if this is a
|
||||
native compiler, or we have a target system root.
|
||||
|
||||
@item
|
||||
The macro @code{MD_STARTFILE_PREFIX_1}, if defined, but only if this is a
|
||||
The macro @code{MD_STARTFILE_PREFIX_1}, if defined, but only if this is a
|
||||
native compiler, or we have a target system root.
|
||||
|
||||
@item
|
||||
|
@ -4371,10 +4371,10 @@ compiled.
|
|||
|
||||
@hook TARGET_LIBCALL_VALUE
|
||||
Define this hook if the back-end needs to know the name of the libcall
|
||||
function in order to determine where the result should be returned.
|
||||
function in order to determine where the result should be returned.
|
||||
|
||||
The mode of the result is given by @var{mode} and the name of the called
|
||||
library function is given by @var{fun}. The hook should return an RTX
|
||||
library function is given by @var{fun}. The hook should return an RTX
|
||||
representing the place where the library function result will be returned.
|
||||
|
||||
If this hook is not defined, then LIBCALL_VALUE will be used.
|
||||
|
@ -5097,12 +5097,12 @@ when it is called.
|
|||
If the target defines @code{TARGET_ASM_TRAMPOLINE_TEMPLATE}, then the
|
||||
first thing this hook should do is emit a block move into @var{m_tramp}
|
||||
from the memory block returned by @code{assemble_trampoline_template}.
|
||||
Note that the block move need only cover the constant parts of the
|
||||
Note that the block move need only cover the constant parts of the
|
||||
trampoline. If the target isolates the variable parts of the trampoline
|
||||
to the end, not all @code{TRAMPOLINE_SIZE} bytes need be copied.
|
||||
|
||||
If the target requires any other actions, such as flushing caches or
|
||||
enabling stack execution, these actions should be performed after
|
||||
enabling stack execution, these actions should be performed after
|
||||
initializing the trampoline proper.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -5306,7 +5306,7 @@ A C expression that is 1 if the RTX @var{x} is a constant which
|
|||
is a valid address. On most machines the default definition of
|
||||
@code{(CONSTANT_P (@var{x}) && GET_CODE (@var{x}) != CONST_DOUBLE)}
|
||||
is acceptable, but a few machines are more restrictive as to which
|
||||
constant addresses are supported.
|
||||
constant addresses are supported.
|
||||
@end defmac
|
||||
|
||||
@defmac CONSTANT_P (@var{x})
|
||||
|
@ -5620,7 +5620,7 @@ preserved (e.g.@: used only by a reduction computation). Otherwise, the
|
|||
|
||||
@hook TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST
|
||||
Returns cost of different scalar or vector statements for vectorization cost model.
|
||||
For vector memory operations the cost may depend on type (@var{vectype}) and
|
||||
For vector memory operations the cost may depend on type (@var{vectype}) and
|
||||
misalignment value (@var{misalign}).
|
||||
@end deftypefn
|
||||
|
||||
|
@ -6218,7 +6218,7 @@ than @code{CLEAR_RATIO}.
|
|||
@defmac SET_RATIO (@var{speed})
|
||||
The threshold of number of scalar move insns, @emph{below} which a sequence
|
||||
of insns should be generated to set memory to a constant value, instead of
|
||||
a block set insn or a library call.
|
||||
a block set insn or a library call.
|
||||
Increasing the value will always make code faster, but
|
||||
eventually incurs high cost in increased code size.
|
||||
|
||||
|
@ -6230,8 +6230,8 @@ If you don't define this, it defaults to the value of @code{MOVE_RATIO}.
|
|||
|
||||
@defmac SET_BY_PIECES_P (@var{size}, @var{alignment})
|
||||
A C expression used to determine whether @code{store_by_pieces} will be
|
||||
used to set a chunk of memory to a constant value, or whether some
|
||||
other mechanism will be used. Used by @code{__builtin_memset} when
|
||||
used to set a chunk of memory to a constant value, or whether some
|
||||
other mechanism will be used. Used by @code{__builtin_memset} when
|
||||
storing values other than constant zero.
|
||||
Defaults to 1 if @code{move_by_pieces_ninsns} returns less
|
||||
than @code{SET_RATIO}.
|
||||
|
@ -7077,7 +7077,7 @@ must modify the definition of @samp{movsi} to do something appropriate
|
|||
when the source operand contains a symbolic address. You may also
|
||||
need to alter the handling of switch statements so that they use
|
||||
relative addresses.
|
||||
@c i rearranged the order of the macros above to try to force one of
|
||||
@c i rearranged the order of the macros above to try to force one of
|
||||
@c them to the next line, to eliminate an overfull hbox. --mew 10feb93
|
||||
|
||||
@defmac PIC_OFFSET_TABLE_REGNUM
|
||||
|
@ -7261,7 +7261,7 @@ this section is associated.
|
|||
@hook TARGET_ASM_FUNCTION_SECTION
|
||||
Return preferred text (sub)section for function @var{decl}.
|
||||
Main purpose of this function is to separate cold, normal and hot
|
||||
functions. @var{startup} is true when function is known to be used only
|
||||
functions. @var{startup} is true when function is known to be used only
|
||||
at startup (from static constructors or it is @code{main()}).
|
||||
@var{exit} is true when function is known to be used only at exit
|
||||
(from static destructors).
|
||||
|
@ -10459,14 +10459,14 @@ given mode.
|
|||
@defmac CLZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
|
||||
@defmacx CTZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
|
||||
A C expression that indicates whether the architecture defines a value
|
||||
for @code{clz} or @code{ctz} with a zero operand.
|
||||
for @code{clz} or @code{ctz} with a zero operand.
|
||||
A result of @code{0} indicates the value is undefined.
|
||||
If the value is defined for only the RTL expression, the macro should
|
||||
evaluate to @code{1}; if the value applies also to the corresponding optab
|
||||
entry (which is normally the case if it expands directly into
|
||||
the corresponding RTL), then the macro should evaluate to @code{2}.
|
||||
the corresponding RTL), then the macro should evaluate to @code{2}.
|
||||
In the cases where the value is defined, @var{value} should be set to
|
||||
this value.
|
||||
this value.
|
||||
|
||||
If this macro is not defined, the value of @code{clz} or
|
||||
@code{ctz} at zero is assumed to be undefined.
|
||||
|
@ -10499,7 +10499,7 @@ to @code{Pmode}.
|
|||
@defmac FUNCTION_MODE
|
||||
An alias for the machine mode used for memory references to functions
|
||||
being called, in @code{call} RTL expressions. On most CISC machines,
|
||||
where an instruction can begin at any byte address, this should be
|
||||
where an instruction can begin at any byte address, this should be
|
||||
@code{QImode}. On most RISC machines, where all instructions have fixed
|
||||
size and alignment, this should be a mode with the same size and alignment
|
||||
as the machine instruction words - typically @code{SImode} or @code{HImode}.
|
||||
|
@ -10884,7 +10884,7 @@ passed along.
|
|||
@end deftypefn
|
||||
|
||||
@hook TARGET_SET_CURRENT_FUNCTION
|
||||
The compiler invokes this hook whenever it changes its current function
|
||||
The compiler invokes this hook whenever it changes its current function
|
||||
context (@code{cfun}). You can define this function if
|
||||
the back end needs to perform any initialization or reset actions on a
|
||||
per-function basis. For example, it may be used to implement function
|
||||
|
@ -11098,21 +11098,21 @@ the front end.
|
|||
|
||||
@hook TARGET_INVALID_PARAMETER_TYPE
|
||||
If defined, this macro returns the diagnostic message when it is
|
||||
invalid for functions to include parameters of type @var{type},
|
||||
invalid for functions to include parameters of type @var{type},
|
||||
or @code{NULL} if validity should be determined by
|
||||
the front end. This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
||||
@hook TARGET_INVALID_RETURN_TYPE
|
||||
If defined, this macro returns the diagnostic message when it is
|
||||
invalid for functions to have return type @var{type},
|
||||
invalid for functions to have return type @var{type},
|
||||
or @code{NULL} if validity should be determined by
|
||||
the front end. This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
||||
@hook TARGET_PROMOTED_TYPE
|
||||
If defined, this target hook returns the type to which values of
|
||||
@var{type} should be promoted when they appear in expressions,
|
||||
If defined, this target hook returns the type to which values of
|
||||
@var{type} should be promoted when they appear in expressions,
|
||||
analogous to the integer promotions, or @code{NULL_TREE} to use the
|
||||
front end's normal promotion rules. This hook is useful when there are
|
||||
target-specific types with special promotion rules.
|
||||
|
@ -11120,10 +11120,10 @@ This is currently used only by the C and C++ front ends.
|
|||
@end deftypefn
|
||||
|
||||
@hook TARGET_CONVERT_TO_TYPE
|
||||
If defined, this hook returns the result of converting @var{expr} to
|
||||
@var{type}. It should return the converted expression,
|
||||
If defined, this hook returns the result of converting @var{expr} to
|
||||
@var{type}. It should return the converted expression,
|
||||
or @code{NULL_TREE} to apply the front end's normal conversion rules.
|
||||
This hook is useful when there are target-specific types with special
|
||||
This hook is useful when there are target-specific types with special
|
||||
conversion rules.
|
||||
This is currently used only by the C and C++ front ends.
|
||||
@end deftypefn
|
||||
|
@ -11141,7 +11141,7 @@ NeXT runtime. By default, OBJC_JBLEN is defined to an innocuous value.
|
|||
|
||||
@defmac LIBGCC2_UNWIND_ATTRIBUTE
|
||||
Define this macro if any target-specific attributes need to be attached
|
||||
to the functions in @file{libgcc} that provide low-level support for
|
||||
to the functions in @file{libgcc} that provide low-level support for
|
||||
call stack unwinding. It is used in declarations in @file{unwind-generic.h}
|
||||
and the associated definitions of those functions.
|
||||
@end defmac
|
||||
|
|
|
@ -184,7 +184,7 @@ must be made to @code{update_stmt} when complete. Calling one of the
|
|||
call to @code{update_stmt}.
|
||||
|
||||
@subsection Operand Iterators And Access Routines
|
||||
@cindex Operand Iterators
|
||||
@cindex Operand Iterators
|
||||
@cindex Operand Access Routines
|
||||
|
||||
Operands are collected by @file{tree-ssa-operands.c}. They are stored
|
||||
|
@ -194,9 +194,9 @@ operand iterators or an access routine.
|
|||
The following access routines are available for examining operands:
|
||||
|
||||
@enumerate
|
||||
@item @code{SINGLE_SSA_@{USE,DEF,TREE@}_OPERAND}: These accessors will return
|
||||
NULL unless there is exactly one operand matching the specified flags. If
|
||||
there is exactly one operand, the operand is returned as either a @code{tree},
|
||||
@item @code{SINGLE_SSA_@{USE,DEF,TREE@}_OPERAND}: These accessors will return
|
||||
NULL unless there is exactly one operand matching the specified flags. If
|
||||
there is exactly one operand, the operand is returned as either a @code{tree},
|
||||
@code{def_operand_p}, or @code{use_operand_p}.
|
||||
|
||||
@smallexample
|
||||
|
@ -205,7 +205,7 @@ use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
|
|||
def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
|
||||
@end smallexample
|
||||
|
||||
@item @code{ZERO_SSA_OPERANDS}: This macro returns true if there are no
|
||||
@item @code{ZERO_SSA_OPERANDS}: This macro returns true if there are no
|
||||
operands matching the specified flags.
|
||||
|
||||
@smallexample
|
||||
|
@ -213,8 +213,8 @@ if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
|
|||
return;
|
||||
@end smallexample
|
||||
|
||||
@item @code{NUM_SSA_OPERANDS}: This macro Returns the number of operands
|
||||
matching 'flags'. This actually executes a loop to perform the count, so
|
||||
@item @code{NUM_SSA_OPERANDS}: This macro Returns the number of operands
|
||||
matching 'flags'. This actually executes a loop to perform the count, so
|
||||
only use this if it is really needed.
|
||||
|
||||
@smallexample
|
||||
|
@ -331,8 +331,8 @@ documentation in @file{tree-ssa-operands.h}.
|
|||
There are also a couple of variants on the stmt iterators regarding PHI
|
||||
nodes.
|
||||
|
||||
@code{FOR_EACH_PHI_ARG} Works exactly like
|
||||
@code{FOR_EACH_SSA_USE_OPERAND}, except it works over @code{PHI} arguments
|
||||
@code{FOR_EACH_PHI_ARG} Works exactly like
|
||||
@code{FOR_EACH_SSA_USE_OPERAND}, except it works over @code{PHI} arguments
|
||||
instead of statement operands.
|
||||
|
||||
@smallexample
|
||||
|
@ -351,10 +351,10 @@ FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
|
|||
my_code;
|
||||
@end smallexample
|
||||
|
||||
@code{FOR_EACH_PHI_OR_STMT_@{USE,DEF@}} works exactly like
|
||||
@code{FOR_EACH_PHI_OR_STMT_@{USE,DEF@}} works exactly like
|
||||
@code{FOR_EACH_SSA_@{USE,DEF@}_OPERAND}, except it will function on
|
||||
either a statement or a @code{PHI} node. These should be used when it is
|
||||
appropriate but they are not quite as efficient as the individual
|
||||
appropriate but they are not quite as efficient as the individual
|
||||
@code{FOR_EACH_PHI} and @code{FOR_EACH_SSA} routines.
|
||||
|
||||
@smallexample
|
||||
|
@ -372,7 +372,7 @@ FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
|
|||
@subsection Immediate Uses
|
||||
@cindex Immediate Uses
|
||||
|
||||
Immediate use information is now always available. Using the immediate use
|
||||
Immediate use information is now always available. Using the immediate use
|
||||
iterators, you may examine every use of any @code{SSA_NAME}. For instance,
|
||||
to change each use of @code{ssa_var} to @code{ssa_var2} and call fold_stmt on
|
||||
each stmt after that is done:
|
||||
|
@ -393,18 +393,18 @@ each stmt after that is done:
|
|||
|
||||
There are 2 iterators which can be used. @code{FOR_EACH_IMM_USE_FAST} is
|
||||
used when the immediate uses are not changed, i.e., you are looking at the
|
||||
uses, but not setting them.
|
||||
uses, but not setting them.
|
||||
|
||||
If they do get changed, then care must be taken that things are not changed
|
||||
under the iterators, so use the @code{FOR_EACH_IMM_USE_STMT} and
|
||||
@code{FOR_EACH_IMM_USE_ON_STMT} iterators. They attempt to preserve the
|
||||
sanity of the use list by moving all the uses for a statement into
|
||||
a controlled position, and then iterating over those uses. Then the
|
||||
If they do get changed, then care must be taken that things are not changed
|
||||
under the iterators, so use the @code{FOR_EACH_IMM_USE_STMT} and
|
||||
@code{FOR_EACH_IMM_USE_ON_STMT} iterators. They attempt to preserve the
|
||||
sanity of the use list by moving all the uses for a statement into
|
||||
a controlled position, and then iterating over those uses. Then the
|
||||
optimization can manipulate the stmt when all the uses have been
|
||||
processed. This is a little slower than the FAST version since it adds a
|
||||
placeholder element and must sort through the list a bit for each statement.
|
||||
This placeholder element must be also be removed if the loop is
|
||||
terminated early. The macro @code{BREAK_FROM_IMM_USE_SAFE} is provided
|
||||
processed. This is a little slower than the FAST version since it adds a
|
||||
placeholder element and must sort through the list a bit for each statement.
|
||||
This placeholder element must be also be removed if the loop is
|
||||
terminated early. The macro @code{BREAK_FROM_IMM_USE_SAFE} is provided
|
||||
to do this :
|
||||
|
||||
@smallexample
|
||||
|
@ -420,15 +420,15 @@ to do this :
|
|||
@end smallexample
|
||||
|
||||
There are checks in @code{verify_ssa} which verify that the immediate use list
|
||||
is up to date, as well as checking that an optimization didn't break from the
|
||||
loop without using this macro. It is safe to simply 'break'; from a
|
||||
is up to date, as well as checking that an optimization didn't break from the
|
||||
loop without using this macro. It is safe to simply 'break'; from a
|
||||
@code{FOR_EACH_IMM_USE_FAST} traverse.
|
||||
|
||||
Some useful functions and macros:
|
||||
@enumerate
|
||||
@item @code{has_zero_uses (ssa_var)} : Returns true if there are no uses of
|
||||
@code{ssa_var}.
|
||||
@item @code{has_single_use (ssa_var)} : Returns true if there is only a
|
||||
@item @code{has_single_use (ssa_var)} : Returns true if there is only a
|
||||
single use of @code{ssa_var}.
|
||||
@item @code{single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)} :
|
||||
Returns true if there is only a single use of @code{ssa_var}, and also returns
|
||||
|
@ -443,18 +443,18 @@ isn't located in a @code{PHI} node.
|
|||
@end enumerate
|
||||
|
||||
Note that uses are not put into an immediate use list until their statement is
|
||||
actually inserted into the instruction stream via a @code{bsi_*} routine.
|
||||
actually inserted into the instruction stream via a @code{bsi_*} routine.
|
||||
|
||||
It is also still possible to utilize lazy updating of statements, but this
|
||||
should be used only when absolutely required. Both alias analysis and the
|
||||
dominator optimizations currently do this.
|
||||
It is also still possible to utilize lazy updating of statements, but this
|
||||
should be used only when absolutely required. Both alias analysis and the
|
||||
dominator optimizations currently do this.
|
||||
|
||||
When lazy updating is being used, the immediate use information is out of date
|
||||
When lazy updating is being used, the immediate use information is out of date
|
||||
and cannot be used reliably. Lazy updating is achieved by simply marking
|
||||
statements modified via calls to @code{mark_stmt_modified} instead of
|
||||
@code{update_stmt}. When lazy updating is no longer required, all the
|
||||
modified statements must have @code{update_stmt} called in order to bring them
|
||||
up to date. This must be done before the optimization is finished, or
|
||||
statements modified via calls to @code{mark_stmt_modified} instead of
|
||||
@code{update_stmt}. When lazy updating is no longer required, all the
|
||||
modified statements must have @code{update_stmt} called in order to bring them
|
||||
up to date. This must be done before the optimization is finished, or
|
||||
@code{verify_ssa} will trigger an abort.
|
||||
|
||||
This is done with a simple loop over the instruction stream:
|
||||
|
@ -561,7 +561,7 @@ Some optimization passes make changes to the function that
|
|||
invalidate the SSA property. This can happen when a pass has
|
||||
added new symbols or changed the program so that variables that
|
||||
were previously aliased aren't anymore. Whenever something like this
|
||||
happens, the affected symbols must be renamed into SSA form again.
|
||||
happens, the affected symbols must be renamed into SSA form again.
|
||||
Transformations that emit new code or replicate existing statements
|
||||
will also need to update the SSA form@.
|
||||
|
||||
|
|
Loading…
Reference in New Issue