![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 8: Permission is granted to make and distribute verbatim copies of 9: this manual provided the copyright notice and this permission notice 10: are preserved on all copies. 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 14: that the section entitled "GNU General Public License" is included 15: exactly as in the original, and provided that the entire resulting 16: derived work is distributed under the terms of a permission notice 17: identical to this one. 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 21: versions, except that the section entitled "GNU General Public 22: License" and this permission notice may be included in translations 23: approved by the Free Software Foundation instead of in the original 24: English. 25: 26: 1.1.1.2 ! root 27: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top ! 28: ! 29: Passes and Files of the Compiler ! 30: ******************************** ! 31: ! 32: The overall control structure of the compiler is in `toplev.c'. ! 33: This file is responsible for initialization, decoding arguments, ! 34: opening and closing files, and sequencing the passes. ! 35: ! 36: The parsing pass is invoked only once, to parse the entire input. ! 37: The RTL intermediate code for a function is generated as the function ! 38: is parsed, a statement at a time. Each statement is read in as a ! 39: syntax tree and then converted to RTL; then the storage for the tree ! 40: for the statement is reclaimed. Storage for types (and the ! 41: expressions for their sizes), declarations, and a representation of ! 42: the binding contours and how they nest, remain until the function is ! 43: finished being compiled; these are all needed to output the debugging ! 44: information. ! 45: ! 46: Each time the parsing pass reads a complete function definition or ! 47: top-level declaration, it calls the function `rest_of_compilation' or ! 48: `rest_of_decl_compilation' in `toplev.c', which are responsible for ! 49: all further processing necessary, ending with output of the assembler ! 50: language. All other compiler passes run, in sequence, within ! 51: `rest_of_compilation'. When that function returns from compiling a ! 52: function definition, the storage used for that function definition's ! 53: compilation is entirely freed, unless it is an inline function (*note ! 54: Inline::.). ! 55: ! 56: Here is a list of all the passes of the compiler and their source ! 57: files. Also included is a description of where debugging dumps can be ! 58: requested with `-d' options. ! 59: ! 60: * Parsing. This pass reads the entire text of a function ! 61: definition, constructing partial syntax trees. This and RTL ! 62: generation are no longer truly separate passes (formerly they ! 63: were), but it is easier to think of them as separate. ! 64: ! 65: The tree representation does not entirely follow C syntax, ! 66: because it is intended to support other languages as well. ! 67: ! 68: Language-specific data type analysis is also done in this pass, ! 69: and every tree node that represents an expression has a data type ! 70: attached. Variables are represented as declaration nodes. ! 71: ! 72: Constant folding and some arithmetic simplifications are also done ! 73: during this pass. ! 74: ! 75: The language-independent source files for parsing are ! 76: `stor-layout.c', `fold-const.c', and `tree.c'. There are also ! 77: header files `tree.h' and `tree.def' which define the format of ! 78: the tree representation. ! 79: ! 80: The source files for parsing C are `c-parse.y', `c-decl.c', ! 81: `c-typeck.c', `c-convert.c', `c-lang.c', and `c-aux-info.c' along ! 82: with header files `c-lex.h', and `c-tree.h'. ! 83: ! 84: The source files for parsing C++ are `cp-parse.y', `cp-class.c', ! 85: `cp-cvt.c', ! 86: `cp-decl.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', ! 87: `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', ! 88: `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', ! 89: along with header files `cp-tree.def', `cp-tree.h', and ! 90: `cp-decl.h'. ! 91: ! 92: The special source files for parsing Objective C are ! 93: `objc-parse.y', `objc-actions.c', `objc-tree.def', and ! 94: `objc-actions.h'. Certain C-specific files are used for this as ! 95: well. ! 96: ! 97: The file `c-common.c' is also used for all of the above languages. ! 98: ! 99: * RTL generation. This is the conversion of syntax tree into RTL ! 100: code. It is actually done statement-by-statement during parsing, ! 101: but for most purposes it can be thought of as a separate pass. ! 102: ! 103: This is where the bulk of target-parameter-dependent code is ! 104: found, since often it is necessary for strategies to apply only ! 105: when certain standard kinds of instructions are available. The ! 106: purpose of named instruction patterns is to provide this ! 107: information to the RTL generation pass. ! 108: ! 109: Optimization is done in this pass for `if'-conditions that are ! 110: comparisons, boolean operations or conditional expressions. Tail ! 111: recursion is detected at this time also. Decisions are made ! 112: about how best to arrange loops and how to output `switch' ! 113: statements. ! 114: ! 115: The source files for RTL generation include `stmt.c', ! 116: `function.c', `expr.c', `calls.c', `explow.c', `expmed.c', ! 117: `optabs.c' and `emit-rtl.c'. Also, the file `insn-emit.c', ! 118: generated from the machine description by the program `genemit', ! 119: is used in this pass. The header file `expr.h' is used for ! 120: communication within this pass. ! 121: ! 122: The header files `insn-flags.h' and `insn-codes.h', generated ! 123: from the machine description by the programs `genflags' and ! 124: `gencodes', tell this pass which standard names are available for ! 125: use and which patterns correspond to them. ! 126: ! 127: Aside from debugging information output, none of the following ! 128: passes refers to the tree structure representation of the ! 129: function (only part of which is saved). ! 130: ! 131: The decision of whether the function can and should be expanded ! 132: inline in its subsequent callers is made at the end of rtl ! 133: generation. The function must meet certain criteria, currently ! 134: related to the size of the function and the types and number of ! 135: parameters it has. Note that this function may contain loops, ! 136: recursive calls to itself (tail-recursive functions can be ! 137: inlined!), gotos, in short, all constructs supported by GNU CC. ! 138: The file `integrate.c' contains the code to save a function's rtl ! 139: for later inlining and to inline that rtl when the function is ! 140: called. The header file `integrate.h' is also used for this ! 141: purpose. ! 142: ! 143: The option `-dr' causes a debugging dump of the RTL code after ! 144: this pass. This dump file's name is made by appending `.rtl' to ! 145: the input file name. ! 146: ! 147: * Jump optimization. This pass simplifies jumps to the following ! 148: instruction, jumps across jumps, and jumps to jumps. It deletes ! 149: unreferenced labels and unreachable code, except that unreachable ! 150: code that contains a loop is not recognized as unreachable in ! 151: this pass. (Such loops are deleted later in the basic block ! 152: analysis.) It also converts some code originally written with ! 153: jumps into sequences of instructions that directly set values ! 154: from the results of comparisons, if the machine has such ! 155: instructions. ! 156: ! 157: Jump optimization is performed two or three times. The first ! 158: time is immediately following RTL generation. The second time is ! 159: after CSE, but only if CSE says repeated jump optimization is ! 160: needed. The last time is right before the final pass. That ! 161: time, cross-jumping and deletion of no-op move instructions are ! 162: done together with the optimizations described above. ! 163: ! 164: The source file of this pass is `jump.c'. ! 165: ! 166: The option `-dj' causes a debugging dump of the RTL code after ! 167: this pass is run for the first time. This dump file's name is ! 168: made by appending `.jump' to the input file name. ! 169: ! 170: * Register scan. This pass finds the first and last use of each ! 171: register, as a guide for common subexpression elimination. Its ! 172: source is in `regclass.c'. ! 173: ! 174: * Jump threading. This pass detects a condition jump that branches ! 175: to an identical or inverse test. Such jumps can be `threaded' ! 176: through the second conditional test. The source code for this ! 177: pass is in `jump.c'. This optimization is only performed if ! 178: `-fthread-jumps' is enabled. ! 179: ! 180: * Common subexpression elimination. This pass also does constant ! 181: propagation. Its source file is `cse.c'. If constant ! 182: propagation causes conditional jumps to become unconditional or to ! 183: become no-ops, jump optimization is run again when CSE is ! 184: finished. ! 185: ! 186: The option `-ds' causes a debugging dump of the RTL code after ! 187: this pass. This dump file's name is made by appending `.cse' to ! 188: the input file name. ! 189: ! 190: * Loop optimization. This pass moves constant expressions out of ! 191: loops, and optionally does strength-reduction and loop unrolling ! 192: as well. Its source files are `loop.c' and `unroll.c', plus the ! 193: header `loop.h' used for communication between them. Loop ! 194: unrolling uses some functions in `integrate.c' and the header ! 195: `integrate.h'. ! 196: ! 197: The option `-dL' causes a debugging dump of the RTL code after ! 198: this pass. This dump file's name is made by appending `.loop' to ! 199: the input file name. ! 200: ! 201: * If `-frerun-cse-after-loop' was enabled, a second common ! 202: subexpression elimination pass is performed after the loop ! 203: optimization pass. Jump threading is also done again at this ! 204: time if it was specified. ! 205: ! 206: The option `-dt' causes a debugging dump of the RTL code after ! 207: this pass. This dump file's name is made by appending `.cse2' to ! 208: the input file name. ! 209: ! 210: * Stupid register allocation is performed at this point in a ! 211: nonoptimizing compilation. It does a little data flow analysis as ! 212: well. When stupid register allocation is in use, the next pass ! 213: executed is the reloading pass; the others in between are skipped. ! 214: The source file is `stupid.c'. ! 215: ! 216: * Data flow analysis (`flow.c'). This pass divides the program ! 217: into basic blocks (and in the process deletes unreachable loops); ! 218: then it computes which pseudo-registers are live at each point in ! 219: the program, and makes the first instruction that uses a value ! 220: point at the instruction that computed the value. ! 221: ! 222: This pass also deletes computations whose results are never used, ! 223: and combines memory references with add or subtract instructions ! 224: to make autoincrement or autodecrement addressing. ! 225: ! 226: The option `-df' causes a debugging dump of the RTL code after ! 227: this pass. This dump file's name is made by appending `.flow' to ! 228: the input file name. If stupid register allocation is in use, ! 229: this dump file reflects the full results of such allocation. ! 230: ! 231: * Instruction combination (`combine.c'). This pass attempts to ! 232: combine groups of two or three instructions that are related by ! 233: data flow into single instructions. It combines the RTL ! 234: expressions for the instructions by substitution, simplifies the ! 235: result using algebra, and then attempts to match the result ! 236: against the machine description. ! 237: ! 238: The option `-dc' causes a debugging dump of the RTL code after ! 239: this pass. This dump file's name is made by appending `.combine' ! 240: to the input file name. ! 241: ! 242: * Instruction scheduling (`sched.c'). This pass looks for ! 243: instructions whose output will not be available by the time that ! 244: it is used in subsequent instructions. (Memory loads and ! 245: floating point instructions often have this behavior on RISC ! 246: machines). It re-orders instructions within a basic block to try ! 247: to separate the definition and use of items that otherwise would ! 248: cause pipeline stalls. ! 249: ! 250: Instruction scheduling is performed twice. The first time is ! 251: immediately after instruction combination and the second is ! 252: immediately after reload. ! 253: ! 254: The option `-dS' causes a debugging dump of the RTL code after ! 255: this pass is run for the first time. The dump file's name is ! 256: made by appending `.sched' to the input file name. ! 257: ! 258: * Register class preferencing. The RTL code is scanned to find out ! 259: which register class is best for each pseudo register. The source ! 260: file is `regclass.c'. ! 261: ! 262: * Local register allocation (`local-alloc.c'). This pass allocates ! 263: hard registers to pseudo registers that are used only within one ! 264: basic block. Because the basic block is linear, it can use fast ! 265: and powerful techniques to do a very good job. ! 266: ! 267: The option `-dl' causes a debugging dump of the RTL code after ! 268: this pass. This dump file's name is made by appending `.lreg' to ! 269: the input file name. ! 270: ! 271: * Global register allocation (`global-alloc.c'). This pass ! 272: allocates hard registers for the remaining pseudo registers (those ! 273: whose life spans are not contained in one basic block). ! 274: ! 275: * Reloading. This pass renumbers pseudo registers with the hardware ! 276: registers numbers they were allocated. Pseudo registers that did ! 277: not get hard registers are replaced with stack slots. Then it ! 278: finds instructions that are invalid because a value has failed to ! 279: end up in a register, or has ended up in a register of the wrong ! 280: kind. It fixes up these instructions by reloading the ! 281: problematical values temporarily into registers. Additional ! 282: instructions are generated to do the copying. ! 283: ! 284: The reload pass also optionally eliminates the frame pointer and ! 285: inserts instructions to save and restore call-clobbered registers ! 286: around calls. ! 287: ! 288: Source files are `reload.c' and `reload1.c', plus the header ! 289: `reload.h' used for communication between them. ! 290: ! 291: The option `-dg' causes a debugging dump of the RTL code after ! 292: this pass. This dump file's name is made by appending `.greg' to ! 293: the input file name. ! 294: ! 295: * Instruction scheduling is repeated here to try to avoid pipeline ! 296: stalls due to memory loads generated for spilled pseudo registers. ! 297: ! 298: The option `-dR' causes a debugging dump of the RTL code after ! 299: this pass. This dump file's name is made by appending `.sched2' ! 300: to the input file name. ! 301: ! 302: * Jump optimization is repeated, this time including cross-jumping ! 303: and deletion of no-op move instructions. ! 304: ! 305: The option `-dJ' causes a debugging dump of the RTL code after ! 306: this pass. This dump file's name is made by appending `.jump2' ! 307: to the input file name. ! 308: ! 309: * Delayed branch scheduling. This optional pass attempts to find ! 310: instructions that can go into the delay slots of other ! 311: instructions, usually jumps and calls. The source file name is ! 312: `reorg.c'. ! 313: ! 314: The option `-dd' causes a debugging dump of the RTL code after ! 315: this pass. This dump file's name is made by appending `.dbr' to ! 316: the input file name. ! 317: ! 318: * Conversion from usage of some hard registers to usage of a ! 319: register stack may be done at this point. Currently, this is ! 320: supported only for the floating-point registers of the Intel ! 321: 80387 coprocessor. The source file name is `reg-stack.c'. ! 322: ! 323: The options `-dk' causes a debugging dump of the RTL code after ! 324: this pass. This dump file's name is made by appending `.stack' ! 325: to the input file name. ! 326: ! 327: * Final. This pass outputs the assembler code for the function. ! 328: It is also responsible for identifying spurious test and compare ! 329: instructions. Machine-specific peephole optimizations are ! 330: performed at the same time. The function entry and exit ! 331: sequences are generated directly as assembler code in this pass; ! 332: they never exist as RTL. ! 333: ! 334: The source files are `final.c' plus `insn-output.c'; the latter ! 335: is generated automatically from the machine description by the ! 336: tool `genoutput'. The header file `conditions.h' is used for ! 337: communication between these files. ! 338: ! 339: * Debugging information output. This is run after final because it ! 340: must output the stack slot offsets for pseudo registers that did ! 341: not get hard registers. Source files are `dbxout.c' for DBX ! 342: symbol table format, `sdbout.c' for SDB symbol table format, and ! 343: `dwarfout.c' for DWARF symbol table format. ! 344: ! 345: Some additional files are used by all or many passes: ! 346: ! 347: * Every pass uses `machmode.def' and `machmode.h' which define the ! 348: machine modes. ! 349: ! 350: * Several passes use `real.h', which defines the default ! 351: representation of floating point constants and how to operate on ! 352: them. ! 353: ! 354: * All the passes that work with RTL use the header files `rtl.h' ! 355: and `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' ! 356: also use these files to read and work with the machine ! 357: 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 ! 367: machine 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 ! 372: basic 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 ! 386: `genattrtab'. ! 387: ! 388: ! 389: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top ! 390: ! 391: RTL Representation ! 392: ****************** ! 393: ! 394: Most of the work of the compiler is done on an intermediate ! 395: representation called register transfer language. In this language, ! 396: the instructions to be output are described, pretty much one by one, ! 397: in an algebraic form that describes what the instruction does. ! 398: ! 399: RTL is inspired by Lisp lists. It has both an internal form, made ! 400: up of structures that point at other structures, and a textual form ! 401: that is used in the machine description and in printed debugging ! 402: dumps. The textual form uses nested parentheses to indicate the ! 403: pointers in the internal form. ! 404: ! 405: * Menu: ! 406: ! 407: * RTL Objects:: Expressions vs vectors vs strings vs integers. ! 408: * Accessors:: Macros to access expression operands or vector elts. ! 409: * Flags:: Other flags in an RTL expression. ! 410: * Machine Modes:: Describing the size and format of a datum. ! 411: * Constants:: Expressions with constant values. ! 412: * Regs and Memory:: Expressions representing register contents or memory. ! 413: * Arithmetic:: Expressions representing arithmetic on other expressions. ! 414: * Comparisons:: Expressions representing comparison of expressions. ! 415: * Bit Fields:: Expressions representing bit-fields in memory or reg. ! 416: * Conversions:: Extending, truncating, floating or fixing. ! 417: * RTL Declarations:: Declaring volatility, constancy, etc. ! 418: * Side Effects:: Expressions for storing in registers, etc. ! 419: * Incdec:: Embedded side-effects for autoincrement addressing. ! 420: * Assembler:: Representing `asm' with operands. ! 421: * Insns:: Expression types for entire insns. ! 422: * Calls:: RTL representation of function call insns. ! 423: * Sharing:: Some expressions are unique; others *must* be copied. ! 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 four kinds of objects: expressions, integers, strings and ! 432: vectors. Expressions are the most important ones. An RTL expression ! 433: ("RTX", for short) is a C structure, but it is usually referred to ! 434: 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. ! 438: ! 439: A string is a sequence of characters. In core it is represented as ! 440: a `char *' in usual C fashion, and it is written in C syntax as well. ! 441: However, strings in RTL may never be null. If you write an empty ! 442: string in a machine description, it is represented in core as a null ! 443: pointer rather than as a pointer to a null character. In certain ! 444: contexts, these null pointers instead of strings are valid. Within ! 445: RTL code, strings are most commonly found inside `symbol_ref' ! 446: expressions, but they appear in other contexts in the RTL expressions ! 447: that make up machine descriptions. ! 448: ! 449: A vector contains an arbitrary number of pointers to expressions. ! 450: The number of elements in the vector is explicitly present in the ! 451: vector. The written form of a vector consists of square brackets ! 452: (`[...]') surrounding the elements, in sequence and with whitespace ! 453: separating them. Vectors of length zero are not created; null ! 454: pointers are used instead. ! 455: ! 456: Expressions are classified by "expression codes" (also called RTX ! 457: codes). The expression code is a name defined in `rtl.def', which is ! 458: also (in upper case) a C enumeration constant. The possible expression ! 459: codes and their meanings are machine-independent. The code of an RTX ! 460: can be extracted with the macro `GET_CODE (X)' and altered with ! 461: `PUT_CODE (X, NEWCODE)'. ! 462: ! 463: The expression code determines how many operands the expression ! 464: contains, and what kinds of objects they are. In RTL, unlike Lisp, ! 465: you cannot tell by looking at an operand what kind of object it is. ! 466: Instead, you must know from its context--from the expression code of ! 467: the containing expression. For example, in an expression of code ! 468: `subreg', the first operand is to be regarded as an expression and the ! 469: second operand as an integer. In an expression of code `plus', there ! 470: are two operands, both of which are to be regarded as expressions. In ! 471: a `symbol_ref' expression, there is one operand, which is to be ! 472: regarded as a string. ! 473: ! 474: Expressions are written as parentheses containing the name of the ! 475: expression type, its flags and machine mode if any, and then the ! 476: operands of the expression (separated by spaces). ! 477: ! 478: Expression code names in the `md' file are written in lower case, ! 479: but when they appear in C code they are written in upper case. In this ! 480: manual, they are shown as follows: `const_int'. ! 481: ! 482: In a few contexts a null pointer is valid where an expression is ! 483: normally wanted. The written form of this is `(nil)'. ! 484: ! 485: 1.1 root 486: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL 487: 488: Access to Operands 489: ================== 490: 491: For each expression type `rtl.def' specifies the number of contained 492: objects and their kinds, with four possibilities: `e' for expression 493: (actually a pointer to an expression), `i' for integer, `s' for 494: string, and `E' for vector of expressions. The sequence of letters 495: for an expression code is called its "format". Thus, the format of 496: `subreg' is `ei'. 497: 498: A few other format characters are used occasionally: 499: 500: `u' 501: `u' is equivalent to `e' except that it is printed differently in 502: debugging dumps. It is used for pointers to insns. 503: 504: `n' 505: `n' is equivalent to `i' except that it is printed differently in 506: debugging dumps. It is used for the line number or code number 507: of a `note' insn. 508: 509: `S' 510: `S' indicates a string which is optional. In the RTL objects in 511: core, `S' is equivalent to `s', but when the object is read, from 512: an `md' file, the string value of this operand may be omitted. 513: An omitted string is taken to be the null string. 514: 515: `V' 516: `V' indicates a vector which is optional. In the RTL objects in 517: core, `V' is equivalent to `E', but when the object is read from 518: an `md' file, the vector value of this operand may be omitted. 519: An omitted vector is effectively the same as a vector of no 520: elements. 521: 522: `0' 523: `0' means a slot whose contents do not fit any normal category. 524: `0' slots are not printed at all in dumps, and are often used in 525: special ways by small parts of the compiler. 526: 527: There are macros to get the number of operands, the format, and the 528: class of an expression code: 529: 530: `GET_RTX_LENGTH (CODE)' 531: Number of operands of an RTX of code CODE. 532: 533: `GET_RTX_FORMAT (CODE)' 534: The format of an RTX of code CODE, as a C string. 535: 536: `GET_RTX_CLASS (CODE)' 537: A single character representing the type of RTX operation that 538: code CODE performs. 539: 540: The following classes are defined: 541: 542: `o' 543: An RTX code that represents an actual object, such as `reg' 544: or `mem'. `subreg' is not in this class. 545: 546: `<' 547: An RTX code for a comparison. The codes in this class are 548: `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', 549: `GTU'. 550: 551: `1' 552: An RTX code for a unary arithmetic operation, such as `neg'. 553: 554: `c' 555: An RTX code for a commutative binary operation, other than 556: `NE' and `EQ' (which have class `<'). 557: 558: `2' 559: An RTX code for a noncommutative binary operation, such as 560: `MINUS'. 561: 562: `b' 563: An RTX code for a bitfield operation (`ZERO_EXTRACT' and 564: `SIGN_EXTRACT'). 565: 566: `3' 567: An RTX code for other three input operations, such as 568: `IF_THEN_ELSE'. 569: 570: `i' 571: An RTX code for a machine insn (`INSN', `JUMP_INSN', and 572: `CALL_INSN'). 573: 574: `m' 575: An RTX code for something that matches in insns, such as 576: `MATCH_DUP'. 577: 578: `x' 579: All other RTX codes. 580: 581: Operands of expressions are accessed using the macros `XEXP', 582: `XINT' and `XSTR'. Each of these macros takes two arguments: an 583: expression-pointer (RTX) and an operand number (counting from zero). 584: Thus, 585: 586: XEXP (X, 2) 587: 588: accesses operand 2 of expression X, as an expression. 589: 590: XINT (X, 2) 591: 592: accesses the same operand as an integer. `XSTR', used in the same 593: fashion, would access it as a string. 594: 595: Any operand can be accessed as an integer, as an expression or as a 596: string. You must choose the correct method of access for the kind of 597: value actually stored in the operand. You would do this based on the 598: expression code of the containing expression. That is also how you 599: would know how many operands there are. 600: 601: For example, if X is a `subreg' expression, you know that it has 602: two operands which can be correctly accessed as `XEXP (X, 0)' and 603: `XINT (X, 1)'. If you did `XINT (X, 0)', you would get the address of 604: the expression operand but cast as an integer; that might occasionally 605: be useful, but it would be cleaner to write `(int) XEXP (X, 0)'. 606: `XEXP (X, 1)' would also compile without error, and would return the 607: second, integer operand cast as an expression pointer, which would 608: probably result in a crash when accessed. Nothing stops you from 609: writing `XEXP (X, 28)' either, but this will access memory past the 610: end of the expression with unpredictable results. 611: 612: Access to operands which are vectors is more complicated. You can 613: use the macro `XVEC' to get the vector-pointer itself, or the macros 614: `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 615: 616: `XVEC (EXP, IDX)' 617: Access the vector-pointer which is operand number IDX in EXP. 618: 619: `XVECLEN (EXP, IDX)' 620: Access the length (number of elements) in the vector which is in 621: operand number IDX in EXP. This value is an `int'. 622: 623: `XVECEXP (EXP, IDX, ELTNUM)' 624: Access element number ELTNUM in the vector which is in operand 625: number IDX in EXP. This value is an RTX. 626: 627: It is up to you to make sure that ELTNUM is not negative and is 628: less than `XVECLEN (EXP, IDX)'. 629: 630: All the macros defined in this section expand into lvalues and 631: therefore can be used to assign the operands, lengths and vector 632: elements as well as to access them. 633: 634: 635: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL 636: 637: Flags in an RTL Expression 638: ========================== 639: 640: RTL expressions contain several flags (one-bit bit-fields) that are 641: used in certain types of expression. Most often they are accessed 642: with the following macros: 643: 644: `MEM_VOLATILE_P (X)' 645: In `mem' expressions, nonzero for volatile memory references. 646: Stored in the `volatil' field and printed as `/v'. 647: 648: `MEM_IN_STRUCT_P (X)' 649: In `mem' expressions, nonzero for reference to an entire 650: structure, union or array, or to a component of one. Zero for 651: references to a scalar variable or through a pointer to a scalar. 652: Stored in the `in_struct' field and printed as `/s'. 653: 654: `REG_LOOP_TEST_P' 655: In `reg' expressions, nonzero if this register's entire life is 656: contained in the exit test code for some loop. Stored in the 657: `in_struct' field and printed as `/s'. 658: 659: `REG_USERVAR_P (X)' 660: In a `reg', nonzero if it corresponds to a variable present in 661: the user's source code. Zero for temporaries generated 662: internally by the compiler. Stored in the `volatil' field and 663: 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 672: zero in this kind of use. 673: 674: `RTX_UNCHANGING_P (X)' 675: Nonzero in a `reg' or `mem' if the value is not changed. (This 676: flag is not set for memory references via pointers to constants. 677: Such pointers only guarantee that the object will not be changed 678: explicitly by the current function. The object might be changed 679: by other functions or by aliasing.) Stored in the `unchanging' 680: field and printed as `/u'. 681: 682: `RTX_INTEGRATED_P (INSN)' 683: Nonzero in an insn if it resulted from an in-line function call. 684: Stored in the `integrated' field and printed as `/i'. This may 685: be deleted; nothing currently depends on it. 686: 687: `SYMBOL_REF_USED (X)' 688: In a `symbol_ref', indicates that X has been used. This is 689: normally only used to ensure that X is only declared external 690: once. Stored in the `used' field. 691: 692: `SYMBOL_REF_FLAG (X)' 693: In a `symbol_ref', this is used as a flag for machine-specific 694: purposes. Stored in the `volatil' field and printed as `/v'. 695: 696: `LABEL_OUTSIDE_LOOP_P' 697: In `label_ref' expressions, nonzero if this is a reference to a 698: label that is outside the innermost loop containing the reference 699: to the label. Stored in the `in_struct' field and printed as 700: `/s'. 701: 702: `INSN_DELETED_P (INSN)' 703: In an insn, nonzero if the insn has been deleted. Stored in the 704: `volatil' field and printed as `/v'. 705: 706: `INSN_ANNULLED_BRANCH_P (INSN)' 707: In an `insn' in the delay slot of a branch insn, indicates that an 708: annulling branch should be used. See the discussion under 709: `sequence' below. Stored in the `unchanging' field and printed 710: as `/u'. 711: 712: `INSN_FROM_TARGET_P (INSN)' 713: In an `insn' in a delay slot of a branch, indicates that the insn 714: is from the target of the branch. If the branch insn has 715: `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if 716: the branch is taken. For annulled branches with this bit clear, 717: the insn should be executed only if the branch is not taken. 718: Stored in the `in_struct' field and printed as `/s'. 719: 720: `CONSTANT_POOL_ADDRESS_P (X)' 721: Nonzero in a `symbol_ref' if it refers to part of the current 722: function's "constants pool". These are addresses close to the 723: beginning of the function, and GNU CC assumes they can be 724: addressed directly (perhaps with the help of base registers). 725: Stored in the `unchanging' field and printed as `/u'. 726: 727: `CONST_CALL_P (X)' 728: In a `call_insn', indicates that the insn represents a call to a 729: const function. Stored in the `unchanging' field and printed as 730: `/u'. 731: 732: `LABEL_PRESERVE_P (X)' 733: In a `code_label', indicates that the label can never be deleted. 734: Labels referenced by a a non-local goto will have this bit set. 735: Stored in the `in_struct' field and printed as `/s'. 736: 737: `SCHED_GROUP_P (INSN)' 738: During instruction scheduling, in an insn, indicates that the 739: previous insn must be scheduled together with this insn. This is 740: used to ensure that certain groups of instructions will not be 741: split up by the instruction scheduling pass, for example, `use' 742: insns before a `call_insn' may not be separated from the 743: `call_insn'. Stored in the `in_struct' field and printed as `/s'. 744: 745: These are the fields which the above macros refer to: 746: 747: `used' 748: Normally, this flag is used only momentarily, at the end of RTL 749: generation for a function, to count the number of times an 750: expression appears in insns. Expressions that appear more than 751: once are copied, according to the rules for shared structure 752: (*note Sharing::.). 753: 754: In a `symbol_ref', it indicates that an external declaration for 755: the symbol has already been written. 756: 757: In a `reg', it is used by the leaf register renumbering code to 758: ensure that each register is only renumbered once. 759: 760: `volatil' 761: This flag is used in `mem',`symbol_ref' and `reg' expressions and 762: in insns. In RTL dump files, it is printed as `/v'. 763: 764: In a `mem' expression, it is 1 if the memory reference is 765: volatile. Volatile memory references may not be deleted, 766: reordered or combined. 767: 768: In a `symbol_ref' expression, it is used for machine-specific 769: purposes. 770: 771: In a `reg' expression, it is 1 if the value is a user-level 772: variable. 0 indicates an internal compiler temporary. 773: 774: In an insn, 1 means the insn has been deleted. 775: 776: `in_struct' 777: In `mem' expressions, it is 1 if the memory datum referred to is 778: all or part of a structure or array; 0 if it is (or might be) a 779: scalar variable. A reference through a C pointer has 0 because 780: the pointer might point to a scalar variable. This information 781: allows the compiler to determine something about possible cases 782: of aliasing. 783: 784: In an insn in the delay slot of a branch, 1 means that this insn 785: is from the target of the branch. 786: 787: During instruction scheduling, in an insn, 1 means that this insn 788: must be scheduled as part of a group together with the previous 789: insn. 790: 791: In `reg' expressions, it is 1 if the register has its entire life 792: contained within the test expression of some loopl. 793: 794: In `label_ref' expressions, 1 means that the referenced label is 795: outside the innermost loop containing the insn in which the 796: `label_ref' was found. 797: 798: In `code_label' expressions, it is 1 if the label may never be 799: deleted. This is used for labels which are the target of 800: non-local gotos. 801: 802: In an RTL dump, this flag is represented as `/s'. 803: 804: `unchanging' 805: In `reg' and `mem' expressions, 1 means that the value of the 806: expression never changes. 807: 808: In an insn, 1 means that this is an annulling branch. 809: 810: In a `symbol_ref' expression, 1 means that this symbol addresses 811: something in the per-function constants pool. 812: 813: In a `call_insn', 1 means that this instruction is a call to a 814: const function. 815: 816: In an RTL dump, this flag is represented as `/u'. 817: 818: `integrated' 819: In some kinds of expressions, including insns, this flag means the 820: rtl was produced by procedure integration. 821: 822: In a `reg' expression, this flag indicates the register 823: containing the value to be returned by the current function. On 824: machines that pass parameters in registers, the same register 825: number may be used for parameters as well, but this flag is not 826: set on such uses. 827: 828: 829: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 830: 831: Machine Modes 832: ============= 833: 834: A machine mode describes a size of data object and the 835: representation used for it. In the C code, machine modes are 836: represented by an enumeration type, `enum machine_mode', defined in 837: `machmode.def'. Each RTL expression has room for a machine mode and 838: so do certain kinds of tree expressions (declarations and types, to be 839: precise). 840: 841: In debugging dumps and machine descriptions, the machine mode of an 842: RTL expression is written after the expression code with a colon to 843: separate them. The letters `mode' which appear at the end of each 844: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' 845: expression with machine mode `SImode'. If the mode is `VOIDmode', it 846: is not written at all. 847: 848: Here is a table of machine modes. The term "byte" below refers to 849: an object of `BITS_PER_UNIT' bits (*note Storage Layout::.). 850: 851: `QImode' 852: "Quarter-Integer" mode represents a single byte treated as an 853: integer. 854: 855: `HImode' 856: "Half-Integer" mode represents a two-byte integer. 857: 858: `PSImode' 859: "Partial Single Integer" mode represents an integer which occupies 860: four bytes but which doesn't really use all four. On some 861: machines, this is the right mode to use for pointers. 862: 863: `SImode' 864: "Single Integer" mode represents a four-byte integer. 865: 866: `PDImode' 867: "Partial Double Integer" mode represents an integer which occupies 868: eight bytes but which doesn't really use all eight. On some 869: machines, this is the right mode to use for certain pointers. 870: 871: `DImode' 872: "Double Integer" mode represents an eight-byte integer. 873: 874: `TImode' 875: "Tetra Integer" (?) mode represents a sixteen-byte integer. 876: 877: `SFmode' 878: "Single Floating" mode represents a single-precision (four byte) 879: floating point number. 880: 881: `DFmode' 882: "Double Floating" mode represents a double-precision (eight byte) 883: floating point number. 884: 885: `XFmode' 886: "Extended Floating" mode represents a triple-precision (twelve 887: byte) floating point number. This mode is used for IEEE extended 888: floating point. 889: 890: `TFmode' 891: "Tetra Floating" mode represents a quadruple-precision (sixteen 892: byte) floating point number. 893: 894: `CCmode' 895: "Condition Code" mode represents the value of a condition code, 896: which is a machine-specific set of bits used to represent the 897: result of a comparison operation. Other machine-specific modes 898: may also be used for the condition code. These modes are not 899: used on machines that use `cc0' (see *note Condition Code::.). 900: 901: `BLKmode' 902: "Block" mode represents values that are aggregates to which none 903: of the other modes apply. In RTL, only memory references can 904: have this mode, and only if they appear in string-move or vector 905: instructions. On machines which have no such instructions, 906: `BLKmode' will not appear in RTL. 907: 908: `VOIDmode' 909: Void mode means the absence of a mode or an unspecified mode. 910: For example, RTL expressions of code `const_int' have mode 911: `VOIDmode' because they can be taken to have whatever mode the 912: context requires. In debugging dumps of RTL, `VOIDmode' is 913: expressed by the absence of any mode. 914: 915: `SCmode, DCmode, XCmode, TCmode' 916: These modes stand for a complex number represented as a pair of 917: floating point values. The values are in `SFmode', `DFmode', 918: `XFmode', and `TFmode', respectively. Since C does not support 919: complex numbers, these machine modes are only partially 920: implemented. 921: 922: The machine description defines `Pmode' as a C macro which expands 923: into the machine mode used for addresses. Normally this is the mode 924: whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 925: 926: The only modes which a machine description must support are 927: `QImode', and the modes corresponding to `BITS_PER_WORD', 928: `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt 929: to use `DImode' for 8-byte structures and unions, but this can be 930: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. 931: Alternatively, you can have the compiler use `TImode' for 16-byte 932: structures and unions. Likewise, you can arrange for the C type 933: `short int' to avoid using `HImode'. 934: 935: Very few explicit references to machine modes remain in the 936: compiler and these few references will soon be removed. Instead, the 937: machine modes are divided into mode classes. These are represented by 938: the enumeration type `enum mode_class' defined in `machmode.h'. The 939: possible mode classes are: 940: 941: `MODE_INT' 942: Integer modes. By default these are `QImode', `HImode', 943: `SImode', `DImode', and `TImode'. 944: 945: `MODE_PARTIAL_INT' 946: The "partial integer" modes, `PSImode' and `PDImode'. 947: 948: `MODE_FLOAT' 949: floating point modes. By default these are `SFmode', `DFmode', 950: `XFmode' and `TFmode'. 951: 952: `MODE_COMPLEX_INT' 953: Complex integer modes. (These are not currently implemented). 954: 955: `MODE_COMPLEX_FLOAT' 956: Complex floating point modes. By default these are `SCmode', 957: `DCmode', `XCmode', and `TCmode'. 958: 959: `MODE_FUNCTION' 960: Algol or Pascal function variables including a static chain. 961: (These are not currently implemented). 962: 963: `MODE_CC' 964: Modes representing condition code values. These are `CCmode' plus 965: any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump 966: Patterns::, also see *Note Condition Code::. 967: 968: `MODE_RANDOM' 969: This is a catchall mode class for modes which don't fit into the 970: above classes. Currently `VOIDmode' and `BLKmode' are in 971: `MODE_RANDOM'. 972: 973: Here are some C macros that relate to machine modes: 974: 975: `GET_MODE (X)' 976: Returns the machine mode of the RTX X. 977: 978: `PUT_MODE (X, NEWMODE)' 979: Alters the machine mode of the RTX X to be NEWMODE. 980: 981: `NUM_MACHINE_MODES' 982: Stands for the number of machine modes available on the target 983: machine. This is one greater than the largest numeric value of 984: any machine mode. 985: 986: `GET_MODE_NAME (M)' 987: Returns the name of mode M as a string. 988: 989: `GET_MODE_CLASS (M)' 990: Returns the mode class of mode M. 991: 992: `GET_MODE_WIDER_MODE (M)' 993: Returns the next wider natural mode. E.g., 994: `GET_WIDER_MODE(QImode)' returns `HImode'. 995: 996: `GET_MODE_SIZE (M)' 997: Returns the size in bytes of a datum of mode M. 998: 999: `GET_MODE_BITSIZE (M)' 1000: Returns the size in bits of a datum of mode M. 1001: 1002: `GET_MODE_MASK (M)' 1003: Returns a bitmask containing 1 for all bits in a word that fit 1004: within mode M. This macro can only be used for modes whose 1005: bitsize is less than or equal to `HOST_BITS_PER_INT'. 1006: 1007: `GET_MODE_ALIGNMENT (M))' 1008: Return the required alignment, in bits, for an object of mode M. 1009: 1010: `GET_MODE_UNIT_SIZE (M)' 1011: Returns the size in bytes of the subunits of a datum of mode M. 1012: This is the same as `GET_MODE_SIZE' except in the case of complex 1013: modes. For them, the unit size is the size of the real or 1014: imaginary part. 1015: 1016: `GET_MODE_NUNITS (M)' 1017: Returns the number of units contained in a mode, i.e., 1018: `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 1019: 1020: `GET_CLASS_NARROWEST_MODE (C)' 1021: Returns the narrowest mode in mode class C. 1022: 1023: The global variables `byte_mode' and `word_mode' contain modes 1024: whose classes are `MODE_INT' and whose bitsizes are `BITS_PER_UNIT' or 1025: `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 1026: and `SImode', respectively. 1027: 1028: 1029: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 1030: 1031: Constant Expression Types 1032: ========================= 1033: 1034: The simplest RTL expressions are those that represent constant 1035: values. 1036: 1037: `(const_int I)' 1038: This type of expression represents the integer value I. I is 1039: customarily accessed with the macro `INTVAL' as in `INTVAL 1040: (EXP)', which is equivalent to `XINT (EXP, 0)'. 1041: 1042: Keep in mind that the result of `INTVAL' is an integer on the host 1043: machine. If the host machine has more bits in an `int' than the 1044: target machine has in the mode in which the constant will be 1045: used, then some of the bits you get from `INTVAL' will be 1046: superfluous. In many cases, for proper results, you must 1047: carefully disregard the values of those bits. 1048: 1049: There is only one expression object for the integer value zero; 1050: it is the value of the variable `const0_rtx'. Likewise, the only 1051: expression for integer value one is found in `const1_rtx', the 1052: only expression for integer value two is found in `const2_rtx', 1053: and the only expression for integer value negative one is found in 1054: `constm1_rtx'. Any attempt to create an expression of code 1055: `const_int' and value zero, one, two or negative one will return 1056: `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 1057: appropriate. 1058: 1059: Similarly, there is only one object for the integer whose value is 1060: `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 1061: `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 1062: point to the same object. If `STORE_FLAG_VALUE' is -1, 1063: `const_true_rtx' and `constm1_rtx' will point to the same object. 1064: 1065: `(const_double:M ADDR I0 I1 ...)' 1066: Represents either a floating-point constant of mode M or an 1067: integer constant that is too large to fit into `HOST_BITS_PER_INT' 1068: bits but small enough to fit within twice that number of bits 1069: (GNU CC does not provide a mechanism to represent even larger 1070: constants). In the latter case, M will be `VOIDmode'. 1071: 1072: ADDR is used to contain the `mem' expression that corresponds to 1073: the location in memory that at which the constant can be found. 1074: If it has not been allocated a memory location, but is on the 1075: chain of all `const_double' expressions in this compilation 1076: (maintained using an undisplayed field), ADDR contains 1077: `const0_rtx'. If it is not on the chain, ADDR contains 1078: `cc0_rtx'. ADDR is customarily accessed with the macro 1079: `CONST_DOUBLE_MEM' and the chain field via `CONST_DOUBLE_CHAIN'. 1080: 1.1.1.2 ! root 1081: If M is `VOIDmode', the bits of the value are stored in I0 and ! 1082: I1. I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' ! 1083: and I1 with `CONST_DOUBLE_HIGH'. 1.1 root 1084: 1085: If the constant is floating point (either single or double 1086: precision), then the number of integers used to store the value 1087: depends on the size of `REAL_VALUE_TYPE' (*note 1088: Cross-compilation::.). The integers represent a `double'. To 1089: convert them to a `double', do 1090: 1091: union real_extract u; 1092: bcopy (&CONST_DOUBLE_LOW (x), &u, sizeof u); 1093: 1094: and then refer to `u.d'. 1095: 1096: The macro `CONST0_RTX (MODE)' refers to an expression with value 1097: 0 in mode MODE. If mode MODE is of mode class `MODE_INT', it 1098: returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' 1099: expression in mode MODE. Similarly, the macro `CONST1_RTX 1100: (MODE)' refers to an expression with value 1 in mode MODE and 1101: similarly for `CONST2_RTX'. 1102: 1103: `(const_string STR)' 1104: Represents a constant string with value STR. Currently this is 1105: used only for insn attributes (*note Insn Attributes::.) since 1106: constant strings in C are placed in memory. 1107: 1.1.1.2 ! root 1108: `(symbol_ref:MODE SYMBOL)' 1.1 root 1109: Represents the value of an assembler label for data. SYMBOL is a 1110: string that describes the name of the assembler label. If it 1111: starts with a `*', the label is the rest of SYMBOL not including 1112: the `*'. Otherwise, the label is SYMBOL, usually prefixed with 1113: `_'. 1114: 1.1.1.2 ! root 1115: The `symbol_ref' contains a mode, which is usually `Pmode'. ! 1116: Usually that is the only mode for which a symbol is directly ! 1117: valid. ! 1118: 1.1 root 1119: `(label_ref LABEL)' 1120: Represents the value of an assembler label for code. It contains 1121: one operand, an expression, which must be a `code_label' that 1122: appears in the instruction sequence to identify the place where 1123: the label should go. 1124: 1125: The reason for using a distinct expression type for code label 1126: references is so that jump optimization can distinguish them. 1127: 1128: `(const:M EXP)' 1129: Represents a constant that is the result of an assembly-time 1130: arithmetic computation. The operand, EXP, is an expression that 1131: contains only constants (`const_int', `symbol_ref' and 1132: `label_ref' expressions) combined with `plus' and `minus'. 1133: However, not all combinations are valid, since the assembler 1134: cannot do arbitrary arithmetic on relocatable symbols. 1135: 1136: M should be `Pmode'. 1137: 1138: `(high:M EXP)' 1139: Represents the high-order bits of EXP, usually a `symbol_ref'. 1140: The number of bits is machine-dependent and is normally the 1141: number of bits specified in an instruction that initializes the 1142: high order bits of a register. It is used with `lo_sum' to 1143: represent the typical two-instruction sequence used in RISC 1144: machines to reference a global memory location. 1145: 1146: M should be `Pmode'. 1147: 1148:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.