diff options
| -rw-r--r-- | gcc/ChangeLog | 7 | ||||
| -rw-r--r-- | gcc/doc/c-tree.texi | 2 | ||||
| -rw-r--r-- | gcc/doc/cfg.texi | 4 | ||||
| -rw-r--r-- | gcc/doc/extend.texi | 12 | ||||
| -rw-r--r-- | gcc/doc/gty.texi | 2 | ||||
| -rw-r--r-- | gcc/doc/install.texi | 4 | ||||
| -rw-r--r-- | gcc/doc/invoke.texi | 42 | ||||
| -rw-r--r-- | gcc/doc/md.texi | 2 | ||||
| -rw-r--r-- | gcc/doc/passes.texi | 62 | ||||
| -rw-r--r-- | gcc/doc/rtl.texi | 2 | ||||
| -rw-r--r-- | gcc/doc/tm.texi | 2 | ||||
| -rw-r--r-- | gcc/doc/tree-ssa.texi | 82 |
12 files changed, 115 insertions, 108 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 239dceccacf..45169122ee4 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -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. diff --git a/gcc/doc/c-tree.texi b/gcc/doc/c-tree.texi index ac143f12cb6..9cd582e05b8 100644 --- a/gcc/doc/c-tree.texi +++ b/gcc/doc/c-tree.texi @@ -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 diff --git a/gcc/doc/cfg.texi b/gcc/doc/cfg.texi index 2b3aec61630..d83e992e320 100644 --- a/gcc/doc/cfg.texi +++ b/gcc/doc/cfg.texi @@ -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 diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 0e5e970e398..8f383b220e4 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -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: diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi index dafad02fa49..cf4bde76d73 100644 --- a/gcc/doc/gty.texi +++ b/gcc/doc/gty.texi @@ -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. diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index acd480544fa..ff013a7fe8b 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -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 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 15e7316276d..b5074f9c78e 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -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 diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 5b5b03ecf01..e01bd317ef7 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -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 diff --git a/gcc/doc/passes.texi b/gcc/doc/passes.texi index 2d3396a2732..f3714cb230c 100644 --- a/gcc/doc/passes.texi +++ b/gcc/doc/passes.texi @@ -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 diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi index 3a72c167341..84a23408e65 100644 --- a/gcc/doc/rtl.texi +++ b/gcc/doc/rtl.texi @@ -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 diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index fd51833acd3..ae7599be854 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -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 diff --git a/gcc/doc/tree-ssa.texi b/gcc/doc/tree-ssa.texi index b5b9ad926a4..68c4f56e0a0 100644 --- a/gcc/doc/tree-ssa.texi +++ b/gcc/doc/tree-ssa.texi @@ -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; - - 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 @@ -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 |