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:
Joseph Myers 2004-11-05 00:53:49 +00:00 committed by Joseph Myers
parent 04fb56d599
commit f0eb93a806
12 changed files with 114 additions and 107 deletions

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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:

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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