[11287] | 1 | This is Info file gcc.info, produced by Makeinfo version 1.67 from the |
---|
| 2 | input file gcc.texi. |
---|
[8833] | 3 | |
---|
| 4 | This file documents the use and the internals of the GNU compiler. |
---|
| 5 | |
---|
| 6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
| 7 | Boston, MA 02111-1307 USA |
---|
| 8 | |
---|
[11287] | 9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
---|
| 10 | Free Software Foundation, Inc. |
---|
[8833] | 11 | |
---|
| 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. |
---|
| 15 | |
---|
| 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. |
---|
| 23 | |
---|
| 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 |
---|
| 30 | original English. |
---|
| 31 | |
---|
| 32 | |
---|
[11287] | 33 | File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top |
---|
| 34 | |
---|
| 35 | Passes and Files of the Compiler |
---|
| 36 | ******************************** |
---|
| 37 | |
---|
| 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. |
---|
| 41 | |
---|
| 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. |
---|
| 50 | |
---|
| 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: |
---|
| 60 | Inline.). |
---|
| 61 | |
---|
| 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. |
---|
| 65 | |
---|
| 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. |
---|
| 70 | |
---|
| 71 | The tree representation does not entirely follow C syntax, because |
---|
| 72 | it is intended to support other languages as well. |
---|
| 73 | |
---|
| 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. |
---|
| 77 | |
---|
| 78 | Constant folding and some arithmetic simplifications are also done |
---|
| 79 | during this pass. |
---|
| 80 | |
---|
| 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. |
---|
| 85 | |
---|
| 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'. |
---|
| 89 | |
---|
| 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'. |
---|
| 95 | |
---|
| 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 |
---|
| 99 | well. |
---|
| 100 | |
---|
| 101 | The file `c-common.c' is also used for all of the above languages. |
---|
| 102 | |
---|
| 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. |
---|
| 106 | |
---|
| 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. |
---|
| 112 | |
---|
| 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. |
---|
| 117 | |
---|
| 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 |
---|
| 123 | this pass. |
---|
| 124 | |
---|
| 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. |
---|
| 129 | |
---|
| 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). |
---|
| 133 | |
---|
| 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 |
---|
| 144 | purpose. |
---|
| 145 | |
---|
| 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 |
---|
| 148 | the input file name. |
---|
| 149 | |
---|
| 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. |
---|
| 158 | |
---|
| 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. |
---|
| 165 | |
---|
| 166 | The source file of this pass is `jump.c'. |
---|
| 167 | |
---|
| 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. |
---|
| 171 | |
---|
| 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'. |
---|
| 175 | |
---|
| 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. |
---|
| 181 | |
---|
| 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. |
---|
| 186 | |
---|
| 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 |
---|
| 189 | the input file name. |
---|
| 190 | |
---|
| 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 |
---|
| 196 | `integrate.h'. |
---|
| 197 | |
---|
| 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 |
---|
| 200 | the input file name. |
---|
| 201 | |
---|
| 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 |
---|
| 205 | if it was specified. |
---|
| 206 | |
---|
| 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 |
---|
| 209 | the input file name. |
---|
| 210 | |
---|
| 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'. |
---|
| 216 | |
---|
| 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. |
---|
| 222 | |
---|
| 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. |
---|
| 226 | |
---|
| 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. |
---|
| 231 | |
---|
| 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. |
---|
| 238 | |
---|
| 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. |
---|
| 242 | |
---|
| 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 |
---|
| 249 | stalls. |
---|
| 250 | |
---|
| 251 | Instruction scheduling is performed twice. The first time is |
---|
| 252 | immediately after instruction combination and the second is |
---|
| 253 | immediately after reload. |
---|
| 254 | |
---|
| 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. |
---|
| 258 | |
---|
| 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'. |
---|
| 262 | |
---|
| 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. |
---|
| 267 | |
---|
| 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 |
---|
| 270 | the input file name. |
---|
| 271 | |
---|
| 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). |
---|
| 275 | |
---|
| 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. |
---|
| 284 | |
---|
| 285 | The reload pass also optionally eliminates the frame pointer and |
---|
| 286 | inserts instructions to save and restore call-clobbered registers |
---|
| 287 | around calls. |
---|
| 288 | |
---|
| 289 | Source files are `reload.c' and `reload1.c', plus the header |
---|
| 290 | `reload.h' used for communication between them. |
---|
| 291 | |
---|
| 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 |
---|
| 294 | the input file name. |
---|
| 295 | |
---|
| 296 | * Instruction scheduling is repeated here to try to avoid pipeline |
---|
| 297 | stalls due to memory loads generated for spilled pseudo registers. |
---|
| 298 | |
---|
| 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. |
---|
| 302 | |
---|
| 303 | * Jump optimization is repeated, this time including cross-jumping |
---|
| 304 | and deletion of no-op move instructions. |
---|
| 305 | |
---|
| 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 |
---|
| 308 | the input file name. |
---|
| 309 | |
---|
| 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 |
---|
| 313 | `reorg.c'. |
---|
| 314 | |
---|
| 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 |
---|
| 317 | the input file name. |
---|
| 318 | |
---|
| 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'. |
---|
| 323 | |
---|
| 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 |
---|
| 326 | the input file name. |
---|
| 327 | |
---|
| 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 |
---|
| 333 | exist as RTL. |
---|
| 334 | |
---|
| 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. |
---|
| 339 | |
---|
| 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. |
---|
| 345 | |
---|
| 346 | Some additional files are used by all or many passes: |
---|
| 347 | |
---|
| 348 | * Every pass uses `machmode.def' and `machmode.h' which define the |
---|
| 349 | machine modes. |
---|
| 350 | |
---|
| 351 | * Several passes use `real.h', which defines the default |
---|
| 352 | representation of floating point constants and how to operate on |
---|
| 353 | them. |
---|
| 354 | |
---|
| 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. |
---|
| 358 | |
---|
| 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 |
---|
| 362 | `genconfig'. |
---|
| 363 | |
---|
| 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'. |
---|
| 368 | |
---|
| 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 |
---|
| 372 | blocks. |
---|
| 373 | |
---|
| 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. |
---|
| 379 | |
---|
| 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'. |
---|
| 386 | |
---|
| 387 | |
---|
| 388 | File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top |
---|
| 389 | |
---|
| 390 | RTL Representation |
---|
| 391 | ****************** |
---|
| 392 | |
---|
| 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. |
---|
| 397 | |
---|
| 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 |
---|
| 402 | the internal form. |
---|
| 403 | |
---|
| 404 | * Menu: |
---|
| 405 | |
---|
| 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. |
---|
| 424 | |
---|
| 425 | |
---|
| 426 | File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL |
---|
| 427 | |
---|
| 428 | RTL Object Types |
---|
| 429 | ================ |
---|
| 430 | |
---|
| 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'. |
---|
| 435 | |
---|
| 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 |
---|
| 439 | digits. |
---|
| 440 | |
---|
| 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. |
---|
| 450 | |
---|
| 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 |
---|
| 456 | are used instead. |
---|
| 457 | |
---|
| 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)'. |
---|
| 464 | |
---|
| 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. |
---|
| 475 | |
---|
| 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). |
---|
| 479 | |
---|
| 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'. |
---|
| 483 | |
---|
| 484 | In a few contexts a null pointer is valid where an expression is |
---|
| 485 | normally wanted. The written form of this is `(nil)'. |
---|
| 486 | |
---|
| 487 | |
---|
| 488 | File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL |
---|
| 489 | |
---|
| 490 | Access to Operands |
---|
| 491 | ================== |
---|
| 492 | |
---|
| 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'. |
---|
| 499 | |
---|
| 500 | A few other format characters are used occasionally: |
---|
| 501 | |
---|
| 502 | `u' |
---|
| 503 | `u' is equivalent to `e' except that it is printed differently in |
---|
| 504 | debugging dumps. It is used for pointers to insns. |
---|
| 505 | |
---|
| 506 | `n' |
---|
| 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 |
---|
| 509 | a `note' insn. |
---|
| 510 | |
---|
| 511 | `S' |
---|
| 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. |
---|
| 516 | |
---|
| 517 | `V' |
---|
| 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. |
---|
| 522 | |
---|
| 523 | `0' |
---|
| 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. |
---|
| 527 | |
---|
| 528 | There are macros to get the number of operands, the format, and the |
---|
| 529 | class of an expression code: |
---|
| 530 | |
---|
| 531 | `GET_RTX_LENGTH (CODE)' |
---|
| 532 | Number of operands of an RTX of code CODE. |
---|
| 533 | |
---|
| 534 | `GET_RTX_FORMAT (CODE)' |
---|
| 535 | The format of an RTX of code CODE, as a C string. |
---|
| 536 | |
---|
| 537 | `GET_RTX_CLASS (CODE)' |
---|
| 538 | A single character representing the type of RTX operation that code |
---|
| 539 | CODE performs. |
---|
| 540 | |
---|
| 541 | The following classes are defined: |
---|
| 542 | |
---|
| 543 | `o' |
---|
| 544 | An RTX code that represents an actual object, such as `reg' or |
---|
| 545 | `mem'. `subreg' is not in this class. |
---|
| 546 | |
---|
| 547 | `<' |
---|
| 548 | An RTX code for a comparison. The codes in this class are |
---|
| 549 | `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', |
---|
| 550 | `GTU'. |
---|
| 551 | |
---|
| 552 | `1' |
---|
| 553 | An RTX code for a unary arithmetic operation, such as `neg'. |
---|
| 554 | |
---|
| 555 | `c' |
---|
| 556 | An RTX code for a commutative binary operation, other than |
---|
| 557 | `NE' and `EQ' (which have class `<'). |
---|
| 558 | |
---|
| 559 | `2' |
---|
| 560 | An RTX code for a noncommutative binary operation, such as |
---|
| 561 | `MINUS'. |
---|
| 562 | |
---|
| 563 | `b' |
---|
| 564 | An RTX code for a bitfield operation, either `ZERO_EXTRACT' or |
---|
| 565 | `SIGN_EXTRACT'. |
---|
| 566 | |
---|
| 567 | `3' |
---|
| 568 | An RTX code for other three input operations, such as |
---|
| 569 | `IF_THEN_ELSE'. |
---|
| 570 | |
---|
| 571 | `i' |
---|
| 572 | An RTX code for a machine insn (`INSN', `JUMP_INSN', and |
---|
| 573 | `CALL_INSN'). |
---|
| 574 | |
---|
| 575 | `m' |
---|
| 576 | An RTX code for something that matches in insns, such as |
---|
| 577 | `MATCH_DUP'. |
---|
| 578 | |
---|
| 579 | `x' |
---|
| 580 | All other RTX codes. |
---|
| 581 | |
---|
| 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). |
---|
| 585 | Thus, |
---|
| 586 | |
---|
| 587 | XEXP (X, 2) |
---|
| 588 | |
---|
| 589 | accesses operand 2 of expression X, as an expression. |
---|
| 590 | |
---|
| 591 | XINT (X, 2) |
---|
| 592 | |
---|
| 593 | accesses the same operand as an integer. `XSTR', used in the same |
---|
| 594 | fashion, would access it as a string. |
---|
| 595 | |
---|
| 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. |
---|
| 601 | |
---|
| 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. |
---|
| 612 | |
---|
| 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. |
---|
| 616 | |
---|
| 617 | `XVEC (EXP, IDX)' |
---|
| 618 | Access the vector-pointer which is operand number IDX in EXP. |
---|
| 619 | |
---|
| 620 | `XVECLEN (EXP, IDX)' |
---|
| 621 | Access the length (number of elements) in the vector which is in |
---|
| 622 | operand number IDX in EXP. This value is an `int'. |
---|
| 623 | |
---|
| 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. |
---|
| 627 | |
---|
| 628 | It is up to you to make sure that ELTNUM is not negative and is |
---|
| 629 | less than `XVECLEN (EXP, IDX)'. |
---|
| 630 | |
---|
| 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. |
---|
| 634 | |
---|
| 635 | |
---|
| 636 | File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL |
---|
| 637 | |
---|
| 638 | Flags in an RTL Expression |
---|
| 639 | ========================== |
---|
| 640 | |
---|
| 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: |
---|
| 644 | |
---|
| 645 | `MEM_VOLATILE_P (X)' |
---|
| 646 | In `mem' expressions, nonzero for volatile memory references. |
---|
| 647 | Stored in the `volatil' field and printed as `/v'. |
---|
| 648 | |
---|
| 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'. |
---|
| 654 | |
---|
| 655 | `REG_LOOP_TEST_P' |
---|
| 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'. |
---|
| 659 | |
---|
| 660 | `REG_USERVAR_P (X)' |
---|
| 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'. |
---|
| 664 | |
---|
| 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'. |
---|
| 669 | |
---|
| 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 |
---|
| 672 | in this kind of use. |
---|
| 673 | |
---|
| 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'. |
---|
| 683 | |
---|
| 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 |
---|
| 688 | printed as `/u'. |
---|
| 689 | |
---|
| 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 |
---|
| 696 | and printed as `/u'. |
---|
| 697 | |
---|
| 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. |
---|
| 702 | |
---|
| 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. |
---|
| 707 | |
---|
| 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'. |
---|
| 711 | |
---|
| 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'. |
---|
| 716 | |
---|
| 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'. |
---|
| 720 | |
---|
| 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 |
---|
| 725 | `/u'. |
---|
| 726 | |
---|
| 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 will only be executed if |
---|
| 731 | the branch is taken. For annulled branches with |
---|
| 732 | `INSN_FROM_TARGET_P' clear, the insn will be executed only if the |
---|
| 733 | branch is not taken. When `INSN_ANNULLED_BRANCH_P' is not set, |
---|
| 734 | this insn will always be executed. Stored in the `in_struct' |
---|
| 735 | field and printed as `/s'. |
---|
| 736 | |
---|
| 737 | `CONSTANT_POOL_ADDRESS_P (X)' |
---|
| 738 | Nonzero in a `symbol_ref' if it refers to part of the current |
---|
| 739 | function's "constants pool". These are addresses close to the |
---|
| 740 | beginning of the function, and GNU CC assumes they can be addressed |
---|
| 741 | directly (perhaps with the help of base registers). Stored in the |
---|
| 742 | `unchanging' field and printed as `/u'. |
---|
| 743 | |
---|
| 744 | `CONST_CALL_P (X)' |
---|
| 745 | In a `call_insn', indicates that the insn represents a call to a |
---|
| 746 | const function. Stored in the `unchanging' field and printed as |
---|
| 747 | `/u'. |
---|
| 748 | |
---|
| 749 | `LABEL_PRESERVE_P (X)' |
---|
| 750 | In a `code_label', indicates that the label can never be deleted. |
---|
| 751 | Labels referenced by a non-local goto will have this bit set. |
---|
| 752 | Stored in the `in_struct' field and printed as `/s'. |
---|
| 753 | |
---|
| 754 | `SCHED_GROUP_P (INSN)' |
---|
| 755 | During instruction scheduling, in an insn, indicates that the |
---|
| 756 | previous insn must be scheduled together with this insn. This is |
---|
| 757 | used to ensure that certain groups of instructions will not be |
---|
| 758 | split up by the instruction scheduling pass, for example, `use' |
---|
| 759 | insns before a `call_insn' may not be separated from the |
---|
| 760 | `call_insn'. Stored in the `in_struct' field and printed as `/s'. |
---|
| 761 | |
---|
| 762 | These are the fields which the above macros refer to: |
---|
| 763 | |
---|
| 764 | `used' |
---|
| 765 | Normally, this flag is used only momentarily, at the end of RTL |
---|
| 766 | generation for a function, to count the number of times an |
---|
| 767 | expression appears in insns. Expressions that appear more than |
---|
| 768 | once are copied, according to the rules for shared structure |
---|
| 769 | (*note Sharing::.). |
---|
| 770 | |
---|
| 771 | In a `symbol_ref', it indicates that an external declaration for |
---|
| 772 | the symbol has already been written. |
---|
| 773 | |
---|
| 774 | In a `reg', it is used by the leaf register renumbering code to |
---|
| 775 | ensure that each register is only renumbered once. |
---|
| 776 | |
---|
| 777 | `volatil' |
---|
| 778 | This flag is used in `mem', `symbol_ref' and `reg' expressions and |
---|
| 779 | in insns. In RTL dump files, it is printed as `/v'. |
---|
| 780 | |
---|
| 781 | In a `mem' expression, it is 1 if the memory reference is volatile. |
---|
| 782 | Volatile memory references may not be deleted, reordered or |
---|
| 783 | combined. |
---|
| 784 | |
---|
| 785 | In a `symbol_ref' expression, it is used for machine-specific |
---|
| 786 | purposes. |
---|
| 787 | |
---|
| 788 | In a `reg' expression, it is 1 if the value is a user-level |
---|
| 789 | variable. 0 indicates an internal compiler temporary. |
---|
| 790 | |
---|
| 791 | In an insn, 1 means the insn has been deleted. |
---|
| 792 | |
---|
| 793 | `in_struct' |
---|
| 794 | In `mem' expressions, it is 1 if the memory datum referred to is |
---|
| 795 | all or part of a structure or array; 0 if it is (or might be) a |
---|
| 796 | scalar variable. A reference through a C pointer has 0 because |
---|
| 797 | the pointer might point to a scalar variable. This information |
---|
| 798 | allows the compiler to determine something about possible cases of |
---|
| 799 | aliasing. |
---|
| 800 | |
---|
| 801 | In an insn in the delay slot of a branch, 1 means that this insn |
---|
| 802 | is from the target of the branch. |
---|
| 803 | |
---|
| 804 | During instruction scheduling, in an insn, 1 means that this insn |
---|
| 805 | must be scheduled as part of a group together with the previous |
---|
| 806 | insn. |
---|
| 807 | |
---|
| 808 | In `reg' expressions, it is 1 if the register has its entire life |
---|
| 809 | contained within the test expression of some loop. |
---|
| 810 | |
---|
| 811 | In `subreg' expressions, 1 means that the `subreg' is accessing an |
---|
| 812 | object that has had its mode promoted from a wider mode. |
---|
| 813 | |
---|
| 814 | In `label_ref' expressions, 1 means that the referenced label is |
---|
| 815 | outside the innermost loop containing the insn in which the |
---|
| 816 | `label_ref' was found. |
---|
| 817 | |
---|
| 818 | In `code_label' expressions, it is 1 if the label may never be |
---|
| 819 | deleted. This is used for labels which are the target of |
---|
| 820 | non-local gotos. |
---|
| 821 | |
---|
| 822 | In an RTL dump, this flag is represented as `/s'. |
---|
| 823 | |
---|
| 824 | `unchanging' |
---|
| 825 | In `reg' and `mem' expressions, 1 means that the value of the |
---|
| 826 | expression never changes. |
---|
| 827 | |
---|
| 828 | In `subreg' expressions, it is 1 if the `subreg' references an |
---|
| 829 | unsigned object whose mode has been promoted to a wider mode. |
---|
| 830 | |
---|
| 831 | In an insn, 1 means that this is an annulling branch. |
---|
| 832 | |
---|
| 833 | In a `symbol_ref' expression, 1 means that this symbol addresses |
---|
| 834 | something in the per-function constants pool. |
---|
| 835 | |
---|
| 836 | In a `call_insn', 1 means that this instruction is a call to a |
---|
| 837 | const function. |
---|
| 838 | |
---|
| 839 | In an RTL dump, this flag is represented as `/u'. |
---|
| 840 | |
---|
| 841 | `integrated' |
---|
| 842 | In some kinds of expressions, including insns, this flag means the |
---|
| 843 | rtl was produced by procedure integration. |
---|
| 844 | |
---|
| 845 | In a `reg' expression, this flag indicates the register containing |
---|
| 846 | the value to be returned by the current function. On machines |
---|
| 847 | that pass parameters in registers, the same register number may be |
---|
| 848 | used for parameters as well, but this flag is not set on such uses. |
---|
| 849 | |
---|
| 850 | |
---|
[8833] | 851 | File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL |
---|
| 852 | |
---|
| 853 | Machine Modes |
---|
| 854 | ============= |
---|
| 855 | |
---|
| 856 | A machine mode describes a size of data object and the |
---|
| 857 | representation used for it. In the C code, machine modes are |
---|
| 858 | represented by an enumeration type, `enum machine_mode', defined in |
---|
| 859 | `machmode.def'. Each RTL expression has room for a machine mode and so |
---|
| 860 | do certain kinds of tree expressions (declarations and types, to be |
---|
| 861 | precise). |
---|
| 862 | |
---|
| 863 | In debugging dumps and machine descriptions, the machine mode of an |
---|
| 864 | RTL expression is written after the expression code with a colon to |
---|
| 865 | separate them. The letters `mode' which appear at the end of each |
---|
| 866 | machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' |
---|
| 867 | expression with machine mode `SImode'. If the mode is `VOIDmode', it |
---|
| 868 | is not written at all. |
---|
| 869 | |
---|
| 870 | Here is a table of machine modes. The term "byte" below refers to an |
---|
| 871 | object of `BITS_PER_UNIT' bits (*note Storage Layout::.). |
---|
| 872 | |
---|
| 873 | `QImode' |
---|
| 874 | "Quarter-Integer" mode represents a single byte treated as an |
---|
| 875 | integer. |
---|
| 876 | |
---|
| 877 | `HImode' |
---|
| 878 | "Half-Integer" mode represents a two-byte integer. |
---|
| 879 | |
---|
| 880 | `PSImode' |
---|
| 881 | "Partial Single Integer" mode represents an integer which occupies |
---|
| 882 | four bytes but which doesn't really use all four. On some |
---|
| 883 | machines, this is the right mode to use for pointers. |
---|
| 884 | |
---|
| 885 | `SImode' |
---|
| 886 | "Single Integer" mode represents a four-byte integer. |
---|
| 887 | |
---|
| 888 | `PDImode' |
---|
| 889 | "Partial Double Integer" mode represents an integer which occupies |
---|
| 890 | eight bytes but which doesn't really use all eight. On some |
---|
| 891 | machines, this is the right mode to use for certain pointers. |
---|
| 892 | |
---|
| 893 | `DImode' |
---|
| 894 | "Double Integer" mode represents an eight-byte integer. |
---|
| 895 | |
---|
| 896 | `TImode' |
---|
| 897 | "Tetra Integer" (?) mode represents a sixteen-byte integer. |
---|
| 898 | |
---|
| 899 | `SFmode' |
---|
| 900 | "Single Floating" mode represents a single-precision (four byte) |
---|
| 901 | floating point number. |
---|
| 902 | |
---|
| 903 | `DFmode' |
---|
| 904 | "Double Floating" mode represents a double-precision (eight byte) |
---|
| 905 | floating point number. |
---|
| 906 | |
---|
| 907 | `XFmode' |
---|
| 908 | "Extended Floating" mode represents a triple-precision (twelve |
---|
| 909 | byte) floating point number. This mode is used for IEEE extended |
---|
| 910 | floating point. On some systems not all bits within these bytes |
---|
| 911 | will actually be used. |
---|
| 912 | |
---|
| 913 | `TFmode' |
---|
| 914 | "Tetra Floating" mode represents a quadruple-precision (sixteen |
---|
| 915 | byte) floating point number. |
---|
| 916 | |
---|
| 917 | `CCmode' |
---|
| 918 | "Condition Code" mode represents the value of a condition code, |
---|
| 919 | which is a machine-specific set of bits used to represent the |
---|
| 920 | result of a comparison operation. Other machine-specific modes |
---|
| 921 | may also be used for the condition code. These modes are not used |
---|
| 922 | on machines that use `cc0' (see *note Condition Code::.). |
---|
| 923 | |
---|
| 924 | `BLKmode' |
---|
| 925 | "Block" mode represents values that are aggregates to which none of |
---|
| 926 | the other modes apply. In RTL, only memory references can have |
---|
| 927 | this mode, and only if they appear in string-move or vector |
---|
| 928 | instructions. On machines which have no such instructions, |
---|
| 929 | `BLKmode' will not appear in RTL. |
---|
| 930 | |
---|
| 931 | `VOIDmode' |
---|
| 932 | Void mode means the absence of a mode or an unspecified mode. For |
---|
| 933 | example, RTL expressions of code `const_int' have mode `VOIDmode' |
---|
| 934 | because they can be taken to have whatever mode the context |
---|
| 935 | requires. In debugging dumps of RTL, `VOIDmode' is expressed by |
---|
| 936 | the absence of any mode. |
---|
| 937 | |
---|
| 938 | `SCmode, DCmode, XCmode, TCmode' |
---|
| 939 | These modes stand for a complex number represented as a pair of |
---|
| 940 | floating point values. The floating point values are in `SFmode', |
---|
| 941 | `DFmode', `XFmode', and `TFmode', respectively. |
---|
| 942 | |
---|
| 943 | `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' |
---|
| 944 | These modes stand for a complex number represented as a pair of |
---|
| 945 | integer values. The integer values are in `QImode', `HImode', |
---|
| 946 | `SImode', `DImode', `TImode', and `OImode', respectively. |
---|
| 947 | |
---|
| 948 | The machine description defines `Pmode' as a C macro which expands |
---|
| 949 | into the machine mode used for addresses. Normally this is the mode |
---|
| 950 | whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. |
---|
| 951 | |
---|
| 952 | The only modes which a machine description must support are |
---|
| 953 | `QImode', and the modes corresponding to `BITS_PER_WORD', |
---|
| 954 | `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to |
---|
| 955 | use `DImode' for 8-byte structures and unions, but this can be |
---|
| 956 | prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. |
---|
| 957 | Alternatively, you can have the compiler use `TImode' for 16-byte |
---|
| 958 | structures and unions. Likewise, you can arrange for the C type `short |
---|
| 959 | int' to avoid using `HImode'. |
---|
| 960 | |
---|
| 961 | Very few explicit references to machine modes remain in the compiler |
---|
| 962 | and these few references will soon be removed. Instead, the machine |
---|
| 963 | modes are divided into mode classes. These are represented by the |
---|
| 964 | enumeration type `enum mode_class' defined in `machmode.h'. The |
---|
| 965 | possible mode classes are: |
---|
| 966 | |
---|
| 967 | `MODE_INT' |
---|
| 968 | Integer modes. By default these are `QImode', `HImode', `SImode', |
---|
| 969 | `DImode', and `TImode'. |
---|
| 970 | |
---|
| 971 | `MODE_PARTIAL_INT' |
---|
| 972 | The "partial integer" modes, `PSImode' and `PDImode'. |
---|
| 973 | |
---|
| 974 | `MODE_FLOAT' |
---|
| 975 | floating point modes. By default these are `SFmode', `DFmode', |
---|
| 976 | `XFmode' and `TFmode'. |
---|
| 977 | |
---|
| 978 | `MODE_COMPLEX_INT' |
---|
| 979 | Complex integer modes. (These are not currently implemented). |
---|
| 980 | |
---|
| 981 | `MODE_COMPLEX_FLOAT' |
---|
| 982 | Complex floating point modes. By default these are `SCmode', |
---|
| 983 | `DCmode', `XCmode', and `TCmode'. |
---|
| 984 | |
---|
| 985 | `MODE_FUNCTION' |
---|
| 986 | Algol or Pascal function variables including a static chain. |
---|
| 987 | (These are not currently implemented). |
---|
| 988 | |
---|
| 989 | `MODE_CC' |
---|
| 990 | Modes representing condition code values. These are `CCmode' plus |
---|
| 991 | any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump |
---|
| 992 | Patterns::, also see *Note Condition Code::. |
---|
| 993 | |
---|
| 994 | `MODE_RANDOM' |
---|
| 995 | This is a catchall mode class for modes which don't fit into the |
---|
| 996 | above classes. Currently `VOIDmode' and `BLKmode' are in |
---|
| 997 | `MODE_RANDOM'. |
---|
| 998 | |
---|
| 999 | Here are some C macros that relate to machine modes: |
---|
| 1000 | |
---|
| 1001 | `GET_MODE (X)' |
---|
| 1002 | Returns the machine mode of the RTX X. |
---|
| 1003 | |
---|
| 1004 | `PUT_MODE (X, NEWMODE)' |
---|
| 1005 | Alters the machine mode of the RTX X to be NEWMODE. |
---|
| 1006 | |
---|
| 1007 | `NUM_MACHINE_MODES' |
---|
| 1008 | Stands for the number of machine modes available on the target |
---|
| 1009 | machine. This is one greater than the largest numeric value of any |
---|
| 1010 | machine mode. |
---|
| 1011 | |
---|
| 1012 | `GET_MODE_NAME (M)' |
---|
| 1013 | Returns the name of mode M as a string. |
---|
| 1014 | |
---|
| 1015 | `GET_MODE_CLASS (M)' |
---|
| 1016 | Returns the mode class of mode M. |
---|
| 1017 | |
---|
| 1018 | `GET_MODE_WIDER_MODE (M)' |
---|
| 1019 | Returns the next wider natural mode. For example, the expression |
---|
| 1020 | `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. |
---|
| 1021 | |
---|
| 1022 | `GET_MODE_SIZE (M)' |
---|
| 1023 | Returns the size in bytes of a datum of mode M. |
---|
| 1024 | |
---|
| 1025 | `GET_MODE_BITSIZE (M)' |
---|
| 1026 | Returns the size in bits of a datum of mode M. |
---|
| 1027 | |
---|
| 1028 | `GET_MODE_MASK (M)' |
---|
| 1029 | Returns a bitmask containing 1 for all bits in a word that fit |
---|
| 1030 | within mode M. This macro can only be used for modes whose |
---|
| 1031 | bitsize is less than or equal to `HOST_BITS_PER_INT'. |
---|
| 1032 | |
---|
| 1033 | `GET_MODE_ALIGNMENT (M))' |
---|
| 1034 | Return the required alignment, in bits, for an object of mode M. |
---|
| 1035 | |
---|
| 1036 | `GET_MODE_UNIT_SIZE (M)' |
---|
| 1037 | Returns the size in bytes of the subunits of a datum of mode M. |
---|
| 1038 | This is the same as `GET_MODE_SIZE' except in the case of complex |
---|
| 1039 | modes. For them, the unit size is the size of the real or |
---|
| 1040 | imaginary part. |
---|
| 1041 | |
---|
| 1042 | `GET_MODE_NUNITS (M)' |
---|
| 1043 | Returns the number of units contained in a mode, i.e., |
---|
| 1044 | `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. |
---|
| 1045 | |
---|
| 1046 | `GET_CLASS_NARROWEST_MODE (C)' |
---|
| 1047 | Returns the narrowest mode in mode class C. |
---|
| 1048 | |
---|
| 1049 | The global variables `byte_mode' and `word_mode' contain modes whose |
---|
| 1050 | classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or |
---|
| 1051 | `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' |
---|
| 1052 | and `SImode', respectively. |
---|
| 1053 | |
---|
| 1054 | |
---|
| 1055 | File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL |
---|
| 1056 | |
---|
| 1057 | Constant Expression Types |
---|
| 1058 | ========================= |
---|
| 1059 | |
---|
| 1060 | The simplest RTL expressions are those that represent constant |
---|
| 1061 | values. |
---|
| 1062 | |
---|
| 1063 | `(const_int I)' |
---|
| 1064 | This type of expression represents the integer value I. I is |
---|
| 1065 | customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', |
---|
| 1066 | which is equivalent to `XWINT (EXP, 0)'. |
---|
| 1067 | |
---|
| 1068 | There is only one expression object for the integer value zero; it |
---|
| 1069 | is the value of the variable `const0_rtx'. Likewise, the only |
---|
| 1070 | expression for integer value one is found in `const1_rtx', the only |
---|
| 1071 | expression for integer value two is found in `const2_rtx', and the |
---|
| 1072 | only expression for integer value negative one is found in |
---|
| 1073 | `constm1_rtx'. Any attempt to create an expression of code |
---|
| 1074 | `const_int' and value zero, one, two or negative one will return |
---|
| 1075 | `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as |
---|
| 1076 | appropriate. |
---|
| 1077 | |
---|
| 1078 | Similarly, there is only one object for the integer whose value is |
---|
| 1079 | `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If |
---|
| 1080 | `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will |
---|
| 1081 | point to the same object. If `STORE_FLAG_VALUE' is -1, |
---|
| 1082 | `const_true_rtx' and `constm1_rtx' will point to the same object. |
---|
| 1083 | |
---|
| 1084 | `(const_double:M ADDR I0 I1 ...)' |
---|
| 1085 | Represents either a floating-point constant of mode M or an |
---|
| 1086 | integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' |
---|
| 1087 | bits but small enough to fit within twice that number of bits (GNU |
---|
| 1088 | CC does not provide a mechanism to represent even larger |
---|
| 1089 | constants). In the latter case, M will be `VOIDmode'. |
---|
| 1090 | |
---|
| 1091 | ADDR is used to contain the `mem' expression that corresponds to |
---|
| 1092 | the location in memory that at which the constant can be found. If |
---|
| 1093 | it has not been allocated a memory location, but is on the chain |
---|
| 1094 | of all `const_double' expressions in this compilation (maintained |
---|
| 1095 | using an undisplayed field), ADDR contains `const0_rtx'. If it is |
---|
| 1096 | not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily |
---|
| 1097 | accessed with the macro `CONST_DOUBLE_MEM' and the chain field via |
---|
| 1098 | `CONST_DOUBLE_CHAIN'. |
---|
| 1099 | |
---|
| 1100 | If M is `VOIDmode', the bits of the value are stored in I0 and I1. |
---|
| 1101 | I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and |
---|
| 1102 | I1 with `CONST_DOUBLE_HIGH'. |
---|
| 1103 | |
---|
| 1104 | If the constant is floating point (regardless of its precision), |
---|
| 1105 | then the number of integers used to store the value depends on the |
---|
| 1106 | size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The |
---|
| 1107 | integers represent a floating point number, but not precisely in |
---|
| 1108 | the target machine's or host machine's floating point format. To |
---|
| 1109 | convert them to the precise bit pattern used by the target |
---|
| 1110 | machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends |
---|
| 1111 | (*note Data Output::.). |
---|
| 1112 | |
---|
| 1113 | The macro `CONST0_RTX (MODE)' refers to an expression with value 0 |
---|
| 1114 | in mode MODE. If mode MODE is of mode class `MODE_INT', it |
---|
| 1115 | returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' |
---|
| 1116 | expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)' |
---|
| 1117 | refers to an expression with value 1 in mode MODE and similarly |
---|
| 1118 | for `CONST2_RTX'. |
---|
| 1119 | |
---|
| 1120 | `(const_string STR)' |
---|
| 1121 | Represents a constant string with value STR. Currently this is |
---|
| 1122 | used only for insn attributes (*note Insn Attributes::.) since |
---|
| 1123 | constant strings in C are placed in memory. |
---|
| 1124 | |
---|
| 1125 | `(symbol_ref:MODE SYMBOL)' |
---|
| 1126 | Represents the value of an assembler label for data. SYMBOL is a |
---|
| 1127 | string that describes the name of the assembler label. If it |
---|
| 1128 | starts with a `*', the label is the rest of SYMBOL not including |
---|
| 1129 | the `*'. Otherwise, the label is SYMBOL, usually prefixed with |
---|
| 1130 | `_'. |
---|
| 1131 | |
---|
| 1132 | The `symbol_ref' contains a mode, which is usually `Pmode'. |
---|
| 1133 | Usually that is the only mode for which a symbol is directly valid. |
---|
| 1134 | |
---|
| 1135 | `(label_ref LABEL)' |
---|
| 1136 | Represents the value of an assembler label for code. It contains |
---|
| 1137 | one operand, an expression, which must be a `code_label' that |
---|
| 1138 | appears in the instruction sequence to identify the place where |
---|
| 1139 | the label should go. |
---|
| 1140 | |
---|
| 1141 | The reason for using a distinct expression type for code label |
---|
| 1142 | references is so that jump optimization can distinguish them. |
---|
| 1143 | |
---|
| 1144 | `(const:M EXP)' |
---|
| 1145 | Represents a constant that is the result of an assembly-time |
---|
| 1146 | arithmetic computation. The operand, EXP, is an expression that |
---|
| 1147 | contains only constants (`const_int', `symbol_ref' and `label_ref' |
---|
| 1148 | expressions) combined with `plus' and `minus'. However, not all |
---|
| 1149 | combinations are valid, since the assembler cannot do arbitrary |
---|
| 1150 | arithmetic on relocatable symbols. |
---|
| 1151 | |
---|
| 1152 | M should be `Pmode'. |
---|
| 1153 | |
---|
| 1154 | `(high:M EXP)' |
---|
| 1155 | Represents the high-order bits of EXP, usually a `symbol_ref'. |
---|
| 1156 | The number of bits is machine-dependent and is normally the number |
---|
| 1157 | of bits specified in an instruction that initializes the high |
---|
| 1158 | order bits of a register. It is used with `lo_sum' to represent |
---|
| 1159 | the typical two-instruction sequence used in RISC machines to |
---|
| 1160 | reference a global memory location. |
---|
| 1161 | |
---|
| 1162 | M should be `Pmode'. |
---|
| 1163 | |
---|