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