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