![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-16 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-16 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue 7: Cambridge, MA 02139 USA 8: 1.1.1.7 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, ! 10: Inc. 1.1 root 11: 1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 1.1 root 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.7 ! root 18: that the sections entitled "GNU General Public License," "Funding for ! 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are ! 20: included exactly as in the original, and provided that the entire ! 21: resulting derived work is distributed under the terms of a permission ! 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public 1.1.1.7 ! root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight ! 28: `Look And Feel'", and this permission notice, may be included in ! 29: translations approved by the Free Software Foundation instead of in the ! 30: original English. 1.1.1.4 root 31: 32: 1.1.1.7 ! root 33: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 1.1.1.4 root 34: 1.1.1.7 ! root 35: Standard Pattern Names For Generation ! 36: ===================================== 1.1.1.5 root 37: 1.1.1.7 ! root 38: Here is a table of the instruction names that are meaningful in the ! 39: RTL generation pass of the compiler. Giving one of these names to an ! 40: instruction pattern tells the RTL generation pass that it can use the ! 41: pattern in to accomplish a certain task. ! 42: ! 43: `movM' ! 44: Here M stands for a two-letter machine mode name, in lower case. ! 45: This instruction pattern moves data with that machine mode from ! 46: operand 1 to operand 0. For example, `movsi' moves full-word data. ! 47: ! 48: If operand 0 is a `subreg' with mode M of a register whose own ! 49: mode is wider than M, the effect of this instruction is to store ! 50: the specified value in the part of the register that corresponds ! 51: to mode M. The effect on the rest of the register is undefined. ! 52: ! 53: This class of patterns is special in several ways. First of all, ! 54: each of these names *must* be defined, because there is no other ! 55: way to copy a datum from one place to another. ! 56: ! 57: Second, these patterns are not used solely in the RTL generation ! 58: pass. Even the reload pass can generate move insns to copy values ! 59: from stack slots into temporary registers. When it does so, one ! 60: of the operands is a hard register and the other is an operand ! 61: that can need to be reloaded into a register. ! 62: ! 63: Therefore, when given such a pair of operands, the pattern must ! 64: generate RTL which needs no reloading and needs no temporary ! 65: registers--no registers other than the operands. For example, if ! 66: you support the pattern with a `define_expand', then in such a ! 67: case the `define_expand' mustn't call `force_reg' or any other such ! 68: function which might generate new pseudo registers. ! 69: ! 70: This requirement exists even for subword modes on a RISC machine ! 71: where fetching those modes from memory normally requires several ! 72: insns and some temporary registers. Look in `spur.md' to see how ! 73: the requirement can be satisfied. ! 74: ! 75: During reload a memory reference with an invalid address may be ! 76: passed as an operand. Such an address will be replaced with a ! 77: valid address later in the reload pass. In this case, nothing may ! 78: be done with the address except to use it as it stands. If it is ! 79: copied, it will not be replaced with a valid address. No attempt ! 80: should be made to make such an address into a valid address and no ! 81: routine (such as `change_address') that will do so may be called. ! 82: Note that `general_operand' will fail when applied to such an ! 83: address. ! 84: ! 85: The global variable `reload_in_progress' (which must be explicitly ! 86: declared if required) can be used to determine whether such special ! 87: handling is required. ! 88: ! 89: The variety of operands that have reloads depends on the rest of ! 90: the machine description, but typically on a RISC machine these can ! 91: only be pseudo registers that did not get hard registers, while on ! 92: other machines explicit memory references will get optional ! 93: reloads. ! 94: ! 95: If a scratch register is required to move an object to or from ! 96: memory, it can be allocated using `gen_reg_rtx' prior to reload. ! 97: But this is impossible during and after reload. If there are ! 98: cases needing scratch registers after reload, you must define ! 99: `SECONDARY_INPUT_RELOAD_CLASS' and perhaps also ! 100: `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide ! 101: patterns `reload_inM' or `reload_outM' to handle them. *Note ! 102: Register Classes::. ! 103: ! 104: The constraints on a `moveM' must permit moving any hard register ! 105: to any other hard register provided that `HARD_REGNO_MODE_OK' ! 106: permits mode M in both registers and `REGISTER_MOVE_COST' applied ! 107: to their classes returns a value of 2. ! 108: ! 109: It is obligatory to support floating point `moveM' instructions ! 110: into and out of any registers that can hold fixed point values, ! 111: because unions and structures (which have modes `SImode' or ! 112: `DImode') can be in those registers and they may have floating ! 113: point members. ! 114: ! 115: There may also be a need to support fixed point `moveM' ! 116: instructions in and out of floating point registers. ! 117: Unfortunately, I have forgotten why this was so, and I don't know ! 118: whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed ! 119: point values in floating point registers, then the constraints of ! 120: the fixed point `moveM' instructions must be designed to avoid ! 121: ever trying to reload into a floating point register. ! 122: ! 123: `reload_inM' ! 124: `reload_outM' ! 125: Like `movM', but used when a scratch register is required to move ! 126: between operand 0 and operand 1. Operand 2 describes the scratch ! 127: register. See the discussion of the `SECONDARY_RELOAD_CLASS' ! 128: macro in *note Register Classes::.. ! 129: ! 130: `movstrictM' ! 131: Like `movM' except that if operand 0 is a `subreg' with mode M of ! 132: a register whose natural mode is wider, the `movstrictM' ! 133: instruction is guaranteed not to alter any of the register except ! 134: the part which belongs to mode M. ! 135: ! 136: `load_multiple' ! 137: Load several consecutive memory locations into consecutive ! 138: registers. Operand 0 is the first of the consecutive registers, ! 139: operand 1 is the first memory location, and operand 2 is a ! 140: constant: the number of consecutive registers. ! 141: ! 142: Define this only if the target machine really has such an ! 143: instruction; do not define this if the most efficient way of ! 144: loading consecutive registers from memory is to do them one at a ! 145: time. ! 146: ! 147: On some machines, there are restrictions as to which consecutive ! 148: registers can be stored into memory, such as particular starting or ! 149: ending register numbers or only a range of valid counts. For those ! 150: machines, use a `define_expand' (*note Expander Definitions::.) ! 151: and make the pattern fail if the restrictions are not met. ! 152: ! 153: Write the generated insn as a `parallel' with elements being a ! 154: `set' of one register from the appropriate memory location (you may ! 155: also need `use' or `clobber' elements). Use a `match_parallel' ! 156: (*note RTL Template::.) to recognize the insn. See `a29k.md' and ! 157: `rs6000.md' for examples of the use of this insn pattern. ! 158: ! 159: `store_multiple' ! 160: Similar to `load_multiple', but store several consecutive registers ! 161: into consecutive memory locations. Operand 0 is the first of the ! 162: consecutive memory locations, operand 1 is the first register, and ! 163: operand 2 is a constant: the number of consecutive registers. ! 164: ! 165: `addM3' ! 166: Add operand 2 and operand 1, storing the result in operand 0. All ! 167: operands must have mode M. This can be used even on two-address ! 168: machines, by means of constraints requiring operands 1 and 0 to be ! 169: the same location. ! 170: ! 171: `subM3', `mulM3' ! 172: `divM3', `udivM3', `modM3', `umodM3' ! 173: `sminM3', `smaxM3', `uminM3', `umaxM3' ! 174: `andM3', `iorM3', `xorM3' ! 175: Similar, for other arithmetic operations. ! 176: ! 177: `mulhisi3' ! 178: Multiply operands 1 and 2, which have mode `HImode', and store a ! 179: `SImode' product in operand 0. ! 180: ! 181: `mulqihi3', `mulsidi3' ! 182: Similar widening-multiplication instructions of other widths. ! 183: ! 184: `umulqihi3', `umulhisi3', `umulsidi3' ! 185: Similar widening-multiplication instructions that do unsigned ! 186: multiplication. ! 187: ! 188: `divmodM4' ! 189: Signed division that produces both a quotient and a remainder. ! 190: Operand 1 is divided by operand 2 to produce a quotient stored in ! 191: operand 0 and a remainder stored in operand 3. ! 192: ! 193: For machines with an instruction that produces both a quotient and ! 194: a remainder, provide a pattern for `divmodM4' but do not provide ! 195: patterns for `divM3' and `modM3'. This allows optimization in the ! 196: relatively common case when both the quotient and remainder are ! 197: computed. ! 198: ! 199: If an instruction that just produces a quotient or just a remainder ! 200: exists and is more efficient than the instruction that produces ! 201: both, write the output routine of `divmodM4' to call ! 202: `find_reg_note' and look for a `REG_UNUSED' note on the quotient ! 203: or remainder and generate the appropriate instruction. ! 204: ! 205: `udivmodM4' ! 206: Similar, but does unsigned division. ! 207: ! 208: `ashlM3' ! 209: Arithmetic-shift operand 1 left by a number of bits specified by ! 210: operand 2, and store the result in operand 0. Here M is the mode ! 211: of operand 0 and operand 1; operand 2's mode is specified by the ! 212: instruction pattern, and the compiler will convert the operand to ! 213: that mode before generating the instruction. ! 214: ! 215: `ashrM3', `lshrM3', `rotlM3', `rotrM3' ! 216: Other shift and rotate instructions, analogous to the `ashlM3' ! 217: instructions. ! 218: ! 219: `negM2' ! 220: Negate operand 1 and store the result in operand 0. ! 221: ! 222: `absM2' ! 223: Store the absolute value of operand 1 into operand 0. ! 224: ! 225: `sqrtM2' ! 226: Store the square root of operand 1 into operand 0. ! 227: ! 228: The `sqrt' built-in function of C always uses the mode which ! 229: corresponds to the C data type `double'. ! 230: ! 231: `ffsM2' ! 232: Store into operand 0 one plus the index of the least significant ! 233: 1-bit of operand 1. If operand 1 is zero, store zero. M is the ! 234: mode of operand 0; operand 1's mode is specified by the instruction ! 235: pattern, and the compiler will convert the operand to that mode ! 236: before generating the instruction. ! 237: ! 238: The `ffs' built-in function of C always uses the mode which ! 239: corresponds to the C data type `int'. ! 240: ! 241: `one_cmplM2' ! 242: Store the bitwise-complement of operand 1 into operand 0. ! 243: ! 244: `cmpM' ! 245: Compare operand 0 and operand 1, and set the condition codes. The ! 246: RTL pattern should look like this: ! 247: ! 248: (set (cc0) (compare (match_operand:M 0 ...) ! 249: (match_operand:M 1 ...))) ! 250: ! 251: `tstM' ! 252: Compare operand 0 against zero, and set the condition codes. The ! 253: RTL pattern should look like this: ! 254: ! 255: (set (cc0) (match_operand:M 0 ...)) ! 256: ! 257: `tstM' patterns should not be defined for machines that do not use ! 258: `(cc0)'. Doing so would confuse the optimizer since it would no ! 259: longer be clear which `set' operations were comparisons. The ! 260: `cmpM' patterns should be used instead. ! 261: ! 262: `movstrM' ! 263: Block move instruction. The addresses of the destination and ! 264: source strings are the first two operands, and both are in mode ! 265: `Pmode'. The number of bytes to move is the third operand, in ! 266: mode M. ! 267: ! 268: The fourth operand is the known shared alignment of the source and ! 269: destination, in the form of a `const_int' rtx. Thus, if the ! 270: compiler knows that both source and destination are word-aligned, ! 271: it may provide the value 4 for this operand. ! 272: ! 273: These patterns need not give special consideration to the ! 274: possibility that the source and destination strings might overlap. ! 275: ! 276: `cmpstrM' ! 277: Block compare instruction, with five operands. Operand 0 is the ! 278: output; it has mode M. The remaining four operands are like the ! 279: operands of `movstrM'. The two memory blocks specified are ! 280: compared byte by byte in lexicographic order. The effect of the ! 281: instruction is to store a value in operand 0 whose sign indicates ! 282: the result of the comparison. ! 283: ! 284: Compute the length of a string, with three operands. Operand 0 is ! 285: the result (of mode M), operand 1 is a `mem' referring to the ! 286: first character of the string, operand 2 is the character to ! 287: search for (normally zero), and operand 3 is a constant describing ! 288: the known alignment of the beginning of the string. ! 289: ! 290: `floatMN2' ! 291: Convert signed integer operand 1 (valid for fixed point mode M) to ! 292: floating point mode N and store in operand 0 (which has mode N). ! 293: ! 294: `floatunsMN2' ! 295: Convert unsigned integer operand 1 (valid for fixed point mode M) ! 296: to floating point mode N and store in operand 0 (which has mode N). ! 297: ! 298: `fixMN2' ! 299: Convert operand 1 (valid for floating point mode M) to fixed point ! 300: mode N as a signed number and store in operand 0 (which has mode ! 301: N). This instruction's result is defined only when the value of ! 302: operand 1 is an integer. ! 303: ! 304: `fixunsMN2' ! 305: Convert operand 1 (valid for floating point mode M) to fixed point ! 306: mode N as an unsigned number and store in operand 0 (which has ! 307: mode N). This instruction's result is defined only when the value ! 308: of operand 1 is an integer. ! 309: ! 310: `ftruncM2' ! 311: Convert operand 1 (valid for floating point mode M) to an integer ! 312: value, still represented in floating point mode M, and store it in ! 313: operand 0 (valid for floating point mode M). ! 314: ! 315: `fix_truncMN2' ! 316: Like `fixMN2' but works for any floating point value of mode M by ! 317: converting the value to an integer. ! 318: ! 319: `fixuns_truncMN2' ! 320: Like `fixunsMN2' but works for any floating point value of mode M ! 321: by converting the value to an integer. ! 322: ! 323: `truncMN' ! 324: Truncate operand 1 (valid for mode M) to mode N and store in ! 325: operand 0 (which has mode N). Both modes must be fixed point or ! 326: both floating point. ! 327: ! 328: `extendMN' ! 329: Sign-extend operand 1 (valid for mode M) to mode N and store in ! 330: operand 0 (which has mode N). Both modes must be fixed point or ! 331: both floating point. ! 332: ! 333: `zero_extendMN' ! 334: Zero-extend operand 1 (valid for mode M) to mode N and store in ! 335: operand 0 (which has mode N). Both modes must be fixed point. ! 336: ! 337: `extv' ! 338: Extract a bit field from operand 1 (a register or memory operand), ! 339: where operand 2 specifies the width in bits and operand 3 the ! 340: starting bit, and store it in operand 0. Operand 0 must have mode ! 341: `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; ! 342: often `word_mode' is allowed only for registers. Operands 2 and 3 ! 343: must be valid for `word_mode'. ! 344: ! 345: The RTL generation pass generates this instruction only with ! 346: constants for operands 2 and 3. ! 347: ! 348: The bit-field value is sign-extended to a full word integer before ! 349: it is stored in operand 0. ! 350: ! 351: `extzv' ! 352: Like `extv' except that the bit-field value is zero-extended. ! 353: ! 354: `insv' ! 355: Store operand 3 (which must be valid for `word_mode') into a bit ! 356: field in operand 0, where operand 1 specifies the width in bits and ! 357: operand 2 the starting bit. Operand 0 may have mode `byte_mode' or ! 358: `word_mode'; often `word_mode' is allowed only for registers. ! 359: Operands 1 and 2 must be valid for `word_mode'. ! 360: ! 361: The RTL generation pass generates this instruction only with ! 362: constants for operands 1 and 2. ! 363: ! 364: `sCOND' ! 365: Store zero or nonzero in the operand according to the condition ! 366: codes. Value stored is nonzero iff the condition COND is true. ! 367: cOND is the name of a comparison operation expression code, such ! 368: as `eq', `lt' or `leu'. ! 369: ! 370: You specify the mode that the operand must have when you write the ! 371: `match_operand' expression. The compiler automatically sees which ! 372: mode you have used and supplies an operand of that mode. ! 373: ! 374: The value stored for a true condition must have 1 as its low bit, ! 375: or else must be negative. Otherwise the instruction is not ! 376: suitable and you should omit it from the machine description. You ! 377: describe to the compiler exactly which value is stored by defining ! 378: the macro `STORE_FLAG_VALUE' (*note Misc::.). If a description ! 379: cannot be found that can be used for all the `sCOND' patterns, you ! 380: should omit those operations from the machine description. ! 381: ! 382: These operations may fail, but should do so only in relatively ! 383: uncommon cases; if they would fail for common cases involving ! 384: integer comparisons, it is best to omit these patterns. ! 385: ! 386: If these operations are omitted, the compiler will usually ! 387: generate code that copies the constant one to the target and ! 388: branches around an assignment of zero to the target. If this code ! 389: is more efficient than the potential instructions used for the ! 390: `sCOND' pattern followed by those required to convert the result ! 391: into a 1 or a zero in `SImode', you should omit the `sCOND' ! 392: operations from the machine description. ! 393: ! 394: `bCOND' ! 395: Conditional branch instruction. Operand 0 is a `label_ref' that ! 396: refers to the label to jump to. Jump if the condition codes meet ! 397: condition COND. ! 398: ! 399: Some machines do not follow the model assumed here where a ! 400: comparison instruction is followed by a conditional branch ! 401: instruction. In that case, the `cmpM' (and `tstM') patterns should ! 402: simply store the operands away and generate all the required insns ! 403: in a `define_expand' (*note Expander Definitions::.) for the ! 404: conditional branch operations. All calls to expand `bCOND' ! 405: patterns are immediately preceded by calls to expand either a ! 406: `cmpM' pattern or a `tstM' pattern. ! 407: ! 408: Machines that use a pseudo register for the condition code value, ! 409: or where the mode used for the comparison depends on the condition ! 410: being tested, should also use the above mechanism. *Note Jump ! 411: Patterns:: ! 412: ! 413: The above discussion also applies to `sCOND' patterns. ! 414: ! 415: `call' ! 416: Subroutine call instruction returning no value. Operand 0 is the ! 417: function to call; operand 1 is the number of bytes of arguments ! 418: pushed (in mode `SImode', except it is normally a `const_int'); ! 419: operand 2 is the number of registers used as operands. ! 420: ! 421: On most machines, operand 2 is not actually stored into the RTL ! 422: pattern. It is supplied for the sake of some RISC machines which ! 423: need to put this information into the assembler code; they can put ! 424: it in the RTL instead of operand 1. ! 425: ! 426: Operand 0 should be a `mem' RTX whose address is the address of the ! 427: function. Note, however, that this address can be a `symbol_ref' ! 428: expression even if it would not be a legitimate memory address on ! 429: the target machine. If it is also not a valid argument for a call ! 430: instruction, the pattern for this operation should be a ! 431: `define_expand' (*note Expander Definitions::.) that places the ! 432: address into a register and uses that register in the call ! 433: instruction. ! 434: ! 435: `call_value' ! 436: Subroutine call instruction returning a value. Operand 0 is the ! 437: hard register in which the value is returned. There are three more ! 438: operands, the same as the three operands of the `call' instruction ! 439: (but with numbers increased by one). ! 440: ! 441: Subroutines that return `BLKmode' objects use the `call' insn. ! 442: ! 443: `call_pop', `call_value_pop' ! 444: Similar to `call' and `call_value', except used if defined and if ! 445: `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' ! 446: that contains both the function call and a `set' to indicate the ! 447: adjustment made to the frame pointer. ! 448: ! 449: For machines where `RETURN_POPS_ARGS' can be non-zero, the use of ! 450: these patterns increases the number of functions for which the ! 451: frame pointer can be eliminated, if desired. ! 452: ! 453: `untyped_call' ! 454: Subroutine call instruction returning a value of any type. ! 455: Operand 0 is the function to call; operand 1 is a memory location ! 456: where the result of calling the function is to be stored; operand ! 457: 2 is a `parallel' expression where each element is a `set' ! 458: expression that indicates the saving of a function return value ! 459: into the result block. ! 460: ! 461: This instruction pattern should be defined to support ! 462: `__builtin_apply' on machines where special instructions are needed ! 463: to call a subroutine with arbitrary arguments or to save the value ! 464: returned. This instruction pattern is required on machines that ! 465: have multiple registers that can hold a return value (i.e. ! 466: `FUNCTION_VALUE_REGNO_P' is true for more than one register). ! 467: ! 468: `return' ! 469: Subroutine return instruction. This instruction pattern name ! 470: should be defined only if a single instruction can do all the work ! 471: of returning from a function. ! 472: ! 473: Like the `movM' patterns, this pattern is also used after the RTL ! 474: generation phase. In this case it is to support machines where ! 475: multiple instructions are usually needed to return from a ! 476: function, but some class of functions only requires one ! 477: instruction to implement a return. Normally, the applicable ! 478: functions are those which do not need to save any registers or ! 479: allocate stack space. ! 480: ! 481: For such machines, the condition specified in this pattern should ! 482: only be true when `reload_completed' is non-zero and the function's ! 483: epilogue would only be a single instruction. For machines with ! 484: register windows, the routine `leaf_function_p' may be used to ! 485: determine if a register window push is required. ! 486: ! 487: Machines that have conditional return instructions should define ! 488: patterns such as ! 489: ! 490: (define_insn "" ! 491: [(set (pc) ! 492: (if_then_else (match_operator ! 493: 0 "comparison_operator" ! 494: [(cc0) (const_int 0)]) ! 495: (return) ! 496: (pc)))] ! 497: "CONDITION" ! 498: "...") ! 499: ! 500: where CONDITION would normally be the same condition specified on ! 501: the named `return' pattern. ! 502: ! 503: `untyped_return' ! 504: Untyped subroutine return instruction. This instruction pattern ! 505: should be defined to support `__builtin_return' on machines where ! 506: special instructions are needed to return a value of any type. ! 507: ! 508: Operand 0 is a memory location where the result of calling a ! 509: function with `__builtin_apply' is stored; operand 1 is a ! 510: `parallel' expression where each element is a `set' expression ! 511: that indicates the restoring of a function return value from the ! 512: result block. ! 513: ! 514: `nop' ! 515: No-op instruction. This instruction pattern name should always be ! 516: defined to output a no-op in assembler code. `(const_int 0)' will ! 517: do as an RTL pattern. ! 518: ! 519: `indirect_jump' ! 520: An instruction to jump to an address which is operand zero. This ! 521: pattern name is mandatory on all machines. ! 522: ! 523: `casesi' ! 524: Instruction to jump through a dispatch table, including bounds ! 525: checking. This instruction takes five operands: ! 526: ! 527: 1. The index to dispatch on, which has mode `SImode'. ! 528: ! 529: 2. The lower bound for indices in the table, an integer constant. ! 530: ! 531: 3. The total range of indices in the table--the largest index ! 532: minus the smallest one (both inclusive). ! 533: ! 534: 4. A label that precedes the table itself. ! 535: ! 536: 5. A label to jump to if the index has a value outside the ! 537: bounds. (If the machine-description macro ! 538: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index ! 539: drops through to the code following the jump table instead of ! 540: jumping to this label. In that case, this label is not ! 541: actually used by the `casesi' instruction, but it is always ! 542: provided as an operand.) ! 543: ! 544: The table is a `addr_vec' or `addr_diff_vec' inside of a ! 545: `jump_insn'. The number of elements in the table is one plus the ! 546: difference between the upper bound and the lower bound. ! 547: ! 548: `tablejump' ! 549: Instruction to jump to a variable address. This is a low-level ! 550: capability which can be used to implement a dispatch table when ! 551: there is no `casesi' pattern. ! 552: ! 553: This pattern requires two operands: the address or offset, and a ! 554: label which should immediately precede the jump table. If the ! 555: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand ! 556: is an offset which counts from the address of the table; ! 557: otherwise, it is an absolute address to jump to. In either case, ! 558: the first operand has mode `Pmode'. ! 559: ! 560: The `tablejump' insn is always the last insn before the jump table ! 561: it uses. Its assembler code normally has no need to use the ! 562: second operand, but you should incorporate it in the RTL pattern so ! 563: that the jump optimizer will not delete the table as unreachable ! 564: code. ! 565: ! 566: `save_stack_block' ! 567: `save_stack_function' ! 568: `save_stack_nonlocal' ! 569: `restore_stack_block' ! 570: `restore_stack_function' ! 571: `restore_stack_nonlocal' ! 572: Most machines save and restore the stack pointer by copying it to ! 573: or from an object of mode `Pmode'. Do not define these patterns on ! 574: such machines. ! 575: ! 576: Some machines require special handling for stack pointer saves and ! 577: restores. On those machines, define the patterns corresponding to ! 578: the non-standard cases by using a `define_expand' (*note Expander ! 579: Definitions::.) that produces the required insns. The three types ! 580: of saves and restores are: ! 581: ! 582: 1. `save_stack_block' saves the stack pointer at the start of a ! 583: block that allocates a variable-sized object, and ! 584: `restore_stack_block' restores the stack pointer when the ! 585: block is exited. ! 586: ! 587: 2. `save_stack_function' and `restore_stack_function' do a ! 588: similar job for the outermost block of a function and are ! 589: used when the function allocates variable-sized objects or ! 590: calls `alloca'. Only the epilogue uses the restored stack ! 591: pointer, allowing a simpler save or restore sequence on some ! 592: machines. ! 593: ! 594: 3. `save_stack_nonlocal' is used in functions that contain labels ! 595: branched to by nested functions. It saves the stack pointer ! 596: in such a way that the inner function can use ! 597: `restore_stack_nonlocal' to restore the stack pointer. The ! 598: compiler generates code to restore the frame and argument ! 599: pointer registers, but some machines require saving and ! 600: restoring additional data such as register window information ! 601: or stack backchains. Place insns in these patterns to save ! 602: and restore any such required data. ! 603: ! 604: When saving the stack pointer, operand 0 is the save area and ! 605: operand 1 is the stack pointer. The mode used to allocate the ! 606: save area is the mode of operand 0. You must specify an integral ! 607: mode, or `VOIDmode' if no save area is needed for a particular ! 608: type of save (either because no save is needed or because a ! 609: machine-specific save area can be used). Operand 0 is the stack ! 610: pointer and operand 1 is the save area for restore operations. If ! 611: `save_stack_block' is defined, operand 0 must not be `VOIDmode' ! 612: since these saves can be arbitrarily nested. ! 613: ! 614: A save area is a `mem' that is at a constant offset from ! 615: `virtual_stack_vars_rtx' when the stack pointer is saved for use by ! 616: nonlocal gotos and a `reg' in the other two cases. ! 617: ! 618: `allocate_stack' ! 619: Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 0 ! 620: from the stack pointer to create space for dynamically allocated ! 621: data. ! 622: ! 623: Do not define this pattern if all that must be done is the ! 624: subtraction. Some machines require other operations such as stack ! 625: probes or maintaining the back chain. Define this pattern to emit ! 626: those operations in addition to updating the stack pointer. 1.1.1.5 root 627: 1.1.1.6 root 628: 1.1.1.7 ! root 629: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 1.1.1.4 root 630: 1.1.1.7 ! root 631: When the Order of Patterns Matters 1.1.1.6 root 632: ================================== 1.1.1.4 root 633: 1.1.1.7 ! root 634: Sometimes an insn can match more than one instruction pattern. Then ! 635: the pattern that appears first in the machine description is the one ! 636: used. Therefore, more specific patterns (patterns that will match ! 637: fewer things) and faster instructions (those that will produce better ! 638: code when they do match) should usually go first in the description. ! 639: ! 640: In some cases the effect of ordering the patterns can be used to hide ! 641: a pattern when it is not valid. For example, the 68000 has an ! 642: instruction for converting a fullword to floating point and another for ! 643: converting a byte to floating point. An instruction converting an ! 644: integer to floating point could match either one. We put the pattern ! 645: to convert the fullword first to make sure that one will be used rather ! 646: than the other. (Otherwise a large integer might be generated as a ! 647: single-byte immediate quantity, which would not work.) Instead of using ! 648: this pattern ordering it would be possible to make the pattern for ! 649: convert-a-byte smart enough to deal properly with any constant value. 1.1.1.4 root 650: 651: 1.1.1.7 ! root 652: File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 1.1.1.5 root 653: 1.1.1.7 ! root 654: Interdependence of Patterns ! 655: =========================== 1.1.1.4 root 656: 1.1.1.7 ! root 657: Every machine description must have a named pattern for each of the ! 658: conditional branch names `bCOND'. The recognition template must always ! 659: have the form ! 660: ! 661: (set (pc) ! 662: (if_then_else (COND (cc0) (const_int 0)) ! 663: (label_ref (match_operand 0 "" "")) ! 664: (pc))) ! 665: ! 666: In addition, every machine description must have an anonymous pattern ! 667: for each of the possible reverse-conditional branches. Their templates ! 668: look like ! 669: ! 670: (set (pc) ! 671: (if_then_else (COND (cc0) (const_int 0)) ! 672: (pc) ! 673: (label_ref (match_operand 0 "" "")))) ! 674: ! 675: They are necessary because jump optimization can turn direct-conditional ! 676: branches into reverse-conditional branches. ! 677: ! 678: It is often convenient to use the `match_operator' construct to ! 679: reduce the number of patterns that must be specified for branches. For ! 680: example, 1.1.1.4 root 681: 1.1.1.7 ! root 682: (define_insn "" ! 683: [(set (pc) ! 684: (if_then_else (match_operator 0 "comparison_operator" ! 685: [(cc0) (const_int 0)]) ! 686: (pc) ! 687: (label_ref (match_operand 1 "" ""))))] ! 688: "CONDITION" ! 689: "...") 1.1.1.6 root 690: 1.1.1.7 ! root 691: In some cases machines support instructions identical except for the ! 692: machine mode of one or more operands. For example, there may be ! 693: "sign-extend halfword" and "sign-extend byte" instructions whose ! 694: patterns are 1.1.1.6 root 695: 1.1.1.7 ! root 696: (set (match_operand:SI 0 ...) ! 697: (extend:SI (match_operand:HI 1 ...))) 1.1.1.6 root 698: 1.1.1.7 ! root 699: (set (match_operand:SI 0 ...) ! 700: (extend:SI (match_operand:QI 1 ...))) 1.1.1.6 root 701: 1.1.1.7 ! root 702: Constant integers do not specify a machine mode, so an instruction to ! 703: extend a constant value could match either pattern. The pattern it ! 704: actually will match is the one that appears first in the file. For ! 705: correct results, this must be the one for the widest possible mode ! 706: (`HImode', here). If the pattern matches the `QImode' instruction, the ! 707: results will be incorrect if the constant value does not actually fit ! 708: that mode. ! 709: ! 710: Such instructions to extend constants are rarely generated because ! 711: they are optimized away, but they do occasionally happen in nonoptimized ! 712: compilations. ! 713: ! 714: If a constraint in a pattern allows a constant, the reload pass may ! 715: replace a register with a constant permitted by the constraint in some ! 716: cases. Similarly for memory references. You must ensure that the ! 717: predicate permits all objects allowed by the constraints to prevent the ! 718: compiler from crashing. ! 719: ! 720: Because of this substitution, you should not provide separate ! 721: patterns for increment and decrement instructions. Instead, they ! 722: should be generated from the same pattern that supports ! 723: register-register add insns by examining the operands and generating ! 724: the appropriate machine instruction. 1.1.1.4 root 725: 726: 1.1.1.7 ! root 727: File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc 1.1.1.4 root 728: 1.1.1.7 ! root 729: Defining Jump Instruction Patterns ! 730: ================================== 1.1.1.6 root 731: 1.1.1.7 ! root 732: For most machines, GNU CC assumes that the machine has a condition ! 733: code. A comparison insn sets the condition code, recording the results ! 734: of both signed and unsigned comparison of the given operands. A ! 735: separate branch insn tests the condition code and branches or not ! 736: according its value. The branch insns come in distinct signed and ! 737: unsigned flavors. Many common machines, such as the Vax, the 68000 and ! 738: the 32000, work this way. ! 739: ! 740: Some machines have distinct signed and unsigned compare ! 741: instructions, and only one set of conditional branch instructions. The ! 742: easiest way to handle these machines is to treat them just like the ! 743: others until the final stage where assembly code is written. At this ! 744: time, when outputting code for the compare instruction, peek ahead at ! 745: the following branch using `next_cc0_user (insn)'. (The variable ! 746: `insn' refers to the insn being output, in the output-writing code in ! 747: an instruction pattern.) If the RTL says that is an unsigned branch, ! 748: output an unsigned compare; otherwise output a signed compare. When ! 749: the branch itself is output, you can treat signed and unsigned branches ! 750: identically. ! 751: ! 752: The reason you can do this is that GNU CC always generates a pair of ! 753: consecutive RTL insns, possibly separated by `note' insns, one to set ! 754: the condition code and one to test it, and keeps the pair inviolate ! 755: until the end. ! 756: ! 757: To go with this technique, you must define the machine-description ! 758: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no ! 759: compare instruction is superfluous. ! 760: ! 761: Some machines have compare-and-branch instructions and no condition ! 762: code. A similar technique works for them. When it is time to "output" ! 763: a compare instruction, record its operands in two static variables. ! 764: When outputting the branch-on-condition-code instruction that follows, ! 765: actually output a compare-and-branch instruction that uses the ! 766: remembered operands. ! 767: ! 768: It also works to define patterns for compare-and-branch instructions. ! 769: In optimizing compilation, the pair of compare and branch instructions ! 770: will be combined according to these patterns. But this does not happen ! 771: if optimization is not requested. So you must use one of the solutions ! 772: above in addition to any special patterns you define. ! 773: ! 774: In many RISC machines, most instructions do not affect the condition ! 775: code and there may not even be a separate condition code register. On ! 776: these machines, the restriction that the definition and use of the ! 777: condition code be adjacent insns is not necessary and can prevent ! 778: important optimizations. For example, on the IBM RS/6000, there is a ! 779: delay for taken branches unless the condition code register is set three ! 780: instructions earlier than the conditional branch. The instruction ! 781: scheduler cannot perform this optimization if it is not permitted to ! 782: separate the definition and use of the condition code register. ! 783: ! 784: On these machines, do not use `(cc0)', but instead use a register to ! 785: represent the condition code. If there is a specific condition code ! 786: register in the machine, use a hard register. If the condition code or ! 787: comparison result can be placed in any general register, or if there are ! 788: multiple condition registers, use a pseudo register. ! 789: ! 790: On some machines, the type of branch instruction generated may ! 791: depend on the way the condition code was produced; for example, on the ! 792: 68k and Sparc, setting the condition code directly from an add or ! 793: subtract instruction does not clear the overflow bit the way that a test ! 794: instruction does, so a different branch instruction must be used for ! 795: some conditional branches. For machines that use `(cc0)', the set and ! 796: use of the condition code must be adjacent (separated only by `note' ! 797: insns) allowing flags in `cc_status' to be used. (*Note Condition ! 798: Code::.) Also, the comparison and branch insns can be located from ! 799: each other by using the functions `prev_cc0_setter' and `next_cc0_user'. ! 800: ! 801: However, this is not true on machines that do not use `(cc0)'. On ! 802: those machines, no assumptions can be made about the adjacency of the ! 803: compare and branch insns and the above methods cannot be used. Instead, ! 804: we use the machine mode of the condition code register to record ! 805: different formats of the condition code register. ! 806: ! 807: Registers used to store the condition code value should have a mode ! 808: that is in class `MODE_CC'. Normally, it will be `CCmode'. If ! 809: additional modes are required (as for the add example mentioned above in ! 810: the Sparc), define the macro `EXTRA_CC_MODES' to list the additional ! 811: modes required (*note Condition Code::.). Also define `EXTRA_CC_NAMES' ! 812: to list the names of those modes and `SELECT_CC_MODE' to choose a mode ! 813: given an operand of a compare. ! 814: ! 815: If it is known during RTL generation that a different mode will be ! 816: required (for example, if the machine has separate compare instructions ! 817: for signed and unsigned quantities, like most IBM processors), they can ! 818: be specified at that time. ! 819: ! 820: If the cases that require different modes would be made by ! 821: instruction combination, the macro `SELECT_CC_MODE' determines which ! 822: machine mode should be used for the comparison result. The patterns ! 823: should be written using that mode. To support the case of the add on ! 824: the Sparc discussed above, we have the pattern 1.1.1.6 root 825: 1.1.1.7 ! root 826: (define_insn "" ! 827: [(set (reg:CC_NOOV 0) ! 828: (compare:CC_NOOV ! 829: (plus:SI (match_operand:SI 0 "register_operand" "%r") ! 830: (match_operand:SI 1 "arith_operand" "rI")) ! 831: (const_int 0)))] 1.1.1.6 root 832: "" 1.1.1.7 ! root 833: "...") 1.1.1.4 root 834: 1.1.1.7 ! root 835: The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for ! 836: comparisons whose argument is a `plus'. 1.1.1.5 root 837: 838: 1.1.1.7 ! root 839: File: gcc.info, Node: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc 1.1.1.5 root 840: 1.1.1.7 ! root 841: Canonicalization of Instructions ! 842: ================================ 1.1.1.5 root 843: 1.1.1.7 ! root 844: There are often cases where multiple RTL expressions could represent ! 845: an operation performed by a single machine instruction. This situation ! 846: is most commonly encountered with logical, branch, and ! 847: multiply-accumulate instructions. In such cases, the compiler attempts ! 848: to convert these multiple RTL expressions into a single canonical form ! 849: to reduce the number of insn patterns required. ! 850: ! 851: In addition to algebraic simplifications, following canonicalizations ! 852: are performed: ! 853: ! 854: * For commutative and comparison operators, a constant is always ! 855: made the second operand. If a machine only supports a constant as ! 856: the second operand, only patterns that match a constant in the ! 857: second operand need be supplied. ! 858: ! 859: For these operators, if only one operand is a `neg', `not', ! 860: `mult', `plus', or `minus' expression, it will be the first ! 861: operand. ! 862: ! 863: * For the `compare' operator, a constant is always the second operand ! 864: on machines where `cc0' is used (*note Jump Patterns::.). On other ! 865: machines, there are rare cases where the compiler might want to ! 866: construct a `compare' with a constant as the first operand. ! 867: However, these cases are not common enough for it to be worthwhile ! 868: to provide a pattern matching a constant as the first operand ! 869: unless the machine actually has such an instruction. ! 870: ! 871: An operand of `neg', `not', `mult', `plus', or `minus' is made the ! 872: first operand under the same conditions as above. ! 873: ! 874: * `(minus X (const_int N))' is converted to `(plus X (const_int ! 875: -N))'. ! 876: ! 877: * Within address computations (i.e., inside `mem'), a left shift is ! 878: converted into the appropriate multiplication by a power of two. ! 879: ! 880: De`Morgan's Law is used to move bitwise negation inside a bitwise ! 881: logical-and or logical-or operation. If this results in only one ! 882: operand being a `not' expression, it will be the first one. ! 883: ! 884: A machine that has an instruction that performs a bitwise ! 885: logical-and of one operand with the bitwise negation of the other ! 886: should specify the pattern for that instruction as ! 887: ! 888: (define_insn "" ! 889: [(set (match_operand:M 0 ...) ! 890: (and:M (not:M (match_operand:M 1 ...)) ! 891: (match_operand:M 2 ...)))] ! 892: "..." ! 893: "...") ! 894: ! 895: Similarly, a pattern for a "NAND" instruction should be written ! 896: ! 897: (define_insn "" ! 898: [(set (match_operand:M 0 ...) ! 899: (ior:M (not:M (match_operand:M 1 ...)) ! 900: (not:M (match_operand:M 2 ...))))] ! 901: "..." ! 902: "...") ! 903: ! 904: In both cases, it is not necessary to include patterns for the many ! 905: logically equivalent RTL expressions. ! 906: ! 907: * The only possible RTL expressions involving both bitwise ! 908: exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M ! 909: (xor:M X Y))'. ! 910: ! 911: * The sum of three items, one of which is a constant, will only ! 912: appear in the form ! 913: ! 914: (plus:M (plus:M X Y) CONSTANT) ! 915: ! 916: * On machines that do not use `cc0', `(compare X (const_int 0))' ! 917: will be converted to X. ! 918: ! 919: * Equality comparisons of a group of bits (usually a single bit) ! 920: with zero will be written using `zero_extract' rather than the ! 921: equivalent `and' or `sign_extract' operations. 1.1.1.5 root 922: 923: 1.1.1.7 ! root 924: File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc 1.1.1.5 root 925: 1.1.1.7 ! root 926: Machine-Specific Peephole Optimizers ! 927: ==================================== 1.1.1.5 root 928: 1.1.1.7 ! root 929: In addition to instruction patterns the `md' file may contain ! 930: definitions of machine-specific peephole optimizations. 1.1.1.5 root 931: 1.1.1.7 ! root 932: The combiner does not notice certain peephole optimizations when the ! 933: data flow in the program does not suggest that it should try them. For ! 934: example, sometimes two consecutive insns related in purpose can be ! 935: combined even though the second one does not appear to use a register ! 936: computed in the first one. A machine-specific peephole optimizer can ! 937: detect such opportunities. ! 938: ! 939: A definition looks like this: ! 940: ! 941: (define_peephole ! 942: [INSN-PATTERN-1 ! 943: INSN-PATTERN-2 ! 944: ...] ! 945: "CONDITION" ! 946: "TEMPLATE" ! 947: "OPTIONAL INSN-ATTRIBUTES") 1.1.1.5 root 948: 1.1.1.7 ! root 949: The last string operand may be omitted if you are not using any ! 950: machine-specific information in this machine description. If present, ! 951: it must obey the same rules as in a `define_insn'. ! 952: ! 953: In this skeleton, INSN-PATTERN-1 and so on are patterns to match ! 954: consecutive insns. The optimization applies to a sequence of insns when ! 955: INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, ! 956: and so on. ! 957: ! 958: Each of the insns matched by a peephole must also match a ! 959: `define_insn'. Peepholes are checked only at the last stage just ! 960: before code generation, and only optionally. Therefore, any insn which ! 961: would match a peephole but no `define_insn' will cause a crash in code ! 962: generation in an unoptimized compilation, or at various optimization ! 963: stages. ! 964: ! 965: The operands of the insns are matched with `match_operands', ! 966: `match_operator', and `match_dup', as usual. What is not usual is that ! 967: the operand numbers apply to all the insn patterns in the definition. ! 968: So, you can check for identical operands in two insns by using ! 969: `match_operand' in one insn and `match_dup' in the other. ! 970: ! 971: The operand constraints used in `match_operand' patterns do not have ! 972: any direct effect on the applicability of the peephole, but they will ! 973: be validated afterward, so make sure your constraints are general enough ! 974: to apply whenever the peephole matches. If the peephole matches but ! 975: the constraints are not satisfied, the compiler will crash. ! 976: ! 977: It is safe to omit constraints in all the operands of the peephole; ! 978: or you can write constraints which serve as a double-check on the ! 979: criteria previously tested. ! 980: ! 981: Once a sequence of insns matches the patterns, the CONDITION is ! 982: checked. This is a C expression which makes the final decision whether ! 983: to perform the optimization (we do so if the expression is nonzero). If ! 984: CONDITION is omitted (in other words, the string is empty) then the ! 985: optimization is applied to every sequence of insns that matches the ! 986: patterns. ! 987: ! 988: The defined peephole optimizations are applied after register ! 989: allocation is complete. Therefore, the peephole definition can check ! 990: which operands have ended up in which kinds of registers, just by ! 991: looking at the operands. ! 992: ! 993: The way to refer to the operands in CONDITION is to write ! 994: `operands[I]' for operand number I (as matched by `(match_operand I ! 995: ...)'). Use the variable `insn' to refer to the last of the insns ! 996: being matched; use `prev_nonnote_insn' to find the preceding insns. ! 997: ! 998: When optimizing computations with intermediate results, you can use ! 999: CONDITION to match only when the intermediate results are not used ! 1000: elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN ! 1001: is the insn in which you expect the value to be used for the last time ! 1002: (from the value of `insn', together with use of `prev_nonnote_insn'), ! 1003: and OP is the intermediate value (from `operands[I]'). ! 1004: ! 1005: Applying the optimization means replacing the sequence of insns with ! 1006: one new insn. The TEMPLATE controls ultimate output of assembler code ! 1007: for this combined insn. It works exactly like the template of a ! 1008: `define_insn'. Operand numbers in this template are the same ones used ! 1009: in matching the original sequence of insns. ! 1010: ! 1011: The result of a defined peephole optimizer does not need to match ! 1012: any of the insn patterns in the machine description; it does not even ! 1013: have an opportunity to match them. The peephole optimizer definition ! 1014: itself serves as the insn pattern to control how the insn is output. ! 1015: ! 1016: Defined peephole optimizers are run as assembler code is being ! 1017: output, so the insns they produce are never combined or rearranged in ! 1018: any way. ! 1019: ! 1020: Here is an example, taken from the 68000 machine description: ! 1021: ! 1022: (define_peephole ! 1023: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) ! 1024: (set (match_operand:DF 0 "register_operand" "=f") ! 1025: (match_operand:DF 1 "register_operand" "ad"))] ! 1026: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" ! 1027: "* ! 1028: { ! 1029: rtx xoperands[2]; ! 1030: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); ! 1031: #ifdef MOTOROLA ! 1032: output_asm_insn (\"move.l %1,(sp)\", xoperands); ! 1033: output_asm_insn (\"move.l %1,-(sp)\", operands); ! 1034: return \"fmove.d (sp)+,%0\"; ! 1035: #else ! 1036: output_asm_insn (\"movel %1,sp@\", xoperands); ! 1037: output_asm_insn (\"movel %1,sp@-\", operands); ! 1038: return \"fmoved sp@+,%0\"; ! 1039: #endif ! 1040: } ! 1041: ") ! 1042: ! 1043: The effect of this optimization is to change ! 1044: ! 1045: jbsr _foobar ! 1046: addql #4,sp ! 1047: movel d1,sp@- ! 1048: movel d0,sp@- ! 1049: fmoved sp@+,fp0 ! 1050: ! 1051: into ! 1052: ! 1053: jbsr _foobar ! 1054: movel d1,sp@ ! 1055: movel d0,sp@- ! 1056: fmoved sp@+,fp0 ! 1057: ! 1058: INSN-PATTERN-1 and so on look *almost* like the second operand of ! 1059: `define_insn'. There is one important difference: the second operand ! 1060: of `define_insn' consists of one or more RTX's enclosed in square ! 1061: brackets. Usually, there is only one: then the same action can be ! 1062: written as an element of a `define_peephole'. But when there are ! 1063: multiple actions in a `define_insn', they are implicitly enclosed in a ! 1064: `parallel'. Then you must explicitly write the `parallel', and the ! 1065: square brackets within it, in the `define_peephole'. Thus, if an insn ! 1066: pattern looks like this, ! 1067: ! 1068: (define_insn "divmodsi4" ! 1069: [(set (match_operand:SI 0 "general_operand" "=d") ! 1070: (div:SI (match_operand:SI 1 "general_operand" "0") ! 1071: (match_operand:SI 2 "general_operand" "dmsK"))) ! 1072: (set (match_operand:SI 3 "general_operand" "=d") ! 1073: (mod:SI (match_dup 1) (match_dup 2)))] ! 1074: "TARGET_68020" ! 1075: "divsl%.l %2,%3:%0") ! 1076: ! 1077: then the way to mention this insn in a peephole is as follows: ! 1078: ! 1079: (define_peephole ! 1080: [... ! 1081: (parallel ! 1082: [(set (match_operand:SI 0 "general_operand" "=d") ! 1083: (div:SI (match_operand:SI 1 "general_operand" "0") ! 1084: (match_operand:SI 2 "general_operand" "dmsK"))) ! 1085: (set (match_operand:SI 3 "general_operand" "=d") ! 1086: (mod:SI (match_dup 1) (match_dup 2)))]) ! 1087: ...] ! 1088: ...) 1.1 root 1089:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.