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