![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-13 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-13 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue 7: Cambridge, MA 02139 USA 8: 1.1.1.7 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, ! 10: 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.1.4 root 31: 32: 1.1.1.7 ! root 33: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 1.1.1.6 root 34: 1.1.1.7 ! root 35: Registers and Memory ! 36: ==================== 1.1.1.6 root 37: 1.1.1.7 ! root 38: Here are the RTL expression types for describing access to machine ! 39: registers and to main memory. ! 40: ! 41: `(reg:M N)' ! 42: For small values of the integer N (those that are less than ! 43: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine ! 44: register number N: a "hard register". For larger values of N, it ! 45: stands for a temporary value or "pseudo register". The compiler's ! 46: strategy is to generate code assuming an unlimited number of such ! 47: pseudo registers, and later convert them into hard registers or ! 48: into memory references. ! 49: ! 50: M is the machine mode of the reference. It is necessary because ! 51: machines can generally refer to each register in more than one ! 52: mode. For example, a register may contain a full word but there ! 53: may be instructions to refer to it as a half word or as a single ! 54: byte, as well as instructions to refer to it as a floating point ! 55: number of various precisions. ! 56: ! 57: Even for a register that the machine can access in only one mode, ! 58: the mode must always be specified. ! 59: ! 60: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine ! 61: description, since the number of hard registers on the machine is ! 62: an invariant characteristic of the machine. Note, however, that ! 63: not all of the machine registers must be general registers. All ! 64: the machine registers that can be used for storage of data are ! 65: given hard register numbers, even those that can be used only in ! 66: certain instructions or can hold only certain types of data. ! 67: ! 68: A hard register may be accessed in various modes throughout one ! 69: function, but each pseudo register is given a natural mode and is ! 70: accessed only in that mode. When it is necessary to describe an ! 71: access to a pseudo register using a nonnatural mode, a `subreg' ! 72: expression is used. ! 73: ! 74: A `reg' expression with a machine mode that specifies more than ! 75: one word of data may actually stand for several consecutive ! 76: registers. If in addition the register number specifies a ! 77: hardware register, then it actually represents several consecutive ! 78: hardware registers starting with the specified one. ! 79: ! 80: Each pseudo register number used in a function's RTL code is ! 81: represented by a unique `reg' expression. ! 82: ! 83: Some pseudo register numbers, those within the range of ! 84: `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear ! 85: during the RTL generation phase and are eliminated before the ! 86: optimization phases. These represent locations in the stack frame ! 87: that cannot be determined until RTL generation for the function ! 88: has been completed. The following virtual register numbers are ! 89: defined: ! 90: ! 91: `VIRTUAL_INCOMING_ARGS_REGNUM' ! 92: This points to the first word of the incoming arguments ! 93: passed on the stack. Normally these arguments are placed ! 94: there by the caller, but the callee may have pushed some ! 95: arguments that were previously passed in registers. ! 96: ! 97: When RTL generation is complete, this virtual register is ! 98: replaced by the sum of the register given by ! 99: `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. ! 100: ! 101: `VIRTUAL_STACK_VARS_REGNUM' ! 102: If `FRAME_GROWS_DOWNWARD' is defined, this points to ! 103: immediately above the first variable on the stack. ! 104: Otherwise, it points to the first variable on the stack. ! 105: ! 106: `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the ! 107: register given by `FRAME_POINTER_REGNUM' and the value ! 108: `STARTING_FRAME_OFFSET'. ! 109: ! 110: `VIRTUAL_STACK_DYNAMIC_REGNUM' ! 111: This points to the location of dynamically allocated memory ! 112: on the stack immediately after the stack pointer has been ! 113: adjusted by the amount of memory desired. ! 114: ! 115: This virtual register is replaced by the sum of the register ! 116: given by `STACK_POINTER_REGNUM' and the value ! 117: `STACK_DYNAMIC_OFFSET'. ! 118: ! 119: `VIRTUAL_OUTGOING_ARGS_REGNUM' ! 120: This points to the location in the stack at which outgoing ! 121: arguments should be written when the stack is pre-pushed ! 122: (arguments pushed using push insns should always use ! 123: `STACK_POINTER_REGNUM'). ! 124: ! 125: This virtual register is replaced by the sum of the register ! 126: given by `STACK_POINTER_REGNUM' and the value ! 127: `STACK_POINTER_OFFSET'. ! 128: ! 129: `(subreg:M REG WORDNUM)' ! 130: `subreg' expressions are used to refer to a register in a machine ! 131: mode other than its natural one, or to refer to one register of a ! 132: multi-word `reg' that actually refers to several registers. ! 133: ! 134: Each pseudo-register has a natural mode. If it is necessary to ! 135: operate on it in a different mode--for example, to perform a ! 136: fullword move instruction on a pseudo-register that contains a ! 137: single byte--the pseudo-register must be enclosed in a `subreg'. ! 138: In such a case, WORDNUM is zero. ! 139: ! 140: Usually M is at least as narrow as the mode of REG, in which case ! 141: it is restricting consideration to only the bits of REG that are ! 142: in M. ! 143: ! 144: Sometimes M is wider than the mode of REG. These `subreg' ! 145: expressions are often called "paradoxical". They are used in ! 146: cases where we want to refer to an object in a wider mode but do ! 147: not care what value the additional bits have. The reload pass ! 148: ensures that paradoxical references are only made to hard ! 149: registers. ! 150: ! 151: The other use of `subreg' is to extract the individual registers of ! 152: a multi-register value. Machine modes such as `DImode' and ! 153: `TImode' can indicate values longer than a word, values which ! 154: usually require two or more consecutive registers. To access one ! 155: of the registers, use a `subreg' with mode `SImode' and a WORDNUM ! 156: that says which register. ! 157: ! 158: Storing in a non-paradoxical `subreg' has undefined results for ! 159: bits belonging to the same word as the `subreg'. This laxity makes ! 160: it easier to generate efficient code for such instructions. To ! 161: represent an instruction that preserves all the bits outside of ! 162: those in the `subreg', use `strict_low_part' around the `subreg'. ! 163: ! 164: The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says ! 165: that word number zero is the most significant part; otherwise, it ! 166: is the least significant part. ! 167: ! 168: Between the combiner pass and the reload pass, it is possible to ! 169: have a paradoxical `subreg' which contains a `mem' instead of a ! 170: `reg' as its first operand. After the reload pass, it is also ! 171: possible to have a non-paradoxical `subreg' which contains a ! 172: `mem'; this usually occurs when the `mem' is a stack slot which ! 173: replaced a pseudo register. ! 174: ! 175: Note that it is not valid to access a `DFmode' value in `SFmode' ! 176: using a `subreg'. On some machines the most significant part of a ! 177: `DFmode' value does not have the same format as a single-precision ! 178: floating value. ! 179: ! 180: It is also not valid to access a single word of a multi-word value ! 181: in a hard register when less registers can hold the value than ! 182: would be expected from its size. For example, some 32-bit ! 183: machines have floating-point registers that can hold an entire ! 184: `DFmode' value. If register 10 were such a register `(subreg:SI ! 185: (reg:DF 10) 1)' would be invalid because there is no way to ! 186: convert that reference to a single machine register. The reload ! 187: pass prevents `subreg' expressions such as these from being formed. ! 188: ! 189: The first operand of a `subreg' expression is customarily accessed ! 190: with the `SUBREG_REG' macro and the second operand is customarily ! 191: accessed with the `SUBREG_WORD' macro. ! 192: ! 193: `(scratch:M)' ! 194: This represents a scratch register that will be required for the ! 195: execution of a single instruction and not used subsequently. It is ! 196: converted into a `reg' by either the local register allocator or ! 197: the reload pass. ! 198: ! 199: `scratch' is usually present inside a `clobber' operation (*note ! 200: Side Effects::.). ! 201: ! 202: `(cc0)' ! 203: This refers to the machine's condition code register. It has no ! 204: operands and may not have a machine mode. There are two ways to ! 205: use it: ! 206: ! 207: * To stand for a complete set of condition code flags. This is ! 208: best on most machines, where each comparison sets the entire ! 209: series of flags. ! 210: ! 211: With this technique, `(cc0)' may be validly used in only two ! 212: contexts: as the destination of an assignment (in test and ! 213: compare instructions) and in comparison operators comparing ! 214: against zero (`const_int' with value zero; that is to say, ! 215: `const0_rtx'). ! 216: ! 217: * To stand for a single flag that is the result of a single ! 218: condition. This is useful on machines that have only a ! 219: single flag bit, and in which comparison instructions must ! 220: specify the condition to test. ! 221: ! 222: With this technique, `(cc0)' may be validly used in only two ! 223: contexts: as the destination of an assignment (in test and ! 224: compare instructions) where the source is a comparison ! 225: operator, and as the first operand of `if_then_else' (in a ! 226: conditional branch). ! 227: ! 228: There is only one expression object of code `cc0'; it is the value ! 229: of the variable `cc0_rtx'. Any attempt to create an expression of ! 230: code `cc0' will return `cc0_rtx'. ! 231: ! 232: Instructions can set the condition code implicitly. On many ! 233: machines, nearly all instructions set the condition code based on ! 234: the value that they compute or store. It is not necessary to ! 235: record these actions explicitly in the RTL because the machine ! 236: description includes a prescription for recognizing the ! 237: instructions that do so (by means of the macro ! 238: `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions ! 239: whose sole purpose is to set the condition code, and instructions ! 240: that use the condition code, need mention `(cc0)'. ! 241: ! 242: On some machines, the condition code register is given a register ! 243: number and a `reg' is used instead of `(cc0)'. This is usually the ! 244: preferable approach if only a small subset of instructions modify ! 245: the condition code. Other machines store condition codes in ! 246: general registers; in such cases a pseudo register should be used. ! 247: ! 248: Some machines, such as the Sparc and RS/6000, have two sets of ! 249: arithmetic instructions, one that sets and one that does not set ! 250: the condition code. This is best handled by normally generating ! 251: the instruction that does not set the condition code, and making a ! 252: pattern that both performs the arithmetic and sets the condition ! 253: code register (which would not be `(cc0)' in this case). For ! 254: examples, search for `addcc' and `andcc' in `sparc.md'. ! 255: ! 256: `(pc)' ! 257: This represents the machine's program counter. It has no operands ! 258: and may not have a machine mode. `(pc)' may be validly used only ! 259: in certain specific contexts in jump instructions. ! 260: ! 261: There is only one expression object of code `pc'; it is the value ! 262: of the variable `pc_rtx'. Any attempt to create an expression of ! 263: code `pc' will return `pc_rtx'. ! 264: ! 265: All instructions that do not jump alter the program counter ! 266: implicitly by incrementing it, but there is no need to mention ! 267: this in the RTL. ! 268: ! 269: `(mem:M ADDR)' ! 270: This RTX represents a reference to main memory at an address ! 271: represented by the expression ADDR. M specifies how large a unit ! 272: of memory is accessed. 1.1.1.6 root 273: 274: 1.1.1.7 ! root 275: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 1.1.1.6 root 276: 1.1.1.7 ! root 277: RTL Expressions for Arithmetic ! 278: ============================== 1.1.1.6 root 279: 1.1.1.7 ! root 280: Unless otherwise specified, all the operands of arithmetic ! 281: expressions must be valid for mode M. An operand is valid for mode M ! 282: if it has mode M, or if it is a `const_int' or `const_double' and M is ! 283: a mode of class `MODE_INT'. ! 284: ! 285: For commutative binary operations, constants should be placed in the ! 286: second operand. ! 287: ! 288: `(plus:M X Y)' ! 289: Represents the sum of the values represented by X and Y carried ! 290: out in machine mode M. ! 291: ! 292: `(lo_sum:M X Y)' ! 293: Like `plus', except that it represents that sum of X and the ! 294: low-order bits of Y. The number of low order bits is ! 295: machine-dependent but is normally the number of bits in a `Pmode' ! 296: item minus the number of bits set by the `high' code (*note ! 297: Constants::.). ! 298: ! 299: M should be `Pmode'. ! 300: ! 301: `(minus:M X Y)' ! 302: Like `plus' but represents subtraction. ! 303: ! 304: `(compare:M X Y)' ! 305: Represents the result of subtracting Y from X for purposes of ! 306: comparison. The result is computed without overflow, as if with ! 307: infinite precision. ! 308: ! 309: Of course, machines can't really subtract with infinite precision. ! 310: However, they can pretend to do so when only the sign of the ! 311: result will be used, which is the case when the result is stored ! 312: in the condition code. And that is the only way this kind of ! 313: expression may validly be used: as a value to be stored in the ! 314: condition codes. ! 315: ! 316: The mode M is not related to the modes of X and Y, but instead is ! 317: the mode of the condition code value. If `(cc0)' is used, it is ! 318: `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often ! 319: `CCmode'. *Note Condition Code::. ! 320: ! 321: Normally, X and Y must have the same mode. Otherwise, `compare' ! 322: is valid only if the mode of X is in class `MODE_INT' and Y is a ! 323: `const_int' or `const_double' with mode `VOIDmode'. The mode of X ! 324: determines what mode the comparison is to be done in; thus it must ! 325: not be `VOIDmode'. ! 326: ! 327: If one of the operands is a constant, it should be placed in the ! 328: second operand and the comparison code adjusted as appropriate. ! 329: ! 330: A `compare' specifying two `VOIDmode' constants is not valid since ! 331: there is no way to know in what mode the comparison is to be ! 332: performed; the comparison must either be folded during the ! 333: compilation or the first operand must be loaded into a register ! 334: while its mode is still known. ! 335: ! 336: `(neg:M X)' ! 337: Represents the negation (subtraction from zero) of the value ! 338: represented by X, carried out in mode M. ! 339: ! 340: `(mult:M X Y)' ! 341: Represents the signed product of the values represented by X and Y ! 342: carried out in machine mode M. ! 343: ! 344: Some machines support a multiplication that generates a product ! 345: wider than the operands. Write the pattern for this as ! 346: ! 347: (mult:M (sign_extend:M X) (sign_extend:M Y)) ! 348: ! 349: where M is wider than the modes of X and Y, which need not be the ! 350: same. ! 351: ! 352: Write patterns for unsigned widening multiplication similarly using ! 353: `zero_extend'. ! 354: ! 355: `(div:M X Y)' ! 356: Represents the quotient in signed division of X by Y, carried out ! 357: in machine mode M. If M is a floating point mode, it represents ! 358: the exact quotient; otherwise, the integerized quotient. ! 359: ! 360: Some machines have division instructions in which the operands and ! 361: quotient widths are not all the same; you should represent such ! 362: instructions using `truncate' and `sign_extend' as in, ! 363: ! 364: (truncate:M1 (div:M2 X (sign_extend:M2 Y))) ! 365: ! 366: `(udiv:M X Y)' ! 367: Like `div' but represents unsigned division. ! 368: ! 369: `(mod:M X Y)' ! 370: `(umod:M X Y)' ! 371: Like `div' and `udiv' but represent the remainder instead of the ! 372: quotient. ! 373: ! 374: `(smin:M X Y)' ! 375: `(smax:M X Y)' ! 376: Represents the smaller (for `smin') or larger (for `smax') of X ! 377: and Y, interpreted as signed integers in mode M. ! 378: ! 379: `(umin:M X Y)' ! 380: `(umax:M X Y)' ! 381: Like `smin' and `smax', but the values are interpreted as unsigned ! 382: integers. ! 383: ! 384: `(not:M X)' ! 385: Represents the bitwise complement of the value represented by X, ! 386: carried out in mode M, which must be a fixed-point machine mode. ! 387: ! 388: `(and:M X Y)' ! 389: Represents the bitwise logical-and of the values represented by X ! 390: and Y, carried out in machine mode M, which must be a fixed-point ! 391: machine mode. ! 392: ! 393: `(ior:M X Y)' ! 394: Represents the bitwise inclusive-or of the values represented by X ! 395: and Y, carried out in machine mode M, which must be a fixed-point ! 396: mode. ! 397: ! 398: `(xor:M X Y)' ! 399: Represents the bitwise exclusive-or of the values represented by X ! 400: and Y, carried out in machine mode M, which must be a fixed-point ! 401: mode. ! 402: ! 403: `(ashift:M X C)' ! 404: Represents the result of arithmetically shifting X left by C ! 405: places. X have mode M, a fixed-point machine mode. C be a ! 406: fixed-point mode or be a constant with mode `VOIDmode'; which mode ! 407: is determined by the mode called for in the machine description ! 408: entry for the left-shift instruction. For example, on the Vax, ! 409: the mode of C is `QImode' regardless of M. ! 410: ! 411: `(lshiftrt:M X C)' ! 412: `(ashiftrt:M X C)' ! 413: Like `ashift' but for right shift. Unlike the case for left shift, ! 414: these two operations are distinct. ! 415: ! 416: `(rotate:M X C)' ! 417: `(rotatert:M X C)' ! 418: Similar but represent left and right rotate. If C is a constant, ! 419: use `rotate'. ! 420: ! 421: `(abs:M X)' ! 422: Represents the absolute value of X, computed in mode M. ! 423: ! 424: `(sqrt:M X)' ! 425: Represents the square root of X, computed in mode M. Most often M ! 426: will be a floating point mode. ! 427: ! 428: `(ffs:M X)' ! 429: Represents one plus the index of the least significant 1-bit in X, ! 430: represented as an integer of mode M. (The value is zero if X is ! 431: zero.) The mode of X need not be M; depending on the target ! 432: machine, various mode combinations may be valid. 1.1.1.6 root 433: 434: 1.1.1.7 ! root 435: File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL 1.1.1.6 root 436: 1.1.1.7 ! root 437: Comparison Operations ! 438: ===================== 1.1.1.6 root 439: 1.1.1.7 ! root 440: Comparison operators test a relation on two operands and are ! 441: considered to represent a machine-dependent nonzero value described by, ! 442: but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.) if the ! 443: relation holds, or zero if it does not. The mode of the comparison ! 444: operation is independent of the mode of the data being compared. If ! 445: the comparison operation is being tested (e.g., the first operand of an ! 446: `if_then_else'), the mode must be `VOIDmode'. If the comparison ! 447: operation is producing data to be stored in some variable, the mode ! 448: must be in class `MODE_INT'. All comparison operations producing data ! 449: must use the same mode, which is machine-specific. ! 450: ! 451: There are two ways that comparison operations may be used. The ! 452: comparison operators may be used to compare the condition codes `(cc0)' ! 453: against zero, as in `(eq (cc0) (const_int 0))'. Such a construct ! 454: actually refers to the result of the preceding instruction in which the ! 455: condition codes were set. The instructing setting the condition code ! 456: must be adjacent to the instruction using the condition code; only ! 457: `note' insns may separate them. ! 458: ! 459: Alternatively, a comparison operation may directly compare two data ! 460: objects. The mode of the comparison is determined by the operands; they ! 461: must both be valid for a common machine mode. A comparison with both ! 462: operands constant would be invalid as the machine mode could not be ! 463: deduced from it, but such a comparison should never exist in RTL due to ! 464: constant folding. ! 465: ! 466: In the example above, if `(cc0)' were last set to `(compare X Y)', ! 467: the comparison operation is identical to `(eq X Y)'. Usually only one ! 468: style of comparisons is supported on a particular machine, but the ! 469: combine pass will try to merge the operations to produce the `eq' shown ! 470: in case it exists in the context of the particular insn involved. ! 471: ! 472: Inequality comparisons come in two flavors, signed and unsigned. ! 473: Thus, there are distinct expression codes `gt' and `gtu' for signed and ! 474: unsigned greater-than. These can produce different results for the same ! 475: pair of integer values: for example, 1 is signed greater-than -1 but not ! 476: unsigned greater-than, because -1 when regarded as unsigned is actually ! 477: `0xffffffff' which is greater than 1. ! 478: ! 479: The signed comparisons are also used for floating point values. ! 480: Floating point comparisons are distinguished by the machine modes of ! 481: the operands. ! 482: ! 483: `(eq:M X Y)' ! 484: 1 if the values represented by X and Y are equal, otherwise 0. ! 485: ! 486: `(ne:M X Y)' ! 487: 1 if the values represented by X and Y are not equal, otherwise 0. ! 488: ! 489: `(gt:M X Y)' ! 490: 1 if the X is greater than Y. If they are fixed-point, the ! 491: comparison is done in a signed sense. ! 492: ! 493: `(gtu:M X Y)' ! 494: Like `gt' but does unsigned comparison, on fixed-point numbers ! 495: only. ! 496: ! 497: `(lt:M X Y)' ! 498: `(ltu:M X Y)' ! 499: Like `gt' and `gtu' but test for "less than". ! 500: ! 501: `(ge:M X Y)' ! 502: `(geu:M X Y)' ! 503: Like `gt' and `gtu' but test for "greater than or equal". ! 504: ! 505: `(le:M X Y)' ! 506: `(leu:M X Y)' ! 507: Like `gt' and `gtu' but test for "less than or equal". ! 508: ! 509: `(if_then_else COND THEN ELSE)' ! 510: This is not a comparison operation but is listed here because it is ! 511: always used in conjunction with a comparison operation. To be ! 512: precise, COND is a comparison expression. This expression ! 513: represents a choice, according to COND, between the value ! 514: represented by THEN and the one represented by ELSE. ! 515: ! 516: On most machines, `if_then_else' expressions are valid only to ! 517: express conditional jumps. ! 518: ! 519: `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' ! 520: Similar to `if_then_else', but more general. Each of TEST1, ! 521: TEST2, ... is performed in turn. The result of this expression is ! 522: the VALUE corresponding to the first non-zero test, or DEFAULT if ! 523: none of the tests are non-zero expressions. 1.1.1.6 root 524: 1.1.1.7 ! root 525: This is currently not valid for instruction patterns and is ! 526: supported only for insn attributes. *Note Insn Attributes::. 1.1.1.6 root 527: 1.1.1.7 ! root 528: ! 529: File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL 1.1.1.6 root 530: 1.1.1.7 ! root 531: Bit Fields ! 532: ========== 1.1.1.6 root 533: 1.1.1.7 ! root 534: Special expression codes exist to represent bitfield instructions. ! 535: These types of expressions are lvalues in RTL; they may appear on the ! 536: left side of an assignment, indicating insertion of a value into the ! 537: specified bit field. ! 538: ! 539: `(sign_extract:M LOC SIZE POS)' ! 540: This represents a reference to a sign-extended bit field contained ! 541: or starting in LOC (a memory or register reference). The bit field ! 542: is SIZE bits wide and starts at bit POS. The compilation option ! 543: `BITS_BIG_ENDIAN' says which end of the memory unit POS counts ! 544: from. ! 545: ! 546: If LOC is in memory, its mode must be a single-byte integer mode. ! 547: If LOC is in a register, the mode to use is specified by the ! 548: operand of the `insv' or `extv' pattern (*note Standard Names::.) ! 549: and is usually a full-word integer mode. ! 550: ! 551: The mode of POS is machine-specific and is also specified in the ! 552: `insv' or `extv' pattern. ! 553: ! 554: The mode M is the same as the mode that would be used for LOC if ! 555: it were a register. ! 556: ! 557: `(zero_extract:M LOC SIZE POS)' ! 558: Like `sign_extract' but refers to an unsigned or zero-extended bit ! 559: field. The same sequence of bits are extracted, but they are ! 560: filled to an entire word with zeros instead of by sign-extension. 1.1.1.6 root 561: 562: 1.1.1.7 ! root 563: File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL 1.1.1.6 root 564: 1.1.1.7 ! root 565: Conversions ! 566: =========== 1.1.1.6 root 567: 1.1.1.7 ! root 568: All conversions between machine modes must be represented by ! 569: explicit conversion operations. For example, an expression which is ! 570: the sum of a byte and a full word cannot be written as `(plus:SI ! 571: (reg:QI 34) (reg:SI 80))' because the `plus' operation requires two ! 572: operands of the same machine mode. Therefore, the byte-sized operand ! 573: is enclosed in a conversion operation, as in ! 574: ! 575: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) ! 576: ! 577: The conversion operation is not a mere placeholder, because there ! 578: may be more than one way of converting from a given starting mode to ! 579: the desired final mode. The conversion operation code says how to do ! 580: it. ! 581: ! 582: For all conversion operations, X must not be `VOIDmode' because the ! 583: mode in which to do the conversion would not be known. The conversion ! 584: must either be done at compile-time or X must be placed into a register. ! 585: ! 586: `(sign_extend:M X)' ! 587: Represents the result of sign-extending the value X to machine ! 588: mode M. M must be a fixed-point mode and X a fixed-point value of ! 589: a mode narrower than M. ! 590: ! 591: `(zero_extend:M X)' ! 592: Represents the result of zero-extending the value X to machine ! 593: mode M. M must be a fixed-point mode and X a fixed-point value of ! 594: a mode narrower than M. ! 595: ! 596: `(float_extend:M X)' ! 597: Represents the result of extending the value X to machine mode M. ! 598: m must be a floating point mode and X a floating point value of a ! 599: mode narrower than M. ! 600: ! 601: `(truncate:M X)' ! 602: Represents the result of truncating the value X to machine mode M. ! 603: M must be a fixed-point mode and X a fixed-point value of a mode ! 604: wider than M. ! 605: ! 606: `(float_truncate:M X)' ! 607: Represents the result of truncating the value X to machine mode M. ! 608: M must be a floating point mode and X a floating point value of a ! 609: mode wider than M. ! 610: ! 611: `(float:M X)' ! 612: Represents the result of converting fixed point value X, regarded ! 613: as signed, to floating point mode M. ! 614: ! 615: `(unsigned_float:M X)' ! 616: Represents the result of converting fixed point value X, regarded ! 617: as unsigned, to floating point mode M. ! 618: ! 619: `(fix:M X)' ! 620: When M is a fixed point mode, represents the result of converting ! 621: floating point value X to mode M, regarded as signed. How ! 622: rounding is done is not specified, so this operation may be used ! 623: validly in compiling C code only for integer-valued operands. ! 624: ! 625: `(unsigned_fix:M X)' ! 626: Represents the result of converting floating point value X to ! 627: fixed point mode M, regarded as unsigned. How rounding is done is ! 628: not specified. ! 629: ! 630: `(fix:M X)' ! 631: When M is a floating point mode, represents the result of ! 632: converting floating point value X (valid for mode M) to an ! 633: integer, still represented in floating point mode M, by rounding ! 634: towards zero. 1.1.1.6 root 635: 636: 1.1.1.7 ! root 637: File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 1.1.1.6 root 638: 1.1.1.7 ! root 639: Declarations ! 640: ============ 1.1.1.6 root 641: 1.1.1.7 ! root 642: Declaration expression codes do not represent arithmetic operations ! 643: but rather state assertions about their operands. 1.1.1.6 root 644: 1.1.1.7 ! root 645: `(strict_low_part (subreg:M (reg:N R) 0))' ! 646: This expression code is used in only one context: as the ! 647: destination operand of a `set' expression. In addition, the ! 648: operand of this expression must be a non-paradoxical `subreg' ! 649: expression. 1.1.1.6 root 650: 1.1.1.7 ! root 651: The presence of `strict_low_part' says that the part of the ! 652: register which is meaningful in mode N, but is not part of mode M, ! 653: is not to be altered. Normally, an assignment to such a subreg is ! 654: allowed to have undefined effects on the rest of the register when ! 655: M is less than a word. 1.1.1.6 root 656: 657: 1.1.1.7 ! root 658: File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 1.1.1.6 root 659: 1.1.1.7 ! root 660: Side Effect Expressions ! 661: ======================= 1.1.1.6 root 662: 1.1.1.7 ! root 663: The expression codes described so far represent values, not actions. ! 664: But machine instructions never produce values; they are meaningful only ! 665: for their side effects on the state of the machine. Special expression ! 666: codes are used to represent side effects. ! 667: ! 668: The body of an instruction is always one of these side effect codes; ! 669: the codes described above, which represent values, appear only as the ! 670: operands of these. ! 671: ! 672: `(set LVAL X)' ! 673: Represents the action of storing the value of X into the place ! 674: represented by LVAL. LVAL must be an expression representing a ! 675: place that can be stored in: `reg' (or `subreg' or ! 676: `strict_low_part'), `mem', `pc' or `cc0'. ! 677: ! 678: If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then ! 679: X must be valid for that mode. ! 680: ! 681: If LVAL is a `reg' whose machine mode is less than the full width ! 682: of the register, then it means that the part of the register ! 683: specified by the machine mode is given the specified value and the ! 684: rest of the register receives an undefined value. Likewise, if ! 685: LVAL is a `subreg' whose machine mode is narrower than the mode of ! 686: the register, the rest of the register can be changed in an ! 687: undefined way. ! 688: ! 689: If LVAL is a `strict_low_part' of a `subreg', then the part of the ! 690: register specified by the machine mode of the `subreg' is given ! 691: the value X and the rest of the register is not changed. ! 692: ! 693: If LVAL is `(cc0)', it has no machine mode, and X may be either a ! 694: `compare' expression or a value that may have any mode. The ! 695: latter case represents a "test" instruction. The expression `(set ! 696: (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) ! 697: (const_int 0)))'. Use the former expression to save space during ! 698: the compilation. ! 699: ! 700: If LVAL is `(pc)', we have a jump instruction, and the ! 701: possibilities for X are very limited. It may be a `label_ref' ! 702: expression (unconditional jump). It may be an `if_then_else' ! 703: (conditional jump), in which case either the second or the third ! 704: operand must be `(pc)' (for the case which does not jump) and the ! 705: other of the two must be a `label_ref' (for the case which does ! 706: jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may ! 707: be a `reg' or a `mem'; these unusual patterns are used to ! 708: represent jumps through branch tables. ! 709: ! 710: If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not ! 711: be `VOIDmode' and the mode of X must be valid for the mode of LVAL. ! 712: ! 713: LVAL is customarily accessed with the `SET_DEST' macro and X with ! 714: the `SET_SRC' macro. ! 715: ! 716: `(return)' ! 717: As the sole expression in a pattern, represents a return from the ! 718: current function, on machines where this can be done with one ! 719: instruction, such as Vaxes. On machines where a multi-instruction ! 720: "epilogue" must be executed in order to return from the function, ! 721: returning is done by jumping to a label which precedes the ! 722: epilogue, and the `return' expression code is never used. ! 723: ! 724: Inside an `if_then_else' expression, represents the value to be ! 725: placed in `pc' to return to the caller. ! 726: ! 727: Note that an insn pattern of `(return)' is logically equivalent to ! 728: `(set (pc) (return))', but the latter form is never used. ! 729: ! 730: `(call FUNCTION NARGS)' ! 731: Represents a function call. FUNCTION is a `mem' expression whose ! 732: address is the address of the function to be called. NARGS is an ! 733: expression which can be used for two purposes: on some machines it ! 734: represents the number of bytes of stack argument; on others, it ! 735: represents the number of argument registers. ! 736: ! 737: Each machine has a standard machine mode which FUNCTION must have. ! 738: The machine description defines macro `FUNCTION_MODE' to expand ! 739: into the requisite mode name. The purpose of this mode is to ! 740: specify what kind of addressing is allowed, on machines where the ! 741: allowed kinds of addressing depend on the machine mode being ! 742: addressed. ! 743: ! 744: `(clobber X)' ! 745: Represents the storing or possible storing of an unpredictable, ! 746: undescribed value into X, which must be a `reg', `scratch' or ! 747: `mem' expression. ! 748: ! 749: One place this is used is in string instructions that store ! 750: standard values into particular hard registers. It may not be ! 751: worth the trouble to describe the values that are stored, but it ! 752: is essential to inform the compiler that the registers will be ! 753: altered, lest it attempt to keep data in them across the string ! 754: instruction. ! 755: ! 756: If X is `(mem:BLK (const_int 0))', it means that all memory ! 757: locations must be presumed clobbered. ! 758: ! 759: Note that the machine description classifies certain hard ! 760: registers as "call-clobbered". All function call instructions are ! 761: assumed by default to clobber these registers, so there is no need ! 762: to use `clobber' expressions to indicate this fact. Also, each ! 763: function call is assumed to have the potential to alter any memory ! 764: location, unless the function is declared `const'. ! 765: ! 766: If the last group of expressions in a `parallel' are each a ! 767: `clobber' expression whose arguments are `reg' or `match_scratch' ! 768: (*note RTL Template::.) expressions, the combiner phase can add ! 769: the appropriate `clobber' expressions to an insn it has ! 770: constructed when doing so will cause a pattern to be matched. ! 771: ! 772: This feature can be used, for example, on a machine that whose ! 773: multiply and add instructions don't use an MQ register but which ! 774: has an add-accumulate instruction that does clobber the MQ ! 775: register. Similarly, a combined instruction might require a ! 776: temporary register while the constituent instructions might not. ! 777: ! 778: When a `clobber' expression for a register appears inside a ! 779: `parallel' with other side effects, the register allocator ! 780: guarantees that the register is unoccupied both before and after ! 781: that insn. However, the reload phase may allocate a register used ! 782: for one of the inputs unless the `&' constraint is specified for ! 783: the selected alternative (*note Modifiers::.). You can clobber ! 784: either a specific hard register, a pseudo register, or a `scratch' ! 785: expression; in the latter two cases, GNU CC will allocate a hard ! 786: register that is available there for use as a temporary. ! 787: ! 788: For instructions that require a temporary register, you should use ! 789: `scratch' instead of a pseudo-register because this will allow the ! 790: combiner phase to add the `clobber' when required. You do this by ! 791: coding (`clobber' (`match_scratch' ...)). If you do clobber a ! 792: pseudo register, use one which appears nowhere else--generate a ! 793: new one each time. Otherwise, you may confuse CSE. ! 794: ! 795: There is one other known use for clobbering a pseudo register in a ! 796: `parallel': when one of the input operands of the insn is also ! 797: clobbered by the insn. In this case, using the same pseudo ! 798: register in the clobber and elsewhere in the insn produces the ! 799: expected results. ! 800: ! 801: `(use X)' ! 802: Represents the use of the value of X. It indicates that the value ! 803: in X at this point in the program is needed, even though it may ! 804: not be apparent why this is so. Therefore, the compiler will not ! 805: attempt to delete previous instructions whose only effect is to ! 806: store a value in X. X must be a `reg' expression. ! 807: ! 808: During the delayed branch scheduling phase, X may be an insn. ! 809: This indicates that X previously was located at this place in the ! 810: code and its data dependencies need to be taken into account. ! 811: These `use' insns will be deleted before the delayed branch ! 812: scheduling phase exits. ! 813: ! 814: `(parallel [X0 X1 ...])' ! 815: Represents several side effects performed in parallel. The square ! 816: brackets stand for a vector; the operand of `parallel' is a vector ! 817: of expressions. X0, X1 and so on are individual side effect ! 818: expressions--expressions of code `set', `call', `return', ! 819: `clobber' or `use'. ! 820: ! 821: "In parallel" means that first all the values used in the ! 822: individual side-effects are computed, and second all the actual ! 823: side-effects are performed. For example, ! 824: ! 825: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) ! 826: (set (mem:SI (reg:SI 1)) (reg:SI 1))]) ! 827: ! 828: says unambiguously that the values of hard register 1 and the ! 829: memory location addressed by it are interchanged. In both places ! 830: where `(reg:SI 1)' appears as a memory address it refers to the ! 831: value in register 1 *before* the execution of the insn. ! 832: ! 833: It follows that it is *incorrect* to use `parallel' and expect the ! 834: result of one `set' to be available for the next one. For ! 835: example, people sometimes attempt to represent a jump-if-zero ! 836: instruction this way: ! 837: ! 838: (parallel [(set (cc0) (reg:SI 34)) ! 839: (set (pc) (if_then_else ! 840: (eq (cc0) (const_int 0)) ! 841: (label_ref ...) ! 842: (pc)))]) ! 843: ! 844: But this is incorrect, because it says that the jump condition ! 845: depends on the condition code value *before* this instruction, not ! 846: on the new value that is set by this instruction. ! 847: ! 848: Peephole optimization, which takes place together with final ! 849: assembly code output, can produce insns whose patterns consist of ! 850: a `parallel' whose elements are the operands needed to output the ! 851: resulting assembler code--often `reg', `mem' or constant ! 852: expressions. This would not be well-formed RTL at any other stage ! 853: in compilation, but it is ok then because no further optimization ! 854: remains to be done. However, the definition of the macro ! 855: `NOTICE_UPDATE_CC', if any, must deal with such insns if you ! 856: define any peephole optimizations. ! 857: ! 858: `(sequence [INSNS ...])' ! 859: Represents a sequence of insns. Each of the INSNS that appears in ! 860: the vector is suitable for appearing in the chain of insns, so it ! 861: must be an `insn', `jump_insn', `call_insn', `code_label', ! 862: `barrier' or `note'. ! 863: ! 864: A `sequence' RTX is never placed in an actual insn during RTL ! 865: generation. It represents the sequence of insns that result from a ! 866: `define_expand' *before* those insns are passed to `emit_insn' to ! 867: insert them in the chain of insns. When actually inserted, the ! 868: individual sub-insns are separated out and the `sequence' is ! 869: forgotten. ! 870: ! 871: After delay-slot scheduling is completed, an insn and all the ! 872: insns that reside in its delay slots are grouped together into a ! 873: `sequence'. The insn requiring the delay slot is the first insn ! 874: in the vector; subsequent insns are to be placed in the delay slot. ! 875: ! 876: `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to ! 877: indicate that a branch insn should be used that will conditionally ! 878: annul the effect of the insns in the delay slots. In such a case, ! 879: `INSN_FROM_TARGET_P' indicates that the insn is from the target of ! 880: the branch and should be executed only if the branch is taken; ! 881: otherwise the insn should be executed only if the branch is not ! 882: taken. *Note Delay Slots::. ! 883: ! 884: These expression codes appear in place of a side effect, as the body ! 885: of an insn, though strictly speaking they do not always describe side ! 886: effects as such: ! 887: ! 888: `(asm_input S)' ! 889: Represents literal assembler code as described by the string S. ! 890: ! 891: `(unspec [OPERANDS ...] INDEX)' ! 892: `(unspec_volatile [OPERANDS ...] INDEX)' ! 893: Represents a machine-specific operation on OPERANDS. INDEX ! 894: selects between multiple machine-specific operations. ! 895: `unspec_volatile' is used for volatile operations and operations ! 896: that may trap; `unspec' is used for other operations. ! 897: ! 898: These codes may appear inside a `pattern' of an insn, inside a ! 899: `parallel', or inside an expression. ! 900: ! 901: `(addr_vec:M [LR0 LR1 ...])' ! 902: Represents a table of jump addresses. The vector elements LR0, ! 903: etc., are `label_ref' expressions. The mode M specifies how much ! 904: space is given to each address; normally M would be `Pmode'. ! 905: ! 906: `(addr_diff_vec:M BASE [LR0 LR1 ...])' ! 907: Represents a table of jump addresses expressed as offsets from ! 908: BASE. The vector elements LR0, etc., are `label_ref' expressions ! 909: and so is BASE. The mode M specifies how much space is given to ! 910: each address-difference. 1.1.1.6 root 911: 912: 1.1.1.7 ! root 913: File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 1.1.1.5 root 914: 1.1.1.7 ! root 915: Embedded Side-Effects on Addresses ! 916: ================================== 1.1.1.5 root 917: 1.1.1.7 ! root 918: Four special side-effect expression codes appear as memory addresses. 1.1.1.5 root 919: 1.1.1.7 ! root 920: `(pre_dec:M X)' ! 921: Represents the side effect of decrementing X by a standard amount ! 922: and represents also the value that X has after being decremented. ! 923: x must be a `reg' or `mem', but most machines allow only a `reg'. ! 924: m must be the machine mode for pointers on the machine in use. ! 925: The amount X is decremented by is the length in bytes of the ! 926: machine mode of the containing memory reference of which this ! 927: expression serves as the address. Here is an example of its use: ! 928: ! 929: (mem:DF (pre_dec:SI (reg:SI 39))) ! 930: ! 931: This says to decrement pseudo register 39 by the length of a ! 932: `DFmode' value and use the result to address a `DFmode' value. ! 933: ! 934: `(pre_inc:M X)' ! 935: Similar, but specifies incrementing X instead of decrementing it. ! 936: ! 937: `(post_dec:M X)' ! 938: Represents the same side effect as `pre_dec' but a different ! 939: value. The value represented here is the value X has before being ! 940: decremented. ! 941: ! 942: `(post_inc:M X)' ! 943: Similar, but specifies incrementing X instead of decrementing it. ! 944: ! 945: These embedded side effect expressions must be used with care. ! 946: Instruction patterns may not use them. Until the `flow' pass of the ! 947: compiler, they may occur only to represent pushes onto the stack. The ! 948: `flow' pass finds cases where registers are incremented or decremented ! 949: in one instruction and used as an address shortly before or after; ! 950: these cases are then transformed to use pre- or post-increment or ! 951: -decrement. ! 952: ! 953: If a register used as the operand of these expressions is used in ! 954: another address in an insn, the original value of the register is used. ! 955: Uses of the register outside of an address are not permitted within the ! 956: same insn as a use in an embedded side effect expression because such ! 957: insns behave differently on different machines and hence must be treated ! 958: as ambiguous and disallowed. ! 959: ! 960: An instruction that can be represented with an embedded side effect ! 961: could also be represented using `parallel' containing an additional ! 962: `set' to describe how the address register is altered. This is not ! 963: done because machines that allow these operations at all typically ! 964: allow them wherever a memory address is called for. Describing them as ! 965: additional parallel stores would require doubling the number of entries ! 966: in the machine description. 1.1.1.5 root 967: 968: 1.1.1.7 ! root 969: File: gcc.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL 1.1.1.5 root 970: 1.1.1.7 ! root 971: Assembler Instructions as Expressions ! 972: ===================================== 1.1.1.5 root 973: 1.1.1.7 ! root 974: The RTX code `asm_operands' represents a value produced by a ! 975: user-specified assembler instruction. It is used to represent an `asm' ! 976: statement with arguments. An `asm' statement with a single output ! 977: operand, like this: ! 978: ! 979: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); ! 980: ! 981: is represented using a single `asm_operands' RTX which represents the ! 982: value that is stored in `outputvar': ! 983: ! 984: (set RTX-FOR-OUTPUTVAR ! 985: (asm_operands "foo %1,%2,%0" "a" 0 ! 986: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] ! 987: [(asm_input:M1 "g") ! 988: (asm_input:M2 "di")])) ! 989: ! 990: Here the operands of the `asm_operands' RTX are the assembler template ! 991: string, the output-operand's constraint, the index-number of the output ! 992: operand among the output operands specified, a vector of input operand ! 993: RTX's, and a vector of input-operand modes and constraints. The mode ! 994: M1 is the mode of the sum `x+y'; M2 is that of `*z'. ! 995: ! 996: When an `asm' statement has multiple output values, its insn has ! 997: several such `set' RTX's inside of a `parallel'. Each `set' contains a ! 998: `asm_operands'; all of these share the same assembler template and ! 999: vectors, but each contains the constraint for the respective output ! 1000: operand. They are also distinguished by the output-operand index ! 1001: number, which is 0, 1, ... for successive output operands. 1.1 root 1002:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.