OSDN Git Service

* doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi,
[pf3gnuchains/gcc-fork.git] / gcc / doc / passes.texi
index 2d3396a..f3714cb 100644 (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