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