![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-3 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / cmd / gcc|
Return to internals-3 CVS log | Up to [Research Unix] / researchv10dc / cmd / gcc |
1.1 ! root 1: ! 2: ! 3: File: internals, Node: Passes, Next: RTL, Prev: Interface, Up: Top ! 4: ! 5: Passes and Files of the Compiler ! 6: ******************************** ! 7: ! 8: The overall control structure of the compiler is in `toplev.c'. This file ! 9: is responsible for initialization, decoding arguments, opening and closing ! 10: files, and sequencing the passes. ! 11: ! 12: The parsing pass is invoked only once, to parse the entire input. The RTL ! 13: intermediate code for a function is generated as the function is parsed, a ! 14: statement at a time. Each statement is read in as a syntax tree and then ! 15: converted to RTL; then the storage for the tree for the statement is ! 16: reclaimed. Storage for types (and the expressions for their sizes), ! 17: declarations, and a representation of the binding contours and how they ! 18: nest, remains until the function is finished being compiled; these are all ! 19: needed to output the debugging information. ! 20: ! 21: Each time the parsing pass reads a complete function definition or ! 22: top-level declaration, it calls the function `rest_of_compilation' or ! 23: `rest_of_decl_compilation' in `toplev.c', which are responsible for all ! 24: further processing necessary, ending with output of the assembler language. ! 25: All other compiler passes run, in sequence, within `rest_of_compilation'. ! 26: When that function returns from compiling a function definition, the ! 27: storage used for that function definition's compilation is entirely freed, ! 28: unless it is an inline function (*Note Inline::.). ! 29: ! 30: Here is a list of all the passes of the compiler and their source files. ! 31: Also included is a description of where debugging dumps can be requested ! 32: with `-d' options. ! 33: ! 34: * Parsing. This pass reads the entire text of a function definition, ! 35: constructing partial syntax trees. This and RTL generation are no ! 36: longer truly separate passes (formerly they were), but it is easier to ! 37: think of them as separate. ! 38: ! 39: The tree representation does not entirely follow C syntax, because it ! 40: is intended to support other languages as well. ! 41: ! 42: C data type analysis is also done in this pass, and every tree node ! 43: that represents an expression has a data type attached. Variables are ! 44: represented as declaration nodes. ! 45: ! 46: Constant folding and associative-law simplifications are also done ! 47: during this pass. ! 48: ! 49: The source files for parsing are `parse.y', `decl.c', `typecheck.c', ! 50: `stor-layout.c', `fold-const.c', and `tree.c'. The last three are ! 51: intended to be language-independent. There are also header files ! 52: `parse.h', `c-tree.h', `tree.h' and `tree.def'. The last two define ! 53: the format of the tree representation. ! 54: ! 55: * RTL generation. This is the conversion of syntax tree into RTL code. ! 56: It is actually done statement-by-statement during parsing, but for ! 57: most purposes it can be thought of as a separate pass. ! 58: ! 59: This is where the bulk of target-parameter-dependent code is found, ! 60: since often it is necessary for strategies to apply only when certain ! 61: standard kinds of instructions are available. The purpose of named ! 62: instruction patterns is to provide this information to the RTL ! 63: generation pass. ! 64: ! 65: Optimization is done in this pass for `if'-conditions that are ! 66: comparisons, boolean operations or conditional expressions. Tail ! 67: recursion is detected at this time also. Decisions are made about how ! 68: best to arrange loops and how to output `switch' statements. ! 69: ! 70: The source files for RTL generation are `stmt.c', `expr.c', ! 71: `explow.c', `expmed.c', `optabs.c' and `emit-rtl.c'. Also, the file ! 72: `insn-emit.c', generated from the machine description by the program ! 73: `genemit', is used in this pass. The header files `expr.h' is used ! 74: for communication within this pass. ! 75: ! 76: The header files `insn-flags.h' and `insn-codes.h', generated from the ! 77: machine description by the programs `genflags' and `gencodes', tell ! 78: this pass which standard names are available for use and which ! 79: patterns correspond to them. ! 80: ! 81: Aside from debugging information output, none of the following passes ! 82: refers to the tree structure representation of the function (only part ! 83: of which is saved). ! 84: ! 85: The decision of whether the function can and should be expanded inline ! 86: in its subsequent callers is made at the end of rtl generation. The ! 87: function must meet certain criteria, currently related to the size of ! 88: the function and the types and number of parameters it has. Note that ! 89: this function may contain loops, recursive calls to itself ! 90: (tail-recursive functions can be inlined!), gotos, in short, all ! 91: constructs supported by GNU CC. ! 92: ! 93: The option `-dr' causes a debugging dump of the RTL code after this ! 94: pass. This dump file's name is made by appending `.rtl' to the input ! 95: file name. ! 96: ! 97: * Jump optimization. This pass simplifies jumps to the following ! 98: instruction, jumps across jumps, and jumps to jumps. It deletes ! 99: unreferenced labels and unreachable code, except that unreachable code ! 100: that contains a loop is not recognized as unreachable in this pass. ! 101: (Such loops are deleted later in the basic block analysis.) ! 102: ! 103: Jump optimization is performed two or three times. The first time is ! 104: immediately following RTL generation. The second time is after CSE, ! 105: but only if CSE says repeated jump optimization is needed. The last ! 106: time is right before the final pass. That time, cross-jumping and ! 107: deletion of no-op move instructions are done together with the ! 108: optimizations described above. ! 109: ! 110: The source file of this pass is `jump.c'. ! 111: ! 112: The option `-dj' causes a debugging dump of the RTL code after this ! 113: pass is run for the first time. This dump file's name is made by ! 114: appending `.jump' to the input file name. ! 115: ! 116: * Register scan. This pass finds the first and last use of each ! 117: register, as a guide for common subexpression elimination. Its source ! 118: is in `regclass.c'. ! 119: ! 120: * Common subexpression elimination. This pass also does constant ! 121: propagation. Its source file is `cse.c'. If constant propagation ! 122: causes conditional jumps to become unconditional or to become no-ops, ! 123: jump optimization is run again when CSE is finished. ! 124: ! 125: The option `-ds' causes a debugging dump of the RTL code after this ! 126: pass. This dump file's name is made by appending `.cse' to the input ! 127: file name. ! 128: ! 129: * Loop optimization. This pass moves constant expressions out of loops. ! 130: Its source file is `loop.c'. ! 131: ! 132: The option `-dL' causes a debugging dump of the RTL code after this ! 133: pass. This dump file's name is made by appending `.loop' to the input ! 134: file name. ! 135: ! 136: * Stupid register allocation is performed at this point in a ! 137: nonoptimizing compilation. It does a little data flow analysis as ! 138: well. When stupid register allocation is in use, the next pass ! 139: executed is the reloading pass; the others in between are skipped. ! 140: The source file is `stupid.c'. ! 141: ! 142: * Data flow analysis (`flow.c'). This pass divides the program into ! 143: basic blocks (and in the process deletes unreachable loops); then it ! 144: computes which pseudo-registers are live at each point in the program, ! 145: and makes the first instruction that uses a value point at the ! 146: instruction that computed the value. ! 147: ! 148: This pass also deletes computations whose results are never used, and ! 149: combines memory references with add or subtract instructions to make ! 150: autoincrement or autodecrement addressing. ! 151: ! 152: The option `-df' causes a debugging dump of the RTL code after this ! 153: pass. This dump file's name is made by appending `.flow' to the input ! 154: file name. If stupid register allocation is in use, this dump file ! 155: reflects the full results of such allocation. ! 156: ! 157: * Instruction combination (`combine.c'). This pass attempts to combine ! 158: groups of two or three instructions that are related by data flow into ! 159: single instructions. It combines the RTL expressions for the ! 160: instructions by substitution, simplifies the result using algebra, and ! 161: then attempts to match the result against the machine description. ! 162: ! 163: The option `-dc' causes a debugging dump of the RTL code after this ! 164: pass. This dump file's name is made by appending `.combine' to the ! 165: input file name. ! 166: ! 167: * Register class preferencing. The RTL code is scanned to find out ! 168: which register class is best for each pseudo register. The source ! 169: file is `regclass.c'. ! 170: ! 171: * Local register allocation (`local-alloc.c'). This pass allocates hard ! 172: registers to pseudo registers that are used only within one basic ! 173: block. Because the basic block is linear, it can use fast and ! 174: powerful techniques to do a very good job. ! 175: ! 176: The option `-dl' causes a debugging dump of the RTL code after this ! 177: pass. This dump file's name is made by appending `.lreg' to the input ! 178: file name. ! 179: ! 180: * Global register allocation (`global-alloc.c'). This pass allocates ! 181: hard registers for the remaining pseudo registers (those whose life ! 182: spans are not contained in one basic block). ! 183: ! 184: * Reloading. This pass renumbers pseudo registers with the hardware ! 185: registers numbers they were allocated. Pseudo registers that did not ! 186: get hard registers are replaced with stack slots. Then it finds ! 187: instructions that are invalid because a value has failed to end up in ! 188: a register, or has ended up in a register of the wrong kind. It fixes ! 189: up these instructions by reloading the problematical values ! 190: temporarily into registers. Additional instructions are generated to ! 191: do the copying. ! 192: ! 193: Source files are `reload.c' and `reload1.c', plus the header ! 194: `reload.h' used for communication between them. ! 195: ! 196: The option `-dg' causes a debugging dump of the RTL code after this ! 197: pass. This dump file's name is made by appending `.greg' to the input ! 198: file name. ! 199: ! 200: * Jump optimization is repeated, this time including cross-jumping and ! 201: deletion of no-op move instructions. Machine-specific peephole ! 202: optimizations are performed at the same time. ! 203: ! 204: The option `-dJ' causes a debugging dump of the RTL code after this ! 205: pass. This dump file's name is made by appending `.jump2' to the ! 206: input file name. ! 207: ! 208: * Final. This pass outputs the assembler code for the function. It is ! 209: also responsible for identifying spurious test and compare ! 210: instructions. The function entry and exit sequences are generated ! 211: directly as assembler code in this pass; they never exist as RTL. ! 212: ! 213: The source files are `final.c' plus `insn-output.c'; the latter is ! 214: generated automatically from the machine description by the tool ! 215: `genoutput'. The header file `conditions.h' is used for communication ! 216: between these files. ! 217: ! 218: * Debugging information output. This is run after final because it must ! 219: output the stack slot offsets for pseudo registers that did not get ! 220: hard registers. Source files are `dbxout.c' for DBX symbol table ! 221: format and `symout.c' for GDB's own symbol table format. ! 222: ! 223: Some additional files are used by all or many passes: ! 224: ! 225: * Every pass uses `machmode.def', which defines the machine modes. ! 226: ! 227: * All the passes that work with RTL use the header files `rtl.h' and ! 228: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also use ! 229: these files to read and work with the machine description RTL. ! 230: ! 231: * Several passes refer to the header file `insn-config.h' which contains ! 232: a few parameters (C macro definitions) generated automatically from ! 233: the machine description RTL by the tool `genconfig'. ! 234: ! 235: * Several passes use the instruction recognizer, which consists of ! 236: `recog.c' and `recog.h', plus the files `insn-recog.c' and ! 237: `insn-extract.c' that are generated automatically from the machine ! 238: description by the tools `genrecog' and `genextract'. ! 239: ! 240: * Several passes use the header files `regs.h' which defines the ! 241: information recorded about pseudo register usage, and `basic-block.h' ! 242: which defines the information recorded about basic blocks. ! 243: ! 244: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector with a ! 245: bit for each hard register, and some macros to manipulate it. This ! 246: type is just `int' if the machine has few enough hard registers; ! 247: otherwise it is an array of `int' and some of the macros expand into ! 248: loops. ! 249: ! 250: ! 251: File: internals, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top ! 252: ! 253: RTL Representation ! 254: ****************** ! 255: ! 256: Most of the work of the compiler is done on an intermediate representation ! 257: called register transfer language. In this language, the instructions to ! 258: be output are described, pretty much one by one, in an algebraic form that ! 259: describes what the instruction does. ! 260: ! 261: RTL is inspired by Lisp lists. It has both an internal form, made up of ! 262: structures that point at other structures, and a textual form that is used ! 263: in the machine description and in printed debugging dumps. The textual ! 264: form uses nested parentheses to indicate the pointers in the internal form. ! 265: ! 266: * Menu: ! 267: ! 268: * RTL Objects:: Expressions vs vectors vs strings vs integers. ! 269: * Accessors:: Macros to access expression operands or vector elts. ! 270: * Flags:: Other flags in an RTL expression. ! 271: * Machine Modes:: Describing the size and format of a datum. ! 272: * Constants:: Expressions with constant values. ! 273: * Regs and Memory:: Expressions representing register contents or memory. ! 274: * Arithmetic:: Expressions representing arithmetic on other expressions. ! 275: * Comparisons:: Expressions representing comparison of expressions. ! 276: * Bit Fields:: Expressions representing bit-fields in memory or reg. ! 277: * Conversions:: Extending, truncating, floating or fixing. ! 278: * RTL Declarations:: Declaring volatility, constancy, etc. ! 279: * Side Effects:: Expressions for storing in registers, etc. ! 280: * Incdec:: Embedded side-effects for autoincrement addressing. ! 281: * Assembler:: Representing `asm' with operands. ! 282: * Insns:: Expression types for entire insns. ! 283: * Calls:: RTL representation of function call insns. ! 284: * Sharing:: Some expressions are unique; others *must* be copied. ! 285: ! 286: ! 287: ! 288: File: internals, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL ! 289: ! 290: RTL Object Types ! 291: ================ ! 292: ! 293: RTL uses four kinds of objects: expressions, integers, strings and vectors. ! 294: Expressions are the most important ones. An RTL expression (``RTX'', for ! 295: short) is a C structure, but it is usually referred to with a pointer; a ! 296: type that is given the typedef name `rtx'. ! 297: ! 298: An integer is simply an `int', and a string is a `char *'. Within RTL ! 299: code, strings appear only inside `symbol_ref' expressions, but they appear ! 300: in other contexts in the RTL expressions that make up machine descriptions. ! 301: Their written form uses decimal digits. ! 302: ! 303: A string is a sequence of characters. In core it is represented as a `char ! 304: *' in usual C fashion, and it is written in C syntax as well. However, ! 305: strings in RTL may never be null. If you write an empty string in a ! 306: machine description, it is represented in core as a null pointer rather ! 307: than as a pointer to a null character. In certain contexts, these null ! 308: pointers instead of strings are valid. ! 309: ! 310: A vector contains an arbitrary, specified number of pointers to ! 311: expressions. The number of elements in the vector is explicitly present in ! 312: the vector. The written form of a vector consists of square brackets ! 313: (`[...]') surrounding the elements, in sequence and with whitespace ! 314: separating them. Vectors of length zero are not created; null pointers are ! 315: used instead. ! 316: ! 317: Expressions are classified by "expression codes" (also called RTX codes). ! 318: The expression code is a name defined in `rtl.def', which is also (in upper ! 319: case) a C enumeration constant. The possible expression codes and their ! 320: meanings are machine-independent. The code of an RTX can be extracted with ! 321: the macro `GET_CODE (X)' and altered with `PUT_CODE (X, NEWCODE)'. ! 322: ! 323: The expression code determines how many operands the expression contains, ! 324: and what kinds of objects they are. In RTL, unlike Lisp, you cannot tell ! 325: by looking at an operand what kind of object it is. Instead, you must know ! 326: from its context---from the expression code of the containing expression. ! 327: For example, in an expression of code `subreg', the first operand is to be ! 328: regarded as an expression and the second operand as an integer. In an ! 329: expression of code `plus', there are two operands, both of which are to be ! 330: regarded as expressions. In a `symbol_ref' expression, there is one ! 331: operand, which is to be regarded as a string. ! 332: ! 333: Expressions are written as parentheses containing the name of the ! 334: expression type, its flags and machine mode if any, and then the operands ! 335: of the expression (separated by spaces). ! 336: ! 337: Expression code names in the `md' file are written in lower case, but when ! 338: they appear in C code they are written in upper case. In this manual, they ! 339: are shown as follows: `const_int'. ! 340: ! 341: In a few contexts a null pointer is valid where an expression is normally ! 342: wanted. The written form of this is `(nil)'. ! 343: ! 344: ! 345: File: internals, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL ! 346: ! 347: Access to Operands ! 348: ================== ! 349: ! 350: For each expression type `rtl.def' specifies the number of contained ! 351: objects and their kinds, with four possibilities: `e' for expression ! 352: (actually a pointer to an expression), `i' for integer, `s' for string, and ! 353: `E' for vector of expressions. The sequence of letters for an expression ! 354: code is called its "format". Thus, the format of `subreg' is `ei'. ! 355: ! 356: Two other format characters are used occasionally: `u' and `0'. `u' is ! 357: equivalent to `e' except that it is printed differently in debugging dumps, ! 358: and `0' means a slot whose contents do not fit any normal category. `0' ! 359: slots are not printed at all in dumps, and are often used in special ways ! 360: by small parts of the compiler. ! 361: ! 362: There are macros to get the number of operands and the format of an ! 363: expression code: ! 364: ! 365: `GET_RTX_LENGTH (CODE)' ! 366: Number of operands of an RTX of code CODE. ! 367: ! 368: `GET_RTX_FORMAT (CODE)' ! 369: The format of an RTX of code CODE, as a C string. ! 370: ! 371: Operands of expressions are accessed using the macros `XEXP', `XINT' and ! 372: `XSTR'. Each of these macros takes two arguments: an expression-pointer ! 373: (RTX) and an operand number (counting from zero). Thus, ! 374: ! 375: XEXP (X, 2) ! 376: ! 377: accesses operand 2 of expression X, as an expression. ! 378: ! 379: XINT (X, 2) ! 380: ! 381: accesses the same operand as an integer. `XSTR', used in the same fashion, ! 382: would access it as a string. ! 383: ! 384: Any operand can be accessed as an integer, as an expression or as a string. ! 385: You must choose the correct method of access for the kind of value ! 386: actually stored in the operand. You would do this based on the expression ! 387: code of the containing expression. That is also how you would know how ! 388: many operands there are. ! 389: ! 390: For example, if X is a `subreg' expression, you know that it has two ! 391: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, ! 392: 1)'. If you did `XINT (X, 0)', you would get the address of the expression ! 393: operand but cast as an integer; that might occasionally be useful, but it ! 394: would be cleaner to write `(int) XEXP (X, 0)'. `XEXP (X, 1)' would also ! 395: compile without error, and would return the second, integer operand cast as ! 396: an expression pointer, which would probably result in a crash when ! 397: accessed. Nothing stops you from writing `XEXP (X, 28)' either, but this ! 398: will access memory past the end of the expression with unpredictable results. ! 399: ! 400: Access to operands which are vectors is more complicated. You can use the ! 401: macro `XVEC' to get the vector-pointer itself, or the macros `XVECEXP' and ! 402: `XVECLEN' to access the elements and length of a vector. ! 403: ! 404: `XVEC (EXP, IDX)' ! 405: Access the vector-pointer which is operand number IDX in EXP. ! 406: ! 407: `XVECLEN (EXP, IDX)' ! 408: Access the length (number of elements) in the vector which is in ! 409: operand number IDX in EXP. This value is an `int'. ! 410: ! 411: `XVECEXP (EXP, IDX, ELTNUM)' ! 412: Access element number ELTNUM in the vector which is in operand number ! 413: IDX in EXP. This value is an RTX. ! 414: ! 415: It is up to you to make sure that ELTNUM is not negative and is less ! 416: than `XVECLEN (EXP, IDX)'. ! 417: ! 418: All the macros defined in this section expand into lvalues and therefore ! 419: can be used to assign the operands, lengths and vector elements as well as ! 420: to access them. ! 421: ! 422: ! 423: File: internals, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL ! 424: ! 425: Flags in an RTL Expression ! 426: ========================== ! 427: ! 428: RTL expressions contain several flags (one-bit bit-fields) that are used in ! 429: certain types of expression. ! 430: ! 431: `used' ! 432: This flag is used only momentarily, at the end of RTL generation for a ! 433: function, to count the number of times an expression appears in insns. ! 434: Expressions that appear more than once are copied, according to the ! 435: rules for shared structure (*Note Sharing::.). ! 436: ! 437: `volatil' ! 438: This flag is used in `mem' and `reg' expressions and in insns. In RTL ! 439: dump files, it is printed as `/v'. ! 440: ! 441: In a `mem' expression, it is 1 if the memory reference is volatile. ! 442: Volatile memory references may not be deleted, reordered or combined. ! 443: ! 444: In a `reg' expression, it is 1 if the value is a user-level variable. ! 445: 0 indicates an internal compiler temporary. ! 446: ! 447: In an insn, 1 means the insn has been deleted. ! 448: ! 449: `in_struct' ! 450: This flag is used in `mem' expressions. It is 1 if the memory datum ! 451: referred to is all or part of a structure or array; 0 if it is (or ! 452: might be) a scalar variable. A reference through a C pointer has 0 ! 453: because the pointer might point to a scalar variable. ! 454: ! 455: This information allows the compiler to determine something about ! 456: possible cases of aliasing. ! 457: ! 458: In an RTL dump, this flag is represented as `/s'. ! 459: ! 460: `unchanging' ! 461: This flag is used in `reg' and `mem' expressions. 1 means that the ! 462: value of the expression never changes (at least within the current ! 463: function). ! 464: ! 465: In an RTL dump, this flag is represented as `/u'. ! 466: ! 467: ! 468: File: internals, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL ! 469: ! 470: Machine Modes ! 471: ============= ! 472: ! 473: A machine mode describes a size of data object and the representation used ! 474: for it. In the C code, machine modes are represented by an enumeration ! 475: type, `enum machine_mode', defined in `machmode.def'. Each RTL expression ! 476: has room for a machine mode and so do certain kinds of tree expressions ! 477: (declarations and types, to be precise). ! 478: ! 479: In debugging dumps and machine descriptions, the machine mode of an RTL ! 480: expression is written after the expression code with a colon to separate ! 481: them. The letters `mode' which appear at the end of each machine mode name ! 482: are omitted. For example, `(reg:SI 38)' is a `reg' expression with machine ! 483: mode `SImode'. If the mode is `VOIDmode', it is not written at all. ! 484: ! 485: Here is a table of machine modes. ! 486: ! 487: `QImode' ! 488: ``Quarter-Integer'' mode represents a single byte treated as an integer. ! 489: ! 490: `HImode' ! 491: ``Half-Integer'' mode represents a two-byte integer. ! 492: ! 493: `SImode' ! 494: ``Single Integer'' mode represents a four-byte integer. ! 495: ! 496: `DImode' ! 497: ``Double Integer'' mode represents an eight-byte integer. ! 498: ! 499: `TImode' ! 500: ``Tetra Integer'' (?) mode represents a sixteen-byte integer. ! 501: ! 502: `SFmode' ! 503: ``Single Floating'' mode represents a single-precision (four byte) ! 504: floating point number. ! 505: ! 506: `DFmode' ! 507: ``Double Floating'' mode represents a double-precision (eight byte) ! 508: floating point number. ! 509: ! 510: `TFmode' ! 511: ``Tetra Floating'' mode represents a quadruple-precision (sixteen ! 512: byte) floating point number. ! 513: ! 514: `BLKmode' ! 515: ``Block'' mode represents values that are aggregates to which none of ! 516: the other modes apply. In RTL, only memory references can have this ! 517: mode, and only if they appear in string-move or vector instructions. ! 518: On machines which have no such instructions, `BLKmode' will not appear ! 519: in RTL. ! 520: ! 521: `VOIDmode' ! 522: Void mode means the absence of a mode or an unspecified mode. For ! 523: example, RTL expressions of code `const_int' have mode `VOIDmode' ! 524: because they can be taken to have whatever mode the context requires. ! 525: In debugging dumps of RTL, `VOIDmode' is expressed by the absence of ! 526: any mode. ! 527: ! 528: `EPmode' ! 529: ``Entry Pointer'' mode is intended to be used for function variables ! 530: in Pascal and other block structured languages. Such values contain ! 531: both a function address and a static chain pointer for access to ! 532: automatic variables of outer levels. This mode is only partially ! 533: implemented since C does not use it. ! 534: ! 535: `CSImode, ...' ! 536: ``Complex Single Integer'' mode stands for a complex number ! 537: represented as a pair of `SImode' integers. Any of the integer and ! 538: floating modes may have `C' prefixed to its name to obtain a complex ! 539: number mode. For example, there are `CQImode', `CSFmode', and ! 540: `CDFmode'. Since C does not support complex numbers, these machine ! 541: modes are only partially implemented. ! 542: ! 543: `BImode' ! 544: This is the machine mode of a bit-field in a structure. It is used ! 545: only in the syntax tree, never in RTL, and in the syntax tree it ! 546: appears only in declaration nodes. In C, it appears only in ! 547: `FIELD_DECL' nodes for structure fields defined with a bit size. ! 548: ! 549: The machine description defines `Pmode' as a C macro which expands into the ! 550: machine mode used for addresses. Normally this is `SImode'. ! 551: ! 552: The only modes which a machine description must support are `QImode', ! 553: `SImode', `SFmode' and `DFmode'. The compiler will attempt to use `DImode' ! 554: for two-word structures and unions, but it would not be hard to program it ! 555: to avoid this. Likewise, you can arrange for the C type `short int' to ! 556: avoid using `HImode'. In the long term it would be desirable to make the ! 557: set of available machine modes machine-dependent and eliminate all ! 558: assumptions about specific machine modes or their uses from the ! 559: machine-independent code of the compiler. ! 560: ! 561: Here are some C macros that relate to machine modes: ! 562: ! 563: `GET_MODE (X)' ! 564: Returns the machine mode of the RTX X. ! 565: ! 566: `PUT_MODE (X, NEWMODE)' ! 567: Alters the machine mode of the RTX X to be NEWMODE. ! 568: ! 569: `GET_MODE_SIZE (M)' ! 570: Returns the size in bytes of a datum of mode M. ! 571: ! 572: `GET_MODE_BITSIZE (M)' ! 573: Returns the size in bits of a datum of mode M. ! 574: ! 575: `GET_MODE_UNIT_SIZE (M)' ! 576: Returns the size in bits of the subunits of a datum of mode M. This ! 577: is the same as `GET_MODE_SIZE' except in the case of complex modes and ! 578: `EPmode'. For them, the unit size is the size of the real or ! 579: imaginary part, or the size of the function pointer or the context ! 580: pointer. ! 581: ! 582: ! 583: File: internals, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL ! 584: ! 585: Constant Expression Types ! 586: ========================= ! 587: ! 588: The simplest RTL expressions are those that represent constant values. ! 589: ! 590: `(const_int I)' ! 591: This type of expression represents the integer value I. I is ! 592: customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', ! 593: which is equivalent to `XINT (EXP, 0)'. ! 594: ! 595: There is only one expression object for the integer value zero; it is ! 596: the value of the variable `const0_rtx'. Likewise, the only expression ! 597: for integer value one is found in `const1_rtx'. Any attempt to create ! 598: an expression of code `const_int' and value zero or one will return ! 599: `const0_rtx' or `const1_rtx' as appropriate. ! 600: ! 601: `(const_double:M I0 I1)' ! 602: Represents a floating point constant value of mode M. The two ! 603: inteGERS I0 and I1 together contain the bits of a `double' value. To ! 604: convert them to a `double', do ! 605: ! 606: union { double d; int i[2];} u; ! 607: u.i[0] = XINT (x, 0); ! 608: u.i[1] = XINT (x, 1); ! 609: ! 610: and then refer to `u.d'. The value of the constant is represented as ! 611: a double in this fashion even if the value represented is ! 612: single-precision. ! 613: ! 614: The global variables `dconst0_rtx' and `fconst0_rtx' hold ! 615: `const_double' expressions with value 0, in modes `DFmode' and ! 616: `SFmode', respectively. ! 617: ! 618: `(symbol_ref SYMBOL)' ! 619: Represents the value of an assembler label for data. SYMBOL is a ! 620: string that describes the name of the assembler label. If it starts ! 621: with a `*', the label is the rest of SYMBOL not including the `*'. ! 622: Otherwise, the label is SYMBOL, prefixed with `_'. ! 623: ! 624: `(label_ref LABEL)' ! 625: Represents the value of an assembler label for code. It contains one ! 626: operand, an expression, which must be a `code_label' that appears in ! 627: the instruction sequence to identify the place where the label should ! 628: go. ! 629: ! 630: The reason for using a distinct expression type for code label ! 631: references is so that jump optimization can distinguish them. ! 632: ! 633: `(const EXP)' ! 634: Represents a constant that is the result of an assembly-time ! 635: arithmetic computation. The operand, EXP, is an expression that ! 636: contains only constants (`const_int', `symbol_ref' and `label_ref' ! 637: expressions) combined with `plus' and `minus'. However, not all ! 638: combinations are valid, since the assembler cannot do arbitrary ! 639: arithmetic on relocatable symbols. ! 640: ! 641: ! 642: File: internals, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL ! 643: ! 644: Registers and Memory ! 645: ==================== ! 646: ! 647: Here are the RTL expression types for describing access to machine ! 648: registers and to main memory. ! 649: ! 650: `(reg:M N)' ! 651: For small values of the integer N (less than `FIRST_PSEUDO_REGISTER'), ! 652: this stands for a reference to machine register number N: a "hard ! 653: register". For larger values of N, it stands for a temporary value or ! 654: "pseudo register". The compiler's strategy is to generate code ! 655: assuming an unlimited number of such pseudo registers, and later ! 656: convert them into hard registers or into memory references. ! 657: ! 658: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine ! 659: description, since the number of hard registers on the machine is an ! 660: invariant characteristic of the machine. Note, however, that not all ! 661: of the machine registers must be general registers. All the machine ! 662: registers that can be used for storage of data are given hard register ! 663: numbers, even those that can be used only in certain instructions or ! 664: can hold only certain types of data. ! 665: ! 666: Each pseudo register number used in a function's RTL code is ! 667: represented by a unique `reg' expression. ! 668: ! 669: M is the machine mode of the reference. It is necessary because ! 670: machines can generally refer to each register in more than one mode. ! 671: For example, a register may contain a full word but there may be ! 672: instructions to refer to it as a half word or as a single byte, as ! 673: well as instructions to refer to it as a floating point number of ! 674: various precisions. ! 675: ! 676: Even for a register that the machine can access in only one mode, the ! 677: mode must always be specified. ! 678: ! 679: A hard register may be accessed in various modes throughout one ! 680: function, but each pseudo register is given a natural mode and is ! 681: accessed only in that mode. When it is necessary to describe an ! 682: access to a pseudo register using a nonnatural mode, a `subreg' ! 683: expression is used. ! 684: ! 685: A `reg' expression with a machine mode that specifies more than one ! 686: word of data may actually stand for several consecutive registers. If ! 687: in addition the register number specifies a hardware register, then it ! 688: actually represents several consecutive hardware registers starting ! 689: with the specified one. ! 690: ! 691: Such multi-word hardware register `reg' expressions may not be live ! 692: across the boundary of a basic block. The lifetime analysis pass does ! 693: not know how to record properly that several consecutive registers are ! 694: actually live there, and therefore register allocation would be ! 695: confused. The CSE pass must go out of its way to make sure the ! 696: situation does not arise. ! 697: ! 698: `(subreg:M REG WORDNUM)' ! 699: `subreg' expressions are used to refer to a register in a machine mode ! 700: other than its natural one, or to refer to one register of a ! 701: multi-word `reg' that actually refers to several registers. ! 702: ! 703: Each pseudo-register has a natural mode. If it is necessary to ! 704: operate on it in a different mode---for example, to perform a fullword ! 705: move instruction on a pseudo-register that contains a single byte--- ! 706: the pseudo-register must be enclosed in a `subreg'. In such a case, ! 707: WORDNUM is zero. ! 708: ! 709: The other use of `subreg' is to extract the individual registers of a ! 710: multi-register value. Machine modes such as `DImode' and `EPmode' ! 711: indicate values longer than a word, values which usually require two ! 712: consecutive registers. To access one of the registers, use a `subreg' ! 713: with mode `SImode' and a WORDNUM that says which register. ! 714: ! 715: The compilation parameter `WORDS_BIG_ENDIAN', if defined, says that ! 716: word number zero is the most significant part; otherwise, it is the ! 717: least significant part. ! 718: ! 719: Note that it is not valid to access a `DFmode' value in `SFmode' using ! 720: a `subreg'. On some machines the most significant part of a `DFmode' ! 721: value does not have the same format as a single-precision floating ! 722: value. ! 723: ! 724: `(cc0)' ! 725: This refers to the machine's condition code register. It has no ! 726: operands and may not have a machine mode. It may be validly used in ! 727: only two contexts: as the destination of an assignment (in test and ! 728: compare instructions) and in comparison operators comparing against ! 729: zero (`const_int' with value zero; that is to say, `const0_rtx'). ! 730: ! 731: There is only one expression object of code `cc0'; it is the value of ! 732: the variable `cc0_rtx'. Any attempt to create an expression of code ! 733: `cc0' will return `cc0_rtx'. ! 734: ! 735: One special thing about the condition code register is that ! 736: instructions can set it implicitly. On many machines, nearly all ! 737: instructions set the condition code based on the value that they ! 738: compute or store. It is not necessary to record these actions ! 739: explicitly in the RTL because the machine description includes a ! 740: prescription for recognizing the instructions that do so (by means of ! 741: the macro `NOTICE_UPDATE_CC'). Only instructions whose sole purpose ! 742: is to set the condition code, and instructions that use the condition ! 743: code, need mention `(cc0)'. ! 744: ! 745: `(pc)' ! 746: This represents the machine's program counter. It has no operands and ! 747: may not have a machine mode. `(pc)' may be validly used only in ! 748: certain specific contexts in jump instructions. ! 749: ! 750: There is only one expression object of code `pc'; it is the value of ! 751: the variable `pc_rtx'. Any attempt to create an expression of code ! 752: `pc' will return `pc_rtx'. ! 753: ! 754: All instructions that do not jump alter the program counter implicitly ! 755: by incrementing it, but there is no need to mention this in the RTL. ! 756: ! 757: `(mem:M ADDR)' ! 758: This RTX represents a reference to main memory at an address ! 759: represented by the expression ADDR. M specifies how large a unit of ! 760: memory is accessed. ! 761: ! 762: ! 763: File: internals, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL ! 764: ! 765: RTL Expressions for Arithmetic ! 766: ============================== ! 767: ! 768: `(plus:M X Y)' ! 769: Represents the sum of the values represented by X and Y carried out in ! 770: machine mode M. This is valid only if X and Y both are valid for mode ! 771: M. ! 772: ! 773: `(minus:M X Y)' ! 774: Like `plus' but represents subtraction. ! 775: ! 776: `(minus X Y)' ! 777: Represents the result of subtracting Y from X for purposes of ! 778: comparison. The absence of a machine mode in the `minus' expression ! 779: indicates that the result is computed without overflow, as if with ! 780: infinite precision. ! 781: ! 782: Of course, machines can't really subtract with infinite precision. ! 783: However, they can pretend to do so when only the sign of the result ! 784: will be used, which is the case when the result is stored in `(cc0)'. ! 785: And that is the only way this kind of expression may validly be used: ! 786: as a value to be stored in the condition codes. ! 787: ! 788: `(neg:M X)' ! 789: Represents the negation (subtraction from zero) of the value ! 790: represented by X, carried out in mode M. X must be valid for mode M. ! 791: ! 792: `(mult:M X Y)' ! 793: Represents the signed product of the values represented by X and Y ! 794: carried out in machine mode M. If X and Y are both valid for mode M, ! 795: this is ordinary size-preserving multiplication. Alternatively, both ! 796: X and Y may be valid for a different, narrower mode. This represents ! 797: the kind of multiplication that generates a product wider than the ! 798: operands. Widening multiplication and same-size multiplication are ! 799: completely distinct and supported by different machine instructions; ! 800: machines may support one but not the other. ! 801: ! 802: `mult' may be used for floating point division as well. Then M is a ! 803: floating point machine mode. ! 804: ! 805: `(umult:M X Y)' ! 806: Like `mult' but represents unsigned multiplication. It may be used in ! 807: both same-size and widening forms, like `mult'. `umult' is used only ! 808: for fixed-point multiplication. ! 809: ! 810: `(div:M X Y)' ! 811: Represents the quotient in signed division of X by Y, carried out in ! 812: machine mode M. If M is a floating-point mode, it represents the ! 813: exact quotient; otherwise, the integerized quotient. If X and Y are ! 814: both valid for mode M, this is ordinary size-preserving division. ! 815: Some machines have division instructions in which the operands and ! 816: quotient widths are not all the same; such instructions are ! 817: represented by `div' expressions in which the machine modes are not ! 818: all the same. ! 819: ! 820: `(udiv:M X Y)' ! 821: Like `div' but represents unsigned division. ! 822: ! 823: `(mod:M X Y)' ! 824: `(umod:M X Y)' ! 825: Like `div' and `udiv' but represent the remainder instead of the ! 826: quotient. ! 827: ! 828: `(not:M X)' ! 829: Represents the bitwise complement of the value represented by X, ! 830: carried out in mode M, which must be a fixed-point machine mode. X ! 831: must be valid for mode M, which must be a fixed-point mode. ! 832: ! 833: `(and:M X Y)' ! 834: Represents the bitwise logical-and of the values represented by X and ! 835: Y, carried out in machine mode M. This is valid only if X and Y both ! 836: are valid for mode M, which must be a fixed-point mode. ! 837: ! 838: `(ior:M X Y)' ! 839: Represents the bitwise inclusive-or of the values represented by X and ! 840: Y, carried out in machine mode M. This is valid only if X and Y both ! 841: are valid for mode M, which must be a fixed-point mode. ! 842: ! 843: `(xor:M X Y)' ! 844: Represents the bitwise exclusive-or of the values represented by X and ! 845: Y, carried out in machine mode M. This is valid only if X and Y both ! 846: are valid for mode M, which must be a fixed-point mode. ! 847: ! 848: `(lshift:M X C)' ! 849: Represents the result of logically shifting X left by C places. X ! 850: must be valid for the mode M, a fixed-point machine mode. C must be ! 851: valid for a fixed-point mode; which mode is determined by the mode ! 852: called for in the machine description entry for the left-shift ! 853: instruction. For example, on the Vax, the mode of C is `QImode' ! 854: regardless of M. ! 855: ! 856: On some machines, negative values of C may be meaningful; this is why ! 857: logical left shift and arithmetic left shift are distinguished. For ! 858: example, Vaxes have no right-shift instructions, and right shifts are ! 859: represented as left-shift instructions whose counts happen to be ! 860: negative constants or else computed (in a previous instruction) by ! 861: negation. ! 862: ! 863: `(ashift:M X C)' ! 864: Like `lshift' but for arithmetic left shift. ! 865: ! 866: `(lshiftrt:M X C)' ! 867: `(ashiftrt:M X C)' ! 868: Like `lshift' and `ashift' but for right shift. ! 869: ! 870: `(rotate:M X C)' ! 871: `(rotatert:M X C)' ! 872: Similar but represent left and right rotate. ! 873: ! 874: `(abs:M X)' ! 875: Represents the absolute value of X, computed in mode M. X must be ! 876: valid for M. ! 877: ! 878: `(sqrt:M X)' ! 879: Represents the square root of X, computed in mode M. X must be valid ! 880: for M. Most often M will be a floating point mode. ! 881: ! 882: `(ffs:M X)' ! 883: Represents the one plus the index of the least significant 1-bit in X, ! 884: represented as an integer of mode M. (The value is zero if X is ! 885: zero.) The mode of X need not be M; depending on the target machine, ! 886: various mode combinations may be valid. ! 887: ! 888: ! 889: File: internals, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL ! 890: ! 891: Comparison Operations ! 892: ===================== ! 893: ! 894: Comparison operators test a relation on two operands and are considered to ! 895: represent the value 1 if the relation holds, or zero if it does not. The ! 896: mode of the comparison is determined by the operands; they must both be ! 897: valid for a common machine mode. A comparison with both operands constant ! 898: would be invalid as the machine mode could not be deduced from it, but such ! 899: a comparison should never exist in RTL due to constant folding. ! 900: ! 901: Inequality comparisons come in two flavors, signed and unsigned. Thus, ! 902: there are distinct expression codes `gt' and `gtu' for signed and unsigned ! 903: greater-than. These can produce different results for the same pair of ! 904: integer values: for example, 1 is signed greater-than -1 but not unsigned ! 905: greater-than, because -1 when regarded as unsigned is actually `0xffffffff' ! 906: which is greater than 1. ! 907: ! 908: The signed comparisons are also used for floating point values. Floating ! 909: point comparisons are distinguished by the machine modes of the operands. ! 910: ! 911: The comparison operators may be used to compare the condition codes `(cc0)' ! 912: against zero, as in `(eq (cc0) (const_int 0))'. Such a construct actually ! 913: refers to the result of the preceding instruction in which the condition ! 914: codes were set. The above example stands for 1 if the condition codes were ! 915: set to say ``zero'' or ``equal'', 0 otherwise. Although the same ! 916: comparison operators are used for this as may be used in other contexts on ! 917: actual data, no confusion can result since the machine description would ! 918: never allow both kinds of uses in the same context. ! 919: ! 920: `(eq X Y)' ! 921: 1 if the values represented by X and Y are equal, otherwise 0. ! 922: ! 923: `(ne X Y)' ! 924: 1 if the values represented by X and Y are not equal, otherwise 0. ! 925: ! 926: `(gt X Y)' ! 927: 1 if the X is greater than Y. If they are fixed-point, the comparison ! 928: is done in a signed sense. ! 929: ! 930: `(gtu X Y)' ! 931: Like `gt' but does unsigned comparison, on fixed-point numbers only. ! 932: ! 933: `(lt X Y)' ! 934: `(ltu X Y)' ! 935: Like `gt' and `gtu' but test for ``less than''. ! 936: ! 937: `(ge X Y)' ! 938: `(geu X Y)' ! 939: Like `gt' and `gtu' but test for ``greater than or equal''. ! 940: ! 941: `(le X Y)' ! 942: `(leu X Y)' ! 943: Like `gt' and `gtu' but test for ``less than or equal''. ! 944: ! 945: `(if_then_else COND THEN ELSE)' ! 946: This is not a comparison operation but is listed here because it is ! 947: always used in conjunction with a comparison operation. To be ! 948: precISE, COND is a comparison expression. This expression represents ! 949: a choice, according to COND, between the value represented by THEN and ! 950: the one represented by ELSE. ! 951: ! 952: On most machines, `if_then_else' expressions are valid only to express ! 953: conditional jumps. ! 954: ! 955: ! 956: File: internals, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL ! 957: ! 958: Bit-fields ! 959: ========== ! 960: ! 961: Special expression codes exist to represent bit-field instructions. These ! 962: types of expressions are lvalues in RTL; they may appear on the left side ! 963: of a assignment, indicating insertion of a value into the specified bit ! 964: field. ! 965: ! 966: `(sign_extract:SI LOC SIZE POS)' ! 967: This represents a reference to a sign-extended bit-field contained or ! 968: starting in LOC (a memory or register reference). The bit field is ! 969: SIZE bits wide and starts at bit POS. The compilation option ! 970: `BITS_BIG_ENDIAN' says which end of the memory unit POS counts from. ! 971: ! 972: Which machine modes are valid for LOC depends on the machine, but ! 973: typically LOC should be a single byte when in memory or a full word in ! 974: a register. ! 975: ! 976: `(zero_extract:SI LOC SIZE POS)' ! 977: Like `sign_extract' but refers to an unsigned or zero-extended bit ! 978: field. The same sequence of bits are extracted, but they are filled ! 979: to an entire word with zeros instead of by sign-extension. ! 980: ! 981: ! 982: File: internals, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL ! 983: ! 984: Conversions ! 985: =========== ! 986: ! 987: All conversions between machine modes must be represented by explicit ! 988: conversion operations. For example, an expression which is the sum of a ! 989: byte and a full word cannot be written as `(plus:SI (reg:QI 34) (reg:SI ! 990: 80))' because the `plus' operation requires two operands of the same ! 991: machine mode. Therefore, the byte-sized operand is enclosed in a ! 992: conversion operation, as in ! 993: ! 994: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) ! 995: ! 996: The conversion operation is not a mere placeholder, because there may be ! 997: more than one way of converting from a given starting mode to the desired ! 998: final mode. The conversion operation code says how to do it. ! 999: ! 1000: `(sign_extend:M X)' ! 1001: Represents the result of sign-extending the value X to machine mode M. ! 1002: M must be a fixed-point mode and X a fixed-point value of a mode ! 1003: narrower than M. ! 1004: ! 1005: `(zero_extend:M X)' ! 1006: Represents the result of zero-extending the value X to machine mode M. ! 1007: M must be a fixed-point mode and X a fixed-point value of a mode ! 1008: narrower than M. ! 1009: ! 1010: `(float_extend:M X)' ! 1011: Represents the result of extending the value X to machine mode M. M ! 1012: must be a floating point mode and X a floating point value of a mode ! 1013: narrower than M. ! 1014: ! 1015: `(truncate:M X)' ! 1016: Represents the result of truncating the value X to machine mode M. M ! 1017: must be a fixed-point mode and X a fixed-point value of a mode wider ! 1018: than M. ! 1019: ! 1020: `(float_truncate:M X)' ! 1021: Represents the result of truncating the value X to machine mode M. M ! 1022: must be a floating point mode and X a floating point value of a mode ! 1023: wider than M. ! 1024: ! 1025: `(float:M X)' ! 1026: Represents the result of converting fixed point value X, regarded as ! 1027: signed, to floating point mode M. ! 1028: ! 1029: `(unsigned_float:M X)' ! 1030: Represents the result of converting fixed point value X, regarded as ! 1031: unsigned, to floating point mode M. ! 1032: ! 1033: `(fix:M X)' ! 1034: When M is a fixed point mode, represents the result of converting ! 1035: floating point value X to mode M, regarded as signed. How rounding is ! 1036: done is not specified, so this operation may be used validly in ! 1037: compiling C code only for integer-valued operands. ! 1038: ! 1039: `(unsigned_fix:M X)' ! 1040: Represents the result of converting floating point value X to fixed ! 1041: point mode M, regarded as unsigned. How rounding is done is not ! 1042: specified. ! 1043: ! 1044: `(fix:M X)' ! 1045: When M is a floating point mode, represents the result of converting ! 1046: floating point value X (valid for mode M) to an integer, still ! 1047: represented in floating point mode M, by rounding towards zero. ! 1048: ! 1049: ! 1050: File: internals, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL ! 1051: ! 1052: Declarations ! 1053: ============ ! 1054: ! 1055: Declaration expression codes do not represent arithmetic operations but ! 1056: rather state assertions about their operands. ! 1057: ! 1058: `(strict_low_part (subreg:M (reg:N R) 0))' ! 1059: This expression code is used in only one context: operand 0 of a `set' ! 1060: expression. In addition, the operand of this expression must be a ! 1061: `subreg' expression. ! 1062: ! 1063: The presence of `strict_low_part' says that the part of the register ! 1064: which is meaningful in mode N, but is not part of mode M, is not to be ! 1065: altered. Normally, an assignment to such a subreg is allowed to have ! 1066: undefined effects on the rest of the register when M is less than a ! 1067: word. ! 1068: ! 1069:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.