OSDN Git Service

2014-02-26 Fabien Chene <fabien@gcc.gnu.org>
[pf3gnuchains/gcc-fork.git] / gcc / doc / passes.texi
index b109f2d..8329ddd 100644 (file)
@@ -1,8 +1,8 @@
-@c markers: CROSSREF BUG TODO
+@c markers: BUG TODO
 
 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-@c 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software
-@c Foundation, Inc.
+@c 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+@c Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -32,7 +32,7 @@ where near complete.
 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
-appropriate.  The C front end uses GENERIC trees (CROSSREF), plus
+appropriate.  The C front end uses GENERIC trees (@pxref{GENERIC}), plus
 a double handful of language specific tree codes defined in
 @file{c-common.def}.  The Fortran front end uses a completely different
 private representation.
@@ -46,10 +46,9 @@ private representation.
 At some point the front end must translate the representation used in the
 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,
+The C front end manually invokes the gimplifier (@pxref{GIMPLE}) on each function,
 and uses the gimplifier callbacks to convert the language-specific tree
-nodes directly to GIMPLE (CROSSREF) before passing the function off to
-be compiled.
+nodes directly to GIMPLE before passing the function off to be compiled.
 The Fortran front end converts from a private representation to GENERIC,
 which is later lowered to GIMPLE when the function is compiled.  Which
 route to choose probably depends on how well GENERIC (plus extensions)
@@ -111,11 +110,10 @@ definitions immediately or queue them for later processing.
 @cindex GIMPLE
 @dfn{Gimplification} is a whimsical term for the process of converting
 the intermediate representation of a function into the GIMPLE language
-(CROSSREF).  The term stuck, and so words like ``gimplification'',
+(@pxref{GIMPLE}).  The term stuck, and so words like ``gimplification'',
 ``gimplify'', ``gimplifier'' and the like are sprinkled throughout this
 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
 intermediate language used by the front end is already fairly simple.
@@ -395,7 +393,7 @@ in @file{tree-ssa-math-opts.c} and is described by
 @item Full redundancy elimination
 
 This is a simpler form of PRE that only eliminates redundancies that
-occur an all paths.  It is located in @file{tree-ssa-pre.c} and
+occur on all paths.  It is located in @file{tree-ssa-pre.c} and
 described by @code{pass_fre}.
 
 @item Loop optimization
@@ -437,23 +435,23 @@ The optimizations also use various utility functions contained in
 
 Vectorization.  This pass transforms loops to operate on vector types
 instead of scalar types.  Data parallelism across loop iterations is exploited
-to group data elements from consecutive iterations into a vector and operate 
-on them in parallel.  Depending on available target support the loop is 
+to group data elements from consecutive iterations into a vector and operate
+on them in parallel.  Depending on available target support the loop is
 conceptually unrolled by a factor @code{VF} (vectorization factor), which is
-the number of elements operated upon in parallel in each iteration, and the 
+the number of elements operated upon in parallel in each iteration, and the
 @code{VF} copies of each scalar operation are fused to form a vector operation.
 Additional loop transformations such as peeling and versioning may take place
-to align the number of iterations, and to align the memory accesses in the 
+to align the number of iterations, and to align the memory accesses in the
 loop.
 The pass is implemented in @file{tree-vectorizer.c} (the main driver),
-@file{tree-vect-loop.c} and @file{tree-vect-loop-manip.c} (loop specific parts 
-and general loop utilities), @file{tree-vect-slp} (loop-aware SLP 
+@file{tree-vect-loop.c} and @file{tree-vect-loop-manip.c} (loop specific parts
+and general loop utilities), @file{tree-vect-slp} (loop-aware SLP
 functionality), @file{tree-vect-stmts.c} and @file{tree-vect-data-refs.c}.
 Analysis of data references is in @file{tree-data-ref.c}.
 
 SLP Vectorization.  This pass performs vectorization of straight-line code. The
 pass is implemented in @file{tree-vectorizer.c} (the main driver),
-@file{tree-vect-slp.c}, @file{tree-vect-stmts.c} and 
+@file{tree-vect-slp.c}, @file{tree-vect-stmts.c} and
 @file{tree-vect-data-refs.c}.
 
 Autoparallelization.  This pass splits the loop iteration space to run
@@ -472,9 +470,8 @@ This pass applies if-conversion to simple loops to help vectorizer.
 We identify if convertible loops, if-convert statements and merge
 basic blocks in one big block.  The idea is to present loop in such
 form so that vectorizer can have one to one mapping between statements
-and available vector operations.  This patch re-introduces COND_EXPR
-at GIMPLE level.  This pass is located in @file{tree-if-conv.c} and is
-described by @code{pass_if_conversion}.
+and available vector operations.  This pass is located in
+@file{tree-if-conv.c} and is described by @code{pass_if_conversion}.
 
 @item Conditional constant propagation