1 This is Info file gcc.info, produced by Makeinfo version 1.68 from the
4 This file documents the use and the internals of the GNU compiler.
6 Published by the Free Software Foundation 59 Temple Place - Suite 330
7 Boston, MA 02111-1307 USA
9 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
10 Software Foundation, Inc.
12 Permission is granted to make and distribute verbatim copies of this
13 manual provided the copyright notice and this permission notice are
14 preserved on all copies.
16 Permission is granted to copy and distribute modified versions of
17 this manual under the conditions for verbatim copying, provided also
18 that the sections entitled "GNU General Public License," "Funding for
19 Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
20 included exactly as in the original, and provided that the entire
21 resulting derived work is distributed under the terms of a permission
22 notice identical to this one.
24 Permission is granted to copy and distribute translations of this
25 manual into another language, under the above conditions for modified
26 versions, except that the sections entitled "GNU General Public
27 License," "Funding for Free Software," and "Protect Your Freedom--Fight
28 `Look And Feel'", and this permission notice, may be included in
29 translations approved by the Free Software Foundation instead of in the
33 File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top
35 Passes and Files of the Compiler
36 ********************************
38 The overall control structure of the compiler is in `toplev.c'. This
39 file is responsible for initialization, decoding arguments, opening and
40 closing files, and sequencing the passes.
42 The parsing pass is invoked only once, to parse the entire input.
43 The RTL intermediate code for a function is generated as the function
44 is parsed, a statement at a time. Each statement is read in as a
45 syntax tree and then converted to RTL; then the storage for the tree
46 for the statement is reclaimed. Storage for types (and the expressions
47 for their sizes), declarations, and a representation of the binding
48 contours and how they nest, remain until the function is finished being
49 compiled; these are all needed to output the debugging information.
51 Each time the parsing pass reads a complete function definition or
52 top-level declaration, it calls either the function
53 `rest_of_compilation', or the function `rest_of_decl_compilation' in
54 `toplev.c', which are responsible for all further processing necessary,
55 ending with output of the assembler language. All other compiler
56 passes run, in sequence, within `rest_of_compilation'. When that
57 function returns from compiling a function definition, the storage used
58 for that function definition's compilation is entirely freed, unless it
59 is an inline function (*note An Inline Function is As Fast As a Macro:
62 Here is a list of all the passes of the compiler and their source
63 files. Also included is a description of where debugging dumps can be
64 requested with `-d' options.
66 * Parsing. This pass reads the entire text of a function definition,
67 constructing partial syntax trees. This and RTL generation are no
68 longer truly separate passes (formerly they were), but it is
69 easier to think of them as separate.
71 The tree representation does not entirely follow C syntax, because
72 it is intended to support other languages as well.
74 Language-specific data type analysis is also done in this pass,
75 and every tree node that represents an expression has a data type
76 attached. Variables are represented as declaration nodes.
78 Constant folding and some arithmetic simplifications are also done
81 The language-independent source files for parsing are
82 `stor-layout.c', `fold-const.c', and `tree.c'. There are also
83 header files `tree.h' and `tree.def' which define the format of
84 the tree representation.
86 The source files to parse C are `c-parse.in', `c-decl.c',
87 `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along
88 with header files `c-lex.h', and `c-tree.h'.
90 The source files for parsing C++ are `cp-parse.y', `cp-class.c',
91 `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c',
92 `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c',
93 `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along
94 with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'.
96 The special source files for parsing Objective C are
97 `objc-parse.y', `objc-actions.c', `objc-tree.def', and
98 `objc-actions.h'. Certain C-specific files are used for this as
101 The file `c-common.c' is also used for all of the above languages.
103 * RTL generation. This is the conversion of syntax tree into RTL
104 code. It is actually done statement-by-statement during parsing,
105 but for most purposes it can be thought of as a separate pass.
107 This is where the bulk of target-parameter-dependent code is found,
108 since often it is necessary for strategies to apply only when
109 certain standard kinds of instructions are available. The purpose
110 of named instruction patterns is to provide this information to
111 the RTL generation pass.
113 Optimization is done in this pass for `if'-conditions that are
114 comparisons, boolean operations or conditional expressions. Tail
115 recursion is detected at this time also. Decisions are made about
116 how best to arrange loops and how to output `switch' statements.
118 The source files for RTL generation include `stmt.c', `calls.c',
119 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
120 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
121 machine description by the program `genemit', is used in this
122 pass. The header file `expr.h' is used for communication within
125 The header files `insn-flags.h' and `insn-codes.h', generated from
126 the machine description by the programs `genflags' and `gencodes',
127 tell this pass which standard names are available for use and
128 which patterns correspond to them.
130 Aside from debugging information output, none of the following
131 passes refers to the tree structure representation of the function
132 (only part of which is saved).
134 The decision of whether the function can and should be expanded
135 inline in its subsequent callers is made at the end of rtl
136 generation. The function must meet certain criteria, currently
137 related to the size of the function and the types and number of
138 parameters it has. Note that this function may contain loops,
139 recursive calls to itself (tail-recursive functions can be
140 inlined!), gotos, in short, all constructs supported by GNU CC.
141 The file `integrate.c' contains the code to save a function's rtl
142 for later inlining and to inline that rtl when the function is
143 called. The header file `integrate.h' is also used for this
146 The option `-dr' causes a debugging dump of the RTL code after
147 this pass. This dump file's name is made by appending `.rtl' to
150 * Jump optimization. This pass simplifies jumps to the following
151 instruction, jumps across jumps, and jumps to jumps. It deletes
152 unreferenced labels and unreachable code, except that unreachable
153 code that contains a loop is not recognized as unreachable in this
154 pass. (Such loops are deleted later in the basic block analysis.)
155 It also converts some code originally written with jumps into
156 sequences of instructions that directly set values from the
157 results of comparisons, if the machine has such instructions.
159 Jump optimization is performed two or three times. The first time
160 is immediately following RTL generation. The second time is after
161 CSE, but only if CSE says repeated jump optimization is needed.
162 The last time is right before the final pass. That time,
163 cross-jumping and deletion of no-op move instructions are done
164 together with the optimizations described above.
166 The source file of this pass is `jump.c'.
168 The option `-dj' causes a debugging dump of the RTL code after
169 this pass is run for the first time. This dump file's name is
170 made by appending `.jump' to the input file name.
172 * Register scan. This pass finds the first and last use of each
173 register, as a guide for common subexpression elimination. Its
174 source is in `regclass.c'.
176 * Jump threading. This pass detects a condition jump that branches
177 to an identical or inverse test. Such jumps can be `threaded'
178 through the second conditional test. The source code for this
179 pass is in `jump.c'. This optimization is only performed if
180 `-fthread-jumps' is enabled.
182 * Common subexpression elimination. This pass also does constant
183 propagation. Its source file is `cse.c'. If constant propagation
184 causes conditional jumps to become unconditional or to become
185 no-ops, jump optimization is run again when CSE is finished.
187 The option `-ds' causes a debugging dump of the RTL code after
188 this pass. This dump file's name is made by appending `.cse' to
191 * Loop optimization. This pass moves constant expressions out of
192 loops, and optionally does strength-reduction and loop unrolling
193 as well. Its source files are `loop.c' and `unroll.c', plus the
194 header `loop.h' used for communication between them. Loop
195 unrolling uses some functions in `integrate.c' and the header
198 The option `-dL' causes a debugging dump of the RTL code after
199 this pass. This dump file's name is made by appending `.loop' to
202 * If `-frerun-cse-after-loop' was enabled, a second common
203 subexpression elimination pass is performed after the loop
204 optimization pass. Jump threading is also done again at this time
207 The option `-dt' causes a debugging dump of the RTL code after
208 this pass. This dump file's name is made by appending `.cse2' to
211 * Stupid register allocation is performed at this point in a
212 nonoptimizing compilation. It does a little data flow analysis as
213 well. When stupid register allocation is in use, the next pass
214 executed is the reloading pass; the others in between are skipped.
215 The source file is `stupid.c'.
217 * Data flow analysis (`flow.c'). This pass divides the program into
218 basic blocks (and in the process deletes unreachable loops); then
219 it computes which pseudo-registers are live at each point in the
220 program, and makes the first instruction that uses a value point at
221 the instruction that computed the value.
223 This pass also deletes computations whose results are never used,
224 and combines memory references with add or subtract instructions
225 to make autoincrement or autodecrement addressing.
227 The option `-df' causes a debugging dump of the RTL code after
228 this pass. This dump file's name is made by appending `.flow' to
229 the input file name. If stupid register allocation is in use, this
230 dump file reflects the full results of such allocation.
232 * Instruction combination (`combine.c'). This pass attempts to
233 combine groups of two or three instructions that are related by
234 data flow into single instructions. It combines the RTL
235 expressions for the instructions by substitution, simplifies the
236 result using algebra, and then attempts to match the result
237 against the machine description.
239 The option `-dc' causes a debugging dump of the RTL code after
240 this pass. This dump file's name is made by appending `.combine'
241 to the input file name.
243 * Instruction scheduling (`sched.c'). This pass looks for
244 instructions whose output will not be available by the time that
245 it is used in subsequent instructions. (Memory loads and floating
246 point instructions often have this behavior on RISC machines). It
247 re-orders instructions within a basic block to try to separate the
248 definition and use of items that otherwise would cause pipeline
251 Instruction scheduling is performed twice. The first time is
252 immediately after instruction combination and the second is
253 immediately after reload.
255 The option `-dS' causes a debugging dump of the RTL code after this
256 pass is run for the first time. The dump file's name is made by
257 appending `.sched' to the input file name.
259 * Register class preferencing. The RTL code is scanned to find out
260 which register class is best for each pseudo register. The source
261 file is `regclass.c'.
263 * Local register allocation (`local-alloc.c'). This pass allocates
264 hard registers to pseudo registers that are used only within one
265 basic block. Because the basic block is linear, it can use fast
266 and powerful techniques to do a very good job.
268 The option `-dl' causes a debugging dump of the RTL code after
269 this pass. This dump file's name is made by appending `.lreg' to
272 * Global register allocation (`global.c'). This pass allocates hard
273 registers for the remaining pseudo registers (those whose life
274 spans are not contained in one basic block).
276 * Reloading. This pass renumbers pseudo registers with the hardware
277 registers numbers they were allocated. Pseudo registers that did
278 not get hard registers are replaced with stack slots. Then it
279 finds instructions that are invalid because a value has failed to
280 end up in a register, or has ended up in a register of the wrong
281 kind. It fixes up these instructions by reloading the
282 problematical values temporarily into registers. Additional
283 instructions are generated to do the copying.
285 The reload pass also optionally eliminates the frame pointer and
286 inserts instructions to save and restore call-clobbered registers
289 Source files are `reload.c' and `reload1.c', plus the header
290 `reload.h' used for communication between them.
292 The option `-dg' causes a debugging dump of the RTL code after
293 this pass. This dump file's name is made by appending `.greg' to
296 * Instruction scheduling is repeated here to try to avoid pipeline
297 stalls due to memory loads generated for spilled pseudo registers.
299 The option `-dR' causes a debugging dump of the RTL code after
300 this pass. This dump file's name is made by appending `.sched2'
301 to the input file name.
303 * Jump optimization is repeated, this time including cross-jumping
304 and deletion of no-op move instructions.
306 The option `-dJ' causes a debugging dump of the RTL code after
307 this pass. This dump file's name is made by appending `.jump2' to
310 * Delayed branch scheduling. This optional pass attempts to find
311 instructions that can go into the delay slots of other
312 instructions, usually jumps and calls. The source file name is
315 The option `-dd' causes a debugging dump of the RTL code after
316 this pass. This dump file's name is made by appending `.dbr' to
319 * Conversion from usage of some hard registers to usage of a register
320 stack may be done at this point. Currently, this is supported only
321 for the floating-point registers of the Intel 80387 coprocessor.
322 The source file name is `reg-stack.c'.
324 The options `-dk' causes a debugging dump of the RTL code after
325 this pass. This dump file's name is made by appending `.stack' to
328 * Final. This pass outputs the assembler code for the function. It
329 is also responsible for identifying spurious test and compare
330 instructions. Machine-specific peephole optimizations are
331 performed at the same time. The function entry and exit sequences
332 are generated directly as assembler code in this pass; they never
335 The source files are `final.c' plus `insn-output.c'; the latter is
336 generated automatically from the machine description by the tool
337 `genoutput'. The header file `conditions.h' is used for
338 communication between these files.
340 * Debugging information output. This is run after final because it
341 must output the stack slot offsets for pseudo registers that did
342 not get hard registers. Source files are `dbxout.c' for DBX
343 symbol table format, `sdbout.c' for SDB symbol table format, and
344 `dwarfout.c' for DWARF symbol table format.
346 Some additional files are used by all or many passes:
348 * Every pass uses `machmode.def' and `machmode.h' which define the
351 * Several passes use `real.h', which defines the default
352 representation of floating point constants and how to operate on
355 * All the passes that work with RTL use the header files `rtl.h' and
356 `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also
357 use these files to read and work with the machine description RTL.
359 * Several passes refer to the header file `insn-config.h' which
360 contains a few parameters (C macro definitions) generated
361 automatically from the machine description RTL by the tool
364 * Several passes use the instruction recognizer, which consists of
365 `recog.c' and `recog.h', plus the files `insn-recog.c' and
366 `insn-extract.c' that are generated automatically from the machine
367 description by the tools `genrecog' and `genextract'.
369 * Several passes use the header files `regs.h' which defines the
370 information recorded about pseudo register usage, and
371 `basic-block.h' which defines the information recorded about basic
374 * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
375 with a bit for each hard register, and some macros to manipulate
376 it. This type is just `int' if the machine has few enough hard
377 registers; otherwise it is an array of `int' and some of the
378 macros expand into loops.
380 * Several passes use instruction attributes. A definition of the
381 attributes defined for a particular machine is in file
382 `insn-attr.h', which is generated from the machine description by
383 the program `genattr'. The file `insn-attrtab.c' contains
384 subroutines to obtain the attribute values for insns. It is
385 generated from the machine description by the program `genattrtab'.
388 File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top
393 Most of the work of the compiler is done on an intermediate
394 representation called register transfer language. In this language,
395 the instructions to be output are described, pretty much one by one, in
396 an algebraic form that describes what the instruction does.
398 RTL is inspired by Lisp lists. It has both an internal form, made
399 up of structures that point at other structures, and a textual form
400 that is used in the machine description and in printed debugging dumps.
401 The textual form uses nested parentheses to indicate the pointers in
406 * RTL Objects:: Expressions vs vectors vs strings vs integers.
407 * Accessors:: Macros to access expression operands or vector elts.
408 * Flags:: Other flags in an RTL expression.
409 * Machine Modes:: Describing the size and format of a datum.
410 * Constants:: Expressions with constant values.
411 * Regs and Memory:: Expressions representing register contents or memory.
412 * Arithmetic:: Expressions representing arithmetic on other expressions.
413 * Comparisons:: Expressions representing comparison of expressions.
414 * Bit Fields:: Expressions representing bitfields in memory or reg.
415 * Conversions:: Extending, truncating, floating or fixing.
416 * RTL Declarations:: Declaring volatility, constancy, etc.
417 * Side Effects:: Expressions for storing in registers, etc.
418 * Incdec:: Embedded side-effects for autoincrement addressing.
419 * Assembler:: Representing `asm' with operands.
420 * Insns:: Expression types for entire insns.
421 * Calls:: RTL representation of function call insns.
422 * Sharing:: Some expressions are unique; others *must* be copied.
423 * Reading RTL:: Reading textual RTL from a file.
426 File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL
431 RTL uses five kinds of objects: expressions, integers, wide integers,
432 strings and vectors. Expressions are the most important ones. An RTL
433 expression ("RTX", for short) is a C structure, but it is usually
434 referred to with a pointer; a type that is given the typedef name `rtx'.
436 An integer is simply an `int'; their written form uses decimal
437 digits. A wide integer is an integral object whose type is
438 `HOST_WIDE_INT' (*note Config::.); their written form uses decimal
441 A string is a sequence of characters. In core it is represented as a
442 `char *' in usual C fashion, and it is written in C syntax as well.
443 However, strings in RTL may never be null. If you write an empty
444 string in a machine description, it is represented in core as a null
445 pointer rather than as a pointer to a null character. In certain
446 contexts, these null pointers instead of strings are valid. Within RTL
447 code, strings are most commonly found inside `symbol_ref' expressions,
448 but they appear in other contexts in the RTL expressions that make up
449 machine descriptions.
451 A vector contains an arbitrary number of pointers to expressions.
452 The number of elements in the vector is explicitly present in the
453 vector. The written form of a vector consists of square brackets
454 (`[...]') surrounding the elements, in sequence and with whitespace
455 separating them. Vectors of length zero are not created; null pointers
458 Expressions are classified by "expression codes" (also called RTX
459 codes). The expression code is a name defined in `rtl.def', which is
460 also (in upper case) a C enumeration constant. The possible expression
461 codes and their meanings are machine-independent. The code of an RTX
462 can be extracted with the macro `GET_CODE (X)' and altered with
463 `PUT_CODE (X, NEWCODE)'.
465 The expression code determines how many operands the expression
466 contains, and what kinds of objects they are. In RTL, unlike Lisp, you
467 cannot tell by looking at an operand what kind of object it is.
468 Instead, you must know from its context--from the expression code of
469 the containing expression. For example, in an expression of code
470 `subreg', the first operand is to be regarded as an expression and the
471 second operand as an integer. In an expression of code `plus', there
472 are two operands, both of which are to be regarded as expressions. In
473 a `symbol_ref' expression, there is one operand, which is to be
474 regarded as a string.
476 Expressions are written as parentheses containing the name of the
477 expression type, its flags and machine mode if any, and then the
478 operands of the expression (separated by spaces).
480 Expression code names in the `md' file are written in lower case,
481 but when they appear in C code they are written in upper case. In this
482 manual, they are shown as follows: `const_int'.
484 In a few contexts a null pointer is valid where an expression is
485 normally wanted. The written form of this is `(nil)'.
488 File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL
493 For each expression type `rtl.def' specifies the number of contained
494 objects and their kinds, with four possibilities: `e' for expression
495 (actually a pointer to an expression), `i' for integer, `w' for wide
496 integer, `s' for string, and `E' for vector of expressions. The
497 sequence of letters for an expression code is called its "format".
498 Thus, the format of `subreg' is `ei'.
500 A few other format characters are used occasionally:
503 `u' is equivalent to `e' except that it is printed differently in
504 debugging dumps. It is used for pointers to insns.
507 `n' is equivalent to `i' except that it is printed differently in
508 debugging dumps. It is used for the line number or code number of
512 `S' indicates a string which is optional. In the RTL objects in
513 core, `S' is equivalent to `s', but when the object is read, from
514 an `md' file, the string value of this operand may be omitted. An
515 omitted string is taken to be the null string.
518 `V' indicates a vector which is optional. In the RTL objects in
519 core, `V' is equivalent to `E', but when the object is read from
520 an `md' file, the vector value of this operand may be omitted. An
521 omitted vector is effectively the same as a vector of no elements.
524 `0' means a slot whose contents do not fit any normal category.
525 `0' slots are not printed at all in dumps, and are often used in
526 special ways by small parts of the compiler.
528 There are macros to get the number of operands, the format, and the
529 class of an expression code:
531 `GET_RTX_LENGTH (CODE)'
532 Number of operands of an RTX of code CODE.
534 `GET_RTX_FORMAT (CODE)'
535 The format of an RTX of code CODE, as a C string.
537 `GET_RTX_CLASS (CODE)'
538 A single character representing the type of RTX operation that code
541 The following classes are defined:
544 An RTX code that represents an actual object, such as `reg' or
545 `mem'. `subreg' is not in this class.
548 An RTX code for a comparison. The codes in this class are
549 `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU',
553 An RTX code for a unary arithmetic operation, such as `neg'.
556 An RTX code for a commutative binary operation, other than
557 `NE' and `EQ' (which have class `<').
560 An RTX code for a noncommutative binary operation, such as
564 An RTX code for a bitfield operation, either `ZERO_EXTRACT' or
568 An RTX code for other three input operations, such as
572 An RTX code for a machine insn (`INSN', `JUMP_INSN', and
576 An RTX code for something that matches in insns, such as
582 Operands of expressions are accessed using the macros `XEXP',
583 `XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments:
584 an expression-pointer (RTX) and an operand number (counting from zero).
589 accesses operand 2 of expression X, as an expression.
593 accesses the same operand as an integer. `XSTR', used in the same
594 fashion, would access it as a string.
596 Any operand can be accessed as an integer, as an expression or as a
597 string. You must choose the correct method of access for the kind of
598 value actually stored in the operand. You would do this based on the
599 expression code of the containing expression. That is also how you
600 would know how many operands there are.
602 For example, if X is a `subreg' expression, you know that it has two
603 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
604 1)'. If you did `XINT (X, 0)', you would get the address of the
605 expression operand but cast as an integer; that might occasionally be
606 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
607 (X, 1)' would also compile without error, and would return the second,
608 integer operand cast as an expression pointer, which would probably
609 result in a crash when accessed. Nothing stops you from writing `XEXP
610 (X, 28)' either, but this will access memory past the end of the
611 expression with unpredictable results.
613 Access to operands which are vectors is more complicated. You can
614 use the macro `XVEC' to get the vector-pointer itself, or the macros
615 `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
618 Access the vector-pointer which is operand number IDX in EXP.
621 Access the length (number of elements) in the vector which is in
622 operand number IDX in EXP. This value is an `int'.
624 `XVECEXP (EXP, IDX, ELTNUM)'
625 Access element number ELTNUM in the vector which is in operand
626 number IDX in EXP. This value is an RTX.
628 It is up to you to make sure that ELTNUM is not negative and is
629 less than `XVECLEN (EXP, IDX)'.
631 All the macros defined in this section expand into lvalues and
632 therefore can be used to assign the operands, lengths and vector
633 elements as well as to access them.
636 File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL
638 Flags in an RTL Expression
639 ==========================
641 RTL expressions contain several flags (one-bit bitfields) that are
642 used in certain types of expression. Most often they are accessed with
643 the following macros:
646 In `mem' expressions, nonzero for volatile memory references.
647 Stored in the `volatil' field and printed as `/v'.
649 `MEM_IN_STRUCT_P (X)'
650 In `mem' expressions, nonzero for reference to an entire
651 structure, union or array, or to a component of one. Zero for
652 references to a scalar variable or through a pointer to a scalar.
653 Stored in the `in_struct' field and printed as `/s'.
656 In `reg' expressions, nonzero if this register's entire life is
657 contained in the exit test code for some loop. Stored in the
658 `in_struct' field and printed as `/s'.
661 In a `reg', nonzero if it corresponds to a variable present in the
662 user's source code. Zero for temporaries generated internally by
663 the compiler. Stored in the `volatil' field and printed as `/v'.
665 `REG_FUNCTION_VALUE_P (X)'
666 Nonzero in a `reg' if it is the place in which this function's
667 value is going to be returned. (This happens only in a hard
668 register.) Stored in the `integrated' field and printed as `/i'.
670 The same hard register may be used also for collecting the values
671 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
674 `SUBREG_PROMOTED_VAR_P'
675 Nonzero in a `subreg' if it was made when accessing an object that
676 was promoted to a wider mode in accord with the `PROMOTED_MODE'
677 machine description macro (*note Storage Layout::.). In this
678 case, the mode of the `subreg' is the declared mode of the object
679 and the mode of `SUBREG_REG' is the mode of the register that
680 holds the object. Promoted variables are always either sign- or
681 zero-extended to the wider mode on every assignment. Stored in
682 the `in_struct' field and printed as `/s'.
684 `SUBREG_PROMOTED_UNSIGNED_P'
685 Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if
686 the object being referenced is kept zero-extended and zero if it
687 is kept sign-extended. Stored in the `unchanging' field and
690 `RTX_UNCHANGING_P (X)'
691 Nonzero in a `reg' or `mem' if the value is not changed. (This
692 flag is not set for memory references via pointers to constants.
693 Such pointers only guarantee that the object will not be changed
694 explicitly by the current function. The object might be changed by
695 other functions or by aliasing.) Stored in the `unchanging' field
698 `RTX_INTEGRATED_P (INSN)'
699 Nonzero in an insn if it resulted from an in-line function call.
700 Stored in the `integrated' field and printed as `/i'. This may be
701 deleted; nothing currently depends on it.
703 `SYMBOL_REF_USED (X)'
704 In a `symbol_ref', indicates that X has been used. This is
705 normally only used to ensure that X is only declared external
706 once. Stored in the `used' field.
708 `SYMBOL_REF_FLAG (X)'
709 In a `symbol_ref', this is used as a flag for machine-specific
710 purposes. Stored in the `volatil' field and printed as `/v'.
712 `LABEL_OUTSIDE_LOOP_P'
713 In `label_ref' expressions, nonzero if this is a reference to a
714 label that is outside the innermost loop containing the reference
715 to the label. Stored in the `in_struct' field and printed as `/s'.
717 `INSN_DELETED_P (INSN)'
718 In an insn, nonzero if the insn has been deleted. Stored in the
719 `volatil' field and printed as `/v'.
721 `INSN_ANNULLED_BRANCH_P (INSN)'
722 In an `insn' in the delay slot of a branch insn, indicates that an
723 annulling branch should be used. See the discussion under
724 `sequence' below. Stored in the `unchanging' field and printed as
727 `INSN_FROM_TARGET_P (INSN)'
728 In an `insn' in a delay slot of a branch, indicates that the insn
729 is from the target of the branch. If the branch insn has
730 `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if
731 the branch is taken. For annulled branches with this bit clear,
732 the insn should be executed only if the branch is not taken.
733 Stored in the `in_struct' field and printed as `/s'.
735 `CONSTANT_POOL_ADDRESS_P (X)'
736 Nonzero in a `symbol_ref' if it refers to part of the current
737 function's "constants pool". These are addresses close to the
738 beginning of the function, and GNU CC assumes they can be addressed
739 directly (perhaps with the help of base registers). Stored in the
740 `unchanging' field and printed as `/u'.
743 In a `call_insn', indicates that the insn represents a call to a
744 const function. Stored in the `unchanging' field and printed as
747 `LABEL_PRESERVE_P (X)'
748 In a `code_label', indicates that the label can never be deleted.
749 Labels referenced by a non-local goto will have this bit set.
750 Stored in the `in_struct' field and printed as `/s'.
752 `SCHED_GROUP_P (INSN)'
753 During instruction scheduling, in an insn, indicates that the
754 previous insn must be scheduled together with this insn. This is
755 used to ensure that certain groups of instructions will not be
756 split up by the instruction scheduling pass, for example, `use'
757 insns before a `call_insn' may not be separated from the
758 `call_insn'. Stored in the `in_struct' field and printed as `/s'.
760 These are the fields which the above macros refer to:
763 Normally, this flag is used only momentarily, at the end of RTL
764 generation for a function, to count the number of times an
765 expression appears in insns. Expressions that appear more than
766 once are copied, according to the rules for shared structure
769 In a `symbol_ref', it indicates that an external declaration for
770 the symbol has already been written.
772 In a `reg', it is used by the leaf register renumbering code to
773 ensure that each register is only renumbered once.
776 This flag is used in `mem', `symbol_ref' and `reg' expressions and
777 in insns. In RTL dump files, it is printed as `/v'.
779 In a `mem' expression, it is 1 if the memory reference is volatile.
780 Volatile memory references may not be deleted, reordered or
783 In a `symbol_ref' expression, it is used for machine-specific
786 In a `reg' expression, it is 1 if the value is a user-level
787 variable. 0 indicates an internal compiler temporary.
789 In an insn, 1 means the insn has been deleted.
792 In `mem' expressions, it is 1 if the memory datum referred to is
793 all or part of a structure or array; 0 if it is (or might be) a
794 scalar variable. A reference through a C pointer has 0 because
795 the pointer might point to a scalar variable. This information
796 allows the compiler to determine something about possible cases of
799 In an insn in the delay slot of a branch, 1 means that this insn
800 is from the target of the branch.
802 During instruction scheduling, in an insn, 1 means that this insn
803 must be scheduled as part of a group together with the previous
806 In `reg' expressions, it is 1 if the register has its entire life
807 contained within the test expression of some loop.
809 In `subreg' expressions, 1 means that the `subreg' is accessing an
810 object that has had its mode promoted from a wider mode.
812 In `label_ref' expressions, 1 means that the referenced label is
813 outside the innermost loop containing the insn in which the
814 `label_ref' was found.
816 In `code_label' expressions, it is 1 if the label may never be
817 deleted. This is used for labels which are the target of
820 In an RTL dump, this flag is represented as `/s'.
823 In `reg' and `mem' expressions, 1 means that the value of the
824 expression never changes.
826 In `subreg' expressions, it is 1 if the `subreg' references an
827 unsigned object whose mode has been promoted to a wider mode.
829 In an insn, 1 means that this is an annulling branch.
831 In a `symbol_ref' expression, 1 means that this symbol addresses
832 something in the per-function constants pool.
834 In a `call_insn', 1 means that this instruction is a call to a
837 In an RTL dump, this flag is represented as `/u'.
840 In some kinds of expressions, including insns, this flag means the
841 rtl was produced by procedure integration.
843 In a `reg' expression, this flag indicates the register containing
844 the value to be returned by the current function. On machines
845 that pass parameters in registers, the same register number may be
846 used for parameters as well, but this flag is not set on such uses.
849 File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
854 A machine mode describes a size of data object and the
855 representation used for it. In the C code, machine modes are
856 represented by an enumeration type, `enum machine_mode', defined in
857 `machmode.def'. Each RTL expression has room for a machine mode and so
858 do certain kinds of tree expressions (declarations and types, to be
861 In debugging dumps and machine descriptions, the machine mode of an
862 RTL expression is written after the expression code with a colon to
863 separate them. The letters `mode' which appear at the end of each
864 machine mode name are omitted. For example, `(reg:SI 38)' is a `reg'
865 expression with machine mode `SImode'. If the mode is `VOIDmode', it
866 is not written at all.
868 Here is a table of machine modes. The term "byte" below refers to an
869 object of `BITS_PER_UNIT' bits (*note Storage Layout::.).
872 "Quarter-Integer" mode represents a single byte treated as an
876 "Half-Integer" mode represents a two-byte integer.
879 "Partial Single Integer" mode represents an integer which occupies
880 four bytes but which doesn't really use all four. On some
881 machines, this is the right mode to use for pointers.
884 "Single Integer" mode represents a four-byte integer.
887 "Partial Double Integer" mode represents an integer which occupies
888 eight bytes but which doesn't really use all eight. On some
889 machines, this is the right mode to use for certain pointers.
892 "Double Integer" mode represents an eight-byte integer.
895 "Tetra Integer" (?) mode represents a sixteen-byte integer.
898 "Single Floating" mode represents a single-precision (four byte)
899 floating point number.
902 "Double Floating" mode represents a double-precision (eight byte)
903 floating point number.
906 "Extended Floating" mode represents a triple-precision (twelve
907 byte) floating point number. This mode is used for IEEE extended
908 floating point. On some systems not all bits within these bytes
909 will actually be used.
912 "Tetra Floating" mode represents a quadruple-precision (sixteen
913 byte) floating point number.
916 "Condition Code" mode represents the value of a condition code,
917 which is a machine-specific set of bits used to represent the
918 result of a comparison operation. Other machine-specific modes
919 may also be used for the condition code. These modes are not used
920 on machines that use `cc0' (see *note Condition Code::.).
923 "Block" mode represents values that are aggregates to which none of
924 the other modes apply. In RTL, only memory references can have
925 this mode, and only if they appear in string-move or vector
926 instructions. On machines which have no such instructions,
927 `BLKmode' will not appear in RTL.
930 Void mode means the absence of a mode or an unspecified mode. For
931 example, RTL expressions of code `const_int' have mode `VOIDmode'
932 because they can be taken to have whatever mode the context
933 requires. In debugging dumps of RTL, `VOIDmode' is expressed by
934 the absence of any mode.
936 `SCmode, DCmode, XCmode, TCmode'
937 These modes stand for a complex number represented as a pair of
938 floating point values. The floating point values are in `SFmode',
939 `DFmode', `XFmode', and `TFmode', respectively.
941 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
942 These modes stand for a complex number represented as a pair of
943 integer values. The integer values are in `QImode', `HImode',
944 `SImode', `DImode', `TImode', and `OImode', respectively.
946 The machine description defines `Pmode' as a C macro which expands
947 into the machine mode used for addresses. Normally this is the mode
948 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
950 The only modes which a machine description must support are
951 `QImode', and the modes corresponding to `BITS_PER_WORD',
952 `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to
953 use `DImode' for 8-byte structures and unions, but this can be
954 prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'.
955 Alternatively, you can have the compiler use `TImode' for 16-byte
956 structures and unions. Likewise, you can arrange for the C type `short
957 int' to avoid using `HImode'.
959 Very few explicit references to machine modes remain in the compiler
960 and these few references will soon be removed. Instead, the machine
961 modes are divided into mode classes. These are represented by the
962 enumeration type `enum mode_class' defined in `machmode.h'. The
963 possible mode classes are:
966 Integer modes. By default these are `QImode', `HImode', `SImode',
967 `DImode', and `TImode'.
970 The "partial integer" modes, `PSImode' and `PDImode'.
973 floating point modes. By default these are `SFmode', `DFmode',
974 `XFmode' and `TFmode'.
977 Complex integer modes. (These are not currently implemented).
980 Complex floating point modes. By default these are `SCmode',
981 `DCmode', `XCmode', and `TCmode'.
984 Algol or Pascal function variables including a static chain.
985 (These are not currently implemented).
988 Modes representing condition code values. These are `CCmode' plus
989 any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump
990 Patterns::, also see *Note Condition Code::.
993 This is a catchall mode class for modes which don't fit into the
994 above classes. Currently `VOIDmode' and `BLKmode' are in
997 Here are some C macros that relate to machine modes:
1000 Returns the machine mode of the RTX X.
1002 `PUT_MODE (X, NEWMODE)'
1003 Alters the machine mode of the RTX X to be NEWMODE.
1006 Stands for the number of machine modes available on the target
1007 machine. This is one greater than the largest numeric value of any
1011 Returns the name of mode M as a string.
1013 `GET_MODE_CLASS (M)'
1014 Returns the mode class of mode M.
1016 `GET_MODE_WIDER_MODE (M)'
1017 Returns the next wider natural mode. For example, the expression
1018 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
1021 Returns the size in bytes of a datum of mode M.
1023 `GET_MODE_BITSIZE (M)'
1024 Returns the size in bits of a datum of mode M.
1027 Returns a bitmask containing 1 for all bits in a word that fit
1028 within mode M. This macro can only be used for modes whose
1029 bitsize is less than or equal to `HOST_BITS_PER_INT'.
1031 `GET_MODE_ALIGNMENT (M))'
1032 Return the required alignment, in bits, for an object of mode M.
1034 `GET_MODE_UNIT_SIZE (M)'
1035 Returns the size in bytes of the subunits of a datum of mode M.
1036 This is the same as `GET_MODE_SIZE' except in the case of complex
1037 modes. For them, the unit size is the size of the real or
1040 `GET_MODE_NUNITS (M)'
1041 Returns the number of units contained in a mode, i.e.,
1042 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
1044 `GET_CLASS_NARROWEST_MODE (C)'
1045 Returns the narrowest mode in mode class C.
1047 The global variables `byte_mode' and `word_mode' contain modes whose
1048 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
1049 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
1050 and `SImode', respectively.
1053 File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
1055 Constant Expression Types
1056 =========================
1058 The simplest RTL expressions are those that represent constant
1062 This type of expression represents the integer value I. I is
1063 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
1064 which is equivalent to `XWINT (EXP, 0)'.
1066 There is only one expression object for the integer value zero; it
1067 is the value of the variable `const0_rtx'. Likewise, the only
1068 expression for integer value one is found in `const1_rtx', the only
1069 expression for integer value two is found in `const2_rtx', and the
1070 only expression for integer value negative one is found in
1071 `constm1_rtx'. Any attempt to create an expression of code
1072 `const_int' and value zero, one, two or negative one will return
1073 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
1076 Similarly, there is only one object for the integer whose value is
1077 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
1078 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
1079 point to the same object. If `STORE_FLAG_VALUE' is -1,
1080 `const_true_rtx' and `constm1_rtx' will point to the same object.
1082 `(const_double:M ADDR I0 I1 ...)'
1083 Represents either a floating-point constant of mode M or an
1084 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
1085 bits but small enough to fit within twice that number of bits (GNU
1086 CC does not provide a mechanism to represent even larger
1087 constants). In the latter case, M will be `VOIDmode'.
1089 ADDR is used to contain the `mem' expression that corresponds to
1090 the location in memory that at which the constant can be found. If
1091 it has not been allocated a memory location, but is on the chain
1092 of all `const_double' expressions in this compilation (maintained
1093 using an undisplayed field), ADDR contains `const0_rtx'. If it is
1094 not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily
1095 accessed with the macro `CONST_DOUBLE_MEM' and the chain field via
1096 `CONST_DOUBLE_CHAIN'.
1098 If M is `VOIDmode', the bits of the value are stored in I0 and I1.
1099 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
1100 I1 with `CONST_DOUBLE_HIGH'.
1102 If the constant is floating point (regardless of its precision),
1103 then the number of integers used to store the value depends on the
1104 size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The
1105 integers represent a floating point number, but not precisely in
1106 the target machine's or host machine's floating point format. To
1107 convert them to the precise bit pattern used by the target
1108 machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends
1109 (*note Data Output::.).
1111 The macro `CONST0_RTX (MODE)' refers to an expression with value 0
1112 in mode MODE. If mode MODE is of mode class `MODE_INT', it
1113 returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE'
1114 expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)'
1115 refers to an expression with value 1 in mode MODE and similarly
1118 `(const_string STR)'
1119 Represents a constant string with value STR. Currently this is
1120 used only for insn attributes (*note Insn Attributes::.) since
1121 constant strings in C are placed in memory.
1123 `(symbol_ref:MODE SYMBOL)'
1124 Represents the value of an assembler label for data. SYMBOL is a
1125 string that describes the name of the assembler label. If it
1126 starts with a `*', the label is the rest of SYMBOL not including
1127 the `*'. Otherwise, the label is SYMBOL, usually prefixed with
1130 The `symbol_ref' contains a mode, which is usually `Pmode'.
1131 Usually that is the only mode for which a symbol is directly valid.
1134 Represents the value of an assembler label for code. It contains
1135 one operand, an expression, which must be a `code_label' that
1136 appears in the instruction sequence to identify the place where
1137 the label should go.
1139 The reason for using a distinct expression type for code label
1140 references is so that jump optimization can distinguish them.
1143 Represents a constant that is the result of an assembly-time
1144 arithmetic computation. The operand, EXP, is an expression that
1145 contains only constants (`const_int', `symbol_ref' and `label_ref'
1146 expressions) combined with `plus' and `minus'. However, not all
1147 combinations are valid, since the assembler cannot do arbitrary
1148 arithmetic on relocatable symbols.
1150 M should be `Pmode'.
1153 Represents the high-order bits of EXP, usually a `symbol_ref'.
1154 The number of bits is machine-dependent and is normally the number
1155 of bits specified in an instruction that initializes the high
1156 order bits of a register. It is used with `lo_sum' to represent
1157 the typical two-instruction sequence used in RISC machines to
1158 reference a global memory location.
1160 M should be `Pmode'.
OSDN Git Service
