![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-15 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-15 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.8 ! root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330
! 7: Boston, MA 02111-1307 USA
1.1.1.5 root 8:
1.1.1.8 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
! 10: Foundation, Inc.
1.1 root 11:
1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this
13: manual provided the copyright notice and this permission notice are
14: preserved on all copies.
1.1 root 15:
16: Permission is granted to copy and distribute modified versions of
17: this manual under the conditions for verbatim copying, provided also
1.1.1.7 root 18: that the sections entitled "GNU General Public License," "Funding for
19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
20: included exactly as in the original, and provided that the entire
21: resulting derived work is distributed under the terms of a permission
22: notice identical to this one.
1.1 root 23:
24: Permission is granted to copy and distribute translations of this
25: manual into another language, under the above conditions for modified
1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public
1.1.1.7 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight
28: `Look And Feel'", and this permission notice, may be included in
29: translations approved by the Free Software Foundation instead of in the
30: original English.
1.1.1.3 root 31:
32:
1.1.1.8 ! root 33: File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
1.1.1.3 root 34:
1.1.1.8 ! root 35: Side Effect Expressions
! 36: =======================
1.1.1.4 root 37:
1.1.1.8 ! root 38: The expression codes described so far represent values, not actions.
! 39: But machine instructions never produce values; they are meaningful only
! 40: for their side effects on the state of the machine. Special expression
! 41: codes are used to represent side effects.
! 42:
! 43: The body of an instruction is always one of these side effect codes;
! 44: the codes described above, which represent values, appear only as the
! 45: operands of these.
! 46:
! 47: `(set LVAL X)'
! 48: Represents the action of storing the value of X into the place
! 49: represented by LVAL. LVAL must be an expression representing a
! 50: place that can be stored in: `reg' (or `subreg' or
! 51: `strict_low_part'), `mem', `pc' or `cc0'.
! 52:
! 53: If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
! 54: X must be valid for that mode.
! 55:
! 56: If LVAL is a `reg' whose machine mode is less than the full width
! 57: of the register, then it means that the part of the register
! 58: specified by the machine mode is given the specified value and the
! 59: rest of the register receives an undefined value. Likewise, if
! 60: LVAL is a `subreg' whose machine mode is narrower than the mode of
! 61: the register, the rest of the register can be changed in an
! 62: undefined way.
! 63:
! 64: If LVAL is a `strict_low_part' of a `subreg', then the part of the
! 65: register specified by the machine mode of the `subreg' is given
! 66: the value X and the rest of the register is not changed.
! 67:
! 68: If LVAL is `(cc0)', it has no machine mode, and X may be either a
! 69: `compare' expression or a value that may have any mode. The
! 70: latter case represents a "test" instruction. The expression `(set
! 71: (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
! 72: (const_int 0)))'. Use the former expression to save space during
! 73: the compilation.
! 74:
! 75: If LVAL is `(pc)', we have a jump instruction, and the
! 76: possibilities for X are very limited. It may be a `label_ref'
! 77: expression (unconditional jump). It may be an `if_then_else'
! 78: (conditional jump), in which case either the second or the third
! 79: operand must be `(pc)' (for the case which does not jump) and the
! 80: other of the two must be a `label_ref' (for the case which does
! 81: jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
! 82: be a `reg' or a `mem'; these unusual patterns are used to
! 83: represent jumps through branch tables.
! 84:
! 85: If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
! 86: be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
! 87:
! 88: LVAL is customarily accessed with the `SET_DEST' macro and X with
! 89: the `SET_SRC' macro.
! 90:
! 91: `(return)'
! 92: As the sole expression in a pattern, represents a return from the
! 93: current function, on machines where this can be done with one
! 94: instruction, such as Vaxes. On machines where a multi-instruction
! 95: "epilogue" must be executed in order to return from the function,
! 96: returning is done by jumping to a label which precedes the
! 97: epilogue, and the `return' expression code is never used.
! 98:
! 99: Inside an `if_then_else' expression, represents the value to be
! 100: placed in `pc' to return to the caller.
! 101:
! 102: Note that an insn pattern of `(return)' is logically equivalent to
! 103: `(set (pc) (return))', but the latter form is never used.
! 104:
! 105: `(call FUNCTION NARGS)'
! 106: Represents a function call. FUNCTION is a `mem' expression whose
! 107: address is the address of the function to be called. NARGS is an
! 108: expression which can be used for two purposes: on some machines it
! 109: represents the number of bytes of stack argument; on others, it
! 110: represents the number of argument registers.
! 111:
! 112: Each machine has a standard machine mode which FUNCTION must have.
! 113: The machine description defines macro `FUNCTION_MODE' to expand
! 114: into the requisite mode name. The purpose of this mode is to
! 115: specify what kind of addressing is allowed, on machines where the
! 116: allowed kinds of addressing depend on the machine mode being
! 117: addressed.
! 118:
! 119: `(clobber X)'
! 120: Represents the storing or possible storing of an unpredictable,
! 121: undescribed value into X, which must be a `reg', `scratch' or
! 122: `mem' expression.
! 123:
! 124: One place this is used is in string instructions that store
! 125: standard values into particular hard registers. It may not be
! 126: worth the trouble to describe the values that are stored, but it
! 127: is essential to inform the compiler that the registers will be
! 128: altered, lest it attempt to keep data in them across the string
! 129: instruction.
1.1.1.7 root 130:
1.1.1.8 ! root 131: If X is `(mem:BLK (const_int 0))', it means that all memory
! 132: locations must be presumed clobbered.
1.1.1.7 root 133:
1.1.1.8 ! root 134: Note that the machine description classifies certain hard
! 135: registers as "call-clobbered". All function call instructions are
! 136: assumed by default to clobber these registers, so there is no need
! 137: to use `clobber' expressions to indicate this fact. Also, each
! 138: function call is assumed to have the potential to alter any memory
! 139: location, unless the function is declared `const'.
! 140:
! 141: If the last group of expressions in a `parallel' are each a
! 142: `clobber' expression whose arguments are `reg' or `match_scratch'
! 143: (*note RTL Template::.) expressions, the combiner phase can add
! 144: the appropriate `clobber' expressions to an insn it has
! 145: constructed when doing so will cause a pattern to be matched.
! 146:
! 147: This feature can be used, for example, on a machine that whose
! 148: multiply and add instructions don't use an MQ register but which
! 149: has an add-accumulate instruction that does clobber the MQ
! 150: register. Similarly, a combined instruction might require a
! 151: temporary register while the constituent instructions might not.
! 152:
! 153: When a `clobber' expression for a register appears inside a
! 154: `parallel' with other side effects, the register allocator
! 155: guarantees that the register is unoccupied both before and after
! 156: that insn. However, the reload phase may allocate a register used
! 157: for one of the inputs unless the `&' constraint is specified for
! 158: the selected alternative (*note Modifiers::.). You can clobber
! 159: either a specific hard register, a pseudo register, or a `scratch'
! 160: expression; in the latter two cases, GNU CC will allocate a hard
! 161: register that is available there for use as a temporary.
! 162:
! 163: For instructions that require a temporary register, you should use
! 164: `scratch' instead of a pseudo-register because this will allow the
! 165: combiner phase to add the `clobber' when required. You do this by
! 166: coding (`clobber' (`match_scratch' ...)). If you do clobber a
! 167: pseudo register, use one which appears nowhere else--generate a
! 168: new one each time. Otherwise, you may confuse CSE.
! 169:
! 170: There is one other known use for clobbering a pseudo register in a
! 171: `parallel': when one of the input operands of the insn is also
! 172: clobbered by the insn. In this case, using the same pseudo
! 173: register in the clobber and elsewhere in the insn produces the
! 174: expected results.
! 175:
! 176: `(use X)'
! 177: Represents the use of the value of X. It indicates that the value
! 178: in X at this point in the program is needed, even though it may
! 179: not be apparent why this is so. Therefore, the compiler will not
! 180: attempt to delete previous instructions whose only effect is to
! 181: store a value in X. X must be a `reg' expression.
! 182:
! 183: During the delayed branch scheduling phase, X may be an insn.
! 184: This indicates that X previously was located at this place in the
! 185: code and its data dependencies need to be taken into account.
! 186: These `use' insns will be deleted before the delayed branch
! 187: scheduling phase exits.
! 188:
! 189: `(parallel [X0 X1 ...])'
! 190: Represents several side effects performed in parallel. The square
! 191: brackets stand for a vector; the operand of `parallel' is a vector
! 192: of expressions. X0, X1 and so on are individual side effect
! 193: expressions--expressions of code `set', `call', `return',
! 194: `clobber' or `use'.
! 195:
! 196: "In parallel" means that first all the values used in the
! 197: individual side-effects are computed, and second all the actual
! 198: side-effects are performed. For example,
! 199:
! 200: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
! 201: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
! 202:
! 203: says unambiguously that the values of hard register 1 and the
! 204: memory location addressed by it are interchanged. In both places
! 205: where `(reg:SI 1)' appears as a memory address it refers to the
! 206: value in register 1 *before* the execution of the insn.
! 207:
! 208: It follows that it is *incorrect* to use `parallel' and expect the
! 209: result of one `set' to be available for the next one. For
! 210: example, people sometimes attempt to represent a jump-if-zero
! 211: instruction this way:
! 212:
! 213: (parallel [(set (cc0) (reg:SI 34))
! 214: (set (pc) (if_then_else
! 215: (eq (cc0) (const_int 0))
! 216: (label_ref ...)
! 217: (pc)))])
! 218:
! 219: But this is incorrect, because it says that the jump condition
! 220: depends on the condition code value *before* this instruction, not
! 221: on the new value that is set by this instruction.
! 222:
! 223: Peephole optimization, which takes place together with final
! 224: assembly code output, can produce insns whose patterns consist of
! 225: a `parallel' whose elements are the operands needed to output the
! 226: resulting assembler code--often `reg', `mem' or constant
! 227: expressions. This would not be well-formed RTL at any other stage
! 228: in compilation, but it is ok then because no further optimization
! 229: remains to be done. However, the definition of the macro
! 230: `NOTICE_UPDATE_CC', if any, must deal with such insns if you
! 231: define any peephole optimizations.
! 232:
! 233: `(sequence [INSNS ...])'
! 234: Represents a sequence of insns. Each of the INSNS that appears in
! 235: the vector is suitable for appearing in the chain of insns, so it
! 236: must be an `insn', `jump_insn', `call_insn', `code_label',
! 237: `barrier' or `note'.
! 238:
! 239: A `sequence' RTX is never placed in an actual insn during RTL
! 240: generation. It represents the sequence of insns that result from a
! 241: `define_expand' *before* those insns are passed to `emit_insn' to
! 242: insert them in the chain of insns. When actually inserted, the
! 243: individual sub-insns are separated out and the `sequence' is
! 244: forgotten.
! 245:
! 246: After delay-slot scheduling is completed, an insn and all the
! 247: insns that reside in its delay slots are grouped together into a
! 248: `sequence'. The insn requiring the delay slot is the first insn
! 249: in the vector; subsequent insns are to be placed in the delay slot.
! 250:
! 251: `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
! 252: indicate that a branch insn should be used that will conditionally
! 253: annul the effect of the insns in the delay slots. In such a case,
! 254: `INSN_FROM_TARGET_P' indicates that the insn is from the target of
! 255: the branch and should be executed only if the branch is taken;
! 256: otherwise the insn should be executed only if the branch is not
! 257: taken. *Note Delay Slots::.
! 258:
! 259: These expression codes appear in place of a side effect, as the body
! 260: of an insn, though strictly speaking they do not always describe side
! 261: effects as such:
! 262:
! 263: `(asm_input S)'
! 264: Represents literal assembler code as described by the string S.
! 265:
! 266: `(unspec [OPERANDS ...] INDEX)'
! 267: `(unspec_volatile [OPERANDS ...] INDEX)'
! 268: Represents a machine-specific operation on OPERANDS. INDEX
! 269: selects between multiple machine-specific operations.
! 270: `unspec_volatile' is used for volatile operations and operations
! 271: that may trap; `unspec' is used for other operations.
! 272:
! 273: These codes may appear inside a `pattern' of an insn, inside a
! 274: `parallel', or inside an expression.
! 275:
! 276: `(addr_vec:M [LR0 LR1 ...])'
! 277: Represents a table of jump addresses. The vector elements LR0,
! 278: etc., are `label_ref' expressions. The mode M specifies how much
! 279: space is given to each address; normally M would be `Pmode'.
! 280:
! 281: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
! 282: Represents a table of jump addresses expressed as offsets from
! 283: BASE. The vector elements LR0, etc., are `label_ref' expressions
! 284: and so is BASE. The mode M specifies how much space is given to
! 285: each address-difference.
1.1.1.4 root 286:
287:
1.1.1.8 ! root 288: File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
1.1.1.3 root 289:
1.1.1.8 ! root 290: Embedded Side-Effects on Addresses
! 291: ==================================
1.1.1.4 root 292:
1.1.1.8 ! root 293: Four special side-effect expression codes appear as memory addresses.
1.1.1.7 root 294:
1.1.1.8 ! root 295: `(pre_dec:M X)'
! 296: Represents the side effect of decrementing X by a standard amount
! 297: and represents also the value that X has after being decremented.
! 298: x must be a `reg' or `mem', but most machines allow only a `reg'.
! 299: m must be the machine mode for pointers on the machine in use.
! 300: The amount X is decremented by is the length in bytes of the
! 301: machine mode of the containing memory reference of which this
! 302: expression serves as the address. Here is an example of its use:
! 303:
! 304: (mem:DF (pre_dec:SI (reg:SI 39)))
! 305:
! 306: This says to decrement pseudo register 39 by the length of a
! 307: `DFmode' value and use the result to address a `DFmode' value.
! 308:
! 309: `(pre_inc:M X)'
! 310: Similar, but specifies incrementing X instead of decrementing it.
! 311:
! 312: `(post_dec:M X)'
! 313: Represents the same side effect as `pre_dec' but a different
! 314: value. The value represented here is the value X has before being
! 315: decremented.
! 316:
! 317: `(post_inc:M X)'
! 318: Similar, but specifies incrementing X instead of decrementing it.
! 319:
! 320: These embedded side effect expressions must be used with care.
! 321: Instruction patterns may not use them. Until the `flow' pass of the
! 322: compiler, they may occur only to represent pushes onto the stack. The
! 323: `flow' pass finds cases where registers are incremented or decremented
! 324: in one instruction and used as an address shortly before or after;
! 325: these cases are then transformed to use pre- or post-increment or
! 326: -decrement.
! 327:
! 328: If a register used as the operand of these expressions is used in
! 329: another address in an insn, the original value of the register is used.
! 330: Uses of the register outside of an address are not permitted within the
! 331: same insn as a use in an embedded side effect expression because such
! 332: insns behave differently on different machines and hence must be treated
! 333: as ambiguous and disallowed.
! 334:
! 335: An instruction that can be represented with an embedded side effect
! 336: could also be represented using `parallel' containing an additional
! 337: `set' to describe how the address register is altered. This is not
! 338: done because machines that allow these operations at all typically
! 339: allow them wherever a memory address is called for. Describing them as
! 340: additional parallel stores would require doubling the number of entries
! 341: in the machine description.
1.1.1.3 root 342:
343:
1.1.1.8 ! root 344: File: gcc.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
1.1.1.5 root 345:
1.1.1.8 ! root 346: Assembler Instructions as Expressions
! 347: =====================================
1.1.1.5 root 348:
1.1.1.8 ! root 349: The RTX code `asm_operands' represents a value produced by a
! 350: user-specified assembler instruction. It is used to represent an `asm'
! 351: statement with arguments. An `asm' statement with a single output
! 352: operand, like this:
! 353:
! 354: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
! 355:
! 356: is represented using a single `asm_operands' RTX which represents the
! 357: value that is stored in `outputvar':
! 358:
! 359: (set RTX-FOR-OUTPUTVAR
! 360: (asm_operands "foo %1,%2,%0" "a" 0
! 361: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
! 362: [(asm_input:M1 "g")
! 363: (asm_input:M2 "di")]))
! 364:
! 365: Here the operands of the `asm_operands' RTX are the assembler template
! 366: string, the output-operand's constraint, the index-number of the output
! 367: operand among the output operands specified, a vector of input operand
! 368: RTX's, and a vector of input-operand modes and constraints. The mode
! 369: M1 is the mode of the sum `x+y'; M2 is that of `*z'.
! 370:
! 371: When an `asm' statement has multiple output values, its insn has
! 372: several such `set' RTX's inside of a `parallel'. Each `set' contains a
! 373: `asm_operands'; all of these share the same assembler template and
! 374: vectors, but each contains the constraint for the respective output
! 375: operand. They are also distinguished by the output-operand index
! 376: number, which is 0, 1, ... for successive output operands.
1.1.1.7 root 377:
378:
1.1.1.8 ! root 379: File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
1.1.1.7 root 380:
1.1.1.8 ! root 381: Insns
! 382: =====
1.1.1.3 root 383:
1.1.1.8 ! root 384: The RTL representation of the code for a function is a doubly-linked
! 385: chain of objects called "insns". Insns are expressions with special
! 386: codes that are used for no other purpose. Some insns are actual
! 387: instructions; others represent dispatch tables for `switch' statements;
! 388: others represent labels to jump to or various sorts of declarative
! 389: information.
! 390:
! 391: In addition to its own specific data, each insn must have a unique
! 392: id-number that distinguishes it from all other insns in the current
! 393: function (after delayed branch scheduling, copies of an insn with the
! 394: same id-number may be present in multiple places in a function, but
! 395: these copies will always be identical and will only appear inside a
! 396: `sequence'), and chain pointers to the preceding and following insns.
! 397: These three fields occupy the same position in every insn, independent
! 398: of the expression code of the insn. They could be accessed with `XEXP'
! 399: and `XINT', but instead three special macros are always used:
! 400:
! 401: `INSN_UID (I)'
! 402: Accesses the unique id of insn I.
! 403:
! 404: `PREV_INSN (I)'
! 405: Accesses the chain pointer to the insn preceding I. If I is the
! 406: first insn, this is a null pointer.
! 407:
! 408: `NEXT_INSN (I)'
! 409: Accesses the chain pointer to the insn following I. If I is the
! 410: last insn, this is a null pointer.
! 411:
! 412: The first insn in the chain is obtained by calling `get_insns'; the
! 413: last insn is the result of calling `get_last_insn'. Within the chain
! 414: delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
! 415: always correspond: if INSN is not the first insn,
! 416:
! 417: NEXT_INSN (PREV_INSN (INSN)) == INSN
! 418:
! 419: is always true and if INSN is not the last insn,
! 420:
! 421: PREV_INSN (NEXT_INSN (INSN)) == INSN
! 422:
! 423: is always true.
! 424:
! 425: After delay slot scheduling, some of the insns in the chain might be
! 426: `sequence' expressions, which contain a vector of insns. The value of
! 427: `NEXT_INSN' in all but the last of these insns is the next insn in the
! 428: vector; the value of `NEXT_INSN' of the last insn in the vector is the
! 429: same as the value of `NEXT_INSN' for the `sequence' in which it is
! 430: contained. Similar rules apply for `PREV_INSN'.
! 431:
! 432: This means that the above invariants are not necessarily true for
! 433: insns inside `sequence' expressions. Specifically, if INSN is the
! 434: first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn
! 435: containing the `sequence' expression, as is the value of `PREV_INSN
! 436: (NEXT_INSN (INSN))' is INSN is the last insn in the `sequence'
! 437: expression. You can use these expressions to find the containing
! 438: `sequence' expression.
! 439:
! 440: Every insn has one of the following six expression codes:
! 441:
! 442: `insn'
! 443: The expression code `insn' is used for instructions that do not
! 444: jump and do not do function calls. `sequence' expressions are
! 445: always contained in insns with code `insn' even if one of those
! 446: insns should jump or do function calls.
! 447:
! 448: Insns with code `insn' have four additional fields beyond the three
! 449: mandatory ones listed above. These four are described in a table
! 450: below.
! 451:
! 452: `jump_insn'
! 453: The expression code `jump_insn' is used for instructions that may
! 454: jump (or, more generally, may contain `label_ref' expressions). If
! 455: there is an instruction to return from the current function, it is
! 456: recorded as a `jump_insn'.
! 457:
! 458: `jump_insn' insns have the same extra fields as `insn' insns,
! 459: accessed in the same way and in addition contain a field
! 460: `JUMP_LABEL' which is defined once jump optimization has completed.
! 461:
! 462: For simple conditional and unconditional jumps, this field
! 463: contains the `code_label' to which this insn will (possibly
! 464: conditionally) branch. In a more complex jump, `JUMP_LABEL'
! 465: records one of the labels that the insn refers to; the only way to
! 466: find the others is to scan the entire body of the insn.
! 467:
! 468: Return insns count as jumps, but since they do not refer to any
! 469: labels, they have zero in the `JUMP_LABEL' field.
! 470:
! 471: `call_insn'
! 472: The expression code `call_insn' is used for instructions that may
! 473: do function calls. It is important to distinguish these
! 474: instructions because they imply that certain registers and memory
! 475: locations may be altered unpredictably.
! 476:
! 477: `call_insn' insns have the same extra fields as `insn' insns,
! 478: accessed in the same way and in addition contain a field
! 479: `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
! 480: `expr_list' expressions) containing `use' and `clobber'
! 481: expressions that denote hard registers used or clobbered by the
! 482: called function. A register specified in a `clobber' in this list
! 483: is modified *after* the execution of the `call_insn', while a
! 484: register in a `clobber' in the body of the `call_insn' is
! 485: clobbered before the insn completes execution. `clobber'
! 486: expressions in this list augment registers specified in
! 487: `CALL_USED_REGISTERS' (*note Register Basics::.).
! 488:
! 489: `code_label'
! 490: A `code_label' insn represents a label that a jump insn can jump
! 491: to. It contains two special fields of data in addition to the
! 492: three standard ones. `CODE_LABEL_NUMBER' is used to hold the
! 493: "label number", a number that identifies this label uniquely among
! 494: all the labels in the compilation (not just in the current
! 495: function). Ultimately, the label is represented in the assembler
! 496: output as an assembler label, usually of the form `LN' where N is
! 497: the label number.
! 498:
! 499: When a `code_label' appears in an RTL expression, it normally
! 500: appears within a `label_ref' which represents the address of the
! 501: label, as a number.
! 502:
! 503: The field `LABEL_NUSES' is only defined once the jump optimization
! 504: phase is completed and contains the number of times this label is
! 505: referenced in the current function.
! 506:
! 507: `barrier'
! 508: Barriers are placed in the instruction stream when control cannot
! 509: flow past them. They are placed after unconditional jump
! 510: instructions to indicate that the jumps are unconditional and
! 511: after calls to `volatile' functions, which do not return (e.g.,
! 512: `exit'). They contain no information beyond the three standard
! 513: fields.
! 514:
! 515: `note'
! 516: `note' insns are used to represent additional debugging and
! 517: declarative information. They contain two nonstandard fields, an
! 518: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
! 519: string accessed with `NOTE_SOURCE_FILE'.
! 520:
! 521: If `NOTE_LINE_NUMBER' is positive, the note represents the
! 522: position of a source line and `NOTE_SOURCE_FILE' is the source
! 523: file name that the line came from. These notes control generation
! 524: of line number data in the assembler output.
! 525:
! 526: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
! 527: code with one of the following values (and `NOTE_SOURCE_FILE' must
! 528: contain a null pointer):
! 529:
! 530: `NOTE_INSN_DELETED'
! 531: Such a note is completely ignorable. Some passes of the
! 532: compiler delete insns by altering them into notes of this
! 533: kind.
! 534:
! 535: `NOTE_INSN_BLOCK_BEG'
! 536: `NOTE_INSN_BLOCK_END'
! 537: These types of notes indicate the position of the beginning
! 538: and end of a level of scoping of variable names. They
! 539: control the output of debugging information.
! 540:
! 541: `NOTE_INSN_LOOP_BEG'
! 542: `NOTE_INSN_LOOP_END'
! 543: These types of notes indicate the position of the beginning
! 544: and end of a `while' or `for' loop. They enable the loop
! 545: optimizer to find loops quickly.
! 546:
! 547: `NOTE_INSN_LOOP_CONT'
! 548: Appears at the place in a loop that `continue' statements
! 549: jump to.
! 550:
! 551: `NOTE_INSN_LOOP_VTOP'
! 552: This note indicates the place in a loop where the exit test
! 553: begins for those loops in which the exit test has been
! 554: duplicated. This position becomes another virtual start of
! 555: the loop when considering loop invariants.
! 556:
! 557: `NOTE_INSN_FUNCTION_END'
! 558: Appears near the end of the function body, just before the
! 559: label that `return' statements jump to (on machine where a
! 560: single instruction does not suffice for returning). This
! 561: note may be deleted by jump optimization.
! 562:
! 563: `NOTE_INSN_SETJMP'
! 564: Appears following each call to `setjmp' or a related function.
! 565:
! 566: These codes are printed symbolically when they appear in debugging
! 567: dumps.
! 568:
! 569: The machine mode of an insn is normally `VOIDmode', but some phases
! 570: use the mode for various purposes; for example, the reload pass sets it
! 571: to `HImode' if the insn needs reloading but not register elimination
! 572: and `QImode' if both are required. The common subexpression
! 573: elimination pass sets the mode of an insn to `QImode' when it is the
! 574: first insn in a block that has already been processed.
! 575:
! 576: Here is a table of the extra fields of `insn', `jump_insn' and
! 577: `call_insn' insns:
! 578:
! 579: `PATTERN (I)'
! 580: An expression for the side effect performed by this insn. This
! 581: must be one of the following codes: `set', `call', `use',
! 582: `clobber', `return', `asm_input', `asm_output', `addr_vec',
! 583: `addr_diff_vec', `trap_if', `unspec', `unspec_volatile',
! 584: `parallel', or `sequence'. If it is a `parallel', each element of
! 585: the `parallel' must be one these codes, except that `parallel'
! 586: expressions cannot be nested and `addr_vec' and `addr_diff_vec'
! 587: are not permitted inside a `parallel' expression.
! 588:
! 589: `INSN_CODE (I)'
! 590: An integer that says which pattern in the machine description
! 591: matches this insn, or -1 if the matching has not yet been
! 592: attempted.
! 593:
! 594: Such matching is never attempted and this field remains -1 on an
! 595: insn whose pattern consists of a single `use', `clobber',
! 596: `asm_input', `addr_vec' or `addr_diff_vec' expression.
! 597:
! 598: Matching is also never attempted on insns that result from an `asm'
! 599: statement. These contain at least one `asm_operands' expression.
! 600: The function `asm_noperands' returns a non-negative value for such
! 601: insns.
! 602:
! 603: In the debugging output, this field is printed as a number
! 604: followed by a symbolic representation that locates the pattern in
! 605: the `md' file as some small positive or negative offset from a
! 606: named pattern.
! 607:
! 608: `LOG_LINKS (I)'
! 609: A list (chain of `insn_list' expressions) giving information about
! 610: dependencies between instructions within a basic block. Neither a
! 611: jump nor a label may come between the related insns.
! 612:
! 613: `REG_NOTES (I)'
! 614: A list (chain of `expr_list' and `insn_list' expressions) giving
! 615: miscellaneous information about the insn. It is often information
! 616: pertaining to the registers used in this insn.
! 617:
! 618: The `LOG_LINKS' field of an insn is a chain of `insn_list'
! 619: expressions. Each of these has two operands: the first is an insn, and
! 620: the second is another `insn_list' expression (the next one in the
! 621: chain). The last `insn_list' in the chain has a null pointer as second
! 622: operand. The significant thing about the chain is which insns appear
! 623: in it (as first operands of `insn_list' expressions). Their order is
! 624: not significant.
! 625:
! 626: This list is originally set up by the flow analysis pass; it is a
! 627: null pointer until then. Flow only adds links for those data
! 628: dependencies which can be used for instruction combination. For each
! 629: insn, the flow analysis pass adds a link to insns which store into
! 630: registers values that are used for the first time in this insn. The
! 631: instruction scheduling pass adds extra links so that every dependence
! 632: will be represented. Links represent data dependencies,
! 633: antidependencies and output dependencies; the machine mode of the link
! 634: distinguishes these three types: antidependencies have mode
! 635: `REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and
! 636: data dependencies have mode `VOIDmode'.
! 637:
! 638: The `REG_NOTES' field of an insn is a chain similar to the
! 639: `LOG_LINKS' field but it includes `expr_list' expressions in addition
! 640: to `insn_list' expressions. There are several kinds of register notes,
! 641: which are distinguished by the machine mode, which in a register note
! 642: is really understood as being an `enum reg_note'. The first operand OP
! 643: of the note is data whose meaning depends on the kind of note.
! 644:
! 645: The macro `REG_NOTE_KIND (X)' returns the kind of register note.
! 646: Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
! 647: register note type of X to be NEWKIND.
! 648:
! 649: Register notes are of three classes: They may say something about an
! 650: input to an insn, they may say something about an output of an insn, or
! 651: they may create a linkage between two insns. There are also a set of
! 652: values that are only used in `LOG_LINKS'.
! 653:
! 654: These register notes annotate inputs to an insn:
! 655:
! 656: `REG_DEAD'
! 657: The value in OP dies in this insn; that is to say, altering the
! 658: value immediately after this insn would not affect the future
! 659: behavior of the program.
! 660:
! 661: This does not necessarily mean that the register OP has no useful
! 662: value after this insn since it may also be an output of the insn.
! 663: In such a case, however, a `REG_DEAD' note would be redundant and
! 664: is usually not present until after the reload pass, but no code
! 665: relies on this fact.
! 666:
! 667: `REG_INC'
! 668: The register OP is incremented (or decremented; at this level
! 669: there is no distinction) by an embedded side effect inside this
! 670: insn. This means it appears in a `post_inc', `pre_inc',
! 671: `post_dec' or `pre_dec' expression.
! 672:
! 673: `REG_NONNEG'
! 674: The register OP is known to have a nonnegative value when this
! 675: insn is reached. This is used so that decrement and branch until
! 676: zero instructions, such as the m68k dbra, can be matched.
! 677:
! 678: The `REG_NONNEG' note is added to insns only if the machine
! 679: description has a `decrement_and_branch_until_zero' pattern.
! 680:
! 681: `REG_NO_CONFLICT'
! 682: This insn does not cause a conflict between OP and the item being
! 683: set by this insn even though it might appear that it does. In
! 684: other words, if the destination register and OP could otherwise be
! 685: assigned the same register, this insn does not prevent that
! 686: assignment.
! 687:
! 688: Insns with this note are usually part of a block that begins with a
! 689: `clobber' insn specifying a multi-word pseudo register (which will
! 690: be the output of the block), a group of insns that each set one
! 691: word of the value and have the `REG_NO_CONFLICT' note attached,
! 692: and a final insn that copies the output to itself with an attached
! 693: `REG_EQUAL' note giving the expression being computed. This block
! 694: is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the
! 695: first and last insns, respectively.
! 696:
! 697: `REG_LABEL'
! 698: This insn uses OP, a `code_label', but is not a `jump_insn'. The
! 699: presence of this note allows jump optimization to be aware that OP
! 700: is, in fact, being used.
! 701:
! 702: The following notes describe attributes of outputs of an insn:
! 703:
! 704: `REG_EQUIV'
! 705: `REG_EQUAL'
! 706: This note is only valid on an insn that sets only one register and
! 707: indicates that that register will be equal to OP at run time; the
! 708: scope of this equivalence differs between the two types of notes.
! 709: The value which the insn explicitly copies into the register may
! 710: look different from OP, but they will be equal at run time. If the
! 711: output of the single `set' is a `strict_low_part' expression, the
! 712: note refers to the register that is contained in `SUBREG_REG' of
! 713: the `subreg' expression.
! 714:
! 715: For `REG_EQUIV', the register is equivalent to OP throughout the
! 716: entire function, and could validly be replaced in all its
! 717: occurrences by OP. ("Validly" here refers to the data flow of the
! 718: program; simple replacement may make some insns invalid.) For
! 719: example, when a constant is loaded into a register that is never
! 720: assigned any other value, this kind of note is used.
! 721:
! 722: When a parameter is copied into a pseudo-register at entry to a
! 723: function, a note of this kind records that the register is
! 724: equivalent to the stack slot where the parameter was passed.
! 725: Although in this case the register may be set by other insns, it
! 726: is still valid to replace the register by the stack slot
! 727: throughout the function.
! 728:
! 729: In the case of `REG_EQUAL', the register that is set by this insn
! 730: will be equal to OP at run time at the end of this insn but not
! 731: necessarily elsewhere in the function. In this case, OP is
! 732: typically an arithmetic expression. For example, when a sequence
! 733: of insns such as a library call is used to perform an arithmetic
! 734: operation, this kind of note is attached to the insn that produces
! 735: or copies the final value.
! 736:
! 737: These two notes are used in different ways by the compiler passes.
! 738: `REG_EQUAL' is used by passes prior to register allocation (such as
! 739: common subexpression elimination and loop optimization) to tell
! 740: them how to think of that value. `REG_EQUIV' notes are used by
! 741: register allocation to indicate that there is an available
! 742: substitute expression (either a constant or a `mem' expression for
! 743: the location of a parameter on the stack) that may be used in
! 744: place of a register if insufficient registers are available.
! 745:
! 746: Except for stack homes for parameters, which are indicated by a
! 747: `REG_EQUIV' note and are not useful to the early optimization
! 748: passes and pseudo registers that are equivalent to a memory
! 749: location throughout there entire life, which is not detected until
! 750: later in the compilation, all equivalences are initially indicated
! 751: by an attached `REG_EQUAL' note. In the early stages of register
! 752: allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note
! 753: if OP is a constant and the insn represents the only set of its
! 754: destination register.
! 755:
! 756: Thus, compiler passes prior to register allocation need only check
! 757: for `REG_EQUAL' notes and passes subsequent to register allocation
! 758: need only check for `REG_EQUIV' notes.
! 759:
! 760: `REG_UNUSED'
! 761: The register OP being set by this insn will not be used in a
! 762: subsequent insn. This differs from a `REG_DEAD' note, which
! 763: indicates that the value in an input will not be used subsequently.
! 764: These two notes are independent; both may be present for the same
! 765: register.
1.1.1.7 root 766:
1.1.1.8 ! root 767: `REG_WAS_0'
! 768: The single output of this insn contained zero before this insn.
! 769: OP is the insn that set it to zero. You can rely on this note if
! 770: it is present and OP has not been deleted or turned into a `note';
! 771: its absence implies nothing.
! 772:
! 773: These notes describe linkages between insns. They occur in pairs:
! 774: one insn has one of a pair of notes that points to a second insn, which
! 775: has the inverse note pointing back to the first insn.
! 776:
! 777: `REG_RETVAL'
! 778: This insn copies the value of a multi-insn sequence (for example, a
! 779: library call), and OP is the first insn of the sequence (for a
! 780: library call, the first insn that was generated to set up the
! 781: arguments for the library call).
! 782:
! 783: Loop optimization uses this note to treat such a sequence as a
! 784: single operation for code motion purposes and flow analysis uses
! 785: this note to delete such sequences whose results are dead.
! 786:
! 787: A `REG_EQUAL' note will also usually be attached to this insn to
! 788: provide the expression being computed by the sequence.
! 789:
! 790: `REG_LIBCALL'
! 791: This is the inverse of `REG_RETVAL': it is placed on the first
! 792: insn of a multi-insn sequence, and it points to the last one.
! 793:
! 794: `REG_CC_SETTER'
! 795: `REG_CC_USER'
! 796: On machines that use `cc0', the insns which set and use `cc0' set
! 797: and use `cc0' are adjacent. However, when branch delay slot
! 798: filling is done, this may no longer be true. In this case a
! 799: `REG_CC_USER' note will be placed on the insn setting `cc0' to
! 800: point to the insn using `cc0' and a `REG_CC_SETTER' note will be
! 801: placed on the insn using `cc0' to point to the insn setting `cc0'.
! 802:
! 803: These values are only used in the `LOG_LINKS' field, and indicate
! 804: the type of dependency that each link represents. Links which indicate
! 805: a data dependence (a read after write dependence) do not use any code,
! 806: they simply have mode `VOIDmode', and are printed without any
! 807: descriptive text.
! 808:
! 809: `REG_DEP_ANTI'
! 810: This indicates an anti dependence (a write after read dependence).
! 811:
! 812: `REG_DEP_OUTPUT'
! 813: This indicates an output dependence (a write after write
! 814: dependence).
! 815:
! 816: For convenience, the machine mode in an `insn_list' or `expr_list'
! 817: is printed using these symbolic codes in debugging dumps.
! 818:
! 819: The only difference between the expression codes `insn_list' and
! 820: `expr_list' is that the first operand of an `insn_list' is assumed to
! 821: be an insn and is printed in debugging dumps as the insn's unique id;
! 822: the first operand of an `expr_list' is printed in the ordinary way as
! 823: an expression.
1.1.1.3 root 824:
1.1.1.4 root 825:
1.1.1.8 ! root 826: File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
1.1.1.7 root 827:
1.1.1.8 ! root 828: RTL Representation of Function-Call Insns
! 829: =========================================
1.1.1.5 root 830:
1.1.1.8 ! root 831: Insns that call subroutines have the RTL expression code `call_insn'.
! 832: These insns must satisfy special rules, and their bodies must use a
! 833: special RTL expression code, `call'.
! 834:
! 835: A `call' expression has two operands, as follows:
! 836:
! 837: (call (mem:FM ADDR) NBYTES)
! 838:
! 839: Here NBYTES is an operand that represents the number of bytes of
! 840: argument data being passed to the subroutine, FM is a machine mode
! 841: (which must equal as the definition of the `FUNCTION_MODE' macro in the
! 842: machine description) and ADDR represents the address of the subroutine.
! 843:
! 844: For a subroutine that returns no value, the `call' expression as
! 845: shown above is the entire body of the insn, except that the insn might
! 846: also contain `use' or `clobber' expressions.
! 847:
! 848: For a subroutine that returns a value whose mode is not `BLKmode',
! 849: the value is returned in a hard register. If this register's number is
! 850: R, then the body of the call insn looks like this:
! 851:
! 852: (set (reg:M R)
! 853: (call (mem:FM ADDR) NBYTES))
! 854:
! 855: This RTL expression makes it clear (to the optimizer passes) that the
! 856: appropriate register receives a useful value in this insn.
! 857:
! 858: When a subroutine returns a `BLKmode' value, it is handled by
! 859: passing to the subroutine the address of a place to store the value.
! 860: So the call insn itself does not "return" any value, and it has the
! 861: same RTL form as a call that returns nothing.
! 862:
! 863: On some machines, the call instruction itself clobbers some register,
! 864: for example to contain the return address. `call_insn' insns on these
! 865: machines should have a body which is a `parallel' that contains both
! 866: the `call' expression and `clobber' expressions that indicate which
! 867: registers are destroyed. Similarly, if the call instruction requires
! 868: some register other than the stack pointer that is not explicitly
! 869: mentioned it its RTL, a `use' subexpression should mention that
! 870: register.
! 871:
! 872: Functions that are called are assumed to modify all registers listed
! 873: in the configuration macro `CALL_USED_REGISTERS' (*note Register
! 874: Basics::.) and, with the exception of `const' functions and library
! 875: calls, to modify all of memory.
! 876:
! 877: Insns containing just `use' expressions directly precede the
! 878: `call_insn' insn to indicate which registers contain inputs to the
! 879: function. Similarly, if registers other than those in
! 880: `CALL_USED_REGISTERS' are clobbered by the called function, insns
! 881: containing a single `clobber' follow immediately after the call to
! 882: indicate which registers.
1.1.1.3 root 883:
1.1.1.5 root 884:
1.1.1.8 ! root 885: File: gcc.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
1.1.1.7 root 886:
1.1.1.8 ! root 887: Structure Sharing Assumptions
! 888: =============================
1.1.1.7 root 889:
1.1.1.8 ! root 890: The compiler assumes that certain kinds of RTL expressions are
! 891: unique; there do not exist two distinct objects representing the same
! 892: value. In other cases, it makes an opposite assumption: that no RTL
! 893: expression object of a certain kind appears in more than one place in
! 894: the containing structure.
! 895:
! 896: These assumptions refer to a single function; except for the RTL
! 897: objects that describe global variables and external functions, and a
! 898: few standard objects such as small integer constants, no RTL objects
! 899: are common to two functions.
! 900:
! 901: * Each pseudo-register has only a single `reg' object to represent
! 902: it, and therefore only a single machine mode.
! 903:
! 904: * For any symbolic label, there is only one `symbol_ref' object
! 905: referring to it.
! 906:
! 907: * There is only one `const_int' expression with value 0, only one
! 908: with value 1, and only one with value -1. Some other integer
! 909: values are also stored uniquely.
! 910:
! 911: * There is only one `pc' expression.
! 912:
! 913: * There is only one `cc0' expression.
! 914:
! 915: * There is only one `const_double' expression with value 0 for each
! 916: floating point mode. Likewise for values 1 and 2.
! 917:
! 918: * No `label_ref' or `scratch' appears in more than one place in the
! 919: RTL structure; in other words, it is safe to do a tree-walk of all
! 920: the insns in the function and assume that each time a `label_ref'
! 921: or `scratch' is seen it is distinct from all others that are seen.
! 922:
! 923: * Only one `mem' object is normally created for each static variable
! 924: or stack slot, so these objects are frequently shared in all the
! 925: places they appear. However, separate but equal objects for these
! 926: variables are occasionally made.
! 927:
! 928: * When a single `asm' statement has multiple output operands, a
! 929: distinct `asm_operands' expression is made for each output operand.
! 930: However, these all share the vector which contains the sequence of
! 931: input operands. This sharing is used later on to test whether two
! 932: `asm_operands' expressions come from the same statement, so all
! 933: optimizations must carefully preserve the sharing if they copy the
! 934: vector at all.
! 935:
! 936: * No RTL object appears in more than one place in the RTL structure
! 937: except as described above. Many passes of the compiler rely on
! 938: this by assuming that they can modify RTL objects in place without
! 939: unwanted side-effects on other insns.
! 940:
! 941: * During initial RTL generation, shared structure is freely
! 942: introduced. After all the RTL for a function has been generated,
! 943: all shared structure is copied by `unshare_all_rtl' in
! 944: `emit-rtl.c', after which the above rules are guaranteed to be
! 945: followed.
! 946:
! 947: * During the combiner pass, shared structure within an insn can exist
! 948: temporarily. However, the shared structure is copied before the
! 949: combiner is finished with the insn. This is done by calling
! 950: `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.
1.1.1.7 root 951:
1.1.1.8 ! root 952:
! 953: File: gcc.info, Node: Reading RTL, Prev: Sharing, Up: RTL
1.1.1.7 root 954:
1.1.1.8 ! root 955: Reading RTL
! 956: ===========
1.1.1.7 root 957:
1.1.1.8 ! root 958: To read an RTL object from a file, call `read_rtx'. It takes one
! 959: argument, a stdio stream, and returns a single RTL object.
1.1.1.7 root 960:
1.1.1.8 ! root 961: Reading RTL from a file is very slow. This is not currently a
! 962: problem since reading RTL occurs only as part of building the compiler.
1.1.1.7 root 963:
1.1.1.8 ! root 964: People frequently have the idea of using RTL stored as text in a
! 965: file as an interface between a language front end and the bulk of GNU
! 966: CC. This idea is not feasible.
1.1.1.7 root 967:
1.1.1.8 ! root 968: GNU CC was designed to use RTL internally only. Correct RTL for a
! 969: given program is very dependent on the particular target machine. And
! 970: the RTL does not contain all the information about the program.
1.1.1.7 root 971:
1.1.1.8 ! root 972: The proper way to interface GNU CC to a new language front end is
! 973: with the "tree" data structure. There is no manual for this data
! 974: structure, but it is described in the files `tree.h' and `tree.def'.
1.1.1.7 root 975:
1.1.1.8 ! root 976:
! 977: File: gcc.info, Node: Machine Desc, Next: Target Macros, Prev: RTL, Up: Top
1.1.1.7 root 978:
1.1.1.8 ! root 979: Machine Descriptions
! 980: ********************
1.1.1.7 root 981:
1.1.1.8 ! root 982: A machine description has two parts: a file of instruction patterns
! 983: (`.md' file) and a C header file of macro definitions.
1.1.1.7 root 984:
1.1.1.8 ! root 985: The `.md' file for a target machine contains a pattern for each
! 986: instruction that the target machine supports (or at least each
! 987: instruction that is worth telling the compiler about). It may also
! 988: contain comments. A semicolon causes the rest of the line to be a
! 989: comment, unless the semicolon is inside a quoted string.
1.1.1.7 root 990:
1.1.1.8 ! root 991: See the next chapter for information on the C header file.
1.1.1.7 root 992:
1.1.1.8 ! root 993: * Menu:
1.1.1.7 root 994:
1.1.1.8 ! root 995: * Patterns:: How to write instruction patterns.
! 996: * Example:: An explained example of a `define_insn' pattern.
! 997: * RTL Template:: The RTL template defines what insns match a pattern.
! 998: * Output Template:: The output template says how to make assembler code
! 999: from such an insn.
! 1000: * Output Statement:: For more generality, write C code to output
! 1001: the assembler code.
! 1002: * Constraints:: When not all operands are general operands.
! 1003: * Standard Names:: Names mark patterns to use for code generation.
! 1004: * Pattern Ordering:: When the order of patterns makes a difference.
! 1005: * Dependent Patterns:: Having one pattern may make you need another.
! 1006: * Jump Patterns:: Special considerations for patterns for jump insns.
! 1007: * Insn Canonicalizations::Canonicalization of Instructions
! 1008: * Peephole Definitions::Defining machine-specific peephole optimizations.
! 1009: * Expander Definitions::Generating a sequence of several RTL insns
! 1010: for a standard operation.
! 1011: * Insn Splitting:: Splitting Instructions into Multiple Instructions
! 1012: * Insn Attributes:: Specifying the value of attributes for generated insns.
1.1.1.7 root 1013:
1.1.1.8 ! root 1014:
! 1015: File: gcc.info, Node: Patterns, Next: Example, Up: Machine Desc
1.1.1.7 root 1016:
1.1.1.8 ! root 1017: Everything about Instruction Patterns
! 1018: =====================================
1.1.1.7 root 1019:
1.1.1.8 ! root 1020: Each instruction pattern contains an incomplete RTL expression, with
! 1021: pieces to be filled in later, operand constraints that restrict how the
! 1022: pieces can be filled in, and an output pattern or C code to generate
! 1023: the assembler output, all wrapped up in a `define_insn' expression.
! 1024:
! 1025: A `define_insn' is an RTL expression containing four or five
! 1026: operands:
! 1027:
! 1028: 1. An optional name. The presence of a name indicate that this
! 1029: instruction pattern can perform a certain standard job for the
! 1030: RTL-generation pass of the compiler. This pass knows certain
! 1031: names and will use the instruction patterns with those names, if
! 1032: the names are defined in the machine description.
! 1033:
! 1034: The absence of a name is indicated by writing an empty string
! 1035: where the name should go. Nameless instruction patterns are never
! 1036: used for generating RTL code, but they may permit several simpler
! 1037: insns to be combined later on.
! 1038:
! 1039: Names that are not thus known and used in RTL-generation have no
! 1040: effect; they are equivalent to no name at all.
! 1041:
! 1042: 2. The "RTL template" (*note RTL Template::.) is a vector of
! 1043: incomplete RTL expressions which show what the instruction should
! 1044: look like. It is incomplete because it may contain
! 1045: `match_operand', `match_operator', and `match_dup' expressions
! 1046: that stand for operands of the instruction.
! 1047:
! 1048: If the vector has only one element, that element is the template
! 1049: for the instruction pattern. If the vector has multiple elements,
! 1050: then the instruction pattern is a `parallel' expression containing
! 1051: the elements described.
! 1052:
! 1053: 3. A condition. This is a string which contains a C expression that
! 1054: is the final test to decide whether an insn body matches this
! 1055: pattern.
! 1056:
! 1057: For a named pattern, the condition (if present) may not depend on
! 1058: the data in the insn being matched, but only the
! 1059: target-machine-type flags. The compiler needs to test these
! 1060: conditions during initialization in order to learn exactly which
! 1061: named instructions are available in a particular run.
! 1062:
! 1063: For nameless patterns, the condition is applied only when matching
! 1064: an individual insn, and only after the insn has matched the
! 1065: pattern's recognition template. The insn's operands may be found
! 1066: in the vector `operands'.
! 1067:
! 1068: 4. The "output template": a string that says how to output matching
! 1069: insns as assembler code. `%' in this string specifies where to
! 1070: substitute the value of an operand. *Note Output Template::.
1.1.1.7 root 1071:
1.1.1.8 ! root 1072: When simple substitution isn't general enough, you can specify a
! 1073: piece of C code to compute the output. *Note Output Statement::.
1.1.1.7 root 1074:
1.1.1.8 ! root 1075: 5. Optionally, a vector containing the values of attributes for insns
! 1076: matching this pattern. *Note Insn Attributes::.
1.1.1.7 root 1077:
1.1.1.8 ! root 1078:
! 1079: File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
1.1.1.7 root 1080:
1.1.1.8 ! root 1081: Example of `define_insn'
! 1082: ========================
1.1.1.7 root 1083:
1.1.1.8 ! root 1084: Here is an actual example of an instruction pattern, for the
! 1085: 68000/68020.
1.1.1.7 root 1086:
1.1.1.8 ! root 1087: (define_insn "tstsi"
! 1088: [(set (cc0)
! 1089: (match_operand:SI 0 "general_operand" "rm"))]
! 1090: ""
! 1091: "*
! 1092: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
! 1093: return \"tstl %0\";
! 1094: return \"cmpl #0,%0\"; }")
! 1095:
! 1096: This is an instruction that sets the condition codes based on the
! 1097: value of a general operand. It has no condition, so any insn whose RTL
! 1098: description has the form shown may be handled according to this
! 1099: pattern. The name `tstsi' means "test a `SImode' value" and tells the
! 1100: RTL generation pass that, when it is necessary to test such a value, an
! 1101: insn to do so can be constructed using this pattern.
! 1102:
! 1103: The output control string is a piece of C code which chooses which
! 1104: output template to return based on the kind of operand and the specific
! 1105: type of CPU for which code is being generated.
1.1.1.7 root 1106:
1.1.1.8 ! root 1107: `"rm"' is an operand constraint. Its meaning is explained below.
1.1 root 1108:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.