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