600 lines
24 KiB
HTML
600 lines
24 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): Passes</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Passes">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Passes">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC148"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_13.html#SEC147" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_13.html#SEC147"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_2.html#SEC2" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 14. Passes and Files of the Compiler </H1>
|
|
<!--docid::SEC148::-->
|
|
<P>
|
|
|
|
<A NAME="IDX441"></A>
|
|
The overall control structure of the compiler is in <TT>`toplev.c'</TT>. This
|
|
file is responsible for initialization, decoding arguments, opening and
|
|
closing files, and sequencing the passes.
|
|
</P><P>
|
|
|
|
<A NAME="IDX442"></A>
|
|
The parsing pass is invoked only once, to parse the entire input. The RTL
|
|
intermediate code for a function is generated as the function is parsed, a
|
|
statement at a time. Each statement is read in as a syntax tree and then
|
|
converted to RTL; then the storage for the tree for the statement is
|
|
reclaimed. Storage for types (and the expressions for their sizes),
|
|
declarations, and a representation of the binding contours and how they nest,
|
|
remain until the function is finished being compiled; these are all needed
|
|
to output the debugging information.
|
|
</P><P>
|
|
|
|
<A NAME="IDX443"></A>
|
|
<A NAME="IDX444"></A>
|
|
Each time the parsing pass reads a complete function definition or
|
|
top-level declaration, it calls either the function
|
|
<CODE>rest_of_compilation</CODE>, or the function
|
|
<CODE>rest_of_decl_compilation</CODE> in <TT>`toplev.c'</TT>, which are
|
|
responsible for all further processing necessary, ending with output of
|
|
the assembler language. All other compiler passes run, in sequence,
|
|
within <CODE>rest_of_compilation</CODE>. When that function returns from
|
|
compiling a function definition, the storage used for that function
|
|
definition's compilation is entirely freed, unless it is an inline
|
|
function
|
|
(see section <A HREF="gcc_4.html#SEC92" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92">An Inline Function is As Fast As a Macro</A>).
|
|
</P><P>
|
|
|
|
Here is a list of all the passes of the compiler and their source files.
|
|
Also included is a description of where debugging dumps can be requested
|
|
with <SAMP>`-d'</SAMP> options.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Parsing. This pass reads the entire text of a function definition,
|
|
constructing partial syntax trees. This and RTL generation are no longer
|
|
truly separate passes (formerly they were), but it is easier to think
|
|
of them as separate.
|
|
<P>
|
|
|
|
The tree representation does not entirely follow C syntax, because it is
|
|
intended to support other languages as well.
|
|
</P><P>
|
|
|
|
Language-specific data type analysis is also done in this pass, and every
|
|
tree node that represents an expression has a data type attached.
|
|
Variables are represented as declaration nodes.
|
|
</P><P>
|
|
|
|
<A NAME="IDX445"></A>
|
|
<A NAME="IDX446"></A>
|
|
<A NAME="IDX447"></A>
|
|
Constant folding and some arithmetic simplifications are also done
|
|
during this pass.
|
|
</P><P>
|
|
|
|
The language-independent source files for parsing are
|
|
<TT>`stor-layout.c'</TT>, <TT>`fold-const.c'</TT>, and <TT>`tree.c'</TT>.
|
|
There are also header files <TT>`tree.h'</TT> and <TT>`tree.def'</TT>
|
|
which define the format of the tree representation.</P><P>
|
|
|
|
The source files to parse C are
|
|
<TT>`c-parse.in'</TT>,
|
|
<TT>`c-decl.c'</TT>,
|
|
<TT>`c-typeck.c'</TT>,
|
|
<TT>`c-aux-info.c'</TT>,
|
|
<TT>`c-convert.c'</TT>,
|
|
and <TT>`c-lang.c'</TT>
|
|
along with header files
|
|
<TT>`c-lex.h'</TT>, and
|
|
<TT>`c-tree.h'</TT>.
|
|
</P><P>
|
|
|
|
The source files for parsing C++ are <TT>`cp-parse.y'</TT>,
|
|
<TT>`cp-class.c'</TT>,<BR>
|
|
<TT>`cp-cvt.c'</TT>, <TT>`cp-decl.c'</TT>, <TT>`cp-decl2.c'</TT>,
|
|
<TT>`cp-dem.c'</TT>, <TT>`cp-except.c'</TT>,<BR>
|
|
<TT>`cp-expr.c'</TT>, <TT>`cp-init.c'</TT>, <TT>`cp-lex.c'</TT>,
|
|
<TT>`cp-method.c'</TT>, <TT>`cp-ptree.c'</TT>,<BR>
|
|
<TT>`cp-search.c'</TT>, <TT>`cp-tree.c'</TT>, <TT>`cp-type2.c'</TT>, and
|
|
<TT>`cp-typeck.c'</TT>, along with header files <TT>`cp-tree.def'</TT>,
|
|
<TT>`cp-tree.h'</TT>, and <TT>`cp-decl.h'</TT>.
|
|
</P><P>
|
|
|
|
The special source files for parsing Objective C are
|
|
<TT>`objc-parse.y'</TT>, <TT>`objc-actions.c'</TT>, <TT>`objc-tree.def'</TT>, and
|
|
<TT>`objc-actions.h'</TT>. Certain C-specific files are used for this as
|
|
well.
|
|
</P><P>
|
|
|
|
The file <TT>`c-common.c'</TT> is also used for all of the above languages.
|
|
</P><P>
|
|
|
|
<A NAME="IDX448"></A>
|
|
<LI>
|
|
RTL generation. This is the conversion of syntax tree into RTL code.
|
|
It is actually done statement-by-statement during parsing, but for
|
|
most purposes it can be thought of as a separate pass.
|
|
<P>
|
|
|
|
<A NAME="IDX449"></A>
|
|
This is where the bulk of target-parameter-dependent code is found,
|
|
since often it is necessary for strategies to apply only when certain
|
|
standard kinds of instructions are available. The purpose of named
|
|
instruction patterns is to provide this information to the RTL
|
|
generation pass.
|
|
</P><P>
|
|
|
|
<A NAME="IDX450"></A>
|
|
Optimization is done in this pass for <CODE>if</CODE>-conditions that are
|
|
comparisons, boolean operations or conditional expressions. Tail
|
|
recursion is detected at this time also. Decisions are made about how
|
|
best to arrange loops and how to output <CODE>switch</CODE> statements.
|
|
</P><P>
|
|
|
|
The source files for RTL generation include
|
|
<TT>`stmt.c'</TT>,
|
|
<TT>`calls.c'</TT>,
|
|
<TT>`expr.c'</TT>,
|
|
<TT>`explow.c'</TT>,
|
|
<TT>`expmed.c'</TT>,
|
|
<TT>`function.c'</TT>,
|
|
<TT>`optabs.c'</TT>
|
|
and <TT>`emit-rtl.c'</TT>.
|
|
Also, the file
|
|
<TT>`insn-emit.c'</TT>, generated from the machine description by the
|
|
program <CODE>genemit</CODE>, is used in this pass. The header file
|
|
<TT>`expr.h'</TT> is used for communication within this pass.</P><P>
|
|
|
|
<A NAME="IDX451"></A>
|
|
<A NAME="IDX452"></A>
|
|
The header files <TT>`insn-flags.h'</TT> and <TT>`insn-codes.h'</TT>,
|
|
generated from the machine description by the programs <CODE>genflags</CODE>
|
|
and <CODE>gencodes</CODE>, tell this pass which standard names are available
|
|
for use and which patterns correspond to them.</P><P>
|
|
|
|
Aside from debugging information output, none of the following passes
|
|
refers to the tree structure representation of the function (only
|
|
part of which is saved).
|
|
</P><P>
|
|
|
|
<A NAME="IDX453"></A>
|
|
The decision of whether the function can and should be expanded inline
|
|
in its subsequent callers is made at the end of rtl generation. The
|
|
function must meet certain criteria, currently related to the size of
|
|
the function and the types and number of parameters it has. Note that
|
|
this function may contain loops, recursive calls to itself
|
|
(tail-recursive functions can be inlined!), gotos, in short, all
|
|
constructs supported by GCC. The file <TT>`integrate.c'</TT> contains
|
|
the code to save a function's rtl for later inlining and to inline that
|
|
rtl when the function is called. The header file <TT>`integrate.h'</TT>
|
|
is also used for this purpose.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-dr'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.rtl'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX454"></A>
|
|
<A NAME="IDX455"></A>
|
|
<A NAME="IDX456"></A>
|
|
<LI>
|
|
Jump optimization. This pass simplifies jumps to the following
|
|
instruction, jumps across jumps, and jumps to jumps. It deletes
|
|
unreferenced labels and unreachable code, except that unreachable code
|
|
that contains a loop is not recognized as unreachable in this pass.
|
|
(Such loops are deleted later in the basic block analysis.) It also
|
|
converts some code originally written with jumps into sequences of
|
|
instructions that directly set values from the results of comparisons,
|
|
if the machine has such instructions.
|
|
<P>
|
|
|
|
Jump optimization is performed two or three times. The first time is
|
|
immediately following RTL generation. The second time is after CSE,
|
|
but only if CSE says repeated jump optimization is needed. The
|
|
last time is right before the final pass. That time, cross-jumping
|
|
and deletion of no-op move instructions are done together with the
|
|
optimizations described above.
|
|
</P><P>
|
|
|
|
The source file of this pass is <TT>`jump.c'</TT>.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-dj'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass is run for the first time. This dump file's name is made by
|
|
appending <SAMP>`.jump'</SAMP> to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX457"></A>
|
|
<LI>
|
|
Register scan. This pass finds the first and last use of each
|
|
register, as a guide for common subexpression elimination. Its source
|
|
is in <TT>`regclass.c'</TT>.
|
|
<P>
|
|
|
|
<A NAME="IDX458"></A>
|
|
<LI>
|
|
Jump threading. This pass detects a condition jump that branches to an
|
|
identical or inverse test. Such jumps can be <SAMP>`threaded'</SAMP> through
|
|
the second conditional test. The source code for this pass is in
|
|
<TT>`jump.c'</TT>. This optimization is only performed if
|
|
<SAMP>`-fthread-jumps'</SAMP> is enabled.
|
|
<P>
|
|
|
|
<A NAME="IDX459"></A>
|
|
<A NAME="IDX460"></A>
|
|
<LI>
|
|
Common subexpression elimination. This pass also does constant
|
|
propagation. Its source file is <TT>`cse.c'</TT>. If constant
|
|
propagation causes conditional jumps to become unconditional or to
|
|
become no-ops, jump optimization is run again when CSE is finished.
|
|
<P>
|
|
|
|
The option <SAMP>`-ds'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.cse'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX461"></A>
|
|
<A NAME="IDX462"></A>
|
|
<A NAME="IDX463"></A>
|
|
<LI>
|
|
Global common subexpression elimination. This pass performs GCSE
|
|
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. This pass also performs global constant
|
|
and copy propagation.
|
|
<P>
|
|
|
|
The source file for this pass is gcse.c.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-dG'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.gcse'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX464"></A>
|
|
<A NAME="IDX465"></A>
|
|
<A NAME="IDX466"></A>
|
|
<LI>
|
|
Loop optimization. This pass moves constant expressions out of loops,
|
|
and optionally does strength-reduction and loop unrolling as well.
|
|
Its source files are <TT>`loop.c'</TT> and <TT>`unroll.c'</TT>, plus the header
|
|
<TT>`loop.h'</TT> used for communication between them. Loop unrolling uses
|
|
some functions in <TT>`integrate.c'</TT> and the header <TT>`integrate.h'</TT>.
|
|
<P>
|
|
|
|
The option <SAMP>`-dL'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.loop'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<LI>
|
|
If <SAMP>`-frerun-cse-after-loop'</SAMP> was enabled, a second common
|
|
subexpression elimination pass is performed after the loop optimization
|
|
pass. Jump threading is also done again at this time if it was specified.
|
|
<P>
|
|
|
|
The option <SAMP>`-dt'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.cse2'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX467"></A>
|
|
<A NAME="IDX468"></A>
|
|
<LI>
|
|
Stupid register allocation is performed at this point in a
|
|
nonoptimizing compilation. It does a little data flow analysis as
|
|
well. When stupid register allocation is in use, the next pass
|
|
executed is the reloading pass; the others in between are skipped.
|
|
The source file is <TT>`stupid.c'</TT>.
|
|
<P>
|
|
|
|
<A NAME="IDX469"></A>
|
|
<A NAME="IDX470"></A>
|
|
<A NAME="IDX471"></A>
|
|
<LI>
|
|
Data flow analysis (<TT>`flow.c'</TT>). This pass divides the program
|
|
into basic blocks (and in the process deletes unreachable loops); then
|
|
it computes which pseudo-registers are live at each point in the
|
|
program, and makes the first instruction that uses a value point at
|
|
the instruction that computed the value.
|
|
<P>
|
|
|
|
<A NAME="IDX472"></A>
|
|
This pass also deletes computations whose results are never used, and
|
|
combines memory references with add or subtract instructions to make
|
|
autoincrement or autodecrement addressing.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-df'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.flow'</SAMP> to
|
|
the input file name. If stupid register allocation is in use, this
|
|
dump file reflects the full results of such allocation.
|
|
</P><P>
|
|
|
|
<A NAME="IDX473"></A>
|
|
<LI>
|
|
Instruction combination (<TT>`combine.c'</TT>). 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.
|
|
<P>
|
|
|
|
The option <SAMP>`-dc'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.combine'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX474"></A>
|
|
<LI>
|
|
Register movement (<TT>`regmove.c'</TT>). This pass looks for cases where
|
|
matching constraints would force an instruction to need a reload, and
|
|
this reload would be a register to register move. It them attempts
|
|
to change the registers used by the instruction to avoid the move
|
|
instruction.
|
|
<P>
|
|
|
|
The option <SAMP>`-dN'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.regmove'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX475"></A>
|
|
<A NAME="IDX476"></A>
|
|
<LI>
|
|
Instruction scheduling (<TT>`sched.c'</TT>). 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.
|
|
<P>
|
|
|
|
Instruction scheduling is performed twice. The first time is immediately
|
|
after instruction combination and the second is immediately after reload.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-dS'</SAMP> causes a debugging dump of the RTL code after this
|
|
pass is run for the first time. The dump file's name is made by
|
|
appending <SAMP>`.sched'</SAMP> to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX477"></A>
|
|
<LI>
|
|
Register class preferencing. The RTL code is scanned to find out
|
|
which register class is best for each pseudo register. The source
|
|
file is <TT>`regclass.c'</TT>.
|
|
<P>
|
|
|
|
<A NAME="IDX478"></A>
|
|
<A NAME="IDX479"></A>
|
|
<LI>
|
|
Local register allocation (<TT>`local-alloc.c'</TT>). This pass allocates
|
|
hard registers to pseudo registers that are used only within one basic
|
|
block. Because the basic block is linear, it can use fast and
|
|
powerful techniques to do a very good job.
|
|
<P>
|
|
|
|
The option <SAMP>`-dl'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.lreg'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX480"></A>
|
|
<LI>
|
|
Global register allocation (<TT>`global.c'</TT>). This pass
|
|
allocates hard registers for the remaining pseudo registers (those
|
|
whose life spans are not contained in one basic block).
|
|
<P>
|
|
|
|
<A NAME="IDX481"></A>
|
|
<LI>
|
|
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.
|
|
<P>
|
|
|
|
The reload pass also optionally eliminates the frame pointer and inserts
|
|
instructions to save and restore call-clobbered registers around calls.
|
|
</P><P>
|
|
|
|
Source files are <TT>`reload.c'</TT> and <TT>`reload1.c'</TT>, plus the header
|
|
<TT>`reload.h'</TT> used for communication between them.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-dg'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.greg'</SAMP> to
|
|
the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX482"></A>
|
|
<A NAME="IDX483"></A>
|
|
<LI>
|
|
Instruction scheduling is repeated here to try to avoid pipeline stalls
|
|
due to memory loads generated for spilled pseudo registers.
|
|
<P>
|
|
|
|
The option <SAMP>`-dR'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.sched2'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX484"></A>
|
|
<A NAME="IDX485"></A>
|
|
<LI>
|
|
Jump optimization is repeated, this time including cross-jumping
|
|
and deletion of no-op move instructions.
|
|
<P>
|
|
|
|
The option <SAMP>`-dJ'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.jump2'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX486"></A>
|
|
<A NAME="IDX487"></A>
|
|
<LI>
|
|
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 source file name is <TT>`reorg.c'</TT>.
|
|
<P>
|
|
|
|
The option <SAMP>`-dd'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.dbr'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX488"></A>
|
|
<LI>
|
|
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
|
|
source file name is <TT>`reg-stack.c'</TT>.
|
|
<P>
|
|
|
|
The options <SAMP>`-dk'</SAMP> causes a debugging dump of the RTL code after
|
|
this pass. This dump file's name is made by appending <SAMP>`.stack'</SAMP>
|
|
to the input file name.
|
|
</P><P>
|
|
|
|
<A NAME="IDX489"></A>
|
|
<A NAME="IDX490"></A>
|
|
<LI>
|
|
Final. This pass outputs the assembler code for the function. It is
|
|
also responsible for identifying spurious test and compare
|
|
instructions. Machine-specific peephole optimizations are performed
|
|
at the same time. The function entry and exit sequences are generated
|
|
directly as assembler code in this pass; they never exist as RTL.
|
|
<P>
|
|
|
|
The source files are <TT>`final.c'</TT> plus <TT>`insn-output.c'</TT>; the
|
|
latter is generated automatically from the machine description by the
|
|
tool <TT>`genoutput'</TT>. The header file <TT>`conditions.h'</TT> is used
|
|
for communication between these files.
|
|
</P><P>
|
|
|
|
<A NAME="IDX491"></A>
|
|
<LI>
|
|
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 <TT>`dbxout.c'</TT> for DBX symbol table
|
|
format, <TT>`sdbout.c'</TT> for SDB symbol table format, and
|
|
<TT>`dwarfout.c'</TT> for DWARF symbol table format.
|
|
</UL>
|
|
<P>
|
|
|
|
Some additional files are used by all or many passes:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Every pass uses <TT>`machmode.def'</TT> and <TT>`machmode.h'</TT> which define
|
|
the machine modes.
|
|
<P>
|
|
|
|
<LI>
|
|
Several passes use <TT>`real.h'</TT>, which defines the default
|
|
representation of floating point constants and how to operate on them.
|
|
<P>
|
|
|
|
<LI>
|
|
All the passes that work with RTL use the header files <TT>`rtl.h'</TT>
|
|
and <TT>`rtl.def'</TT>, and subroutines in file <TT>`rtl.c'</TT>. The tools
|
|
<CODE>gen*</CODE> also use these files to read and work with the machine
|
|
description RTL.
|
|
<P>
|
|
|
|
<A NAME="IDX492"></A>
|
|
<LI>
|
|
Several passes refer to the header file <TT>`insn-config.h'</TT> which
|
|
contains a few parameters (C macro definitions) generated
|
|
automatically from the machine description RTL by the tool
|
|
<CODE>genconfig</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX493"></A>
|
|
<LI>
|
|
Several passes use the instruction recognizer, which consists of
|
|
<TT>`recog.c'</TT> and <TT>`recog.h'</TT>, plus the files <TT>`insn-recog.c'</TT>
|
|
and <TT>`insn-extract.c'</TT> that are generated automatically from the
|
|
machine description by the tools <TT>`genrecog'</TT> and
|
|
<TT>`genextract'</TT>.<P>
|
|
|
|
<LI>
|
|
Several passes use the header files <TT>`regs.h'</TT> which defines the
|
|
information recorded about pseudo register usage, and <TT>`basic-block.h'</TT>
|
|
which defines the information recorded about basic blocks.
|
|
<P>
|
|
|
|
<LI>
|
|
<TT>`hard-reg-set.h'</TT> defines the type <CODE>HARD_REG_SET</CODE>, a bit-vector
|
|
with a bit for each hard register, and some macros to manipulate it.
|
|
This type is just <CODE>int</CODE> if the machine has few enough hard registers;
|
|
otherwise it is an array of <CODE>int</CODE> and some of the macros expand
|
|
into loops.
|
|
<P>
|
|
|
|
<LI>
|
|
Several passes use instruction attributes. A definition of the
|
|
attributes defined for a particular machine is in file
|
|
<TT>`insn-attr.h'</TT>, which is generated from the machine description by
|
|
the program <TT>`genattr'</TT>. The file <TT>`insn-attrtab.c'</TT> contains
|
|
subroutines to obtain the attribute values for insns. It is generated
|
|
from the machine description by the program <TT>`genattrtab'</TT>.</UL>
|
|
<P>
|
|
|
|
<A NAME="RTL"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_2.html#SEC2" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|