![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-14 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-14 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.9 ! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.8 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330 7: Boston, MA 02111-1307 USA 1.1.1.5 root 8: 1.1.1.8 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software 10: Foundation, Inc. 1.1 root 11: 1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 1.1 root 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.7 root 18: that the sections entitled "GNU General Public License," "Funding for 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are 20: included exactly as in the original, and provided that the entire 21: resulting derived work is distributed under the terms of a permission 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public 1.1.1.7 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight 28: `Look And Feel'", and this permission notice, may be included in 29: translations approved by the Free Software Foundation instead of in the 30: original English. 1.1 root 31: 32: 1.1.1.8 root 33: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 1.1.1.3 root 34: 1.1.1.8 root 35: Machine Modes 36: ============= 1.1.1.2 root 37: 1.1.1.8 root 38: A machine mode describes a size of data object and the 39: representation used for it. In the C code, machine modes are 40: represented by an enumeration type, `enum machine_mode', defined in 41: `machmode.def'. Each RTL expression has room for a machine mode and so 42: do certain kinds of tree expressions (declarations and types, to be 43: precise). 44: 45: In debugging dumps and machine descriptions, the machine mode of an 46: RTL expression is written after the expression code with a colon to 47: separate them. The letters `mode' which appear at the end of each 48: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' 49: expression with machine mode `SImode'. If the mode is `VOIDmode', it 50: is not written at all. 51: 52: Here is a table of machine modes. The term "byte" below refers to an 53: object of `BITS_PER_UNIT' bits (*note Storage Layout::.). 54: 55: `QImode' 56: "Quarter-Integer" mode represents a single byte treated as an 57: integer. 58: 59: `HImode' 60: "Half-Integer" mode represents a two-byte integer. 61: 62: `PSImode' 63: "Partial Single Integer" mode represents an integer which occupies 64: four bytes but which doesn't really use all four. On some 65: machines, this is the right mode to use for pointers. 66: 67: `SImode' 68: "Single Integer" mode represents a four-byte integer. 69: 70: `PDImode' 71: "Partial Double Integer" mode represents an integer which occupies 72: eight bytes but which doesn't really use all eight. On some 73: machines, this is the right mode to use for certain pointers. 74: 75: `DImode' 76: "Double Integer" mode represents an eight-byte integer. 77: 78: `TImode' 79: "Tetra Integer" (?) mode represents a sixteen-byte integer. 80: 81: `SFmode' 82: "Single Floating" mode represents a single-precision (four byte) 83: floating point number. 84: 85: `DFmode' 86: "Double Floating" mode represents a double-precision (eight byte) 87: floating point number. 88: 89: `XFmode' 90: "Extended Floating" mode represents a triple-precision (twelve 91: byte) floating point number. This mode is used for IEEE extended 92: floating point. On some systems not all bits within these bytes 93: will actually be used. 94: 95: `TFmode' 96: "Tetra Floating" mode represents a quadruple-precision (sixteen 97: byte) floating point number. 98: 99: `CCmode' 100: "Condition Code" mode represents the value of a condition code, 101: which is a machine-specific set of bits used to represent the 102: result of a comparison operation. Other machine-specific modes 103: may also be used for the condition code. These modes are not used 104: on machines that use `cc0' (see *note Condition Code::.). 105: 106: `BLKmode' 107: "Block" mode represents values that are aggregates to which none of 108: the other modes apply. In RTL, only memory references can have 109: this mode, and only if they appear in string-move or vector 110: instructions. On machines which have no such instructions, 111: `BLKmode' will not appear in RTL. 112: 113: `VOIDmode' 114: Void mode means the absence of a mode or an unspecified mode. For 115: example, RTL expressions of code `const_int' have mode `VOIDmode' 116: because they can be taken to have whatever mode the context 117: requires. In debugging dumps of RTL, `VOIDmode' is expressed by 118: the absence of any mode. 119: 120: `SCmode, DCmode, XCmode, TCmode' 121: These modes stand for a complex number represented as a pair of 122: floating point values. The floating point values are in `SFmode', 123: `DFmode', `XFmode', and `TFmode', respectively. 124: 125: `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 126: These modes stand for a complex number represented as a pair of 127: integer values. The integer values are in `QImode', `HImode', 128: `SImode', `DImode', `TImode', and `OImode', respectively. 129: 130: The machine description defines `Pmode' as a C macro which expands 131: into the machine mode used for addresses. Normally this is the mode 132: whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 133: 134: The only modes which a machine description must support are 135: `QImode', and the modes corresponding to `BITS_PER_WORD', 136: `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to 137: use `DImode' for 8-byte structures and unions, but this can be 138: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. 139: Alternatively, you can have the compiler use `TImode' for 16-byte 140: structures and unions. Likewise, you can arrange for the C type `short 141: int' to avoid using `HImode'. 142: 143: Very few explicit references to machine modes remain in the compiler 144: and these few references will soon be removed. Instead, the machine 145: modes are divided into mode classes. These are represented by the 146: enumeration type `enum mode_class' defined in `machmode.h'. The 147: possible mode classes are: 148: 149: `MODE_INT' 150: Integer modes. By default these are `QImode', `HImode', `SImode', 151: `DImode', and `TImode'. 152: 153: `MODE_PARTIAL_INT' 154: The "partial integer" modes, `PSImode' and `PDImode'. 155: 156: `MODE_FLOAT' 157: floating point modes. By default these are `SFmode', `DFmode', 158: `XFmode' and `TFmode'. 159: 160: `MODE_COMPLEX_INT' 161: Complex integer modes. (These are not currently implemented). 162: 163: `MODE_COMPLEX_FLOAT' 164: Complex floating point modes. By default these are `SCmode', 165: `DCmode', `XCmode', and `TCmode'. 166: 167: `MODE_FUNCTION' 168: Algol or Pascal function variables including a static chain. 169: (These are not currently implemented). 170: 171: `MODE_CC' 172: Modes representing condition code values. These are `CCmode' plus 173: any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump 174: Patterns::, also see *Note Condition Code::. 175: 176: `MODE_RANDOM' 177: This is a catchall mode class for modes which don't fit into the 178: above classes. Currently `VOIDmode' and `BLKmode' are in 179: `MODE_RANDOM'. 180: 181: Here are some C macros that relate to machine modes: 182: 183: `GET_MODE (X)' 184: Returns the machine mode of the RTX X. 185: 186: `PUT_MODE (X, NEWMODE)' 187: Alters the machine mode of the RTX X to be NEWMODE. 188: 189: `NUM_MACHINE_MODES' 190: Stands for the number of machine modes available on the target 191: machine. This is one greater than the largest numeric value of any 192: machine mode. 193: 194: `GET_MODE_NAME (M)' 195: Returns the name of mode M as a string. 196: 197: `GET_MODE_CLASS (M)' 198: Returns the mode class of mode M. 199: 200: `GET_MODE_WIDER_MODE (M)' 201: Returns the next wider natural mode. For example, the expression 202: `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 203: 204: `GET_MODE_SIZE (M)' 205: Returns the size in bytes of a datum of mode M. 206: 207: `GET_MODE_BITSIZE (M)' 208: Returns the size in bits of a datum of mode M. 209: 210: `GET_MODE_MASK (M)' 211: Returns a bitmask containing 1 for all bits in a word that fit 212: within mode M. This macro can only be used for modes whose 213: bitsize is less than or equal to `HOST_BITS_PER_INT'. 214: 215: `GET_MODE_ALIGNMENT (M))' 216: Return the required alignment, in bits, for an object of mode M. 217: 218: `GET_MODE_UNIT_SIZE (M)' 219: Returns the size in bytes of the subunits of a datum of mode M. 220: This is the same as `GET_MODE_SIZE' except in the case of complex 221: modes. For them, the unit size is the size of the real or 222: imaginary part. 223: 224: `GET_MODE_NUNITS (M)' 225: Returns the number of units contained in a mode, i.e., 226: `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 227: 228: `GET_CLASS_NARROWEST_MODE (C)' 229: Returns the narrowest mode in mode class C. 230: 231: The global variables `byte_mode' and `word_mode' contain modes whose 232: classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 233: `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 234: and `SImode', respectively. 1.1.1.2 root 235: 1.1.1.3 root 236: 1.1.1.8 root 237: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 1.1.1.3 root 238: 1.1.1.8 root 239: Constant Expression Types 240: ========================= 1.1.1.2 root 241: 1.1.1.8 root 242: The simplest RTL expressions are those that represent constant 243: values. 1.1.1.3 root 244: 1.1.1.8 root 245: `(const_int I)' 246: This type of expression represents the integer value I. I is 247: customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 248: which is equivalent to `XWINT (EXP, 0)'. 249: 250: There is only one expression object for the integer value zero; it 251: is the value of the variable `const0_rtx'. Likewise, the only 252: expression for integer value one is found in `const1_rtx', the only 253: expression for integer value two is found in `const2_rtx', and the 254: only expression for integer value negative one is found in 255: `constm1_rtx'. Any attempt to create an expression of code 256: `const_int' and value zero, one, two or negative one will return 257: `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 258: appropriate. 259: 260: Similarly, there is only one object for the integer whose value is 261: `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 262: `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 263: point to the same object. If `STORE_FLAG_VALUE' is -1, 264: `const_true_rtx' and `constm1_rtx' will point to the same object. 265: 266: `(const_double:M ADDR I0 I1 ...)' 267: Represents either a floating-point constant of mode M or an 268: integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 269: bits but small enough to fit within twice that number of bits (GNU 270: CC does not provide a mechanism to represent even larger 271: constants). In the latter case, M will be `VOIDmode'. 272: 273: ADDR is used to contain the `mem' expression that corresponds to 274: the location in memory that at which the constant can be found. If 275: it has not been allocated a memory location, but is on the chain 276: of all `const_double' expressions in this compilation (maintained 277: using an undisplayed field), ADDR contains `const0_rtx'. If it is 278: not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily 279: accessed with the macro `CONST_DOUBLE_MEM' and the chain field via 280: `CONST_DOUBLE_CHAIN'. 281: 282: If M is `VOIDmode', the bits of the value are stored in I0 and I1. 283: I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 284: I1 with `CONST_DOUBLE_HIGH'. 285: 286: If the constant is floating point (regardless of its precision), 287: then the number of integers used to store the value depends on the 288: size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The 289: integers represent a floating point number, but not precisely in 290: the target machine's or host machine's floating point format. To 291: convert them to the precise bit pattern used by the target 292: machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends 293: (*note Data Output::.). 294: 295: The macro `CONST0_RTX (MODE)' refers to an expression with value 0 296: in mode MODE. If mode MODE is of mode class `MODE_INT', it 297: returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' 298: expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)' 299: refers to an expression with value 1 in mode MODE and similarly 300: for `CONST2_RTX'. 301: 302: `(const_string STR)' 303: Represents a constant string with value STR. Currently this is 304: used only for insn attributes (*note Insn Attributes::.) since 305: constant strings in C are placed in memory. 306: 307: `(symbol_ref:MODE SYMBOL)' 308: Represents the value of an assembler label for data. SYMBOL is a 309: string that describes the name of the assembler label. If it 310: starts with a `*', the label is the rest of SYMBOL not including 311: the `*'. Otherwise, the label is SYMBOL, usually prefixed with 312: `_'. 313: 314: The `symbol_ref' contains a mode, which is usually `Pmode'. 315: Usually that is the only mode for which a symbol is directly valid. 316: 317: `(label_ref LABEL)' 318: Represents the value of an assembler label for code. It contains 319: one operand, an expression, which must be a `code_label' that 320: appears in the instruction sequence to identify the place where 321: the label should go. 322: 323: The reason for using a distinct expression type for code label 324: references is so that jump optimization can distinguish them. 325: 326: `(const:M EXP)' 327: Represents a constant that is the result of an assembly-time 328: arithmetic computation. The operand, EXP, is an expression that 329: contains only constants (`const_int', `symbol_ref' and `label_ref' 330: expressions) combined with `plus' and `minus'. However, not all 331: combinations are valid, since the assembler cannot do arbitrary 332: arithmetic on relocatable symbols. 333: 334: M should be `Pmode'. 335: 336: `(high:M EXP)' 337: Represents the high-order bits of EXP, usually a `symbol_ref'. 338: The number of bits is machine-dependent and is normally the number 339: of bits specified in an instruction that initializes the high 340: order bits of a register. It is used with `lo_sum' to represent 341: the typical two-instruction sequence used in RISC machines to 342: reference a global memory location. 1.1.1.6 root 343: 1.1.1.8 root 344: M should be `Pmode'. 1.1.1.2 root 345: 346: 1.1.1.8 root 347: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 1.1.1.6 root 348: 1.1.1.8 root 349: Registers and Memory 350: ==================== 1.1.1.6 root 351: 1.1.1.8 root 352: Here are the RTL expression types for describing access to machine 353: registers and to main memory. 1.1.1.6 root 354: 1.1.1.8 root 355: `(reg:M N)' 356: For small values of the integer N (those that are less than 357: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 358: register number N: a "hard register". For larger values of N, it 359: stands for a temporary value or "pseudo register". The compiler's 360: strategy is to generate code assuming an unlimited number of such 361: pseudo registers, and later convert them into hard registers or 362: into memory references. 363: 364: M is the machine mode of the reference. It is necessary because 365: machines can generally refer to each register in more than one 366: mode. For example, a register may contain a full word but there 367: may be instructions to refer to it as a half word or as a single 368: byte, as well as instructions to refer to it as a floating point 369: number of various precisions. 370: 371: Even for a register that the machine can access in only one mode, 372: the mode must always be specified. 373: 374: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 375: description, since the number of hard registers on the machine is 376: an invariant characteristic of the machine. Note, however, that 377: not all of the machine registers must be general registers. All 378: the machine registers that can be used for storage of data are 379: given hard register numbers, even those that can be used only in 380: certain instructions or can hold only certain types of data. 381: 382: A hard register may be accessed in various modes throughout one 383: function, but each pseudo register is given a natural mode and is 384: accessed only in that mode. When it is necessary to describe an 385: access to a pseudo register using a nonnatural mode, a `subreg' 386: expression is used. 387: 388: A `reg' expression with a machine mode that specifies more than 389: one word of data may actually stand for several consecutive 390: registers. If in addition the register number specifies a 391: hardware register, then it actually represents several consecutive 392: hardware registers starting with the specified one. 393: 394: Each pseudo register number used in a function's RTL code is 395: represented by a unique `reg' expression. 396: 397: Some pseudo register numbers, those within the range of 398: `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 399: during the RTL generation phase and are eliminated before the 400: optimization phases. These represent locations in the stack frame 401: that cannot be determined until RTL generation for the function 402: has been completed. The following virtual register numbers are 403: defined: 404: 405: `VIRTUAL_INCOMING_ARGS_REGNUM' 406: This points to the first word of the incoming arguments 407: passed on the stack. Normally these arguments are placed 408: there by the caller, but the callee may have pushed some 409: arguments that were previously passed in registers. 410: 411: When RTL generation is complete, this virtual register is 412: replaced by the sum of the register given by 413: `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 414: 415: `VIRTUAL_STACK_VARS_REGNUM' 416: If `FRAME_GROWS_DOWNWARD' is defined, this points to 417: immediately above the first variable on the stack. 418: Otherwise, it points to the first variable on the stack. 419: 420: `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 421: register given by `FRAME_POINTER_REGNUM' and the value 422: `STARTING_FRAME_OFFSET'. 423: 424: `VIRTUAL_STACK_DYNAMIC_REGNUM' 425: This points to the location of dynamically allocated memory 426: on the stack immediately after the stack pointer has been 427: adjusted by the amount of memory desired. 428: 429: This virtual register is replaced by the sum of the register 430: given by `STACK_POINTER_REGNUM' and the value 431: `STACK_DYNAMIC_OFFSET'. 432: 433: `VIRTUAL_OUTGOING_ARGS_REGNUM' 434: This points to the location in the stack at which outgoing 435: arguments should be written when the stack is pre-pushed 436: (arguments pushed using push insns should always use 437: `STACK_POINTER_REGNUM'). 438: 439: This virtual register is replaced by the sum of the register 440: given by `STACK_POINTER_REGNUM' and the value 441: `STACK_POINTER_OFFSET'. 442: 443: `(subreg:M REG WORDNUM)' 444: `subreg' expressions are used to refer to a register in a machine 445: mode other than its natural one, or to refer to one register of a 446: multi-word `reg' that actually refers to several registers. 447: 448: Each pseudo-register has a natural mode. If it is necessary to 449: operate on it in a different mode--for example, to perform a 450: fullword move instruction on a pseudo-register that contains a 451: single byte--the pseudo-register must be enclosed in a `subreg'. 452: In such a case, WORDNUM is zero. 453: 454: Usually M is at least as narrow as the mode of REG, in which case 455: it is restricting consideration to only the bits of REG that are 456: in M. 457: 458: Sometimes M is wider than the mode of REG. These `subreg' 459: expressions are often called "paradoxical". They are used in 460: cases where we want to refer to an object in a wider mode but do 461: not care what value the additional bits have. The reload pass 462: ensures that paradoxical references are only made to hard 463: registers. 464: 465: The other use of `subreg' is to extract the individual registers of 466: a multi-register value. Machine modes such as `DImode' and 467: `TImode' can indicate values longer than a word, values which 468: usually require two or more consecutive registers. To access one 469: of the registers, use a `subreg' with mode `SImode' and a WORDNUM 470: that says which register. 471: 472: Storing in a non-paradoxical `subreg' has undefined results for 473: bits belonging to the same word as the `subreg'. This laxity makes 474: it easier to generate efficient code for such instructions. To 475: represent an instruction that preserves all the bits outside of 476: those in the `subreg', use `strict_low_part' around the `subreg'. 477: 478: The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says 479: that word number zero is the most significant part; otherwise, it 480: is the least significant part. 481: 482: Between the combiner pass and the reload pass, it is possible to 483: have a paradoxical `subreg' which contains a `mem' instead of a 484: `reg' as its first operand. After the reload pass, it is also 485: possible to have a non-paradoxical `subreg' which contains a 486: `mem'; this usually occurs when the `mem' is a stack slot which 487: replaced a pseudo register. 488: 489: Note that it is not valid to access a `DFmode' value in `SFmode' 490: using a `subreg'. On some machines the most significant part of a 491: `DFmode' value does not have the same format as a single-precision 492: floating value. 493: 494: It is also not valid to access a single word of a multi-word value 495: in a hard register when less registers can hold the value than 496: would be expected from its size. For example, some 32-bit 497: machines have floating-point registers that can hold an entire 498: `DFmode' value. If register 10 were such a register `(subreg:SI 499: (reg:DF 10) 1)' would be invalid because there is no way to 500: convert that reference to a single machine register. The reload 501: pass prevents `subreg' expressions such as these from being formed. 502: 503: The first operand of a `subreg' expression is customarily accessed 504: with the `SUBREG_REG' macro and the second operand is customarily 505: accessed with the `SUBREG_WORD' macro. 506: 507: `(scratch:M)' 508: This represents a scratch register that will be required for the 509: execution of a single instruction and not used subsequently. It is 510: converted into a `reg' by either the local register allocator or 511: the reload pass. 512: 513: `scratch' is usually present inside a `clobber' operation (*note 514: Side Effects::.). 515: 516: `(cc0)' 517: This refers to the machine's condition code register. It has no 518: operands and may not have a machine mode. There are two ways to 519: use it: 520: 521: * To stand for a complete set of condition code flags. This is 522: best on most machines, where each comparison sets the entire 523: series of flags. 524: 525: With this technique, `(cc0)' may be validly used in only two 526: contexts: as the destination of an assignment (in test and 527: compare instructions) and in comparison operators comparing 528: against zero (`const_int' with value zero; that is to say, 529: `const0_rtx'). 530: 531: * To stand for a single flag that is the result of a single 532: condition. This is useful on machines that have only a 533: single flag bit, and in which comparison instructions must 534: specify the condition to test. 535: 536: With this technique, `(cc0)' may be validly used in only two 537: contexts: as the destination of an assignment (in test and 538: compare instructions) where the source is a comparison 539: operator, and as the first operand of `if_then_else' (in a 540: conditional branch). 541: 542: There is only one expression object of code `cc0'; it is the value 543: of the variable `cc0_rtx'. Any attempt to create an expression of 544: code `cc0' will return `cc0_rtx'. 545: 546: Instructions can set the condition code implicitly. On many 547: machines, nearly all instructions set the condition code based on 548: the value that they compute or store. It is not necessary to 549: record these actions explicitly in the RTL because the machine 550: description includes a prescription for recognizing the 551: instructions that do so (by means of the macro 552: `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 553: whose sole purpose is to set the condition code, and instructions 554: that use the condition code, need mention `(cc0)'. 555: 556: On some machines, the condition code register is given a register 557: number and a `reg' is used instead of `(cc0)'. This is usually the 558: preferable approach if only a small subset of instructions modify 559: the condition code. Other machines store condition codes in 560: general registers; in such cases a pseudo register should be used. 561: 562: Some machines, such as the Sparc and RS/6000, have two sets of 563: arithmetic instructions, one that sets and one that does not set 564: the condition code. This is best handled by normally generating 565: the instruction that does not set the condition code, and making a 566: pattern that both performs the arithmetic and sets the condition 567: code register (which would not be `(cc0)' in this case). For 568: examples, search for `addcc' and `andcc' in `sparc.md'. 569: 570: `(pc)' 571: This represents the machine's program counter. It has no operands 572: and may not have a machine mode. `(pc)' may be validly used only 573: in certain specific contexts in jump instructions. 574: 575: There is only one expression object of code `pc'; it is the value 576: of the variable `pc_rtx'. Any attempt to create an expression of 577: code `pc' will return `pc_rtx'. 578: 579: All instructions that do not jump alter the program counter 580: implicitly by incrementing it, but there is no need to mention 581: this in the RTL. 582: 583: `(mem:M ADDR)' 584: This RTX represents a reference to main memory at an address 585: represented by the expression ADDR. M specifies how large a unit 586: of memory is accessed. 1.1.1.6 root 587: 1.1.1.7 root 588: 1.1.1.8 root 589: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 1.1.1.6 root 590: 1.1.1.8 root 591: RTL Expressions for Arithmetic 592: ============================== 1.1.1.6 root 593: 1.1.1.8 root 594: Unless otherwise specified, all the operands of arithmetic 595: expressions must be valid for mode M. An operand is valid for mode M 596: if it has mode M, or if it is a `const_int' or `const_double' and M is 597: a mode of class `MODE_INT'. 598: 599: For commutative binary operations, constants should be placed in the 600: second operand. 601: 602: `(plus:M X Y)' 603: Represents the sum of the values represented by X and Y carried 604: out in machine mode M. 605: 606: `(lo_sum:M X Y)' 607: Like `plus', except that it represents that sum of X and the 608: low-order bits of Y. The number of low order bits is 609: machine-dependent but is normally the number of bits in a `Pmode' 610: item minus the number of bits set by the `high' code (*note 611: Constants::.). 612: 613: M should be `Pmode'. 614: 615: `(minus:M X Y)' 616: Like `plus' but represents subtraction. 617: 618: `(compare:M X Y)' 619: Represents the result of subtracting Y from X for purposes of 620: comparison. The result is computed without overflow, as if with 621: infinite precision. 622: 623: Of course, machines can't really subtract with infinite precision. 624: However, they can pretend to do so when only the sign of the 625: result will be used, which is the case when the result is stored 626: in the condition code. And that is the only way this kind of 627: expression may validly be used: as a value to be stored in the 628: condition codes. 629: 630: The mode M is not related to the modes of X and Y, but instead is 631: the mode of the condition code value. If `(cc0)' is used, it is 632: `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 633: `CCmode'. *Note Condition Code::. 634: 635: Normally, X and Y must have the same mode. Otherwise, `compare' 636: is valid only if the mode of X is in class `MODE_INT' and Y is a 637: `const_int' or `const_double' with mode `VOIDmode'. The mode of X 638: determines what mode the comparison is to be done in; thus it must 639: not be `VOIDmode'. 640: 641: If one of the operands is a constant, it should be placed in the 642: second operand and the comparison code adjusted as appropriate. 643: 644: A `compare' specifying two `VOIDmode' constants is not valid since 645: there is no way to know in what mode the comparison is to be 646: performed; the comparison must either be folded during the 647: compilation or the first operand must be loaded into a register 648: while its mode is still known. 649: 650: `(neg:M X)' 651: Represents the negation (subtraction from zero) of the value 652: represented by X, carried out in mode M. 653: 654: `(mult:M X Y)' 655: Represents the signed product of the values represented by X and Y 656: carried out in machine mode M. 657: 658: Some machines support a multiplication that generates a product 659: wider than the operands. Write the pattern for this as 660: 661: (mult:M (sign_extend:M X) (sign_extend:M Y)) 662: 663: where M is wider than the modes of X and Y, which need not be the 664: same. 665: 666: Write patterns for unsigned widening multiplication similarly using 667: `zero_extend'. 668: 669: `(div:M X Y)' 670: Represents the quotient in signed division of X by Y, carried out 671: in machine mode M. If M is a floating point mode, it represents 672: the exact quotient; otherwise, the integerized quotient. 673: 674: Some machines have division instructions in which the operands and 675: quotient widths are not all the same; you should represent such 676: instructions using `truncate' and `sign_extend' as in, 677: 678: (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 679: 680: `(udiv:M X Y)' 681: Like `div' but represents unsigned division. 682: 683: `(mod:M X Y)' 684: `(umod:M X Y)' 685: Like `div' and `udiv' but represent the remainder instead of the 686: quotient. 687: 688: `(smin:M X Y)' 689: `(smax:M X Y)' 690: Represents the smaller (for `smin') or larger (for `smax') of X 691: and Y, interpreted as signed integers in mode M. 692: 693: `(umin:M X Y)' 694: `(umax:M X Y)' 695: Like `smin' and `smax', but the values are interpreted as unsigned 696: integers. 697: 698: `(not:M X)' 699: Represents the bitwise complement of the value represented by X, 700: carried out in mode M, which must be a fixed-point machine mode. 701: 702: `(and:M X Y)' 703: Represents the bitwise logical-and of the values represented by X 704: and Y, carried out in machine mode M, which must be a fixed-point 705: machine mode. 706: 707: `(ior:M X Y)' 708: Represents the bitwise inclusive-or of the values represented by X 709: and Y, carried out in machine mode M, which must be a fixed-point 710: mode. 711: 712: `(xor:M X Y)' 713: Represents the bitwise exclusive-or of the values represented by X 714: and Y, carried out in machine mode M, which must be a fixed-point 715: mode. 716: 717: `(ashift:M X C)' 718: Represents the result of arithmetically shifting X left by C 719: places. X have mode M, a fixed-point machine mode. C be a 720: fixed-point mode or be a constant with mode `VOIDmode'; which mode 721: is determined by the mode called for in the machine description 722: entry for the left-shift instruction. For example, on the Vax, 723: the mode of C is `QImode' regardless of M. 724: 725: `(lshiftrt:M X C)' 726: `(ashiftrt:M X C)' 727: Like `ashift' but for right shift. Unlike the case for left shift, 728: these two operations are distinct. 729: 730: `(rotate:M X C)' 731: `(rotatert:M X C)' 732: Similar but represent left and right rotate. If C is a constant, 733: use `rotate'. 734: 735: `(abs:M X)' 736: Represents the absolute value of X, computed in mode M. 737: 738: `(sqrt:M X)' 739: Represents the square root of X, computed in mode M. Most often M 740: will be a floating point mode. 741: 742: `(ffs:M X)' 743: Represents one plus the index of the least significant 1-bit in X, 744: represented as an integer of mode M. (The value is zero if X is 745: zero.) The mode of X need not be M; depending on the target 746: machine, various mode combinations may be valid. 1.1.1.6 root 747: 1.1.1.7 root 748: 1.1.1.8 root 749: File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL 1.1.1.6 root 750: 1.1.1.8 root 751: Comparison Operations 752: ===================== 1.1.1.6 root 753: 1.1.1.8 root 754: Comparison operators test a relation on two operands and are 755: considered to represent a machine-dependent nonzero value described by, 756: but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.) if the 757: relation holds, or zero if it does not. The mode of the comparison 758: operation is independent of the mode of the data being compared. If 759: the comparison operation is being tested (e.g., the first operand of an 760: `if_then_else'), the mode must be `VOIDmode'. If the comparison 761: operation is producing data to be stored in some variable, the mode 762: must be in class `MODE_INT'. All comparison operations producing data 763: must use the same mode, which is machine-specific. 764: 765: There are two ways that comparison operations may be used. The 766: comparison operators may be used to compare the condition codes `(cc0)' 767: against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 768: actually refers to the result of the preceding instruction in which the 769: condition codes were set. The instructing setting the condition code 770: must be adjacent to the instruction using the condition code; only 771: `note' insns may separate them. 772: 773: Alternatively, a comparison operation may directly compare two data 774: objects. The mode of the comparison is determined by the operands; they 775: must both be valid for a common machine mode. A comparison with both 776: operands constant would be invalid as the machine mode could not be 777: deduced from it, but such a comparison should never exist in RTL due to 778: constant folding. 779: 780: In the example above, if `(cc0)' were last set to `(compare X Y)', 781: the comparison operation is identical to `(eq X Y)'. Usually only one 782: style of comparisons is supported on a particular machine, but the 783: combine pass will try to merge the operations to produce the `eq' shown 784: in case it exists in the context of the particular insn involved. 785: 786: Inequality comparisons come in two flavors, signed and unsigned. 787: Thus, there are distinct expression codes `gt' and `gtu' for signed and 788: unsigned greater-than. These can produce different results for the same 789: pair of integer values: for example, 1 is signed greater-than -1 but not 790: unsigned greater-than, because -1 when regarded as unsigned is actually 791: `0xffffffff' which is greater than 1. 792: 793: The signed comparisons are also used for floating point values. 794: Floating point comparisons are distinguished by the machine modes of 795: the operands. 796: 797: `(eq:M X Y)' 798: 1 if the values represented by X and Y are equal, otherwise 0. 799: 800: `(ne:M X Y)' 801: 1 if the values represented by X and Y are not equal, otherwise 0. 802: 803: `(gt:M X Y)' 804: 1 if the X is greater than Y. If they are fixed-point, the 805: comparison is done in a signed sense. 806: 807: `(gtu:M X Y)' 808: Like `gt' but does unsigned comparison, on fixed-point numbers 809: only. 810: 811: `(lt:M X Y)' 812: `(ltu:M X Y)' 813: Like `gt' and `gtu' but test for "less than". 814: 815: `(ge:M X Y)' 816: `(geu:M X Y)' 817: Like `gt' and `gtu' but test for "greater than or equal". 818: 819: `(le:M X Y)' 820: `(leu:M X Y)' 821: Like `gt' and `gtu' but test for "less than or equal". 822: 823: `(if_then_else COND THEN ELSE)' 824: This is not a comparison operation but is listed here because it is 825: always used in conjunction with a comparison operation. To be 826: precise, COND is a comparison expression. This expression 827: represents a choice, according to COND, between the value 828: represented by THEN and the one represented by ELSE. 829: 830: On most machines, `if_then_else' expressions are valid only to 831: express conditional jumps. 832: 833: `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 834: Similar to `if_then_else', but more general. Each of TEST1, 835: TEST2, ... is performed in turn. The result of this expression is 836: the VALUE corresponding to the first non-zero test, or DEFAULT if 837: none of the tests are non-zero expressions. 1.1.1.6 root 838: 1.1.1.8 root 839: This is currently not valid for instruction patterns and is 840: supported only for insn attributes. *Note Insn Attributes::. 1.1.1.6 root 841: 1.1.1.7 root 842: 1.1.1.8 root 843: File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL 844: 845: Bit Fields 846: ========== 1.1.1.6 root 847: 1.1.1.8 root 848: Special expression codes exist to represent bitfield instructions. 849: These types of expressions are lvalues in RTL; they may appear on the 850: left side of an assignment, indicating insertion of a value into the 851: specified bit field. 852: 853: `(sign_extract:M LOC SIZE POS)' 854: This represents a reference to a sign-extended bit field contained 855: or starting in LOC (a memory or register reference). The bit field 856: is SIZE bits wide and starts at bit POS. The compilation option 857: `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 858: from. 859: 860: If LOC is in memory, its mode must be a single-byte integer mode. 861: If LOC is in a register, the mode to use is specified by the 862: operand of the `insv' or `extv' pattern (*note Standard Names::.) 863: and is usually a full-word integer mode. 864: 865: The mode of POS is machine-specific and is also specified in the 866: `insv' or `extv' pattern. 867: 868: The mode M is the same as the mode that would be used for LOC if 869: it were a register. 870: 871: `(zero_extract:M LOC SIZE POS)' 872: Like `sign_extract' but refers to an unsigned or zero-extended bit 873: field. The same sequence of bits are extracted, but they are 874: filled to an entire word with zeros instead of by sign-extension. 1.1.1.6 root 875: 1.1.1.8 root 876: 877: File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL 1.1.1.6 root 878: 1.1.1.8 root 879: Conversions 880: =========== 1.1.1.6 root 881: 1.1.1.8 root 882: All conversions between machine modes must be represented by 883: explicit conversion operations. For example, an expression which is 884: the sum of a byte and a full word cannot be written as `(plus:SI 885: (reg:QI 34) (reg:SI 80))' because the `plus' operation requires two 886: operands of the same machine mode. Therefore, the byte-sized operand 887: is enclosed in a conversion operation, as in 888: 889: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 890: 891: The conversion operation is not a mere placeholder, because there 892: may be more than one way of converting from a given starting mode to 893: the desired final mode. The conversion operation code says how to do 894: it. 895: 896: For all conversion operations, X must not be `VOIDmode' because the 897: mode in which to do the conversion would not be known. The conversion 898: must either be done at compile-time or X must be placed into a register. 899: 900: `(sign_extend:M X)' 901: Represents the result of sign-extending the value X to machine 902: mode M. M must be a fixed-point mode and X a fixed-point value of 903: a mode narrower than M. 904: 905: `(zero_extend:M X)' 906: Represents the result of zero-extending the value X to machine 907: mode M. M must be a fixed-point mode and X a fixed-point value of 908: a mode narrower than M. 909: 910: `(float_extend:M X)' 911: Represents the result of extending the value X to machine mode M. 1.1.1.9 ! root 912: M must be a floating point mode and X a floating point value of a 1.1.1.8 root 913: mode narrower than M. 914: 915: `(truncate:M X)' 916: Represents the result of truncating the value X to machine mode M. 917: M must be a fixed-point mode and X a fixed-point value of a mode 918: wider than M. 919: 920: `(float_truncate:M X)' 921: Represents the result of truncating the value X to machine mode M. 922: M must be a floating point mode and X a floating point value of a 923: mode wider than M. 924: 925: `(float:M X)' 926: Represents the result of converting fixed point value X, regarded 927: as signed, to floating point mode M. 928: 929: `(unsigned_float:M X)' 930: Represents the result of converting fixed point value X, regarded 931: as unsigned, to floating point mode M. 932: 933: `(fix:M X)' 934: When M is a fixed point mode, represents the result of converting 935: floating point value X to mode M, regarded as signed. How 936: rounding is done is not specified, so this operation may be used 937: validly in compiling C code only for integer-valued operands. 938: 939: `(unsigned_fix:M X)' 940: Represents the result of converting floating point value X to 941: fixed point mode M, regarded as unsigned. How rounding is done is 942: not specified. 943: 944: `(fix:M X)' 945: When M is a floating point mode, represents the result of 946: converting floating point value X (valid for mode M) to an 947: integer, still represented in floating point mode M, by rounding 948: towards zero. 1.1.1.6 root 949: 1.1.1.7 root 950: 1.1.1.8 root 951: File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 1.1.1.6 root 952: 1.1.1.8 root 953: Declarations 1.1.1.7 root 954: ============ 1.1.1.6 root 955: 1.1.1.8 root 956: Declaration expression codes do not represent arithmetic operations 957: but rather state assertions about their operands. 1.1.1.7 root 958: 1.1.1.8 root 959: `(strict_low_part (subreg:M (reg:N R) 0))' 960: This expression code is used in only one context: as the 961: destination operand of a `set' expression. In addition, the 962: operand of this expression must be a non-paradoxical `subreg' 1.1.1.7 root 963: expression. 1.1.1.6 root 964: 1.1.1.8 root 965: The presence of `strict_low_part' says that the part of the 966: register which is meaningful in mode N, but is not part of mode M, 967: is not to be altered. Normally, an assignment to such a subreg is 968: allowed to have undefined effects on the rest of the register when 969: M is less than a word. 1.1 root 970:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.