c-tree.texi, [...]: Remove trailing whitespace.
* doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi, doc/install.texi, doc/invoke.texi, doc/md.texi, doc/passes.texi, doc/rtl.texi, doc/tm.texi, doc/tree-ssa.texi: Remove trailing whitespace. From-SVN: r90100
This commit is contained in:
parent
04fb56d599
commit
f0eb93a806
|
@ -1,3 +1,10 @@
|
|||
2004-11-05 Joseph S. Myers <joseph@codesourcery.com>
|
||||
|
||||
* doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi,
|
||||
doc/install.texi, doc/invoke.texi, doc/md.texi, doc/passes.texi,
|
||||
doc/rtl.texi, doc/tm.texi, doc/tree-ssa.texi: Remove trailing
|
||||
whitespace.
|
||||
|
||||
2004-11-04 Mark Mitchell <mark@codesourcery.com>
|
||||
|
||||
* config/arm/arm.c (arm_handle_notshared_attribute): New function.
|
||||
|
|
|
@ -2170,7 +2170,7 @@ variable is initialized, rather than assigned to subsequently.
|
|||
These nodes represent non-static data member accesses. The first
|
||||
operand is the object (rather than a pointer to it); the second operand
|
||||
is the @code{FIELD_DECL} for the data member. The third operand represents
|
||||
the byte offset of the field, but should not be used directly; call
|
||||
the byte offset of the field, but should not be used directly; call
|
||||
@code{component_ref_field_offset} instead.
|
||||
|
||||
@item COMPOUND_EXPR
|
||||
|
|
|
@ -229,7 +229,7 @@ and many computed jumps may have @emph{very} dense flow graphs, so
|
|||
these edges need to be handled with special care. During the earlier
|
||||
stages of the compilation process, GCC tries to avoid such dense flow
|
||||
graphs by factoring computed jumps. For example, given the following
|
||||
series of jumps,
|
||||
series of jumps,
|
||||
|
||||
@smallexample
|
||||
goto *x;
|
||||
|
@ -580,7 +580,7 @@ be freely reused for other values when a register is dead.
|
|||
@findex REG_DEAD, REG_UNUSED
|
||||
The liveness information is stored partly in the RTL instruction
|
||||
stream and partly in the flow graph. Local information is stored in
|
||||
the instruction stream:
|
||||
the instruction stream:
|
||||
Each instruction may contain @code{REG_DEAD} notes representing that
|
||||
the value of a given register is no longer needed, or
|
||||
@code{REG_UNUSED} notes representing that the value computed by the
|
||||
|
|
|
@ -3310,14 +3310,14 @@ above in recent GCC versions.
|
|||
@subsection ARM Type Attributes
|
||||
|
||||
On those ARM targets that support @code{dllimport} (such as Symbian
|
||||
OS), you can use the @code{notshared} attribute to indicate that the
|
||||
OS), you can use the @code{notshared} attribute to indicate that the
|
||||
virtual table and other similar data for a class should not be
|
||||
exported from a DLL. For example:
|
||||
|
||||
@smallexample
|
||||
class __declspec(notshared) C @{
|
||||
public:
|
||||
__declspec(dllimport) C();
|
||||
__declspec(dllimport) C();
|
||||
virtual void f();
|
||||
@}
|
||||
|
||||
|
@ -3689,7 +3689,7 @@ int foo ()
|
|||
int result;
|
||||
asm ("magic stuff accessing an 'int' pointed to by '%1'"
|
||||
"=&d" (r) : "a" (y), "m" (*y));
|
||||
return result;
|
||||
return result;
|
||||
@}
|
||||
@end smallexample
|
||||
|
||||
|
@ -3790,10 +3790,10 @@ The @code{volatile} keyword indicates that the instruction has
|
|||
important side-effects. GCC will not delete a volatile @code{asm} if
|
||||
it is reachable. (The instruction can still be deleted if GCC can
|
||||
prove that control-flow will never reach the location of the
|
||||
instruction.) Note that even a volatile @code{asm} instruction
|
||||
instruction.) Note that even a volatile @code{asm} instruction
|
||||
can be moved relative to other code, including across jump
|
||||
instructions. For example, on many targets there is a system
|
||||
register which can be set to control the rounding mode of
|
||||
instructions. For example, on many targets there is a system
|
||||
register which can be set to control the rounding mode of
|
||||
floating point operations. You might try
|
||||
setting it with a volatile @code{asm}, like this PowerPC example:
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ static GTY(()) int @var{counter}; /* @r{save counter in a PCH} */
|
|||
@end smallexample
|
||||
|
||||
The parser understands simple typedefs such as
|
||||
@code{typedef struct @var{tag} *@var{name};} and
|
||||
@code{typedef struct @var{tag} *@var{name};} and
|
||||
@code{typedef int @var{name};}.
|
||||
These don't need to be marked.
|
||||
|
||||
|
|
|
@ -1235,7 +1235,7 @@ The following options apply to the build of the Fortran front end.
|
|||
@itemx --with-mpfr=@var{pathname}
|
||||
@itemx --with-gmp-dir=@var{pathname}
|
||||
@itemx --with-mpfr-dir=@var{pathname}
|
||||
If you don't have GMP (the GNU Multiple Precision library) and the MPFR
|
||||
If you don't have GMP (the GNU Multiple Precision library) and the MPFR
|
||||
Libraries installed in a standard location and you want to build the Fortran
|
||||
front-end, you can explicitly specify the directory where they are installed
|
||||
(@samp{--with-gmp=gmpinstalldir}, @samp{--with-mpfr=mpfrinstalldir}) or where
|
||||
|
@ -2751,7 +2751,7 @@ needed whenever @env{CC} is used.
|
|||
|
||||
Specifically, options that determine the runtime architecture must be
|
||||
in @env{CC} to correctly select the target for the build. It is also
|
||||
convenient to place many other compiler options in @env{CC}. For example,
|
||||
convenient to place many other compiler options in @env{CC}. For example,
|
||||
@env{CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"}
|
||||
can be used to bootstrap the GCC 3.3 branch with the HP compiler in
|
||||
64-bit K&R/bundled mode. The @option{+DA2.0W} option will result in
|
||||
|
|
|
@ -1834,7 +1834,7 @@ Objective-C and Objective-C++ programs; you can use the other options with
|
|||
any language supported by GCC@.
|
||||
|
||||
Note that since Objective-C is an extension of the C language, Objective-C
|
||||
compilations may also use options specific to the C front-end (e.g.,
|
||||
compilations may also use options specific to the C front-end (e.g.,
|
||||
@option{-Wtraditional}). Similarly, Objective-C++ compilations may use
|
||||
C++-specific options (e.g., @option{-Wabi}).
|
||||
|
||||
|
@ -3516,7 +3516,7 @@ loop optimization pass, to @file{@var{file}.06.loop}. @option{-dL} and
|
|||
@itemx -fdump-rtl-sms
|
||||
@opindex dm
|
||||
@opindex fdump-rtl-sms
|
||||
Dump after modulo scheduling, to @file{@var{file}.20.sms}.
|
||||
Dump after modulo scheduling, to @file{@var{file}.20.sms}.
|
||||
|
||||
@item -dM
|
||||
@itemx -fdump-rtl-mach
|
||||
|
@ -3842,7 +3842,7 @@ file name.
|
|||
|
||||
@item vect
|
||||
@opindex fdump-tree-vect
|
||||
Dump each function after applying vectorization of loops. The file name is
|
||||
Dump each function after applying vectorization of loops. The file name is
|
||||
made by appending @file{.vect} to the source file name.
|
||||
|
||||
@item all
|
||||
|
@ -4650,7 +4650,7 @@ Perform loop optimizations on trees. This flag is enabled by default
|
|||
at @option{-O} and higher.
|
||||
|
||||
@item -ftree-loop-linear
|
||||
Perform linear loop transformations on tree. This flag can improve cache
|
||||
Perform linear loop transformations on tree. This flag can improve cache
|
||||
performance and allow further loop optimizations to take place.
|
||||
|
||||
@item -ftree-lim
|
||||
|
@ -4733,7 +4733,7 @@ This optimization is enabled by default.
|
|||
|
||||
@item -fvariable-expansion-in-unroller
|
||||
@opindex -fvariable-expansion-in-unroller
|
||||
With this option, the compiler will create multiple copies of some
|
||||
With this option, the compiler will create multiple copies of some
|
||||
local variables when unrolling a loop which can result in superior code.
|
||||
|
||||
@item -fprefetch-loop-arrays
|
||||
|
@ -7252,14 +7252,14 @@ Emit debugging information for all symbols and types.
|
|||
@item -mone-byte-bool
|
||||
@opindex -mone-byte-bool
|
||||
Override the defaults for @samp{bool} so that @samp{sizeof(bool)==1}.
|
||||
By default @samp{sizeof(bool)} is @samp{4} when compiling for
|
||||
By default @samp{sizeof(bool)} is @samp{4} when compiling for
|
||||
Darwin/PowerPC and @samp{1} when compiling for Darwin/x86, so this
|
||||
option has no effect on x86.
|
||||
|
||||
@strong{Warning:} The @option{-mone-byte-bool} switch causes GCC
|
||||
to generate code that is not binary compatible with code generated
|
||||
without that switch. Using this switch may require recompiling all
|
||||
other modules in a program, including system libraries. Use this
|
||||
other modules in a program, including system libraries. Use this
|
||||
switch to conform to a non-default data model.
|
||||
|
||||
@item -mfix-and-continue
|
||||
|
@ -10837,18 +10837,18 @@ In order to provide a backchain the address of the caller's frame
|
|||
is stored within the callee's stack frame.
|
||||
A backchain may be needed to allow debugging using tools that do not understand
|
||||
DWARF-2 call frame information.
|
||||
For @option{-mno-backchain} no backchain is maintained at all which is the
|
||||
default.
|
||||
If one of the other options is present the backchain pointer is placed either
|
||||
For @option{-mno-backchain} no backchain is maintained at all which is the
|
||||
default.
|
||||
If one of the other options is present the backchain pointer is placed either
|
||||
on top of the stack frame (@option{-mkernel-backchain}) or on
|
||||
the bottom (@option{-mbackchain}).
|
||||
Beside the different backchain location @option{-mkernel-backchain}
|
||||
also changes stack frame layout breaking the ABI. This option
|
||||
is intended to be used for code which internally needs a backchain but has
|
||||
to get by with a limited stack size e.g.@: the linux kernel.
|
||||
to get by with a limited stack size e.g.@: the linux kernel.
|
||||
Internal unwinding code not using DWARF-2 info has to be able to locate the
|
||||
return address of a function. That will be eased be the fact that
|
||||
the return address of a function is placed two words below the backchain
|
||||
the return address of a function is placed two words below the backchain
|
||||
pointer.
|
||||
|
||||
@item -msmall-exec
|
||||
|
@ -10936,8 +10936,8 @@ hardware floating point is used.
|
|||
@opindex mwarn-framesize
|
||||
Emit a warning if the current function exceeds the given frame size. Because
|
||||
this is a compile time check it doesn't need to be a real problem when the program
|
||||
runs. It is intended to identify functions which most probably cause
|
||||
a stack overflow. It is useful to be used in an environment with limited stack
|
||||
runs. It is intended to identify functions which most probably cause
|
||||
a stack overflow. It is useful to be used in an environment with limited stack
|
||||
size e.g.@: the linux kernel.
|
||||
|
||||
@item -mwarn-dynamicstack
|
||||
|
@ -10951,11 +10951,11 @@ sized arrays. This is generally a bad idea with a limited stack size.
|
|||
@opindex mstack-size
|
||||
These arguments always have to be used in conjunction. If they are present the s390
|
||||
back end emits additional instructions in the function prologue which trigger a trap
|
||||
if the stack size is @var{stack-guard} bytes above the @var{stack-size}
|
||||
(remember that the stack on s390 grows downward). These options are intended to
|
||||
be used to help debugging stack overflow problems. The additionally emitted code
|
||||
cause only little overhead and hence can also be used in production like systems
|
||||
without greater performance degradation. The given values have to be exact
|
||||
if the stack size is @var{stack-guard} bytes above the @var{stack-size}
|
||||
(remember that the stack on s390 grows downward). These options are intended to
|
||||
be used to help debugging stack overflow problems. The additionally emitted code
|
||||
cause only little overhead and hence can also be used in production like systems
|
||||
without greater performance degradation. The given values have to be exact
|
||||
powers of 2 and @var{stack-size} has to be greater than @var{stack-guard}.
|
||||
In order to be efficient the extra code makes the assumption that the stack starts
|
||||
at an address aligned to the value given by @var{stack-size}.
|
||||
|
@ -12181,7 +12181,7 @@ load times of shared object libraries, produce more optimized
|
|||
code, provide near-perfect API export and prevent symbol clashes.
|
||||
It is @strong{strongly} recommended that you use this in any shared objects
|
||||
you distribute.
|
||||
|
||||
|
||||
Despite the nomenclature, @code{default} always means public ie;
|
||||
available to be linked against from outside the shared object.
|
||||
@code{protected} and @code{internal} are pretty useless in real-world
|
||||
|
@ -12190,7 +12190,7 @@ The default if @option{-fvisibility} isn't specified is
|
|||
@code{default}, i.e., make every
|
||||
symbol public---this causes the same behavior as previous versions of
|
||||
GCC.
|
||||
|
||||
|
||||
A good explanation of the benefits offered by ensuring ELF
|
||||
symbols have the correct visibility is given by ``How To Write
|
||||
Shared Libraries'' by Ulrich Drepper (which can be found at
|
||||
|
|
|
@ -919,7 +919,7 @@ logical operators, which have the semantics of the C operators
|
|||
@end table
|
||||
|
||||
@item
|
||||
An optional block of C code, which should execute
|
||||
An optional block of C code, which should execute
|
||||
@samp{@w{return true}} if the predicate is found to match and
|
||||
@samp{@w{return false}} if it does not. It must not have any side
|
||||
effects. The predicate arguments, @var{op} and @var{mode}, are
|
||||
|
|
|
@ -12,7 +12,7 @@
|
|||
@cindex compiler passes and files
|
||||
|
||||
This chapter is dedicated to giving an overview of the optimization and
|
||||
code generation passes of the compiler. In the process, it describes
|
||||
code generation passes of the compiler. In the process, it describes
|
||||
some of the language front end interface, though this description is no
|
||||
where near complete.
|
||||
|
||||
|
@ -30,7 +30,7 @@ where near complete.
|
|||
@findex lang_hooks.parse_file
|
||||
The language front end is invoked only once, via
|
||||
@code{lang_hooks.parse_file}, to parse the entire input. The language
|
||||
front end may use any intermediate language representation deemed
|
||||
front end may use any intermediate language representation deemed
|
||||
appropriate. The C front end uses GENERIC trees (CROSSREF), plus
|
||||
a double handful of language specific tree codes defined in
|
||||
@file{c-common.def}. The Fortran front end uses a completely different
|
||||
|
@ -43,10 +43,10 @@ private representation.
|
|||
@cindex intermediate representation lowering
|
||||
@cindex lowering, language-dependent intermediate representation
|
||||
At some point the front end must translate the representation used in the
|
||||
front end to a representation understood by the language-independent
|
||||
front end to a representation understood by the language-independent
|
||||
portions of the compiler. Current practice takes one of two forms.
|
||||
The C front end manually invokes the gimplifier (CROSSREF) on each function,
|
||||
and uses the gimplifier callbacks to convert the language-specific tree
|
||||
and uses the gimplifier callbacks to convert the language-specific tree
|
||||
nodes directly to GIMPLE (CROSSREF) before passing the function off to
|
||||
be compiled.
|
||||
The Fortran front end converts from a private representation to GENERIC,
|
||||
|
@ -72,7 +72,7 @@ Hum... this sounds overly complicated. Perhaps we should just
|
|||
have the front end gimplify always; in most cases it's only one
|
||||
function call.
|
||||
|
||||
The front end needs to pass all function definitions and top level
|
||||
The front end needs to pass all function definitions and top level
|
||||
declarations off to the middle-end so that they can be compiled and
|
||||
emitted to the object file. For a simple procedural language, it is
|
||||
usually most convenient to do this as each top level declaration or
|
||||
|
@ -80,14 +80,14 @@ definition is seen. There is also a distinction to be made between
|
|||
generating functional code and generating complete debug information.
|
||||
The only thing that is absolutely required for functional code is that
|
||||
function and data @emph{definitions} be passed to the middle-end. For
|
||||
complete debug information, function, data and type declarations
|
||||
complete debug information, function, data and type declarations
|
||||
should all be passed as well.
|
||||
|
||||
@findex rest_of_decl_compilation
|
||||
@findex rest_of_type_compilation
|
||||
@findex cgraph_finalize_function
|
||||
In any case, the front end needs each complete top-level function or
|
||||
data declaration, and each data definition should be passed to
|
||||
data declaration, and each data definition should be passed to
|
||||
@code{rest_of_decl_compilation}. Each complete type definition should
|
||||
be passed to @code{rest_of_type_compilation}. Each function definition
|
||||
should be passed to @code{cgraph_finalize_function}.
|
||||
|
@ -100,7 +100,7 @@ as the official interface? Possibly we should rename all three
|
|||
interfaces such that the names match in some meaningful way and
|
||||
that is more descriptive than "rest_of".
|
||||
|
||||
The middle-end will, at its option, emit the function and data
|
||||
The middle-end will, at its option, emit the function and data
|
||||
definitions immediately or queue them for later processing.
|
||||
|
||||
@node Gimplification pass
|
||||
|
@ -116,7 +116,7 @@ section of code.
|
|||
|
||||
@cindex GENERIC
|
||||
While a front end may certainly choose to generate GIMPLE directly if
|
||||
it chooses, this can be a moderately complex process unless the
|
||||
it chooses, this can be a moderately complex process unless the
|
||||
intermediate language used by the front end is already fairly simple.
|
||||
Usually it is easier to generate GENERIC trees plus extensions
|
||||
and let the language-independent gimplifier do most of the work.
|
||||
|
@ -125,7 +125,7 @@ and let the language-independent gimplifier do most of the work.
|
|||
@findex gimplify_expr
|
||||
@findex lang_hooks.gimplify_expr
|
||||
The main entry point to this pass is @code{gimplify_function_tree}
|
||||
located in @file{gimplify.c}. From here we process the entire
|
||||
located in @file{gimplify.c}. From here we process the entire
|
||||
function gimplifying each statement in turn. The main workhorse
|
||||
for this pass is @code{gimplify_expr}. Approximately everything
|
||||
passes through here at least once, and it is from here that we
|
||||
|
@ -135,7 +135,7 @@ The callback should examine the expression in question and return
|
|||
@code{GS_UNHANDLED} if the expression is not a language specific
|
||||
construct that requires attention. Otherwise it should alter the
|
||||
expression in some way to such that forward progress is made toward
|
||||
producing valid GIMPLE. If the callback is certain that the
|
||||
producing valid GIMPLE. If the callback is certain that the
|
||||
transformation is complete and the expression is valid GIMPLE, it
|
||||
should return @code{GS_ALL_DONE}. Otherwise it should return
|
||||
@code{GS_OK}, which will cause the expression to be processed again.
|
||||
|
@ -152,7 +152,7 @@ and take care of standard bookkeeping that applies to every pass.
|
|||
|
||||
The theory of operation is that each pass defines a structure that
|
||||
represents everything we need to know about that pass---when it
|
||||
should be run, how it should be run, what intermediate language
|
||||
should be run, how it should be run, what intermediate language
|
||||
form or on-the-side data structures it needs. We register the pass
|
||||
to be run in some particular order, and the pass manager arranges
|
||||
for everything to happen in the correct order.
|
||||
|
@ -203,13 +203,13 @@ by @code{pass_mudflap_1}.
|
|||
|
||||
@item Lower control flow
|
||||
|
||||
This pass flattens @code{if} statements (@code{COND_EXPR}) and
|
||||
This pass flattens @code{if} statements (@code{COND_EXPR}) and
|
||||
and moves lexical bindings (@code{BIND_EXPR}) out of line. After
|
||||
this pass, all @code{if} statements will have exactly two @code{goto}
|
||||
statements in its @code{then} and @code{else} arms. Lexical binding
|
||||
information for each statement will be found in @code{TREE_BLOCK} rather
|
||||
than being inferred from its position under a @code{BIND_EXPR}. This
|
||||
pass is found in @file{gimple-low.c} and is described by
|
||||
pass is found in @file{gimple-low.c} and is described by
|
||||
@code{pass_lower_cf}.
|
||||
|
||||
@item Lower exception handling control flow
|
||||
|
@ -233,7 +233,7 @@ is described by @code{pass_build_cfg}.
|
|||
|
||||
@item Find all referenced variables
|
||||
|
||||
This pass walks the entire function and collects an array of all
|
||||
This pass walks the entire function and collects an array of all
|
||||
variables referenced in the function, @code{referenced_vars}. The
|
||||
index at which a variable is found in the array is used as a UID
|
||||
for the variable within this function. This data is needed by the
|
||||
|
@ -244,8 +244,8 @@ and is described by @code{pass_referenced_vars}.
|
|||
|
||||
This pass rewrites the function such that it is in SSA form. After
|
||||
this pass, all @code{is_gimple_reg} variables will be referenced by
|
||||
@code{SSA_NAME}, and all occurrences of other variables will be
|
||||
annotated with @code{VDEFS} and @code{VUSES}; phi nodes will have
|
||||
@code{SSA_NAME}, and all occurrences of other variables will be
|
||||
annotated with @code{VDEFS} and @code{VUSES}; phi nodes will have
|
||||
been inserted as necessary for each basic block. This pass is
|
||||
located in @file{tree-ssa.c} and is described by @code{pass_build_ssa}.
|
||||
|
||||
|
@ -287,23 +287,23 @@ described by @code{pass_redundant_phi}.o
|
|||
|
||||
This pass attempts to remove redundant computation by substituting
|
||||
variables that are used once into the expression that uses them and
|
||||
seeing if the result can be simplified. It is located in
|
||||
seeing if the result can be simplified. It is located in
|
||||
@file{tree-ssa-forwprop.c} and is described by @code{pass_forwprop}.
|
||||
|
||||
@item Copy Renaming
|
||||
|
||||
This pass attempts to change the name of compiler temporaries involved in
|
||||
This pass attempts to change the name of compiler temporaries involved in
|
||||
copy operations such that SSA->normal can coalesce the copy away. When compiler
|
||||
temporaries are copies of user variables, it also renames the compiler
|
||||
temporary to the user variable resulting in better use of user symbols. It is
|
||||
located in @file{tree-ssa-copyrename.c} and is described by
|
||||
temporary to the user variable resulting in better use of user symbols. It is
|
||||
located in @file{tree-ssa-copyrename.c} and is described by
|
||||
@code{pass_copyrename}.
|
||||
|
||||
@item PHI node optimizations
|
||||
|
||||
This pass recognizes forms of phi inputs that can be represented as
|
||||
conditional expressions and rewrites them into straight line code.
|
||||
It is located in @file{tree-ssa-phiopt.c} and is described by
|
||||
It is located in @file{tree-ssa-phiopt.c} and is described by
|
||||
@code{pass_phiopt}.
|
||||
|
||||
@item May-alias optimization
|
||||
|
@ -333,7 +333,7 @@ and is described by @code{pass_lower_complex}.
|
|||
@item Scalar replacement of aggregates
|
||||
|
||||
This pass rewrites suitable non-aliased local aggregate variables into
|
||||
a set of scalar variables. The resulting scalar variables are
|
||||
a set of scalar variables. The resulting scalar variables are
|
||||
rewritten into SSA form, which allows subsequent optimization passes
|
||||
to do a significantly better job with them. The pass is located in
|
||||
@file{tree-sra.c} and is described by @code{pass_sra}.
|
||||
|
@ -410,7 +410,7 @@ by @code{pass_ccp}.
|
|||
|
||||
@item Folding builtin functions
|
||||
|
||||
This pass simplifies builtin functions, as applicable, with constant
|
||||
This pass simplifies builtin functions, as applicable, with constant
|
||||
arguments or with inferrable string lengths. It is located in
|
||||
@file{tree-ssa-ccp.c} and is described by @code{pass_fold_builtins}.
|
||||
|
||||
|
@ -440,7 +440,7 @@ data and control flow problem is solved. The code transformation
|
|||
requires target support, and so is delayed until RTL. In the
|
||||
meantime @code{CALL_EXPR_TAILCALL} is set indicating the possibility.
|
||||
The pass is located in @file{tree-tailcall.c} and is described by
|
||||
@code{pass_tail_calls}. The RTL transformation is handled by
|
||||
@code{pass_tail_calls}. The RTL transformation is handled by
|
||||
@code{fixup_tail_calls} in @file{calls.c}.
|
||||
|
||||
@item Warn for function return without value
|
||||
|
@ -516,13 +516,13 @@ for this pass is located within @file{except.c}.
|
|||
This pass removes unreachable code, simplifies jumps to next, jumps to
|
||||
jump, jumps across jumps, etc. The pass is run multiple times.
|
||||
For historical reasons, it is occasionally referred to as the ``jump
|
||||
optimization pass''. The bulk of the code for this pass is in
|
||||
optimization pass''. The bulk of the code for this pass is in
|
||||
@file{cfgcleanup.c}, and there are support routines in @file{cfgrtl.c}
|
||||
and @file{jump.c}.
|
||||
|
||||
@item Common subexpression elimination
|
||||
|
||||
This pass removes redundant computation within basic blocks, and
|
||||
This pass removes redundant computation within basic blocks, and
|
||||
optimizes addressing modes based on cost. The pass is run twice.
|
||||
The source is located in @file{cse.c}.
|
||||
|
||||
|
@ -617,12 +617,12 @@ completely target-specific. The source is located in @file{lcm.c}.
|
|||
|
||||
@cindex modulo scheduling
|
||||
@cindex sms, swing, software pipelining
|
||||
@item Modulo scheduling
|
||||
@item Modulo scheduling
|
||||
|
||||
This pass looks at innermost loops and reorders their instructions
|
||||
by overlapping different iterations. Modulo scheduling is performed
|
||||
This pass looks at innermost loops and reorders their instructions
|
||||
by overlapping different iterations. Modulo scheduling is performed
|
||||
immediately before instruction scheduling.
|
||||
The pass is located in (@file{modulo-sched.c}).
|
||||
The pass is located in (@file{modulo-sched.c}).
|
||||
|
||||
@item Instruction scheduling
|
||||
|
||||
|
|
|
@ -1772,7 +1772,7 @@ saturates at the maximum signed value representable in @var{m};
|
|||
This expression represents the sum of @var{x} and the low-order bits
|
||||
of @var{y}. It is used with @code{high} (@pxref{Constants}) to
|
||||
represent the typical two-instruction sequence used in RISC machines
|
||||
to reference a global memory location.
|
||||
to reference a global memory location.
|
||||
|
||||
The number of low order bits is machine-dependent but is
|
||||
normally the number of bits in a @code{Pmode} item minus the number of
|
||||
|
|
|
@ -5024,7 +5024,7 @@ you define this macro, the compiler will use it instead of
|
|||
A C expression which is nonzero if @var{x} (assumed to be a @code{reg} RTX)
|
||||
is suitable for use as a base register in base plus index operand addresses,
|
||||
accessing memory in mode @var{mode}. It may be either a suitable hard
|
||||
register or a pseudo register that has been allocated such a hard register.
|
||||
register or a pseudo register that has been allocated such a hard register.
|
||||
You should define this macro if base plus index addresses have different
|
||||
requirements than other base register uses.
|
||||
@end defmac
|
||||
|
|
|
@ -102,7 +102,7 @@ place of the container.
|
|||
|
||||
The compiler pass which lowers GENERIC to GIMPLE is referred to as the
|
||||
@samp{gimplifier}. The gimplifier works recursively, replacing complex
|
||||
statements with sequences of simple statements.
|
||||
statements with sequences of simple statements.
|
||||
|
||||
@c Currently, the only way to
|
||||
@c tell whether or not an expression is in GIMPLE form is by recursively
|
||||
|
@ -195,7 +195,7 @@ GIMPLE rvalue (@code{is_gimple_val}), i.e.@: a constant or a register
|
|||
variable. More complex operands are factored out into temporaries, so
|
||||
that
|
||||
@smallexample
|
||||
a = b + c + d
|
||||
a = b + c + d
|
||||
@end smallexample
|
||||
becomes
|
||||
@smallexample
|
||||
|
@ -293,7 +293,7 @@ Most statements will be assignment statements, represented by
|
|||
@code{MODIFY_EXPR}. A @code{CALL_EXPR} whose value is ignored can
|
||||
also be a statement. No other C expressions can appear at statement level;
|
||||
a reference to a volatile object is converted into a @code{MODIFY_EXPR}.
|
||||
In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type
|
||||
In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type
|
||||
of LHS or RHS.
|
||||
|
||||
There are also several varieties of complex statements.
|
||||
|
@ -318,7 +318,7 @@ expressed using the @code{BIND_EXPR} code, which in previous versions of
|
|||
GCC was primarily used for the C statement-expression extension.
|
||||
|
||||
Variables in a block are collected into @code{BIND_EXPR_VARS} in
|
||||
declaration order. Any runtime initialization is moved out of
|
||||
declaration order. Any runtime initialization is moved out of
|
||||
@code{DECL_INITIAL} and into a statement in the controlled block. When
|
||||
gimplifying from C or C++, this initialization replaces the
|
||||
@code{DECL_STMT}.
|
||||
|
@ -328,7 +328,7 @@ refers to variables initialized earlier in the block. To handle this, we
|
|||
currently split the block at that point, and move the VLA into a new, inner
|
||||
@code{BIND_EXPR}. This strategy may change in the future.
|
||||
|
||||
@code{DECL_SAVED_TREE} for a GIMPLE function will always be a
|
||||
@code{DECL_SAVED_TREE} for a GIMPLE function will always be a
|
||||
@code{BIND_EXPR} which contains declarations for the temporary variables
|
||||
used in the function.
|
||||
|
||||
|
@ -422,7 +422,7 @@ edge.
|
|||
@cindex GIMPLE Exception Handling
|
||||
|
||||
Other exception handling constructs are represented using
|
||||
@code{TRY_CATCH_EXPR}. The handler operand of a @code{TRY_CATCH_EXPR}
|
||||
@code{TRY_CATCH_EXPR}. The handler operand of a @code{TRY_CATCH_EXPR}
|
||||
can be a normal statement to be executed if the controlled block throws an
|
||||
exception, or it can have one of two special forms:
|
||||
|
||||
|
@ -711,7 +711,7 @@ operands, they are organized into arrays associated inside each
|
|||
statement's annotation. Each element in an operand array is a pointer
|
||||
to a @code{VAR_DECL}, @code{PARM_DECL} or @code{SSA_NAME} tree node.
|
||||
This provides a very convenient way of examining and replacing
|
||||
operands.
|
||||
operands.
|
||||
|
||||
Data flow analysis and optimization is done on all tree nodes
|
||||
representing variables. Any node for which @code{SSA_VAR_P} returns
|
||||
|
@ -755,12 +755,12 @@ In contrast, virtual operands are used with variables that can have
|
|||
a partial or ambiguous reference. This includes structures, arrays,
|
||||
globals, and aliased variables. In these cases, we have two types of
|
||||
definitions. For globals, structures, and arrays, we can determine from
|
||||
a statement whether a variable of these types has a killing definition.
|
||||
a statement whether a variable of these types has a killing definition.
|
||||
If the variable does, then the statement is marked as having a
|
||||
@dfn{must definition} of that variable. However, if a statement is only
|
||||
defining a part of the variable (i.e.@: a field in a structure), or if we
|
||||
know that a statement might define the variable but we cannot say for sure,
|
||||
then we mark that statement as having a @dfn{may definition}. For
|
||||
then we mark that statement as having a @dfn{may definition}. For
|
||||
instance, given
|
||||
|
||||
@smallexample
|
||||
|
@ -814,9 +814,9 @@ incorrect assumptions about them.
|
|||
|
||||
Operands are collected by @file{tree-ssa-operands.c}. They are stored
|
||||
inside each statement's annotation and can be accessed with
|
||||
@code{DEF_OPS}, @code{USE_OPS}, @code{V_MAY_DEF_OPS},
|
||||
@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the
|
||||
accessor macros available to access USE operands. To access all the
|
||||
@code{DEF_OPS}, @code{USE_OPS}, @code{V_MAY_DEF_OPS},
|
||||
@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the
|
||||
accessor macros available to access USE operands. To access all the
|
||||
other operand arrays, just change the name accordingly:
|
||||
|
||||
@defmac USE_OPS (@var{ann})
|
||||
|
@ -858,7 +858,7 @@ print_ops (tree stmt)
|
|||
|
||||
get_stmt_operands (stmt);
|
||||
ann = stmt_ann (stmt);
|
||||
|
||||
|
||||
defs = DEF_OPS (ann);
|
||||
for (i = 0; i < NUM_DEFS (defs); i++)
|
||||
print_generic_expr (stderr, DEF_OP (defs, i), 0);
|
||||
|
@ -866,7 +866,7 @@ print_ops (tree stmt)
|
|||
uses = USE_OPS (ann);
|
||||
for (i = 0; i < NUM_USES (uses); i++)
|
||||
print_generic_expr (stderr, USE_OP (uses, i), 0);
|
||||
|
||||
|
||||
v_may_defs = V_MAY_DEF_OPS (ann);
|
||||
for (i = 0; i < NUM_V_MAY_DEFS (v_may_defs); i++)
|
||||
@{
|
||||
|
@ -877,7 +877,7 @@ print_ops (tree stmt)
|
|||
v_must_defs = V_MUST_DEF_OPS (ann);
|
||||
for (i = 0; i < NUM_V_MUST_DEFS (v_must_defs); i++)
|
||||
print_generic_expr (stderr, V_MUST_DEF_OP (v_must_defs, i), 0);
|
||||
|
||||
|
||||
vuses = VUSE_OPS (ann);
|
||||
for (i = 0; i < NUM_VUSES (vuses); i++)
|
||||
print_generic_expr (stderr, VUSE_OP (vuses, i), 0);
|
||||
|
@ -914,23 +914,23 @@ print_ops (tree stmt)
|
|||
|
||||
@enumerate
|
||||
@item Determine whether you are need to see the operand pointers, or just the
|
||||
trees, and choose the appropriate macro:
|
||||
trees, and choose the appropriate macro:
|
||||
|
||||
@smallexample
|
||||
Need Macro:
|
||||
---- -------
|
||||
use_operand_p FOR_EACH_SSA_USE_OPERAND
|
||||
def_operand_p FOR_EACH_SSA_DEF_OPERAND
|
||||
tree FOR_EACH_SSA_TREE_OPERAND
|
||||
Need Macro:
|
||||
---- -------
|
||||
use_operand_p FOR_EACH_SSA_USE_OPERAND
|
||||
def_operand_p FOR_EACH_SSA_DEF_OPERAND
|
||||
tree FOR_EACH_SSA_TREE_OPERAND
|
||||
@end smallexample
|
||||
|
||||
@item You need to declare a variable of the type you are interested
|
||||
in, and an ssa_op_iter structure which serves as the loop
|
||||
controlling variable.
|
||||
controlling variable.
|
||||
|
||||
@item Determine which operands you wish to use, and specify the flags of
|
||||
those you are interested in. They are documented in
|
||||
@file{tree-ssa-operands.h}:
|
||||
@file{tree-ssa-operands.h}:
|
||||
|
||||
@smallexample
|
||||
#define SSA_OP_USE 0x01 /* Real USE operands. */
|
||||
|
@ -950,22 +950,22 @@ tree FOR_EACH_SSA_TREE_OPERAND
|
|||
@end enumerate
|
||||
|
||||
So if you want to look at the use pointers for all the @code{USE} and
|
||||
@code{VUSE} operands, you would do something like:
|
||||
@code{VUSE} operands, you would do something like:
|
||||
|
||||
@smallexample
|
||||
use_operand_p use_p;
|
||||
ssa_op_iter iter;
|
||||
use_operand_p use_p;
|
||||
ssa_op_iter iter;
|
||||
|
||||
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
|
||||
@{
|
||||
process_use_ptr (use_p);
|
||||
@}
|
||||
@{
|
||||
process_use_ptr (use_p);
|
||||
@}
|
||||
@end smallexample
|
||||
|
||||
The @code{_TREE_} macro is basically the same as the @code{USE} and
|
||||
@code{DEF} macros, only with the use or def dereferenced via
|
||||
@code{USE_FROM_PTR (use_p)} and @code{DEF_FROM_PTR (def_p)}. Since we
|
||||
aren't using operand pointers, use and defs flags can be mixed.
|
||||
aren't using operand pointers, use and defs flags can be mixed.
|
||||
|
||||
@smallexample
|
||||
tree var;
|
||||
|
@ -983,22 +983,22 @@ Note that @code{V_MAY_DEFS} are broken into 2 flags, one for the
|
|||
@code{V_MAY_DEFS} together, there is a fourth iterator macro for this,
|
||||
which returns both a def_operand_p and a use_operand_p for each
|
||||
@code{V_MAY_DEF} in the statement. Note that you don't need any flags for
|
||||
this one.
|
||||
this one.
|
||||
|
||||
@smallexample
|
||||
use_operand_p use_p;
|
||||
def_operand_p def_p;
|
||||
ssa_op_iter iter;
|
||||
use_operand_p use_p;
|
||||
def_operand_p def_p;
|
||||
ssa_op_iter iter;
|
||||
|
||||
FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
|
||||
@{
|
||||
my_code;
|
||||
@}
|
||||
FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
|
||||
@{
|
||||
my_code;
|
||||
@}
|
||||
@end smallexample
|
||||
|
||||
|
||||
There are many examples in the code as well, as well as the
|
||||
documentation in @file{tree-ssa-operands.h}.
|
||||
documentation in @file{tree-ssa-operands.h}.
|
||||
|
||||
|
||||
@node SSA
|
||||
|
@ -1127,7 +1127,7 @@ Calls function @var{fn} at each reaching definition found. Function
|
|||
(@var{def_stmt}) and a generic pointer to whatever state information
|
||||
that @var{fn} may want to maintain (@var{data}). Function @var{fn} is
|
||||
able to stop the walk by returning @code{true}, otherwise in order to
|
||||
continue the walk, @var{fn} should return @code{false}.
|
||||
continue the walk, @var{fn} should return @code{false}.
|
||||
|
||||
Note, that if @var{def_stmt} is a @code{PHI} node, the semantics are
|
||||
slightly different. For each argument @var{arg} of the PHI node, this
|
||||
|
|
Loading…
Reference in New Issue