+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.
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
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;
@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
@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();
@}
int result;
asm ("magic stuff accessing an 'int' pointed to by '%1'"
"=&d" (r) : "a" (y), "m" (*y));
- return result;
+ return result;
@}
@end smallexample
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:
@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.
@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
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
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}).
@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
@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
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
@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
@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
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
@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
@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}.
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
@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
@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
@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.
@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
@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,
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
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}.
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
@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.
@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
@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.
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.
@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
@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
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}.
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
@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}.
@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}.
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
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}.
@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
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
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
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
variable. More complex operands are factored out into temporaries, so
that
@smallexample
- a = b + c + d
+ a = b + c + d
@end smallexample
becomes
@smallexample
@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.
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}.
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.
@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:
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
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
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})
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);
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++)
@{
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);
@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. */
@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;
@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;
-
- FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
- @{
- my_code;
- @}
+ 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;
+ @}
@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
(@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
projects / thirdparty / gcc.git / commitdiff
