989 lines
43 KiB
Plaintext
989 lines
43 KiB
Plaintext
@c markers: BUG TODO
|
|
|
|
@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
|
|
@c This is part of the GCC manual.
|
|
@c For copying conditions, see the file gcc.texi.
|
|
|
|
@node Passes
|
|
@chapter Passes and Files of the Compiler
|
|
@cindex passes and files of the compiler
|
|
@cindex files and passes of the compiler
|
|
@cindex compiler passes and files
|
|
@cindex pass dumps
|
|
|
|
This chapter is dedicated to giving an overview of the optimization and
|
|
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.
|
|
|
|
@menu
|
|
* Parsing pass:: The language front end turns text into bits.
|
|
* Cilk Plus Transformation:: Transform Cilk Plus Code to equivalent C/C++.
|
|
* Gimplification pass:: The bits are turned into something we can optimize.
|
|
* Pass manager:: Sequencing the optimization passes.
|
|
* Tree SSA passes:: Optimizations on a high-level representation.
|
|
* RTL passes:: Optimizations on a low-level representation.
|
|
* Optimization info:: Dumping optimization information from passes.
|
|
@end menu
|
|
|
|
@node Parsing pass
|
|
@section Parsing pass
|
|
@cindex GENERIC
|
|
@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
|
|
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.
|
|
|
|
@cindex GIMPLE
|
|
@cindex gimplification
|
|
@cindex gimplifier
|
|
@cindex language-independent intermediate 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
|
|
portions of the compiler. Current practice takes one of two forms.
|
|
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 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)
|
|
can be made to match up with the source language and necessary parsing
|
|
data structures.
|
|
|
|
BUG: Gimplification must occur before nested function lowering,
|
|
and nested function lowering must be done by the front end before
|
|
passing the data off to cgraph.
|
|
|
|
TODO: Cgraph should control nested function lowering. It would
|
|
only be invoked when it is certain that the outer-most function
|
|
is used.
|
|
|
|
TODO: Cgraph needs a gimplify_function callback. It should be
|
|
invoked when (1) it is certain that the function is used, (2)
|
|
warning flags specified by the user require some amount of
|
|
compilation in order to honor, (3) the language indicates that
|
|
semantic analysis is not complete until gimplification occurs.
|
|
Hum@dots{} 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
|
|
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
|
|
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
|
|
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
|
|
@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}.
|
|
|
|
TODO: I know rest_of_compilation currently has all sorts of
|
|
RTL generation semantics. I plan to move all code generation
|
|
bits (both Tree and RTL) to compile_function. Should we hide
|
|
cgraph from the front ends and move back to rest_of_compilation
|
|
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
|
|
definitions immediately or queue them for later processing.
|
|
|
|
@node Cilk Plus Transformation
|
|
@section Cilk Plus Transformation
|
|
@cindex CILK_PLUS
|
|
|
|
If Cilk Plus generation (flag @option{-fcilkplus}) is enabled, all the Cilk
|
|
Plus code is transformed into equivalent C and C++ functions. Majority of this
|
|
transformation occurs toward the end of the parsing and right before the
|
|
gimplification pass.
|
|
|
|
These are the major components to the Cilk Plus language extension:
|
|
@itemize @bullet
|
|
@item Array Notations:
|
|
During parsing phase, all the array notation specific information is stored in
|
|
@code{ARRAY_NOTATION_REF} tree using the function
|
|
@code{c_parser_array_notation}. During the end of parsing, we check the entire
|
|
function to see if there are any array notation specific code (using the
|
|
function @code{contains_array_notation_expr}). If this function returns
|
|
true, then we expand them using either @code{expand_array_notation_exprs} or
|
|
@code{build_array_notation_expr}. For the cases where array notations are
|
|
inside conditions, they are transformed using the function
|
|
@code{fix_conditional_array_notations}. The C language-specific routines are
|
|
located in @file{c/c-array-notation.c} and the equivalent C++ routines are in
|
|
the file @file{cp/cp-array-notation.c}. Common routines such as functions to
|
|
initialize built-in functions are stored in @file{array-notation-common.c}.
|
|
|
|
@item Cilk keywords:
|
|
@itemize @bullet
|
|
@item @code{_Cilk_spawn}:
|
|
The @code{_Cilk_spawn} keyword is parsed and the function it contains is marked
|
|
as a spawning function. The spawning function is called the spawner. At
|
|
the end of the parsing phase, appropriate built-in functions are
|
|
added to the spawner that are defined in the Cilk runtime. The appropriate
|
|
locations of these functions, and the internal structures are detailed in
|
|
@code{cilk_init_builtins} in the file @file{cilk-common.c}. The pointers to
|
|
Cilk functions and fields of internal structures are described
|
|
in @file{cilk.h}. The built-in functions are described in
|
|
@file{cilk-builtins.def}.
|
|
|
|
During gimplification, a new "spawn-helper" function is created.
|
|
The spawned function is replaced with a spawn helper function in the spawner.
|
|
The spawned function-call is moved into the spawn helper. The main function
|
|
that does these transformations is @code{gimplify_cilk_spawn} in
|
|
@file{c-family/cilk.c}. In the spawn-helper, the gimplification function
|
|
@code{gimplify_call_expr}, inserts a function call @code{__cilkrts_detach}.
|
|
This function is expanded by @code{builtin_expand_cilk_detach} located in
|
|
@file{c-family/cilk.c}.
|
|
|
|
@item @code{_Cilk_sync}:
|
|
@code{_Cilk_sync} is parsed like a keyword. During gimplification,
|
|
the function @code{gimplify_cilk_sync} in @file{c-family/cilk.c}, will replace
|
|
this keyword with a set of functions that are stored in the Cilk runtime.
|
|
One of the internal functions inserted during gimplification,
|
|
@code{__cilkrts_pop_frame} must be expanded by the compiler and is
|
|
done by @code{builtin_expand_cilk_pop_frame} in @file{cilk-common.c}.
|
|
|
|
@end itemize
|
|
@end itemize
|
|
|
|
Documentation about Cilk Plus and language specification is provided under the
|
|
"Learn" section in @w{@uref{http://www.cilkplus.org/}}. It is worth mentioning
|
|
that the current implementation follows ABI 1.1.
|
|
|
|
@node Gimplification pass
|
|
@section Gimplification pass
|
|
|
|
@cindex gimplification
|
|
@cindex GIMPLE
|
|
@dfn{Gimplification} is a whimsical term for the process of converting
|
|
the intermediate representation of a function into the GIMPLE language
|
|
(@pxref{GIMPLE}). The term stuck, and so words like ``gimplification'',
|
|
``gimplify'', ``gimplifier'' and the like are sprinkled throughout this
|
|
section of code.
|
|
|
|
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.
|
|
Usually it is easier to generate GENERIC trees plus extensions
|
|
and let the language-independent gimplifier do most of the work.
|
|
|
|
@findex gimplify_function_tree
|
|
@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
|
|
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
|
|
invoke the @code{lang_hooks.gimplify_expr} callback.
|
|
|
|
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
|
|
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.
|
|
If the callback encounters an error during the transformation (because
|
|
the front end is relying on the gimplification process to finish
|
|
semantic checks), it should return @code{GS_ERROR}.
|
|
|
|
@node Pass manager
|
|
@section Pass manager
|
|
|
|
The pass manager is located in @file{passes.c}, @file{tree-optimize.c}
|
|
and @file{tree-pass.h}.
|
|
It processes passes as described in @file{passes.def}.
|
|
Its job is to run all of the individual passes in the correct order,
|
|
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
|
|
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.
|
|
|
|
The actuality doesn't completely live up to the theory at present.
|
|
Command-line switches and @code{timevar_id_t} enumerations must still
|
|
be defined elsewhere. The pass manager validates constraints but does
|
|
not attempt to (re-)generate data structures or lower intermediate
|
|
language form based on the requirements of the next pass. Nevertheless,
|
|
what is present is useful, and a far sight better than nothing at all.
|
|
|
|
Each pass should have a unique name.
|
|
Each pass may have its own dump file (for GCC debugging purposes).
|
|
Passes with a name starting with a star do not dump anything.
|
|
Sometimes passes are supposed to share a dump file / option name.
|
|
To still give these unique names, you can use a prefix that is delimited
|
|
by a space from the part that is used for the dump file / option name.
|
|
E.g. When the pass name is "ud dce", the name used for dump file/options
|
|
is "dce".
|
|
|
|
TODO: describe the global variables set up by the pass manager,
|
|
and a brief description of how a new pass should use it.
|
|
I need to look at what info RTL passes use first@enddots{}
|
|
|
|
@node Tree SSA passes
|
|
@section Tree SSA passes
|
|
|
|
The following briefly describes the Tree optimization passes that are
|
|
run after gimplification and what source files they are located in.
|
|
|
|
@itemize @bullet
|
|
@item Remove useless statements
|
|
|
|
This pass is an extremely simple sweep across the gimple code in which
|
|
we identify obviously dead code and remove it. Here we do things like
|
|
simplify @code{if} statements with constant conditions, remove
|
|
exception handling constructs surrounding code that obviously cannot
|
|
throw, remove lexical bindings that contain no variables, and other
|
|
assorted simplistic cleanups. The idea is to get rid of the obvious
|
|
stuff quickly rather than wait until later when it's more work to get
|
|
rid of it. This pass is located in @file{tree-cfg.c} and described by
|
|
@code{pass_remove_useless_stmts}.
|
|
|
|
@item OpenMP lowering
|
|
|
|
If OpenMP generation (@option{-fopenmp}) is enabled, this pass lowers
|
|
OpenMP constructs into GIMPLE.
|
|
|
|
Lowering of OpenMP constructs involves creating replacement
|
|
expressions for local variables that have been mapped using data
|
|
sharing clauses, exposing the control flow of most synchronization
|
|
directives and adding region markers to facilitate the creation of the
|
|
control flow graph. The pass is located in @file{omp-low.c} and is
|
|
described by @code{pass_lower_omp}.
|
|
|
|
@item OpenMP expansion
|
|
|
|
If OpenMP generation (@option{-fopenmp}) is enabled, this pass expands
|
|
parallel regions into their own functions to be invoked by the thread
|
|
library. The pass is located in @file{omp-low.c} and is described by
|
|
@code{pass_expand_omp}.
|
|
|
|
@item Lower control flow
|
|
|
|
This pass flattens @code{if} statements (@code{COND_EXPR})
|
|
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
|
|
@code{pass_lower_cf}.
|
|
|
|
@item Lower exception handling control flow
|
|
|
|
This pass decomposes high-level exception handling constructs
|
|
(@code{TRY_FINALLY_EXPR} and @code{TRY_CATCH_EXPR}) into a form
|
|
that explicitly represents the control flow involved. After this
|
|
pass, @code{lookup_stmt_eh_region} will return a non-negative
|
|
number for any statement that may have EH control flow semantics;
|
|
examine @code{tree_can_throw_internal} or @code{tree_can_throw_external}
|
|
for exact semantics. Exact control flow may be extracted from
|
|
@code{foreach_reachable_handler}. The EH region nesting tree is defined
|
|
in @file{except.h} and built in @file{except.c}. The lowering pass
|
|
itself is in @file{tree-eh.c} and is described by @code{pass_lower_eh}.
|
|
|
|
@item Build the control flow graph
|
|
|
|
This pass decomposes a function into basic blocks and creates all of
|
|
the edges that connect them. It is located in @file{tree-cfg.c} and
|
|
is described by @code{pass_build_cfg}.
|
|
|
|
@item Find all referenced variables
|
|
|
|
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
|
|
SSA rewriting routines. The pass is located in @file{tree-dfa.c}
|
|
and is described by @code{pass_referenced_vars}.
|
|
|
|
@item Enter static single assignment form
|
|
|
|
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
|
|
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}.
|
|
|
|
@item Warn for uninitialized variables
|
|
|
|
This pass scans the function for uses of @code{SSA_NAME}s that
|
|
are fed by default definition. For non-parameter variables, such
|
|
uses are uninitialized. The pass is run twice, before and after
|
|
optimization (if turned on). In the first pass we only warn for uses that are
|
|
positively uninitialized; in the second pass we warn for uses that
|
|
are possibly uninitialized. The pass is located in @file{tree-ssa.c}
|
|
and is defined by @code{pass_early_warn_uninitialized} and
|
|
@code{pass_late_warn_uninitialized}.
|
|
|
|
@item Dead code elimination
|
|
|
|
This pass scans the function for statements without side effects whose
|
|
result is unused. It does not do memory life analysis, so any value
|
|
that is stored in memory is considered used. The pass is run multiple
|
|
times throughout the optimization process. It is located in
|
|
@file{tree-ssa-dce.c} and is described by @code{pass_dce}.
|
|
|
|
@item Dominator optimizations
|
|
|
|
This pass performs trivial dominator-based copy and constant propagation,
|
|
expression simplification, and jump threading. It is run multiple times
|
|
throughout the optimization process. It is located in @file{tree-ssa-dom.c}
|
|
and is described by @code{pass_dominator}.
|
|
|
|
@item Forward propagation of single-use variables
|
|
|
|
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
|
|
@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
|
|
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
|
|
@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
|
|
@code{pass_phiopt}.
|
|
|
|
@item May-alias optimization
|
|
|
|
This pass performs a flow sensitive SSA-based points-to analysis.
|
|
The resulting may-alias, must-alias, and escape analysis information
|
|
is used to promote variables from in-memory addressable objects to
|
|
non-aliased variables that can be renamed into SSA form. We also
|
|
update the @code{VDEF}/@code{VUSE} memory tags for non-renameable
|
|
aggregates so that we get fewer false kills. The pass is located
|
|
in @file{tree-ssa-alias.c} and is described by @code{pass_may_alias}.
|
|
|
|
Interprocedural points-to information is located in
|
|
@file{tree-ssa-structalias.c} and described by @code{pass_ipa_pta}.
|
|
|
|
@item Profiling
|
|
|
|
This pass instruments the function in order to collect runtime block
|
|
and value profiling data. Such data may be fed back into the compiler
|
|
on a subsequent run so as to allow optimization based on expected
|
|
execution frequencies. The pass is located in @file{tree-profile.c} and
|
|
is described by @code{pass_ipa_tree_profile}.
|
|
|
|
@item Static profile estimation
|
|
|
|
This pass implements series of heuristics to guess propababilities
|
|
of branches. The resulting predictions are turned into edge profile
|
|
by propagating branches across the control flow graphs.
|
|
The pass is located in @file{tree-profile.c} and is described by
|
|
@code{pass_profile}.
|
|
|
|
@item Lower complex arithmetic
|
|
|
|
This pass rewrites complex arithmetic operations into their component
|
|
scalar arithmetic operations. The pass is located in @file{tree-complex.c}
|
|
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
|
|
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 Dead store elimination
|
|
|
|
This pass eliminates stores to memory that are subsequently overwritten
|
|
by another store, without any intervening loads. The pass is located
|
|
in @file{tree-ssa-dse.c} and is described by @code{pass_dse}.
|
|
|
|
@item Tail recursion elimination
|
|
|
|
This pass transforms tail recursion into a loop. It is located in
|
|
@file{tree-tailcall.c} and is described by @code{pass_tail_recursion}.
|
|
|
|
@item Forward store motion
|
|
|
|
This pass sinks stores and assignments down the flowgraph closer to their
|
|
use point. The pass is located in @file{tree-ssa-sink.c} and is
|
|
described by @code{pass_sink_code}.
|
|
|
|
@item Partial redundancy elimination
|
|
|
|
This pass eliminates partially redundant computations, as well as
|
|
performing load motion. The pass is located in @file{tree-ssa-pre.c}
|
|
and is described by @code{pass_pre}.
|
|
|
|
Just before partial redundancy elimination, if
|
|
@option{-funsafe-math-optimizations} is on, GCC tries to convert
|
|
divisions to multiplications by the reciprocal. The pass is located
|
|
in @file{tree-ssa-math-opts.c} and is described by
|
|
@code{pass_cse_reciprocal}.
|
|
|
|
@item Full redundancy elimination
|
|
|
|
This is a simpler form of PRE that only eliminates redundancies that
|
|
occur on all paths. It is located in @file{tree-ssa-pre.c} and
|
|
described by @code{pass_fre}.
|
|
|
|
@item Loop optimization
|
|
|
|
The main driver of the pass is placed in @file{tree-ssa-loop.c}
|
|
and described by @code{pass_loop}.
|
|
|
|
The optimizations performed by this pass are:
|
|
|
|
Loop invariant motion. This pass moves only invariants that
|
|
would be hard to handle on RTL level (function calls, operations that expand to
|
|
nontrivial sequences of insns). With @option{-funswitch-loops} it also moves
|
|
operands of conditions that are invariant out of the loop, so that we can use
|
|
just trivial invariantness analysis in loop unswitching. The pass also includes
|
|
store motion. The pass is implemented in @file{tree-ssa-loop-im.c}.
|
|
|
|
Canonical induction variable creation. This pass creates a simple counter
|
|
for number of iterations of the loop and replaces the exit condition of the
|
|
loop using it, in case when a complicated analysis is necessary to determine
|
|
the number of iterations. Later optimizations then may determine the number
|
|
easily. The pass is implemented in @file{tree-ssa-loop-ivcanon.c}.
|
|
|
|
Induction variable optimizations. This pass performs standard induction
|
|
variable optimizations, including strength reduction, induction variable
|
|
merging and induction variable elimination. The pass is implemented in
|
|
@file{tree-ssa-loop-ivopts.c}.
|
|
|
|
Loop unswitching. This pass moves the conditional jumps that are invariant
|
|
out of the loops. To achieve this, a duplicate of the loop is created for
|
|
each possible outcome of conditional jump(s). The pass is implemented in
|
|
@file{tree-ssa-loop-unswitch.c}.
|
|
|
|
The optimizations also use various utility functions contained in
|
|
@file{tree-ssa-loop-manip.c}, @file{cfgloop.c}, @file{cfgloopanal.c} and
|
|
@file{cfgloopmanip.c}.
|
|
|
|
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
|
|
conceptually unrolled by a factor @code{VF} (vectorization factor), which is
|
|
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
|
|
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
|
|
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-data-refs.c}.
|
|
|
|
Autoparallelization. This pass splits the loop iteration space to run
|
|
into several threads. The pass is implemented in @file{tree-parloops.c}.
|
|
|
|
Graphite is a loop transformation framework based on the polyhedral
|
|
model. Graphite stands for Gimple Represented as Polyhedra. The
|
|
internals of this infrastructure are documented in
|
|
@w{@uref{http://gcc.gnu.org/wiki/Graphite}}. The passes working on
|
|
this representation are implemented in the various @file{graphite-*}
|
|
files.
|
|
|
|
@item Tree level if-conversion for vectorizer
|
|
|
|
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 pass is located in
|
|
@file{tree-if-conv.c} and is described by @code{pass_if_conversion}.
|
|
|
|
@item Conditional constant propagation
|
|
|
|
This pass relaxes a lattice of values in order to identify those
|
|
that must be constant even in the presence of conditional branches.
|
|
The pass is located in @file{tree-ssa-ccp.c} and is described
|
|
by @code{pass_ccp}.
|
|
|
|
A related pass that works on memory loads and stores, and not just
|
|
register values, is located in @file{tree-ssa-ccp.c} and described by
|
|
@code{pass_store_ccp}.
|
|
|
|
@item Conditional copy propagation
|
|
|
|
This is similar to constant propagation but the lattice of values is
|
|
the ``copy-of'' relation. It eliminates redundant copies from the
|
|
code. The pass is located in @file{tree-ssa-copy.c} and described by
|
|
@code{pass_copy_prop}.
|
|
|
|
A related pass that works on memory copies, and not just register
|
|
copies, is located in @file{tree-ssa-copy.c} and described by
|
|
@code{pass_store_copy_prop}.
|
|
|
|
@item Value range propagation
|
|
|
|
This transformation is similar to constant propagation but
|
|
instead of propagating single constant values, it propagates
|
|
known value ranges. The implementation is based on Patterson's
|
|
range propagation algorithm (Accurate Static Branch Prediction by
|
|
Value Range Propagation, J. R. C. Patterson, PLDI '95). In
|
|
contrast to Patterson's algorithm, this implementation does not
|
|
propagate branch probabilities nor it uses more than a single
|
|
range per SSA name. This means that the current implementation
|
|
cannot be used for branch prediction (though adapting it would
|
|
not be difficult). The pass is located in @file{tree-vrp.c} and is
|
|
described by @code{pass_vrp}.
|
|
|
|
@item Folding built-in functions
|
|
|
|
This pass simplifies built-in functions, as applicable, with constant
|
|
arguments or with inferable string lengths. It is located in
|
|
@file{tree-ssa-ccp.c} and is described by @code{pass_fold_builtins}.
|
|
|
|
@item Split critical edges
|
|
|
|
This pass identifies critical edges and inserts empty basic blocks
|
|
such that the edge is no longer critical. The pass is located in
|
|
@file{tree-cfg.c} and is described by @code{pass_split_crit_edges}.
|
|
|
|
@item Control dependence dead code elimination
|
|
|
|
This pass is a stronger form of dead code elimination that can
|
|
eliminate unnecessary control flow statements. It is located
|
|
in @file{tree-ssa-dce.c} and is described by @code{pass_cd_dce}.
|
|
|
|
@item Tail call elimination
|
|
|
|
This pass identifies function calls that may be rewritten into
|
|
jumps. No code transformation is actually applied here, but the
|
|
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{fixup_tail_calls} in @file{calls.c}.
|
|
|
|
@item Warn for function return without value
|
|
|
|
For non-void functions, this pass locates return statements that do
|
|
not specify a value and issues a warning. Such a statement may have
|
|
been injected by falling off the end of the function. This pass is
|
|
run last so that we have as much time as possible to prove that the
|
|
statement is not reachable. It is located in @file{tree-cfg.c} and
|
|
is described by @code{pass_warn_function_return}.
|
|
|
|
@item Leave static single assignment form
|
|
|
|
This pass rewrites the function such that it is in normal form. At
|
|
the same time, we eliminate as many single-use temporaries as possible,
|
|
so the intermediate language is no longer GIMPLE, but GENERIC@. The
|
|
pass is located in @file{tree-outof-ssa.c} and is described by
|
|
@code{pass_del_ssa}.
|
|
|
|
@item Merge PHI nodes that feed into one another
|
|
|
|
This is part of the CFG cleanup passes. It attempts to join PHI nodes
|
|
from a forwarder CFG block into another block with PHI nodes. The
|
|
pass is located in @file{tree-cfgcleanup.c} and is described by
|
|
@code{pass_merge_phi}.
|
|
|
|
@item Return value optimization
|
|
|
|
If a function always returns the same local variable, and that local
|
|
variable is an aggregate type, then the variable is replaced with the
|
|
return value for the function (i.e., the function's DECL_RESULT). This
|
|
is equivalent to the C++ named return value optimization applied to
|
|
GIMPLE@. The pass is located in @file{tree-nrv.c} and is described by
|
|
@code{pass_nrv}.
|
|
|
|
@item Return slot optimization
|
|
|
|
If a function returns a memory object and is called as @code{var =
|
|
foo()}, this pass tries to change the call so that the address of
|
|
@code{var} is sent to the caller to avoid an extra memory copy. This
|
|
pass is located in @code{tree-nrv.c} and is described by
|
|
@code{pass_return_slot}.
|
|
|
|
@item Optimize calls to @code{__builtin_object_size}
|
|
|
|
This is a propagation pass similar to CCP that tries to remove calls
|
|
to @code{__builtin_object_size} when the size of the object can be
|
|
computed at compile-time. This pass is located in
|
|
@file{tree-object-size.c} and is described by
|
|
@code{pass_object_sizes}.
|
|
|
|
@item Loop invariant motion
|
|
|
|
This pass removes expensive loop-invariant computations out of loops.
|
|
The pass is located in @file{tree-ssa-loop.c} and described by
|
|
@code{pass_lim}.
|
|
|
|
@item Loop nest optimizations
|
|
|
|
This is a family of loop transformations that works on loop nests. It
|
|
includes loop interchange, scaling, skewing and reversal and they are
|
|
all geared to the optimization of data locality in array traversals
|
|
and the removal of dependencies that hamper optimizations such as loop
|
|
parallelization and vectorization. The pass is located in
|
|
@file{tree-loop-linear.c} and described by
|
|
@code{pass_linear_transform}.
|
|
|
|
@item Removal of empty loops
|
|
|
|
This pass removes loops with no code in them. The pass is located in
|
|
@file{tree-ssa-loop-ivcanon.c} and described by
|
|
@code{pass_empty_loop}.
|
|
|
|
@item Unrolling of small loops
|
|
|
|
This pass completely unrolls loops with few iterations. The pass
|
|
is located in @file{tree-ssa-loop-ivcanon.c} and described by
|
|
@code{pass_complete_unroll}.
|
|
|
|
@item Predictive commoning
|
|
|
|
This pass makes the code reuse the computations from the previous
|
|
iterations of the loops, especially loads and stores to memory.
|
|
It does so by storing the values of these computations to a bank
|
|
of temporary variables that are rotated at the end of loop. To avoid
|
|
the need for this rotation, the loop is then unrolled and the copies
|
|
of the loop body are rewritten to use the appropriate version of
|
|
the temporary variable. This pass is located in @file{tree-predcom.c}
|
|
and described by @code{pass_predcom}.
|
|
|
|
@item Array prefetching
|
|
|
|
This pass issues prefetch instructions for array references inside
|
|
loops. The pass is located in @file{tree-ssa-loop-prefetch.c} and
|
|
described by @code{pass_loop_prefetch}.
|
|
|
|
@item Reassociation
|
|
|
|
This pass rewrites arithmetic expressions to enable optimizations that
|
|
operate on them, like redundancy elimination and vectorization. The
|
|
pass is located in @file{tree-ssa-reassoc.c} and described by
|
|
@code{pass_reassoc}.
|
|
|
|
@item Optimization of @code{stdarg} functions
|
|
|
|
This pass tries to avoid the saving of register arguments into the
|
|
stack on entry to @code{stdarg} functions. If the function doesn't
|
|
use any @code{va_start} macros, no registers need to be saved. If
|
|
@code{va_start} macros are used, the @code{va_list} variables don't
|
|
escape the function, it is only necessary to save registers that will
|
|
be used in @code{va_arg} macros. For instance, if @code{va_arg} is
|
|
only used with integral types in the function, floating point
|
|
registers don't need to be saved. This pass is located in
|
|
@code{tree-stdarg.c} and described by @code{pass_stdarg}.
|
|
|
|
@end itemize
|
|
|
|
@node RTL passes
|
|
@section RTL passes
|
|
|
|
The following briefly describes the RTL generation and optimization
|
|
passes that are run after the Tree optimization passes.
|
|
|
|
@itemize @bullet
|
|
@item RTL generation
|
|
|
|
@c Avoiding overfull is tricky here.
|
|
The source files for RTL generation include
|
|
@file{stmt.c},
|
|
@file{calls.c},
|
|
@file{expr.c},
|
|
@file{explow.c},
|
|
@file{expmed.c},
|
|
@file{function.c},
|
|
@file{optabs.c}
|
|
and @file{emit-rtl.c}.
|
|
Also, the file
|
|
@file{insn-emit.c}, generated from the machine description by the
|
|
program @code{genemit}, is used in this pass. The header file
|
|
@file{expr.h} is used for communication within this pass.
|
|
|
|
@findex genflags
|
|
@findex gencodes
|
|
The header files @file{insn-flags.h} and @file{insn-codes.h},
|
|
generated from the machine description by the programs @code{genflags}
|
|
and @code{gencodes}, tell this pass which standard names are available
|
|
for use and which patterns correspond to them.
|
|
|
|
@item Generation of exception landing pads
|
|
|
|
This pass generates the glue that handles communication between the
|
|
exception handling library routines and the exception handlers within
|
|
the function. Entry points in the function that are invoked by the
|
|
exception handling library are called @dfn{landing pads}. The code
|
|
for this pass is located in @file{except.c}.
|
|
|
|
@item Control flow graph cleanup
|
|
|
|
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
|
|
@file{cfgcleanup.c}, and there are support routines in @file{cfgrtl.c}
|
|
and @file{jump.c}.
|
|
|
|
@item Forward propagation of single-def values
|
|
|
|
This pass attempts to remove redundant computation by substituting
|
|
variables that come from a single definition, and
|
|
seeing if the result can be simplified. It performs copy propagation
|
|
and addressing mode selection. The pass is run twice, with values
|
|
being propagated into loops only on the second run. The code is
|
|
located in @file{fwprop.c}.
|
|
|
|
@item Common subexpression elimination
|
|
|
|
This pass removes redundant computation within basic blocks, and
|
|
optimizes addressing modes based on cost. The pass is run twice.
|
|
The code for this pass is located in @file{cse.c}.
|
|
|
|
@item Global common subexpression elimination
|
|
|
|
This pass performs two
|
|
different types of GCSE depending on whether you are optimizing for
|
|
size or not (LCM based GCSE tends to increase code size for a gain in
|
|
speed, while Morel-Renvoise based GCSE does not).
|
|
When optimizing for size, GCSE is done using Morel-Renvoise Partial
|
|
Redundancy Elimination, with the exception that it does not try to move
|
|
invariants out of loops---that is left to the loop optimization pass.
|
|
If MR PRE GCSE is done, code hoisting (aka unification) is also done, as
|
|
well as load motion.
|
|
If you are optimizing for speed, LCM (lazy code motion) based GCSE is
|
|
done. LCM is based on the work of Knoop, Ruthing, and Steffen. LCM
|
|
based GCSE also does loop invariant code motion. We also perform load
|
|
and store motion when optimizing for speed.
|
|
Regardless of which type of GCSE is used, the GCSE pass also performs
|
|
global constant and copy propagation.
|
|
The source file for this pass is @file{gcse.c}, and the LCM routines
|
|
are in @file{lcm.c}.
|
|
|
|
@item Loop optimization
|
|
|
|
This pass performs several loop related optimizations.
|
|
The source files @file{cfgloopanal.c} and @file{cfgloopmanip.c} contain
|
|
generic loop analysis and manipulation code. Initialization and finalization
|
|
of loop structures is handled by @file{loop-init.c}.
|
|
A loop invariant motion pass is implemented in @file{loop-invariant.c}.
|
|
Basic block level optimizations---unrolling, and peeling loops---
|
|
are implemented in @file{loop-unroll.c}.
|
|
Replacing of the exit condition of loops by special machine-dependent
|
|
instructions is handled by @file{loop-doloop.c}.
|
|
|
|
@item Jump bypassing
|
|
|
|
This pass is an aggressive form of GCSE that transforms the control
|
|
flow graph of a function by propagating constants into conditional
|
|
branch instructions. The source file for this pass is @file{gcse.c}.
|
|
|
|
@item If conversion
|
|
|
|
This pass attempts to replace conditional branches and surrounding
|
|
assignments with arithmetic, boolean value producing comparison
|
|
instructions, and conditional move instructions. In the very last
|
|
invocation after reload/LRA, it will generate predicated instructions
|
|
when supported by the target. The code is located in @file{ifcvt.c}.
|
|
|
|
@item Web construction
|
|
|
|
This pass splits independent uses of each pseudo-register. This can
|
|
improve effect of the other transformation, such as CSE or register
|
|
allocation. The code for this pass is located in @file{web.c}.
|
|
|
|
@item Instruction combination
|
|
|
|
This pass attempts to combine groups of two or three instructions that
|
|
are related by data flow into single instructions. It combines the
|
|
RTL expressions for the instructions by substitution, simplifies the
|
|
result using algebra, and then attempts to match the result against
|
|
the machine description. The code is located in @file{combine.c}.
|
|
|
|
@item Mode switching optimization
|
|
|
|
This pass looks for instructions that require the processor to be in a
|
|
specific ``mode'' and minimizes the number of mode changes required to
|
|
satisfy all users. What these modes are, and what they apply to are
|
|
completely target-specific. The code for this pass is located in
|
|
@file{mode-switching.c}.
|
|
|
|
@cindex modulo scheduling
|
|
@cindex sms, swing, software pipelining
|
|
@item Modulo scheduling
|
|
|
|
This pass looks at innermost loops and reorders their instructions
|
|
by overlapping different iterations. Modulo scheduling is performed
|
|
immediately before instruction scheduling. The code for this pass is
|
|
located in @file{modulo-sched.c}.
|
|
|
|
@item Instruction scheduling
|
|
|
|
This pass looks for instructions whose output will not be available by
|
|
the time that it is used in subsequent instructions. Memory loads and
|
|
floating point instructions often have this behavior on RISC machines.
|
|
It re-orders instructions within a basic block to try to separate the
|
|
definition and use of items that otherwise would cause pipeline
|
|
stalls. This pass is performed twice, before and after register
|
|
allocation. The code for this pass is located in @file{haifa-sched.c},
|
|
@file{sched-deps.c}, @file{sched-ebb.c}, @file{sched-rgn.c} and
|
|
@file{sched-vis.c}.
|
|
|
|
@item Register allocation
|
|
|
|
These passes make sure that all occurrences of pseudo registers are
|
|
eliminated, either by allocating them to a hard register, replacing
|
|
them by an equivalent expression (e.g.@: a constant) or by placing
|
|
them on the stack. This is done in several subpasses:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The integrated register allocator (@acronym{IRA}). It is called
|
|
integrated because coalescing, register live range splitting, and hard
|
|
register preferencing are done on-the-fly during coloring. It also
|
|
has better integration with the reload/LRA pass. Pseudo-registers spilled
|
|
by the allocator or the reload/LRA have still a chance to get
|
|
hard-registers if the reload/LRA evicts some pseudo-registers from
|
|
hard-registers. The allocator helps to choose better pseudos for
|
|
spilling based on their live ranges and to coalesce stack slots
|
|
allocated for the spilled pseudo-registers. IRA is a regional
|
|
register allocator which is transformed into Chaitin-Briggs allocator
|
|
if there is one region. By default, IRA chooses regions using
|
|
register pressure but the user can force it to use one region or
|
|
regions corresponding to all loops.
|
|
|
|
Source files of the allocator are @file{ira.c}, @file{ira-build.c},
|
|
@file{ira-costs.c}, @file{ira-conflicts.c}, @file{ira-color.c},
|
|
@file{ira-emit.c}, @file{ira-lives}, plus header files @file{ira.h}
|
|
and @file{ira-int.h} used for the communication between the allocator
|
|
and the rest of the compiler and between the IRA files.
|
|
|
|
@cindex reloading
|
|
@item
|
|
Reloading. This pass renumbers pseudo registers with the hardware
|
|
registers numbers they were allocated. Pseudo registers that did not
|
|
get hard registers are replaced with stack slots. Then it finds
|
|
instructions that are invalid because a value has failed to end up in
|
|
a register, or has ended up in a register of the wrong kind. It fixes
|
|
up these instructions by reloading the problematical values
|
|
temporarily into registers. Additional instructions are generated to
|
|
do the copying.
|
|
|
|
The reload pass also optionally eliminates the frame pointer and inserts
|
|
instructions to save and restore call-clobbered registers around calls.
|
|
|
|
Source files are @file{reload.c} and @file{reload1.c}, plus the header
|
|
@file{reload.h} used for communication between them.
|
|
|
|
@cindex Local Register Allocator (LRA)
|
|
@item
|
|
This pass is a modern replacement of the reload pass. Source files
|
|
are @file{lra.c}, @file{lra-assign.c}, @file{lra-coalesce.c},
|
|
@file{lra-constraints.c}, @file{lra-eliminations.c},
|
|
@file{lra-lives.c}, @file{lra-remat.c}, @file{lra-spills.c}, the
|
|
header @file{lra-int.h} used for communication between them, and the
|
|
header @file{lra.h} used for communication between LRA and the rest of
|
|
compiler.
|
|
|
|
Unlike the reload pass, intermediate LRA decisions are reflected in
|
|
RTL as much as possible. This reduces the number of target-dependent
|
|
macros and hooks, leaving instruction constraints as the primary
|
|
source of control.
|
|
|
|
LRA is run on targets for which TARGET_LRA_P returns true.
|
|
@end itemize
|
|
|
|
@item Basic block reordering
|
|
|
|
This pass implements profile guided code positioning. If profile
|
|
information is not available, various types of static analysis are
|
|
performed to make the predictions normally coming from the profile
|
|
feedback (IE execution frequency, branch probability, etc). It is
|
|
implemented in the file @file{bb-reorder.c}, and the various
|
|
prediction routines are in @file{predict.c}.
|
|
|
|
@item Variable tracking
|
|
|
|
This pass computes where the variables are stored at each
|
|
position in code and generates notes describing the variable locations
|
|
to RTL code. The location lists are then generated according to these
|
|
notes to debug information if the debugging information format supports
|
|
location lists. The code is located in @file{var-tracking.c}.
|
|
|
|
@item Delayed branch scheduling
|
|
|
|
This optional pass attempts to find instructions that can go into the
|
|
delay slots of other instructions, usually jumps and calls. The code
|
|
for this pass is located in @file{reorg.c}.
|
|
|
|
@item Branch shortening
|
|
|
|
On many RISC machines, branch instructions have a limited range.
|
|
Thus, longer sequences of instructions must be used for long branches.
|
|
In this pass, the compiler figures out what how far each instruction
|
|
will be from each other instruction, and therefore whether the usual
|
|
instructions, or the longer sequences, must be used for each branch.
|
|
The code for this pass is located in @file{final.c}.
|
|
|
|
@item Register-to-stack conversion
|
|
|
|
Conversion from usage of some hard registers to usage of a register
|
|
stack may be done at this point. Currently, this is supported only
|
|
for the floating-point registers of the Intel 80387 coprocessor. The
|
|
code for this pass is located in @file{reg-stack.c}.
|
|
|
|
@item Final
|
|
|
|
This pass outputs the assembler code for the function. The source files
|
|
are @file{final.c} plus @file{insn-output.c}; the latter is generated
|
|
automatically from the machine description by the tool @file{genoutput}.
|
|
The header file @file{conditions.h} is used for communication between
|
|
these files.
|
|
|
|
@item Debugging information output
|
|
|
|
This is run after final because it must output the stack slot offsets
|
|
for pseudo registers that did not get hard registers. Source files
|
|
are @file{dbxout.c} for DBX symbol table format, @file{sdbout.c} for
|
|
SDB symbol table format, @file{dwarfout.c} for DWARF symbol table
|
|
format, files @file{dwarf2out.c} and @file{dwarf2asm.c} for DWARF2
|
|
symbol table format, and @file{vmsdbgout.c} for VMS debug symbol table
|
|
format.
|
|
|
|
@end itemize
|
|
|
|
@node Optimization info
|
|
@section Optimization info
|
|
@include optinfo.texi
|