1020 lines
46 KiB
Plaintext
1020 lines
46 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo-1.47 from the input
|
||
file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the sections entitled "GNU General Public License" and "Boycott"
|
||
are included exactly as in the original, and provided that the entire
|
||
resulting derived work is distributed under the terms of a permission
|
||
notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the sections entitled "GNU General Public
|
||
License" and "Boycott", and this permission notice, may be included in
|
||
translations approved by the Free Software Foundation instead of in the
|
||
original English.
|
||
|
||
|
||
File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS
|
||
|
||
Other VMS Issues
|
||
================
|
||
|
||
GNU CC automatically arranges for `main' to return 1 by default if
|
||
you fail to specify an explicit return value. This will be interpreted
|
||
by VMS as a status code indicating a normal successful completion.
|
||
Version 1 of GNU CC did not provide this default.
|
||
|
||
GNU CC on VMS works only with the GNU assembler, GAS. You need
|
||
version 1.37 or later of GAS in order to produce value debugging
|
||
information for the VMS debugger. Use the ordinary VMS linker with the
|
||
object files produced by GAS.
|
||
|
||
Under previous versions of GNU CC, the generated code would
|
||
occasionally give strange results when linked to the sharable `VAXCRTL'
|
||
library. Now this should work.
|
||
|
||
A caveat for use of `const' global variables: the `const' modifier
|
||
must be specified in every external declaration of the variable in all
|
||
of the source files that use that variable. Otherwise the linker will
|
||
issue warnings about conflicting attributes for the variable. Your
|
||
program will still work despite the warnings, but the variable will be
|
||
placed in writable storage.
|
||
|
||
The VMS linker does not distinguish between upper and lower case
|
||
letters in function and variable names. However, usual practice in C
|
||
is to distinguish case. Normally GNU CC (by means of the assembler GAS)
|
||
implements usual C behavior by augmenting each name that is not all
|
||
lower-case. A name is augmented by truncating it to at most 23
|
||
characters and then adding more characters at the end which encode the
|
||
case pattern the rest.
|
||
|
||
Name augmentation yields bad results for programs that use
|
||
precompiled libraries (such as Xlib) which were generated by another
|
||
compiler. You can use the compiler option `/NOCASE_HACK' to inhibit
|
||
augmentation; it makes external C functions and variables
|
||
case-independent as is usual on VMS. Alternatively, you could write
|
||
all references to the functions and variables in such libraries using
|
||
lower case; this will work on VMS, but is not portable to other systems.
|
||
|
||
Function and variable names are handled somewhat differently with GNU
|
||
C++. The GNU C++ compiler performs "name mangling" on function names,
|
||
which means that it adds information to the function name to describe
|
||
the data types of the arguments that the function takes. One result of
|
||
this is that the name of a function can become very long. Since the VMS
|
||
linker only recognizes the first 31 characters in a name, special
|
||
action is taken to ensure that each function and variable has a unique
|
||
name that can be represented in 31 characters.
|
||
|
||
If the name (plus a name augmentation, if required) is less than 32
|
||
characters in length, then no special action is performed. If the name
|
||
is longer than 31 characters, the assembler (GAS) will generate a hash
|
||
string based upon the function name, truncate the function name to 23
|
||
characters, and append the hash string to the truncated name. If the
|
||
`/VERBOSE' compiler option is used, the assembler will print both the
|
||
full and truncated names of each symbol that is truncated.
|
||
|
||
The `/NOCASE_HACK' compiler option should not be used when you are
|
||
compiling programs that use libg++. libg++ has several instances of
|
||
objects (i.e. `Filebuf' and `filebuf') which become indistinguishable
|
||
in a case-insensitive environment. This leads to cases where you need
|
||
to inhibit augmentation selectively (if you were using libg++ and Xlib
|
||
in the same program, for example). There is no special feature for
|
||
doing this, but you can get the result by defining a macro for each
|
||
mixed case symbol for which you wish to inhibit augmentation. The
|
||
macro should expand into the lower case equivalent of itself. For
|
||
example:
|
||
|
||
#define StuDlyCapS studlycaps
|
||
|
||
These macro definitions can be placed in a header file to minimize
|
||
the number of changes to your source code.
|
||
|
||
|
||
File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top
|
||
|
||
GNU CC and Portability
|
||
**********************
|
||
|
||
The main goal of GNU CC was to make a good, fast compiler for
|
||
machines in the class that the GNU system aims to run on: 32-bit
|
||
machines that address 8-bit bytes and have several general registers.
|
||
Elegance, theoretical power and simplicity are only secondary.
|
||
|
||
GNU CC gets most of the information about the target machine from a
|
||
machine description which gives an algebraic formula for each of the
|
||
machine's instructions. This is a very clean way to describe the
|
||
target. But when the compiler needs information that is difficult to
|
||
express in this fashion, I have not hesitated to define an ad-hoc
|
||
parameter to the machine description. The purpose of portability is to
|
||
reduce the total work needed on the compiler; it was not of interest
|
||
for its own sake.
|
||
|
||
GNU CC does not contain machine dependent code, but it does contain
|
||
code that depends on machine parameters such as endianness (whether the
|
||
most significant byte has the highest or lowest address of the bytes in
|
||
a word) and the availability of autoincrement addressing. In the
|
||
RTL-generation pass, it is often necessary to have multiple strategies
|
||
for generating code for a particular kind of syntax tree, strategies
|
||
that are usable for different combinations of parameters. Often I have
|
||
not tried to address all possible cases, but only the common ones or
|
||
only the ones that I have encountered. As a result, a new target may
|
||
require additional strategies. You will know if this happens because
|
||
the compiler will call `abort'. Fortunately, the new strategies can be
|
||
added in a machine-independent fashion, and will affect only the target
|
||
machines that need them.
|
||
|
||
|
||
File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top
|
||
|
||
Interfacing to GNU CC Output
|
||
****************************
|
||
|
||
GNU CC is normally configured to use the same function calling
|
||
convention normally in use on the target system. This is done with the
|
||
machine-description macros described (*note Target Macros::.).
|
||
|
||
However, returning of structure and union values is done differently
|
||
on some target machines. As a result, functions compiled with PCC
|
||
returning such types cannot be called from code compiled with GNU CC,
|
||
and vice versa. This does not cause trouble often because few Unix
|
||
library routines return structures or unions.
|
||
|
||
GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes
|
||
long in the same registers used for `int' or `double' return values.
|
||
(GNU CC typically allocates variables of such types in registers also.)
|
||
Structures and unions of other sizes are returned by storing them into
|
||
an address passed by the caller (usually in a register). The
|
||
machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE'
|
||
tell GNU CC where to pass this address.
|
||
|
||
By contrast, PCC on most target machines returns structures and
|
||
unions of any size by copying the data into an area of static storage,
|
||
and then returning the address of that storage as if it were a pointer
|
||
value. The caller must copy the data from that memory area to the place
|
||
where the value is wanted. This is slower than the method used by GNU
|
||
CC, and fails to be reentrant.
|
||
|
||
On some target machines, such as RISC machines and the 80386, the
|
||
standard system convention is to pass to the subroutine the address of
|
||
where to return the value. On these machines, GNU CC has been
|
||
configured to be compatible with the standard compiler, when this method
|
||
is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes.
|
||
|
||
GNU CC uses the system's standard convention for passing arguments.
|
||
On some machines, the first few arguments are passed in registers; in
|
||
others, all are passed on the stack. It would be possible to use
|
||
registers for argument passing on any machine, and this would probably
|
||
result in a significant speedup. But the result would be complete
|
||
incompatibility with code that follows the standard convention. So this
|
||
change is practical only if you are switching to GNU CC as the sole C
|
||
compiler for the system. We may implement register argument passing on
|
||
certain machines once we have a complete GNU system so that we can
|
||
compile the libraries with GNU CC.
|
||
|
||
On some machines (particularly the Sparc), certain types of arguments
|
||
are passed "by invisible reference". This means that the value is
|
||
stored in memory, and the address of the memory location is passed to
|
||
the subroutine.
|
||
|
||
If you use `longjmp', beware of automatic variables. ANSI C says
|
||
that automatic variables that are not declared `volatile' have undefined
|
||
values after a `longjmp'. And this is all GNU CC promises to do,
|
||
because it is very difficult to restore register variables correctly,
|
||
and one of GNU CC's features is that it can put variables in registers
|
||
without your asking it to.
|
||
|
||
If you want a variable to be unaltered by `longjmp', and you don't
|
||
want to write `volatile' because old C compilers don't accept it, just
|
||
take the address of the variable. If a variable's address is ever
|
||
taken, even if just to compute it and ignore it, then the variable
|
||
cannot go in a register:
|
||
|
||
{
|
||
int careful;
|
||
&careful;
|
||
...
|
||
}
|
||
|
||
Code compiled with GNU CC may call certain library routines. Most of
|
||
them handle arithmetic for which there are no instructions. This
|
||
includes multiply and divide on some machines, and floating point
|
||
operations on any machine for which floating point support is disabled
|
||
with `-msoft-float'. Some standard parts of the C library, such as
|
||
`bcopy' or `memcpy', are also called automatically. The usual function
|
||
call interface is used for calling the library routines.
|
||
|
||
These library routines should be defined in the library `libgcc.a',
|
||
which GNU CC automatically searches whenever it links a program. On
|
||
machines that have multiply and divide instructions, if hardware
|
||
floating point is in use, normally `libgcc.a' is not needed, but it is
|
||
searched just in case.
|
||
|
||
Each arithmetic function is defined in `libgcc1.c' to use the
|
||
corresponding C arithmetic operator. As long as the file is compiled
|
||
with another C compiler, which supports all the C arithmetic operators,
|
||
this file will work portably. However, `libgcc1.c' does not work if
|
||
compiled with GNU CC, because each arithmetic function would compile
|
||
into a call to itself!
|
||
|
||
|
||
File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top
|
||
|
||
Passes and Files of the Compiler
|
||
********************************
|
||
|
||
The overall control structure of the compiler is in `toplev.c'. This
|
||
file is responsible for initialization, decoding arguments, opening and
|
||
closing files, and sequencing the passes.
|
||
|
||
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.
|
||
|
||
Each time the parsing pass reads a complete function definition or
|
||
top-level declaration, it calls the function `rest_of_compilation' or
|
||
`rest_of_decl_compilation' in `toplev.c', which are responsible for all
|
||
further processing necessary, ending with output of the assembler
|
||
language. All other compiler passes run, in sequence, within
|
||
`rest_of_compilation'. 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 (*note
|
||
Inline::.).
|
||
|
||
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 `-d' options.
|
||
|
||
* 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.
|
||
|
||
The tree representation does not entirely follow C syntax, because
|
||
it is intended to support other languages as well.
|
||
|
||
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.
|
||
|
||
Constant folding and some arithmetic simplifications are also done
|
||
during this pass.
|
||
|
||
The language-independent source files for parsing are
|
||
`stor-layout.c', `fold-const.c', and `tree.c'. There are also
|
||
header files `tree.h' and `tree.def' which define the format of
|
||
the tree representation.
|
||
|
||
The source files for parsing C are `c-parse.y', `c-decl.c',
|
||
`c-typeck.c', `c-convert.c', `c-lang.c', and `c-aux-info.c' along
|
||
with header files `c-lex.h', and `c-tree.h'.
|
||
|
||
The source files for parsing C++ are `cp-parse.y', `cp-class.c',
|
||
`cp-cvt.c',
|
||
`cp-decl.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c',
|
||
`cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c',
|
||
`cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along
|
||
with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'.
|
||
|
||
The special source files for parsing Objective C are
|
||
`objc-parse.y', `objc-actions.c', `objc-tree.def', and
|
||
`objc-actions.h'. Certain C-specific files are used for this as
|
||
well.
|
||
|
||
The file `c-common.c' is also used for all of the above languages.
|
||
|
||
* 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.
|
||
|
||
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.
|
||
|
||
Optimization is done in this pass for `if'-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 `switch' statements.
|
||
|
||
The source files for RTL generation include `stmt.c',
|
||
`function.c', `expr.c', `calls.c', `explow.c', `expmed.c',
|
||
`optabs.c' and `emit-rtl.c'. Also, the file `insn-emit.c',
|
||
generated from the machine description by the program `genemit',
|
||
is used in this pass. The header file `expr.h' is used for
|
||
communication within this pass.
|
||
|
||
The header files `insn-flags.h' and `insn-codes.h', generated from
|
||
the machine description by the programs `genflags' and `gencodes',
|
||
tell this pass which standard names are available for use and
|
||
which patterns correspond to them.
|
||
|
||
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).
|
||
|
||
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 GNU CC.
|
||
The file `integrate.c' 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 `integrate.h' is also used for this
|
||
purpose.
|
||
|
||
The option `-dr' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.rtl' to
|
||
the input file name.
|
||
|
||
* 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.
|
||
|
||
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.
|
||
|
||
The source file of this pass is `jump.c'.
|
||
|
||
The option `-dj' 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 `.jump' to the input file name.
|
||
|
||
* Register scan. This pass finds the first and last use of each
|
||
register, as a guide for common subexpression elimination. Its
|
||
source is in `regclass.c'.
|
||
|
||
* Jump threading. This pass detects a condition jump that branches
|
||
to an identical or inverse test. Such jumps can be `threaded'
|
||
through the second conditional test. The source code for this
|
||
pass is in `jump.c'. This optimization is only performed if
|
||
`-fthread-jumps' is enabled.
|
||
|
||
* Common subexpression elimination. This pass also does constant
|
||
propagation. Its source file is `cse.c'. If constant propagation
|
||
causes conditional jumps to become unconditional or to become
|
||
no-ops, jump optimization is run again when CSE is finished.
|
||
|
||
The option `-ds' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.cse' to
|
||
the input file name.
|
||
|
||
* Loop optimization. This pass moves constant expressions out of
|
||
loops, and optionally does strength-reduction and loop unrolling
|
||
as well. Its source files are `loop.c' and `unroll.c', plus the
|
||
header `loop.h' used for communication between them. Loop
|
||
unrolling uses some functions in `integrate.c' and the header
|
||
`integrate.h'.
|
||
|
||
The option `-dL' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.loop' to
|
||
the input file name.
|
||
|
||
* If `-frerun-cse-after-loop' 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.
|
||
|
||
The option `-dt' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.cse2' to
|
||
the input file name.
|
||
|
||
* 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 `stupid.c'.
|
||
|
||
* Data flow analysis (`flow.c'). 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.
|
||
|
||
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.
|
||
|
||
The option `-df' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.flow' to
|
||
the input file name. If stupid register allocation is in use, this
|
||
dump file reflects the full results of such allocation.
|
||
|
||
* Instruction combination (`combine.c'). 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 option `-dc' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.combine'
|
||
to the input file name.
|
||
|
||
* Instruction scheduling (`sched.c'). 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.
|
||
|
||
Instruction scheduling is performed twice. The first time is
|
||
immediately after instruction combination and the second is
|
||
immediately after reload.
|
||
|
||
The option `-dS' 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 `.sched' to the input file name.
|
||
|
||
* Register class preferencing. The RTL code is scanned to find out
|
||
which register class is best for each pseudo register. The source
|
||
file is `regclass.c'.
|
||
|
||
* Local register allocation (`local-alloc.c'). 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.
|
||
|
||
The option `-dl' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.lreg' to
|
||
the input file name.
|
||
|
||
* Global register allocation (`global-alloc.c'). This pass
|
||
allocates hard registers for the remaining pseudo registers (those
|
||
whose life spans are not contained in one basic block).
|
||
|
||
* 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 `reload.c' and `reload1.c', plus the header
|
||
`reload.h' used for communication between them.
|
||
|
||
The option `-dg' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.greg' to
|
||
the input file name.
|
||
|
||
* Instruction scheduling is repeated here to try to avoid pipeline
|
||
stalls due to memory loads generated for spilled pseudo registers.
|
||
|
||
The option `-dR' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.sched2'
|
||
to the input file name.
|
||
|
||
* Jump optimization is repeated, this time including cross-jumping
|
||
and deletion of no-op move instructions.
|
||
|
||
The option `-dJ' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.jump2' to
|
||
the input file name.
|
||
|
||
* 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
|
||
`reorg.c'.
|
||
|
||
The option `-dd' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.dbr' to
|
||
the input file name.
|
||
|
||
* 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 `reg-stack.c'.
|
||
|
||
The options `-dk' causes a debugging dump of the RTL code after
|
||
this pass. This dump file's name is made by appending `.stack' to
|
||
the input file name.
|
||
|
||
* 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.
|
||
|
||
The source files are `final.c' plus `insn-output.c'; the latter is
|
||
generated automatically from the machine description by the tool
|
||
`genoutput'. The header file `conditions.h' is used for
|
||
communication between these files.
|
||
|
||
* 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 `dbxout.c' for DBX
|
||
symbol table format, `sdbout.c' for SDB symbol table format, and
|
||
`dwarfout.c' for DWARF symbol table format.
|
||
|
||
Some additional files are used by all or many passes:
|
||
|
||
* Every pass uses `machmode.def' and `machmode.h' which define the
|
||
machine modes.
|
||
|
||
* Several passes use `real.h', which defines the default
|
||
representation of floating point constants and how to operate on
|
||
them.
|
||
|
||
* All the passes that work with RTL use the header files `rtl.h' and
|
||
`rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also
|
||
use these files to read and work with the machine description RTL.
|
||
|
||
* Several passes refer to the header file `insn-config.h' which
|
||
contains a few parameters (C macro definitions) generated
|
||
automatically from the machine description RTL by the tool
|
||
`genconfig'.
|
||
|
||
* Several passes use the instruction recognizer, which consists of
|
||
`recog.c' and `recog.h', plus the files `insn-recog.c' and
|
||
`insn-extract.c' that are generated automatically from the machine
|
||
description by the tools `genrecog' and `genextract'.
|
||
|
||
* Several passes use the header files `regs.h' which defines the
|
||
information recorded about pseudo register usage, and
|
||
`basic-block.h' which defines the information recorded about basic
|
||
blocks.
|
||
|
||
* `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
|
||
with a bit for each hard register, and some macros to manipulate
|
||
it. This type is just `int' if the machine has few enough hard
|
||
registers; otherwise it is an array of `int' and some of the
|
||
macros expand into loops.
|
||
|
||
* Several passes use instruction attributes. A definition of the
|
||
attributes defined for a particular machine is in file
|
||
`insn-attr.h', which is generated from the machine description by
|
||
the program `genattr'. The file `insn-attrtab.c' contains
|
||
subroutines to obtain the attribute values for insns. It is
|
||
generated from the machine description by the program `genattrtab'.
|
||
|
||
|
||
File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top
|
||
|
||
RTL Representation
|
||
******************
|
||
|
||
Most of the work of the compiler is done on an intermediate
|
||
representation called register transfer language. In this language,
|
||
the instructions to be output are described, pretty much one by one, in
|
||
an algebraic form that describes what the instruction does.
|
||
|
||
RTL is inspired by Lisp lists. It has both an internal form, made
|
||
up of structures that point at other structures, and a textual form
|
||
that is used in the machine description and in printed debugging dumps.
|
||
The textual form uses nested parentheses to indicate the pointers in
|
||
the internal form.
|
||
|
||
* Menu:
|
||
|
||
* RTL Objects:: Expressions vs vectors vs strings vs integers.
|
||
* Accessors:: Macros to access expression operands or vector elts.
|
||
* Flags:: Other flags in an RTL expression.
|
||
* Machine Modes:: Describing the size and format of a datum.
|
||
* Constants:: Expressions with constant values.
|
||
* Regs and Memory:: Expressions representing register contents or memory.
|
||
* Arithmetic:: Expressions representing arithmetic on other expressions.
|
||
* Comparisons:: Expressions representing comparison of expressions.
|
||
* Bit Fields:: Expressions representing bit-fields in memory or reg.
|
||
* Conversions:: Extending, truncating, floating or fixing.
|
||
* RTL Declarations:: Declaring volatility, constancy, etc.
|
||
* Side Effects:: Expressions for storing in registers, etc.
|
||
* Incdec:: Embedded side-effects for autoincrement addressing.
|
||
* Assembler:: Representing `asm' with operands.
|
||
* Insns:: Expression types for entire insns.
|
||
* Calls:: RTL representation of function call insns.
|
||
* Sharing:: Some expressions are unique; others *must* be copied.
|
||
|
||
|
||
File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL
|
||
|
||
RTL Object Types
|
||
================
|
||
|
||
RTL uses four kinds of objects: expressions, integers, strings and
|
||
vectors. Expressions are the most important ones. An RTL expression
|
||
("RTX", for short) is a C structure, but it is usually referred to with
|
||
a pointer; a type that is given the typedef name `rtx'.
|
||
|
||
An integer is simply an `int'; their written form uses decimal
|
||
digits.
|
||
|
||
A string is a sequence of characters. In core it is represented as a
|
||
`char *' in usual C fashion, and it is written in C syntax as well.
|
||
However, strings in RTL may never be null. If you write an empty
|
||
string in a machine description, it is represented in core as a null
|
||
pointer rather than as a pointer to a null character. In certain
|
||
contexts, these null pointers instead of strings are valid. Within RTL
|
||
code, strings are most commonly found inside `symbol_ref' expressions,
|
||
but they appear in other contexts in the RTL expressions that make up
|
||
machine descriptions.
|
||
|
||
A vector contains an arbitrary number of pointers to expressions.
|
||
The number of elements in the vector is explicitly present in the
|
||
vector. The written form of a vector consists of square brackets
|
||
(`[...]') surrounding the elements, in sequence and with whitespace
|
||
separating them. Vectors of length zero are not created; null pointers
|
||
are used instead.
|
||
|
||
Expressions are classified by "expression codes" (also called RTX
|
||
codes). The expression code is a name defined in `rtl.def', which is
|
||
also (in upper case) a C enumeration constant. The possible expression
|
||
codes and their meanings are machine-independent. The code of an RTX
|
||
can be extracted with the macro `GET_CODE (X)' and altered with
|
||
`PUT_CODE (X, NEWCODE)'.
|
||
|
||
The expression code determines how many operands the expression
|
||
contains, and what kinds of objects they are. In RTL, unlike Lisp, you
|
||
cannot tell by looking at an operand what kind of object it is.
|
||
Instead, you must know from its context--from the expression code of
|
||
the containing expression. For example, in an expression of code
|
||
`subreg', the first operand is to be regarded as an expression and the
|
||
second operand as an integer. In an expression of code `plus', there
|
||
are two operands, both of which are to be regarded as expressions. In
|
||
a `symbol_ref' expression, there is one operand, which is to be
|
||
regarded as a string.
|
||
|
||
Expressions are written as parentheses containing the name of the
|
||
expression type, its flags and machine mode if any, and then the
|
||
operands of the expression (separated by spaces).
|
||
|
||
Expression code names in the `md' file are written in lower case,
|
||
but when they appear in C code they are written in upper case. In this
|
||
manual, they are shown as follows: `const_int'.
|
||
|
||
In a few contexts a null pointer is valid where an expression is
|
||
normally wanted. The written form of this is `(nil)'.
|
||
|
||
|
||
File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL
|
||
|
||
Access to Operands
|
||
==================
|
||
|
||
For each expression type `rtl.def' specifies the number of contained
|
||
objects and their kinds, with four possibilities: `e' for expression
|
||
(actually a pointer to an expression), `i' for integer, `s' for string,
|
||
and `E' for vector of expressions. The sequence of letters for an
|
||
expression code is called its "format". Thus, the format of `subreg'
|
||
is `ei'.
|
||
|
||
A few other format characters are used occasionally:
|
||
|
||
`u'
|
||
`u' is equivalent to `e' except that it is printed differently in
|
||
debugging dumps. It is used for pointers to insns.
|
||
|
||
`n'
|
||
`n' is equivalent to `i' except that it is printed differently in
|
||
debugging dumps. It is used for the line number or code number of
|
||
a `note' insn.
|
||
|
||
`S'
|
||
`S' indicates a string which is optional. In the RTL objects in
|
||
core, `S' is equivalent to `s', but when the object is read, from
|
||
an `md' file, the string value of this operand may be omitted. An
|
||
omitted string is taken to be the null string.
|
||
|
||
`V'
|
||
`V' indicates a vector which is optional. In the RTL objects in
|
||
core, `V' is equivalent to `E', but when the object is read from
|
||
an `md' file, the vector value of this operand may be omitted. An
|
||
omitted vector is effectively the same as a vector of no elements.
|
||
|
||
`0'
|
||
`0' means a slot whose contents do not fit any normal category.
|
||
`0' slots are not printed at all in dumps, and are often used in
|
||
special ways by small parts of the compiler.
|
||
|
||
There are macros to get the number of operands, the format, and the
|
||
class of an expression code:
|
||
|
||
`GET_RTX_LENGTH (CODE)'
|
||
Number of operands of an RTX of code CODE.
|
||
|
||
`GET_RTX_FORMAT (CODE)'
|
||
The format of an RTX of code CODE, as a C string.
|
||
|
||
`GET_RTX_CLASS (CODE)'
|
||
A single character representing the type of RTX operation that code
|
||
CODE performs.
|
||
|
||
The following classes are defined:
|
||
|
||
`o'
|
||
An RTX code that represents an actual object, such as `reg' or
|
||
`mem'. `subreg' is not in this class.
|
||
|
||
`<'
|
||
An RTX code for a comparison. The codes in this class are
|
||
`NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU',
|
||
`GTU'.
|
||
|
||
`1'
|
||
An RTX code for a unary arithmetic operation, such as `neg'.
|
||
|
||
`c'
|
||
An RTX code for a commutative binary operation, other than
|
||
`NE' and `EQ' (which have class `<').
|
||
|
||
`2'
|
||
An RTX code for a noncommutative binary operation, such as
|
||
`MINUS'.
|
||
|
||
`b'
|
||
An RTX code for a bitfield operation (`ZERO_EXTRACT' and
|
||
`SIGN_EXTRACT').
|
||
|
||
`3'
|
||
An RTX code for other three input operations, such as
|
||
`IF_THEN_ELSE'.
|
||
|
||
`i'
|
||
An RTX code for a machine insn (`INSN', `JUMP_INSN', and
|
||
`CALL_INSN').
|
||
|
||
`m'
|
||
An RTX code for something that matches in insns, such as
|
||
`MATCH_DUP'.
|
||
|
||
`x'
|
||
All other RTX codes.
|
||
|
||
Operands of expressions are accessed using the macros `XEXP', `XINT'
|
||
and `XSTR'. Each of these macros takes two arguments: an
|
||
expression-pointer (RTX) and an operand number (counting from zero).
|
||
Thus,
|
||
|
||
XEXP (X, 2)
|
||
|
||
accesses operand 2 of expression X, as an expression.
|
||
|
||
XINT (X, 2)
|
||
|
||
accesses the same operand as an integer. `XSTR', used in the same
|
||
fashion, would access it as a string.
|
||
|
||
Any operand can be accessed as an integer, as an expression or as a
|
||
string. You must choose the correct method of access for the kind of
|
||
value actually stored in the operand. You would do this based on the
|
||
expression code of the containing expression. That is also how you
|
||
would know how many operands there are.
|
||
|
||
For example, if X is a `subreg' expression, you know that it has two
|
||
operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
|
||
1)'. If you did `XINT (X, 0)', you would get the address of the
|
||
expression operand but cast as an integer; that might occasionally be
|
||
useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
|
||
(X, 1)' would also compile without error, and would return the second,
|
||
integer operand cast as an expression pointer, which would probably
|
||
result in a crash when accessed. Nothing stops you from writing `XEXP
|
||
(X, 28)' either, but this will access memory past the end of the
|
||
expression with unpredictable results.
|
||
|
||
Access to operands which are vectors is more complicated. You can
|
||
use the macro `XVEC' to get the vector-pointer itself, or the macros
|
||
`XVECEXP' and `XVECLEN' to access the elements and length of a vector.
|
||
|
||
`XVEC (EXP, IDX)'
|
||
Access the vector-pointer which is operand number IDX in EXP.
|
||
|
||
`XVECLEN (EXP, IDX)'
|
||
Access the length (number of elements) in the vector which is in
|
||
operand number IDX in EXP. This value is an `int'.
|
||
|
||
`XVECEXP (EXP, IDX, ELTNUM)'
|
||
Access element number ELTNUM in the vector which is in operand
|
||
number IDX in EXP. This value is an RTX.
|
||
|
||
It is up to you to make sure that ELTNUM is not negative and is
|
||
less than `XVECLEN (EXP, IDX)'.
|
||
|
||
All the macros defined in this section expand into lvalues and
|
||
therefore can be used to assign the operands, lengths and vector
|
||
elements as well as to access them.
|
||
|
||
|
||
File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL
|
||
|
||
Flags in an RTL Expression
|
||
==========================
|
||
|
||
RTL expressions contain several flags (one-bit bit-fields) that are
|
||
used in certain types of expression. Most often they are accessed with
|
||
the following macros:
|
||
|
||
`MEM_VOLATILE_P (X)'
|
||
In `mem' expressions, nonzero for volatile memory references.
|
||
Stored in the `volatil' field and printed as `/v'.
|
||
|
||
`MEM_IN_STRUCT_P (X)'
|
||
In `mem' expressions, nonzero for reference to an entire
|
||
structure, union or array, or to a component of one. Zero for
|
||
references to a scalar variable or through a pointer to a scalar.
|
||
Stored in the `in_struct' field and printed as `/s'.
|
||
|
||
`REG_LOOP_TEST_P'
|
||
In `reg' expressions, nonzero if this register's entire life is
|
||
contained in the exit test code for some loop. Stored in the
|
||
`in_struct' field and printed as `/s'.
|
||
|
||
`REG_USERVAR_P (X)'
|
||
In a `reg', nonzero if it corresponds to a variable present in the
|
||
user's source code. Zero for temporaries generated internally by
|
||
the compiler. Stored in the `volatil' field and printed as `/v'.
|
||
|
||
`REG_FUNCTION_VALUE_P (X)'
|
||
Nonzero in a `reg' if it is the place in which this function's
|
||
value is going to be returned. (This happens only in a hard
|
||
register.) Stored in the `integrated' field and printed as `/i'.
|
||
|
||
The same hard register may be used also for collecting the values
|
||
of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
|
||
in this kind of use.
|
||
|
||
`RTX_UNCHANGING_P (X)'
|
||
Nonzero in a `reg' or `mem' if the value is not changed. (This
|
||
flag is not set for memory references via pointers to constants.
|
||
Such pointers only guarantee that the object will not be changed
|
||
explicitly by the current function. The object might be changed by
|
||
other functions or by aliasing.) Stored in the `unchanging' field
|
||
and printed as `/u'.
|
||
|
||
`RTX_INTEGRATED_P (INSN)'
|
||
Nonzero in an insn if it resulted from an in-line function call.
|
||
Stored in the `integrated' field and printed as `/i'. This may be
|
||
deleted; nothing currently depends on it.
|
||
|
||
`SYMBOL_REF_USED (X)'
|
||
In a `symbol_ref', indicates that X has been used. This is
|
||
normally only used to ensure that X is only declared external
|
||
once. Stored in the `used' field.
|
||
|
||
`SYMBOL_REF_FLAG (X)'
|
||
In a `symbol_ref', this is used as a flag for machine-specific
|
||
purposes. Stored in the `volatil' field and printed as `/v'.
|
||
|
||
`LABEL_OUTSIDE_LOOP_P'
|
||
In `label_ref' expressions, nonzero if this is a reference to a
|
||
label that is outside the innermost loop containing the reference
|
||
to the label. Stored in the `in_struct' field and printed as `/s'.
|
||
|
||
`INSN_DELETED_P (INSN)'
|
||
In an insn, nonzero if the insn has been deleted. Stored in the
|
||
`volatil' field and printed as `/v'.
|
||
|
||
`INSN_ANNULLED_BRANCH_P (INSN)'
|
||
In an `insn' in the delay slot of a branch insn, indicates that an
|
||
annulling branch should be used. See the discussion under
|
||
`sequence' below. Stored in the `unchanging' field and printed as
|
||
`/u'.
|
||
|
||
`INSN_FROM_TARGET_P (INSN)'
|
||
In an `insn' in a delay slot of a branch, indicates that the insn
|
||
is from the target of the branch. If the branch insn has
|
||
`INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if
|
||
the branch is taken. For annulled branches with this bit clear,
|
||
the insn should be executed only if the branch is not taken.
|
||
Stored in the `in_struct' field and printed as `/s'.
|
||
|
||
`CONSTANT_POOL_ADDRESS_P (X)'
|
||
Nonzero in a `symbol_ref' if it refers to part of the current
|
||
function's "constants pool". These are addresses close to the
|
||
beginning of the function, and GNU CC assumes they can be addressed
|
||
directly (perhaps with the help of base registers). Stored in the
|
||
`unchanging' field and printed as `/u'.
|
||
|
||
`CONST_CALL_P (X)'
|
||
In a `call_insn', indicates that the insn represents a call to a
|
||
const function. Stored in the `unchanging' field and printed as
|
||
`/u'.
|
||
|
||
`LABEL_PRESERVE_P (X)'
|
||
In a `code_label', indicates that the label can never be deleted.
|
||
Labels referenced by a a non-local goto will have this bit set.
|
||
Stored in the `in_struct' field and printed as `/s'.
|
||
|
||
`SCHED_GROUP_P (INSN)'
|
||
During instruction scheduling, in an insn, indicates that the
|
||
previous insn must be scheduled together with this insn. This is
|
||
used to ensure that certain groups of instructions will not be
|
||
split up by the instruction scheduling pass, for example, `use'
|
||
insns before a `call_insn' may not be separated from the
|
||
`call_insn'. Stored in the `in_struct' field and printed as `/s'.
|
||
|
||
These are the fields which the above macros refer to:
|
||
|
||
`used'
|
||
Normally, this flag is used only momentarily, at the end of RTL
|
||
generation for a function, to count the number of times an
|
||
expression appears in insns. Expressions that appear more than
|
||
once are copied, according to the rules for shared structure
|
||
(*note Sharing::.).
|
||
|
||
In a `symbol_ref', it indicates that an external declaration for
|
||
the symbol has already been written.
|
||
|
||
In a `reg', it is used by the leaf register renumbering code to
|
||
ensure that each register is only renumbered once.
|
||
|
||
`volatil'
|
||
This flag is used in `mem',`symbol_ref' and `reg' expressions and
|
||
in insns. In RTL dump files, it is printed as `/v'.
|
||
|
||
In a `mem' expression, it is 1 if the memory reference is volatile.
|
||
Volatile memory references may not be deleted, reordered or
|
||
combined.
|
||
|
||
In a `symbol_ref' expression, it is used for machine-specific
|
||
purposes.
|
||
|
||
In a `reg' expression, it is 1 if the value is a user-level
|
||
variable. 0 indicates an internal compiler temporary.
|
||
|
||
In an insn, 1 means the insn has been deleted.
|
||
|
||
`in_struct'
|
||
In `mem' expressions, it is 1 if the memory datum referred to is
|
||
all or part of a structure or array; 0 if it is (or might be) a
|
||
scalar variable. A reference through a C pointer has 0 because
|
||
the pointer might point to a scalar variable. This information
|
||
allows the compiler to determine something about possible cases of
|
||
aliasing.
|
||
|
||
In an insn in the delay slot of a branch, 1 means that this insn
|
||
is from the target of the branch.
|
||
|
||
During instruction scheduling, in an insn, 1 means that this insn
|
||
must be scheduled as part of a group together with the previous
|
||
insn.
|
||
|
||
In `reg' expressions, it is 1 if the register has its entire life
|
||
contained within the test expression of some loopl.
|
||
|
||
In `label_ref' expressions, 1 means that the referenced label is
|
||
outside the innermost loop containing the insn in which the
|
||
`label_ref' was found.
|
||
|
||
In `code_label' expressions, it is 1 if the label may never be
|
||
deleted. This is used for labels which are the target of non-local
|
||
gotos.
|
||
|
||
In an RTL dump, this flag is represented as `/s'.
|
||
|
||
`unchanging'
|
||
In `reg' and `mem' expressions, 1 means that the value of the
|
||
expression never changes.
|
||
|
||
In an insn, 1 means that this is an annulling branch.
|
||
|
||
In a `symbol_ref' expression, 1 means that this symbol addresses
|
||
something in the per-function constants pool.
|
||
|
||
In a `call_insn', 1 means that this instruction is a call to a
|
||
const function.
|
||
|
||
In an RTL dump, this flag is represented as `/u'.
|
||
|
||
`integrated'
|
||
In some kinds of expressions, including insns, this flag means the
|
||
rtl was produced by procedure integration.
|
||
|
||
In a `reg' expression, this flag indicates the register containing
|
||
the value to be returned by the current function. On machines
|
||
that pass parameters in registers, the same register number may be
|
||
used for parameters as well, but this flag is not set on such uses.
|
||
|
||
|