![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-5 CVS log | Up to [GCC 1.x] / gcc |
1.1 ! root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input ! 2: file gcc.texinfo. ! 3: ! 4: This file documents the use and the internals of the GNU compiler. ! 5: ! 6: Copyright (C) 1988 Free Software Foundation, Inc. ! 7: ! 8: Permission is granted to make and distribute verbatim copies of this ! 9: manual provided the copyright notice and this permission notice are ! 10: preserved on all copies. ! 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 CC General Public License'' is ! 15: included exactly as in the original, and provided that the entire ! 16: resulting derived work is distributed under the terms of a permission ! 17: notice identical to this one. ! 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 CC 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: ! 28: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints ! 29: ! 30: Simple Constraints ! 31: ------------------ ! 32: ! 33: The simplest kind of constraint is a string full of letters, each of ! 34: which describes one kind of operand that is permitted. Here are the ! 35: letters that are allowed: ! 36: ! 37: `m' ! 38: A memory operand is allowed, with any kind of address that the ! 39: machine supports in general. ! 40: ! 41: `o' ! 42: A memory operand is allowed, but only if the address is ! 43: "offsetable". This means that adding a small integer (actually, ! 44: the width in bytes of the operand, as determined by its machine ! 45: mode) may be added to the address and the result is also a valid ! 46: memory address. ! 47: ! 48: For example, an address which is constant is offsetable; so is ! 49: an address that is the sum of a register and a constant (as long ! 50: as a slightly larger constant is also within the range of ! 51: address-offsets supported by the machine); but an autoincrement ! 52: or autodecrement address is not offsetable. More complicated ! 53: indirect/indexed addresses may or may not be offsetable ! 54: depending on the other addressing modes that the machine supports. ! 55: ! 56: Note that in an output operand which can be matched by another ! 57: operand, the constraint letter `o' is valid only when ! 58: accompanied by both `<' (if the target machine has predecrement ! 59: addressing) and `>' (if the target machine has preincrement ! 60: addressing). ! 61: ! 62: When the constraint letter `o' is used, the reload pass may ! 63: generate instructions which copy a nonoffsetable address into an ! 64: index register. The idea is that the register can be used as a ! 65: replacement offsetable address. But this method requires that ! 66: there be patterns to copy any kind of address into a register. ! 67: Auto-increment and auto-decrement addresses are an exception; ! 68: there need not be an instruction that can copy such an address ! 69: into a register, because reload handles these cases specially. ! 70: ! 71: Most older machine designs have ``load address'' instructions ! 72: which do just what is needed here. Some RISC machines do not ! 73: advertise such instructions, but the possible addresses on these ! 74: machines are very limited, so it is easy to fake them. ! 75: ! 76: `<' ! 77: A memory operand with autodecrement addressing (either ! 78: predecrement or postdecrement) is allowed. ! 79: ! 80: `>' ! 81: A memory operand with autoincrement addressing (either ! 82: preincrement or postincrement) is allowed. ! 83: ! 84: `r' ! 85: A register operand is allowed provided that it is in a general ! 86: register. ! 87: ! 88: `d', `a', `f', ... ! 89: Other letters can be defined in machine-dependent fashion to ! 90: stand for particular classes of registers. `d', `a' and `f' are ! 91: defined on the 68000/68020 to stand for data, address and ! 92: floating point registers. ! 93: ! 94: `i' ! 95: An immediate integer operand (one with constant value) is allowed. ! 96: This includes symbolic constants whose values will be known only ! 97: at assembly time. ! 98: ! 99: `n' ! 100: An immediate integer operand with a known numeric value is ! 101: allowed. Many systems cannot support assembly-time constants ! 102: for operands less than a word wide. Constraints for these ! 103: operands should use `n' rather than `i'. ! 104: ! 105: `I', `J', `K', ... ! 106: Other letters in the range `I' through `M' may be defined in a ! 107: machine-dependent fashion to permit immediate integer operands ! 108: with explicit integer values in specified ranges. For example, ! 109: on the 68000, `I' is defined to stand for the range of values 1 ! 110: to 8. This is the range permitted as a shift count in the shift ! 111: instructions. ! 112: ! 113: `F' ! 114: An immediate floating operand (expression code `const_double') ! 115: is allowed. ! 116: ! 117: `G', `H' ! 118: `G' and `H' may be defined in a machine-dependent fashion to ! 119: permit immediate floating operands in particular ranges of values. ! 120: ! 121: `s' ! 122: An immediate integer operand whose value is not an explicit ! 123: integer is allowed. ! 124: ! 125: This might appear strange; if an insn allows a constant operand ! 126: with a value not known at compile time, it certainly must allow ! 127: any known value. So why use `s' instead of `i'? Sometimes it ! 128: allows better code to be generated. ! 129: ! 130: For example, on the 68000 in a fullword instruction it is ! 131: possible to use an immediate operand; but if the immediate value ! 132: is between -32 and 31, better code results from loading the ! 133: value into a register and using the register. This is because ! 134: the load into the register can be done with a `moveq' ! 135: instruction. We arrange for this to happen by defining the ! 136: letter `K' to mean ``any integer outside the range -32 to 31'', ! 137: and then specifying `Ks' in the operand constraints. ! 138: ! 139: `g' ! 140: Any register, memory or immediate integer operand is allowed, ! 141: except for registers that are not general registers. ! 142: ! 143: `N' (a digit) ! 144: An operand that matches operand number N is allowed. If a digit ! 145: is used together with letters, the digit should come last. ! 146: ! 147: This is called a "matching constraint" and what it really means ! 148: is that the assembler has only a single operand that fills two ! 149: roles considered separate in the RTL insn. For example, an add ! 150: insn has two input operands and one output operand in the RTL, ! 151: but on most machines an add instruction really has only two ! 152: operands, one of them an input-output operand. ! 153: ! 154: Matching constraints work only in circumstances like that add ! 155: insn. More precisely, the matching constraint must appear in an ! 156: input-only operand and the operand that it matches must be an ! 157: output-only operand with a lower number. ! 158: ! 159: For operands to match in a particular case usually means that ! 160: they are identical-looking RTL expressions. But in a few ! 161: special cases specific kinds of dissimilarity are allowed. For ! 162: example, `*x' as an input operand will match `*x++' as an output ! 163: operand. For proper results in such cases, the output template ! 164: should always use the output-operand's number when printing the ! 165: operand. ! 166: ! 167: `p' ! 168: An operand that is a valid memory address is allowed. This is ! 169: for ``load address'' and ``push address'' instructions. ! 170: ! 171: If `p' is used in the constraint, the test-function in the ! 172: `match_operand' must be `address_operand'. ! 173: ! 174: In order to have valid assembler code, each operand must satisfy its ! 175: constraint. But a failure to do so does not prevent the pattern from ! 176: applying to an insn. Instead, it directs the compiler to modify the ! 177: code so that the constraint will be satisfied. Usually this is done ! 178: by copying an operand into a register. ! 179: ! 180: Contrast, therefore, the two instruction patterns that follow: ! 181: ! 182: (define_insn "" ! 183: [(set (match_operand:SI 0 "general_operand" "r") ! 184: (plus:SI (match_dup 0) ! 185: (match_operand:SI 1 "general_operand" "r")))] ! 186: "" ! 187: "...") ! 188: ! 189: which has two operands, one of which must appear in two places, and ! 190: ! 191: (define_insn "" ! 192: [(set (match_operand:SI 0 "general_operand" "r") ! 193: (plus:SI (match_operand:SI 1 "general_operand" "0") ! 194: (match_operand:SI 2 "general_operand" "r")))] ! 195: "" ! 196: "...") ! 197: ! 198: which has three operands, two of which are required by a constraint ! 199: to be identical. If we are considering an insn of the form ! 200: ! 201: (insn N PREV NEXT ! 202: (set (reg:SI 3) ! 203: (plus:SI (reg:SI 6) (reg:SI 109))) ! 204: ...) ! 205: ! 206: the first pattern would not apply at all, because this insn does not ! 207: contain two identical subexpressions in the right place. The pattern ! 208: would say, ``That does not look like an add instruction; try other ! 209: patterns.'' The second pattern would say, ``Yes, that's an add ! 210: instruction, but there is something wrong with it.'' It would direct ! 211: the reload pass of the compiler to generate additional insns to make ! 212: the constraint true. The results might look like this: ! 213: ! 214: (insn N2 PREV N ! 215: (set (reg:SI 3) (reg:SI 6)) ! 216: ...) ! 217: ! 218: (insn N N2 NEXT ! 219: (set (reg:SI 3) ! 220: (plus:SI (reg:SI 3) (reg:SI 109))) ! 221: ...) ! 222: ! 223: It is up to you to make sure that each operand, in each pattern, has ! 224: constraints that can handle any RTL expression that could be present ! 225: for that operand. (When multiple alternatives are in use, each ! 226: pattern must, for each possible combination of operand expressions, ! 227: have at least one alternative which can handle that combination of ! 228: operands.) The constraints don't need to *allow* any possible ! 229: operand--when this is the case, they do not constrain--but they must ! 230: at least point the way to reloading any possible operand so that it ! 231: will fit. ! 232: ! 233: * If the constraint accepts whatever operands the predicate ! 234: permits, there is no problem: reloading is never necessary for ! 235: this operand. ! 236: ! 237: For example, an operand whose constraints permit everything ! 238: except registers is safe provided its predicate rejects registers. ! 239: ! 240: An operand whose predicate accepts only constant values is safe ! 241: provided its constraints include the letter `i'. If any ! 242: possible constant value is accepted, then nothing less than `i' ! 243: will do; if the predicate is more selective, than the ! 244: constraints may also be more selective. ! 245: ! 246: * Any operand expression can be reloaded by copying it into a ! 247: register. So if an operand's constraints allow some kind of ! 248: register, it is certain to be safe. It need not permit all ! 249: classes of registers; the compiler knows how to copy a register ! 250: into another register of the proper class in order to make an ! 251: instruction valid. ! 252: ! 253: * A nonoffsetable memory reference can be reloaded by copying the ! 254: address into a register. So if the constraint uses the letter ! 255: `o', all memory references are taken care of. ! 256: ! 257: * A constant operand can be reloaded by storing it in memory; it ! 258: then becomes an offsetable memory reference. So if the ! 259: constraint uses the letters `o' or `m', constant operands are ! 260: not a problem. ! 261: ! 262: If the operand's predicate can recognize registers, but the ! 263: constraint does not permit them, it can make the compiler crash. ! 264: When this operand happens to be a register, the reload pass will be ! 265: stymied, because it does not know how to copy a register temporarily ! 266: into memory. ! 267: ! 268: ! 269: ! 270: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints ! 271: ! 272: Multiple Alternative Constraints ! 273: -------------------------------- ! 274: ! 275: Sometimes a single instruction has multiple alternative sets of ! 276: possible operands. For example, on the 68000, a logical-or ! 277: instruction can combine register or an immediate value into memory, ! 278: or it can combine any kind of operand into a register; but it cannot ! 279: combine one memory location into another. ! 280: ! 281: These constraints are represented as multiple alternatives. An ! 282: alternative can be described by a series of letters for each operand. ! 283: The overall constraint for an operand is made from the letters for ! 284: this operand from the first alternative, a comma, the letters for ! 285: this operand from the second alternative, a comma, and so on until ! 286: the last alternative. Here is how it is done for fullword logical-or ! 287: on the 68000: ! 288: ! 289: (define_insn "iorsi3" ! 290: [(set (match_operand:SI 0 "general_operand" "=%m,d") ! 291: (ior:SI (match_operand:SI 1 "general_operand" "0,0") ! 292: (match_operand:SI 2 "general_operand" "dKs,dmKs")))] ! 293: ...) ! 294: ! 295: The first alternative has `m' (memory) for operand 0, `0' for operand ! 296: 1 (meaning it must match operand 0), and `dKs' for operand 2. The ! 297: second alternative has `d' (data register) for operand 0, `0' for ! 298: operand 1, and `dmKs' for operand 2. The `=' and `%' in the ! 299: constraint for operand 0 are not part of any alternative; their ! 300: meaning is explained in the next section. ! 301: ! 302: If all the operands fit any one alternative, the instruction is valid. ! 303: Otherwise, for each alternative, the compiler counts how many ! 304: instructions must be added to copy the operands so that that ! 305: alternative applies. The alternative requiring the least copying is ! 306: chosen. If two alternatives need the same amount of copying, the one ! 307: that comes first is chosen. These choices can be altered with the ! 308: `?' and `!' characters: ! 309: ! 310: `?' ! 311: Disparage slightly the alternative that the `?' appears in, as a ! 312: choice when no alternative applies exactly. The compiler ! 313: regards this alternative as one unit more costly for each `?' ! 314: that appears in it. ! 315: ! 316: `!' ! 317: Disparage severely the alternative that the `!' appears in. ! 318: When operands must be copied into registers, the compiler will ! 319: never choose this alternative as the one to strive for. ! 320: ! 321: When an insn pattern has multiple alternatives in its constraints, ! 322: often the appearance of the assembler code determined mostly by which ! 323: alternative was matched. When this is so, the C code for writing the ! 324: assembler code can use the variable `which_alternative', which is the ! 325: ordinal number of the alternative that was actually satisfied (0 for ! 326: the first, 1 for the second alternative, etc.). For example: ! 327: ! 328: (define_insn "" ! 329: [(set (match_operand:SI 0 "general_operand" "r,m") ! 330: (const_int 0))] ! 331: "" ! 332: "* ! 333: return (which_alternative == 0 ! 334: ? \"clrreg %0\" : \"clrmem %0\"); ! 335: ") ! 336: ! 337: ! 338: ! 339: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints ! 340: ! 341: Register Class Preferences ! 342: -------------------------- ! 343: ! 344: The operand constraints have another function: they enable the ! 345: compiler to decide which kind of hardware register a pseudo register ! 346: is best allocated to. The compiler examines the constraints that ! 347: apply to the insns that use the pseudo register, looking for the ! 348: machine-dependent letters such as `d' and `a' that specify classes of ! 349: registers. The pseudo register is put in whichever class gets the ! 350: most ``votes''. The constraint letters `g' and `r' also vote: they ! 351: vote in favor of a general register. The machine description says ! 352: which registers are considered general. ! 353: ! 354: Of course, on some machines all registers are equivalent, and no ! 355: register classes are defined. Then none of this complexity is ! 356: relevant. ! 357: ! 358: ! 359: ! 360: File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints ! 361: ! 362: Constraint Modifier Characters ! 363: ------------------------------ ! 364: ! 365: `=' ! 366: Means that this operand is write-only for this instruction: the ! 367: previous value is discarded and replaced by output data. ! 368: ! 369: `+' ! 370: Means that this operand is both read and written by the ! 371: instruction. ! 372: ! 373: When the compiler fixes up the operands to satisfy the ! 374: constraints, it needs to know which operands are inputs to the ! 375: instruction and which are outputs from it. `=' identifies an ! 376: output; `+' identifies an operand that is both input and output; ! 377: all other operands are assumed to be input only. ! 378: ! 379: `&' ! 380: Means (in a particular alternative) that this operand is written ! 381: before the instruction is finished using the input operands. ! 382: Therefore, this operand may not lie in a register that is used ! 383: as an input operand or as part of any memory address. ! 384: ! 385: `&' applies only to the alternative in which it is written. In ! 386: constraints with multiple alternatives, sometimes one ! 387: alternative requires `&' while others do not. See, for example, ! 388: the `movdf' insn of the 68000. ! 389: ! 390: `&' does not obviate the need to write `='. ! 391: ! 392: `%' ! 393: Declares the instruction to be commutative for this operand and ! 394: the following operand. This means that the compiler may ! 395: interchange the two operands if that is the cheapest way to make ! 396: all operands fit the constraints. This is often used in ! 397: patterns for addition instructions that really have only two ! 398: operands: the result must go in one of the arguments. Here for ! 399: example, is how the 68000 halfword-add instruction is defined: ! 400: ! 401: (define_insn "addhi3" ! 402: [(set (match_operand:HI 0 "general_operand" "=m,r") ! 403: (plus:HI (match_operand:HI 1 "general_operand" "%0,0") ! 404: (match_operand:HI 2 "general_operand" "di,g")))] ! 405: ...) ! 406: ! 407: Note that in previous versions of GNU CC the `%' constraint ! 408: modifier always applied to operands 1 and 2 regardless of which ! 409: operand it was written in. The usual custom was to write it in ! 410: operand 0. Now it must be in operand 1 if the operands to be ! 411: exchanged are 1 and 2. ! 412: ! 413: `#' ! 414: Says that all following characters, up to the next comma, are to ! 415: be ignored as a constraint. They are significant only for ! 416: choosing register preferences. ! 417: ! 418: `*' ! 419: Says that the following character should be ignored when ! 420: choosing register preferences. `*' has no effect on the meaning ! 421: of the constraint as a constraint. ! 422: ! 423: Here is an example: the 68000 has an instruction to sign-extend ! 424: a halfword in a data register, and can also sign-extend a value ! 425: by copying it into an address register. While either kind of ! 426: register is acceptable, the constraints on an address-register ! 427: destination are less strict, so it is best if register ! 428: allocation makes an address register its goal. Therefore, `*' ! 429: is used so that the `d' constraint letter (for data register) is ! 430: ignored when computing register preferences. ! 431: ! 432: (define_insn "extendhisi2" ! 433: [(set (match_operand:SI 0 "general_operand" "=*d,a") ! 434: (sign_extend:SI ! 435: (match_operand:HI 1 "general_operand" "0,g")))] ! 436: ...) ! 437: ! 438: ! 439: ! 440: File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints ! 441: ! 442: Not Using Constraints ! 443: --------------------- ! 444: ! 445: Some machines are so clean that operand constraints are not required. ! 446: For example, on the Vax, an operand valid in one context is valid in ! 447: any other context. On such a machine, every operand constraint would ! 448: be `g', excepting only operands of ``load address'' instructions ! 449: which are written as if they referred to a memory location's contents ! 450: but actual refer to its address. They would have constraint `p'. ! 451: ! 452: For such machines, instead of writing `g' and `p' for all the ! 453: constraints, you can choose to write a description with empty ! 454: constraints. Then you write `""' for the constraint in every ! 455: `match_operand'. Address operands are identified by writing an ! 456: `address' expression around the `match_operand', not by their ! 457: constraints. ! 458: ! 459: When the machine description has just empty constraints, certain ! 460: parts of compilation are skipped, making the compiler faster. ! 461: ! 462: ! 463: ! 464: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc ! 465: ! 466: Standard Names for Patterns Used in Generation ! 467: ============================================== ! 468: ! 469: Here is a table of the instruction names that are meaningful in the ! 470: RTL generation pass of the compiler. Giving one of these names to an ! 471: instruction pattern tells the RTL generation pass that it can use the ! 472: pattern in to accomplish a certain task. ! 473: ! 474: `movM' ! 475: Here M is a two-letter machine mode name, in lower case. This ! 476: instruction pattern moves data with that machine mode from ! 477: operand 1 to operand 0. For example, `movsi' moves full-word ! 478: data. ! 479: ! 480: If operand 0 is a `subreg' with mode M of a register whose ! 481: natural mode is wider than M, the effect of this instruction is ! 482: to store the specified value in the part of the register that ! 483: corresponds to mode M. The effect on the rest of the register ! 484: is undefined. ! 485: ! 486: This class of patterns is special in several ways. First of ! 487: all, each of these names *must* be defined, because there is no ! 488: other way to copy a datum from one place to another. ! 489: ! 490: Second, these patterns are not used solely in the RTL generation ! 491: pass. Even the reload pass can generate move insns to copy ! 492: values from stack slots into temporary registers. When it does ! 493: so, one of the operands is a hard register and the other is an ! 494: operand that can have a reload. ! 495: ! 496: Therefore, when given such a pair of operands, the pattern must ! 497: generate RTL which needs no temporary registers--no registers ! 498: other than the operands. For example, if you support the ! 499: pattern with a `define_expand', then in such a case you mustn't ! 500: call `force_reg' or any other such function which might generate ! 501: new pseudo registers. ! 502: ! 503: This requirement exists even for subword modes on a RISC machine ! 504: where fetching those modes from memory normally requires several ! 505: insns and some temporary registers. Look in `spur.md' to see ! 506: how the requirement is satisfied. ! 507: ! 508: The variety of operands that have reloads depends on the rest of ! 509: the machine description, but typically on a RISC machine these ! 510: can only be pseudo registers that did not get hard registers, ! 511: while on other machines explicit memory references will get ! 512: optional reloads. ! 513: ! 514: In addition, the constraints must allow any hard register to be ! 515: moved to any other hard register (provided that ! 516: `HARD_REGNO_MODE_OK' permits mode M in each of the registers). ! 517: ! 518: `movstrictM' ! 519: Like `movM' except that if operand 0 is a `subreg' with mode M ! 520: of a register whose natural mode is wider, the `movstrictM' ! 521: instruction is guaranteed not to alter any of the register ! 522: except the part which belongs to mode M. ! 523: ! 524: `addM3' ! 525: Add operand 2 and operand 1, storing the result in operand 0. ! 526: All operands must have mode M. This can be used even on ! 527: two-address machines, by means of constraints requiring operands ! 528: 1 and 0 to be the same location. ! 529: ! 530: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3' ! 531: Similar, for other arithmetic operations. ! 532: ! 533: There are special considerations for register classes for ! 534: logical-and instructions, affecting also the macro ! 535: `PREFERRED_RELOAD_CLASS'. They apply not only to the patterns ! 536: with these standard names, but to any patterns that will match ! 537: such an instruction. *Note Register Classes::. ! 538: ! 539: `mulhisi3' ! 540: Multiply operands 1 and 2, which have mode `HImode', and store a ! 541: `SImode' product in operand 0. ! 542: ! 543: `mulqihi3', `mulsidi3' ! 544: Similar widening-multiplication instructions of other widths. ! 545: ! 546: `umulqihi3', `umulhisi3', `umulsidi3' ! 547: Similar widening-multiplication instructions that do unsigned ! 548: multiplication. ! 549: ! 550: `divmodM4' ! 551: Signed division that produces both a quotient and a remainder. ! 552: Operand 1 is divided by operand 2 to produce a quotient stored ! 553: in operand 0 and a remainder stored in operand 3. ! 554: ! 555: `udivmodM4' ! 556: Similar, but does unsigned division. ! 557: ! 558: `divmodMN4' ! 559: Like `divmodM4' except that only the dividend has mode M; the ! 560: divisor, quotient and remainder have mode N. For example, the ! 561: Vax has a `divmoddisi4' instruction (but it is omitted from the ! 562: machine description, because it is so slow that it is faster to ! 563: compute remainders by the circumlocution that the compiler will ! 564: use if this instruction is not available). ! 565: ! 566: `ashlM3' ! 567: Arithmetic-shift operand 1 left by a number of bits specified by ! 568: operand 2, and store the result in operand 0. Operand 2 has ! 569: mode `SImode', not mode M. ! 570: ! 571: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3' ! 572: Other shift and rotate instructions. ! 573: ! 574: Logical and arithmetic left shift are the same. Machines that ! 575: do not allow negative shift counts often have only one ! 576: instruction for shifting left. On such machines, you should ! 577: define a pattern named `ashlM3' and leave `lshlM3' undefined. ! 578: ! 579: There are special considerations for register classes for shift ! 580: instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'. ! 581: They apply not only to the patterns with these standard names, ! 582: but to any patterns that will match such an instruction. *Note ! 583: Register Classes::. ! 584: ! 585: `negM2' ! 586: Negate operand 1 and store the result in operand 0. ! 587: ! 588: `absM2' ! 589: Store the absolute value of operand 1 into operand 0. ! 590: ! 591: `sqrtM2' ! 592: Store the square root of operand 1 into operand 0. ! 593: ! 594: `ffsM2' ! 595: Store into operand 0 one plus the index of the least significant ! 596: 1-bit of operand 1. If operand 1 is zero, store zero. M is the ! 597: mode of operand 0; operand 1's mode is specified by the ! 598: instruction pattern, and the compiler will convert the operand ! 599: to that mode before generating the instruction. ! 600: ! 601: `one_cmplM2' ! 602: Store the bitwise-complement of operand 1 into operand 0. ! 603: ! 604: `cmpM' ! 605: Compare operand 0 and operand 1, and set the condition codes. ! 606: The RTL pattern should look like this: ! 607: ! 608: (set (cc0) (minus (match_operand:M 0 ...) ! 609: (match_operand:M 1 ...))) ! 610: ! 611: Each such definition in the machine description, for integer ! 612: mode M, must have a corresponding `tstM' pattern, because ! 613: optimization can simplify the compare into a test when operand 1 ! 614: is zero. ! 615: ! 616: `tstM' ! 617: Compare operand 0 against zero, and set the condition codes. ! 618: The RTL pattern should look like this: ! 619: ! 620: (set (cc0) (match_operand:M 0 ...)) ! 621: ! 622: `movstrM' ! 623: Block move instruction. The addresses of the destination and ! 624: source strings are the first two operands, and both are in mode ! 625: `Pmode'. The number of bytes to move is the third operand, in ! 626: mode M. ! 627: ! 628: `cmpstrM' ! 629: Block compare instruction, with operands like `movstrM' except ! 630: that the two memory blocks are compared byte by byte in ! 631: lexicographic order. The effect of the instruction is to set ! 632: the condition codes. ! 633: ! 634: `floatMN2' ! 635: Convert operand 1 (valid for fixed point mode M) to floating ! 636: point mode N and store in operand 0 (which has mode N). ! 637: ! 638: `fixMN2' ! 639: Convert operand 1 (valid for floating point mode M) to fixed ! 640: point mode N as a signed number and store in operand 0 (which ! 641: has mode N). This instruction's result is defined only when the ! 642: value of operand 1 is an integer. ! 643: ! 644: `fixunsMN2' ! 645: Convert operand 1 (valid for floating point mode M) to fixed ! 646: point mode N as an unsigned number and store in operand 0 (which ! 647: has mode N). This instruction's result is defined only when the ! 648: value of operand 1 is an integer. ! 649: ! 650: `ftruncM2' ! 651: Convert operand 1 (valid for floating point mode M) to an ! 652: integer value, still represented in floating point mode M, and ! 653: store it in operand 0 (valid for floating point mode M). ! 654: ! 655: `fix_truncMN2' ! 656: Like `fixMN2' but works for any floating point value of mode M ! 657: by converting the value to an integer. ! 658: ! 659: `fixuns_truncMN2' ! 660: Like `fixunsMN2' but works for any floating point value of mode ! 661: M by converting the value to an integer. ! 662: ! 663: `truncMN' ! 664: Truncate operand 1 (valid for mode M) to mode N and store in ! 665: operand 0 (which has mode N). Both modes must be fixed point or ! 666: both floating point. ! 667: ! 668: `extendMN' ! 669: Sign-extend operand 1 (valid for mode M) to mode N and store in ! 670: operand 0 (which has mode N). Both modes must be fixed point or ! 671: both floating point. ! 672: ! 673: `zero_extendMN' ! 674: Zero-extend operand 1 (valid for mode M) to mode N and store in ! 675: operand 0 (which has mode N). Both modes must be fixed point. ! 676: ! 677: `extv' ! 678: Extract a bit-field from operand 1 (a register or memory ! 679: operand), where operand 2 specifies the width in bits and ! 680: operand 3 the starting bit, and store it in operand 0. Operand ! 681: 0 must have `Simode'. Operand 1 may have mode `QImode' or ! 682: `SImode'; often `SImode' is allowed only for registers. ! 683: Operands 2 and 3 must be valid for `SImode'. ! 684: ! 685: The RTL generation pass generates this instruction only with ! 686: constants for operands 2 and 3. ! 687: ! 688: The bit-field value is sign-extended to a full word integer ! 689: before it is stored in operand 0. ! 690: ! 691: `extzv' ! 692: Like `extv' except that the bit-field value is zero-extended. ! 693: ! 694: `insv' ! 695: Store operand 3 (which must be valid for `SImode') into a ! 696: bit-field in operand 0, where operand 1 specifies the width in ! 697: bits and operand 2 the starting bit. Operand 0 may have mode ! 698: `QImode' or `SImode'; often `SImode' is allowed only for ! 699: registers. Operands 1 and 2 must be valid for `SImode'. ! 700: ! 701: The RTL generation pass generates this instruction only with ! 702: constants for operands 1 and 2. ! 703: ! 704: `sCOND' ! 705: Store zero or nonzero in the operand according to the condition ! 706: codes. Value stored is nonzero iff the condition COND is true. ! 707: COND is the name of a comparison operation expression code, such ! 708: as `eq', `lt' or `leu'. ! 709: ! 710: You specify the mode that the operand must have when you write ! 711: the `match_operand' expression. The compiler automatically sees ! 712: which mode you have used and supplies an operand of that mode. ! 713: ! 714: The value stored for a true condition must have 1 as its low bit. ! 715: Otherwise the instruction is not suitable and must be omitted ! 716: from the machine description. You must tell the compiler ! 717: exactly which value is stored by defining the macro ! 718: `STORE_FLAG_VALUE'. ! 719: ! 720: `bCOND' ! 721: Conditional branch instruction. Operand 0 is a `label_ref' that ! 722: refers to the label to jump to. Jump if the condition codes ! 723: meet condition COND. ! 724: ! 725: `call' ! 726: Subroutine call instruction returning no value. Operand 0 is ! 727: the function to call; operand 1 is the number of bytes of ! 728: arguments pushed (in mode `SImode', except it is normally a ! 729: `const_int'); operand 2 is the number of registers used as ! 730: operands. ! 731: ! 732: On most machines, operand 2 is not actually stored into the RTL ! 733: pattern. It is supplied for the sake of some RISC machines ! 734: which need to put this information into the assembler code; they ! 735: can put it in the RTL instead of operand 1. ! 736: ! 737: Operand 0 should be a `mem' RTX whose address is the address of ! 738: the function. ! 739: ! 740: `call_value' ! 741: Subroutine call instruction returning a value. Operand 0 is the ! 742: hard register in which the value is returned. There are three ! 743: more operands, the same as the three operands of the `call' ! 744: instruction (but with numbers increased by one). ! 745: ! 746: Subroutines that return `BLKmode' objects use the `call' insn. ! 747: ! 748: `return' ! 749: Subroutine return instruction. This instruction pattern name ! 750: should be defined only if a single instruction can do all the ! 751: work of returning from a function. ! 752: ! 753: `casesi' ! 754: Instruction to jump through a dispatch table, including bounds ! 755: checking. This instruction takes five operands: ! 756: ! 757: 1. The index to dispatch on, which has mode `SImode'. ! 758: ! 759: 2. The lower bound for indices in the table, an integer ! 760: constant. ! 761: ! 762: 3. The upper bound for indices in the table, an integer ! 763: constant. ! 764: ! 765: 4. A label to jump to if the index has a value outside the ! 766: bounds. (If the machine-description macro ! 767: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds ! 768: index drops through to the code following the jump table ! 769: instead of jumping to this label. In that case, this label ! 770: is not actually used by the `casesi' instruction, but it is ! 771: always provided as an operand.) ! 772: ! 773: 5. A label that precedes the table itself. ! 774: ! 775: The table is a `addr_vec' or `addr_diff_vec' inside of a ! 776: `jump_insn'. The number of elements in the table is one plus ! 777: the difference between the upper bound and the lower bound. ! 778: ! 779: `tablejump' ! 780: Instruction to jump to a variable address. This is a low-level ! 781: capability which can be used to implement a dispatch table when ! 782: there is no `casesi' pattern. ! 783: ! 784: This pattern requires two operands: the address or offset, and a ! 785: label which should immediately precede the jump table. If the ! 786: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first ! 787: operand is an absolute address to jump to; otherwise, it is an ! 788: offset which counts from the address of the table. ! 789: ! 790: The `tablejump' insn is always the last insn before the jump ! 791: table it uses. Its assembler code normally has no need to use ! 792: the second operand, but you should incorporate it in the RTL ! 793: pattern so that the jump optimizer will not delete the table as ! 794: unreachable code. ! 795: ! 796: ! 797: ! 798: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc ! 799: ! 800: When the Order of Patterns Matters ! 801: ================================== ! 802: ! 803: Sometimes an insn can match more than one instruction pattern. Then ! 804: the pattern that appears first in the machine description is the one ! 805: used. Therefore, more specific patterns (patterns that will match ! 806: fewer things) and faster instructions (those that will produce better ! 807: code when they do match) should usually go first in the description. ! 808: ! 809: In some cases the effect of ordering the patterns can be used to hide ! 810: a pattern when it is not valid. For example, the 68000 has an ! 811: instruction for converting a fullword to floating point and another ! 812: for converting a byte to floating point. An instruction converting ! 813: an integer to floating point could match either one. We put the ! 814: pattern to convert the fullword first to make sure that one will be ! 815: used rather than the other. (Otherwise a large integer might be ! 816: generated as a single-byte immediate quantity, which would not work.) ! 817: Instead of using this pattern ordering it would be possible to make ! 818: the pattern for convert-a-byte smart enough to deal properly with any ! 819: constant value. ! 820: ! 821: ! 822: ! 823: File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc ! 824: ! 825: Interdependence of Patterns ! 826: =========================== ! 827: ! 828: Every machine description must have a named pattern for each of the ! 829: conditional branch names `bCOND'. The recognition template must ! 830: always have the form ! 831: ! 832: (set (pc) ! 833: (if_then_else (COND (cc0) (const_int 0)) ! 834: (label_ref (match_operand 0 "" "")) ! 835: (pc))) ! 836: ! 837: In addition, every machine description must have an anonymous pattern ! 838: for each of the possible reverse-conditional branches. These ! 839: patterns look like ! 840: ! 841: (set (pc) ! 842: (if_then_else (COND (cc0) (const_int 0)) ! 843: (pc) ! 844: (label_ref (match_operand 0 "" "")))) ! 845: ! 846: They are necessary because jump optimization can turn ! 847: direct-conditional branches into reverse-conditional branches. ! 848: ! 849: The compiler does more with RTL than just create it from patterns and ! 850: recognize the patterns: it can perform arithmetic expression codes ! 851: when constant values for their operands can be determined. As a ! 852: result, sometimes having one pattern can require other patterns. For ! 853: example, the Vax has no `and' instruction, but it has `and not' ! 854: instructions. Here is the definition of one of them: ! 855: ! 856: (define_insn "andcbsi2" ! 857: [(set (match_operand:SI 0 "general_operand" "") ! 858: (and:SI (match_dup 0) ! 859: (not:SI (match_operand:SI ! 860: 1 "general_operand" ""))))] ! 861: "" ! 862: "bicl2 %1,%0") ! 863: ! 864: If operand 1 is an explicit integer constant, an instruction ! 865: constructed using that pattern can be simplified into an `and' like ! 866: this: ! 867: ! 868: (set (reg:SI 41) ! 869: (and:SI (reg:SI 41) ! 870: (const_int 0xffff7fff))) ! 871: ! 872: (where the integer constant is the one's complement of what appeared ! 873: in the original instruction). ! 874: ! 875: To avoid a fatal error, the compiler must have a pattern that ! 876: recognizes such an instruction. Here is what is used: ! 877: ! 878: (define_insn "" ! 879: [(set (match_operand:SI 0 "general_operand" "") ! 880: (and:SI (match_dup 0) ! 881: (match_operand:SI 1 "general_operand" "")))] ! 882: "GET_CODE (operands[1]) == CONST_INT" ! 883: "* ! 884: { operands[1] ! 885: = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1])); ! 886: return \"bicl2 %1,%0\"; ! 887: }") ! 888: ! 889: Whereas a pattern to match a general `and' instruction is impossible ! 890: to support on the Vax, this pattern is possible because it matches ! 891: only a constant second argument: a special case that can be output as ! 892: an `and not' instruction. ! 893: ! 894: A ``compare'' instruction whose RTL looks like this: ! 895: ! 896: (set (cc0) (minus OPERAND (const_int 0))) ! 897: ! 898: may be simplified by optimization into a ``test'' like this: ! 899: ! 900: (set (cc0) OPERAND) ! 901: ! 902: So in the machine description, each ``compare'' pattern for an ! 903: integer mode must have a corresponding ``test'' pattern that will ! 904: match the result of such simplification. ! 905: ! 906: In some cases machines support instructions identical except for the ! 907: machine mode of one or more operands. For example, there may be ! 908: ``sign-extend halfword'' and ``sign-extend byte'' instructions whose ! 909: patterns are ! 910: ! 911: (set (match_operand:SI 0 ...) ! 912: (extend:SI (match_operand:HI 1 ...))) ! 913: ! 914: (set (match_operand:SI 0 ...) ! 915: (extend:SI (match_operand:QI 1 ...))) ! 916: ! 917: Constant integers do not specify a machine mode, so an instruction to ! 918: extend a constant value could match either pattern. The pattern it ! 919: actually will match is the one that appears first in the file. For ! 920: correct results, this must be the one for the widest possible mode ! 921: (`HImode', here). If the pattern matches the `QImode' instruction, ! 922: the results will be incorrect if the constant value does not actually ! 923: fit that mode. ! 924: ! 925: Such instructions to extend constants are rarely generated because ! 926: they are optimized away, but they do occasionally happen in ! 927: nonoptimized compilations. ! 928: ! 929: When an instruction has the constraint letter `o', the reload pass ! 930: may generate instructions which copy a nonoffsetable address into an ! 931: index register. The idea is that the register can be used as a ! 932: replacement offsetable address. In order for these generated ! 933: instructions to work, there must be patterns to copy any kind of ! 934: valid address into a register. ! 935: ! 936: Most older machine designs have ``load address'' instructions which ! 937: do just what is needed here. Some RISC machines do not advertise ! 938: such instructions, but the possible addresses on these machines are ! 939: very limited, so it is easy to fake them. ! 940: ! 941: Auto-increment and auto-decrement addresses are an exception; there ! 942: need not be an instruction that can copy such an address into a ! 943: register, because reload handles these cases in a different manner. ! 944: ! 945: ! 946: ! 947: File: gcc.info, Node: Jump Patterns, Next: Peephole Definitions, Prev: Dependent Patterns, Up: Machine Desc ! 948: ! 949: Defining Jump Instruction Patterns ! 950: ================================== ! 951: ! 952: GNU CC assumes that the machine has a condition code. A comparison ! 953: insn sets the condition code, recording the results of both signed ! 954: and unsigned comparison of the given operands. A separate branch ! 955: insn tests the condition code and branches or not according its ! 956: value. The branch insns come in distinct signed and unsigned ! 957: flavors. Many common machines, such as the Vax, the 68000 and the ! 958: 32000, work this way. ! 959: ! 960: Some machines have distinct signed and unsigned compare instructions, ! 961: and only one set of conditional branch instructions. The easiest way ! 962: to handle these machines is to treat them just like the others until ! 963: the final stage where assembly code is written. At this time, when ! 964: outputting code for the compare instruction, peek ahead at the ! 965: following branch using `NEXT_INSN (insn)'. (The variable `insn' ! 966: refers to the insn being output, in the output-writing code in an ! 967: instruction pattern.) If the RTL says that is an unsigned branch, ! 968: output an unsigned compare; otherwise output a signed compare. When ! 969: the branch itself is output, you can treat signed and unsigned ! 970: branches identically. ! 971: ! 972: The reason you can do this is that GNU CC always generates a pair of ! 973: consecutive RTL insns, one to set the condition code and one to test ! 974: it, and keeps the pair inviolate until the end. ! 975: ! 976: To go with this technique, you must define the machine-description ! 977: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no ! 978: compare instruction is superfluous. ! 979: ! 980: Some machines have compare-and-branch instructions and no condition ! 981: code. A similar technique works for them. When it is time to ! 982: ``output'' a compare instruction, record its operands in two static ! 983: variables. When outputting the branch-on-condition-code instruction ! 984: that follows, actually output a compare-and-branch instruction that ! 985: uses the remembered operands. ! 986: ! 987: It also works to define patterns for compare-and-branch instructions. ! 988: In optimizing compilation, the pair of compare and branch ! 989: instructions will be combined accoprding to these patterns. But this ! 990: does not happen if optimization is not requested. So you must use ! 991: one of the solutions above in addition to any special patterns you ! 992: define. ! 993: ! 994: ! 995: ! 996: File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Jump Patterns, Up: Machine Desc ! 997: ! 998: Defining Machine-Specific Peephole Optimizers ! 999: ============================================= ! 1000: ! 1001: In addition to instruction patterns the `md' file may contain ! 1002: definitions of machine-specific peephole optimizations. ! 1003: ! 1004: The combiner does not notice certain peephole optimizations when the ! 1005: data flow in the program does not suggest that it should try them. ! 1006: For example, sometimes two consecutive insns related in purpose can ! 1007: be combined even though the second one does not appear to use a ! 1008: register computed in the first one. A machine-specific peephole ! 1009: optimizer can detect such opportunities. ! 1010: ! 1011: A definition looks like this: ! 1012: ! 1013: (define_peephole ! 1014: [INSN-PATTERN-1 ! 1015: INSN-PATTERN-2 ! 1016: ...] ! 1017: "CONDITION" ! 1018: "TEMPLATE" ! 1019: "MACHINE-SPECIFIC INFO") ! 1020: ! 1021: The last string operand may be omitted if you are not using any ! 1022: machine-specific information in this machine description. If ! 1023: present, it must obey the same rules as in a `define_insn'. ! 1024: ! 1025: In this skeleton, INSN-PATTERN-1 and so on are patterns to match ! 1026: consecutive instructions. The optimization applies to a sequence of ! 1027: instructions when INSN-PATTERN-1 matches the first one, ! 1028: INSN-PATTERN-2 matches the next, and so on. ! 1029: ! 1030: INSN-PATTERN-1 and so on look *almost* like the second operand of ! 1031: `define_insn'. There is one important difference: this pattern is an ! 1032: RTX, not a vector. If the `define_insn' pattern would be a vector of ! 1033: one element, the INSN-PATTERN should be just that element, no vector. ! 1034: If the `define_insn' pattern would have multiple elements then the ! 1035: INSN-PATTERN must place the vector inside an explicit `parallel' RTX. ! 1036: ! 1037: The operands of the instructions are matched with `match_operands' ! 1038: and `match_dup', as usual). What is not usual is that the operand ! 1039: numbers apply to all the instruction patterns in the definition. So, ! 1040: you can check for identical operands in two instructions by using ! 1041: `match_operand' in one instruction and `match_dup' in the other. ! 1042: ! 1043: The operand constraints used in `match_operand' patterns do not have ! 1044: any direct effect on the applicability of the optimization, but they ! 1045: will be validated afterward, so write constraints that are sure to ! 1046: fit whenever the optimization is applied. It is safe to use `"g"' ! 1047: for each operand. ! 1048: ! 1049: Once a sequence of instructions matches the patterns, the CONDITION ! 1050: is checked. This is a C expression which makes the final decision ! 1051: whether to perform the optimization (do so if the expression is ! 1052: nonzero). If CONDITION is omitted (in other words, the string is ! 1053: empty) then the optimization is applied to every sequence of ! 1054: instructions that matches the patterns. ! 1055: ! 1056: The defined peephole optimizations are applied after register ! 1057: allocation is complete. Therefore, the optimizer can check which ! 1058: operands have ended up in which kinds of registers, just by looking ! 1059: at the operands. ! 1060: ! 1061: The way to refer to the operands in CONDITION is to write ! 1062: `operands[I]' for operand number I (as matched by `(match_operand I ! 1063: ...)'). Use the variable `insn' to refer to the last of the insns ! 1064: being matched; use `PREV_INSN' to find the preceding insns (but be ! 1065: careful to skip over any `note' insns that intervene). ! 1066: ! 1067: When optimizing computations with intermediate results, you can use ! 1068: CONDITION to match only when the intermediate results are not used ! 1069: elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where ! 1070: INSN is the insn in which you expect the value to be used for the ! 1071: last time (from the value of `insn', together with use of ! 1072: `PREV_INSN'), and OP is the intermediate value (from `operands[I]'). ! 1073: ! 1074: Applying the optimization means replacing the sequence of ! 1075: instructions with one new instruction. The TEMPLATE controls ! 1076: ultimate output of assembler code for this combined instruction. It ! 1077: works exactly like the template of a `define_insn'. Operand numbers ! 1078: in this template are the same ones used in matching the original ! 1079: sequence of instructions. ! 1080: ! 1081: The result of a defined peephole optimizer does not need to match any ! 1082: of the instruction patterns, and it does not have an opportunity to ! 1083: match them. The peephole optimizer definition itself serves as the ! 1084: instruction pattern to control how the instruction is output. ! 1085: ! 1086: Defined peephole optimizers are run in the last jump optimization ! 1087: pass, so the instructions they produce are never combined or ! 1088: rearranged automatically in any way. ! 1089: ! 1090: Here is an example, taken from the 68000 machine description: ! 1091: ! 1092: (define_peephole ! 1093: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) ! 1094: (set (match_operand:DF 0 "register_operand" "f") ! 1095: (match_operand:DF 1 "register_operand" "ad"))] ! 1096: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" ! 1097: "* ! 1098: { ! 1099: rtx xoperands[2]; ! 1100: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); ! 1101: #ifdef MOTOROLA ! 1102: output_asm_insn (\"move.l %1,(sp)\", xoperands); ! 1103: output_asm_insn (\"move.l %1,-(sp)\", operands); ! 1104: return \"fmove.d (sp)+,%0\"; ! 1105: #else ! 1106: output_asm_insn (\"movel %1,sp@\", xoperands); ! 1107: output_asm_insn (\"movel %1,sp@-\", operands); ! 1108: return \"fmoved sp@+,%0\"; ! 1109: #endif ! 1110: } ! 1111: ") ! 1112: ! 1113: The effect of this optimization is to change ! 1114: ! 1115: jbsr _foobar ! 1116: addql #4,sp ! 1117: movel d1,sp@- ! 1118: movel d0,sp@- ! 1119: fmoved sp@+,fp0 ! 1120: ! 1121: into ! 1122: ! 1123: jbsr _foobar ! 1124: movel d1,sp@ ! 1125: movel d0,sp@- ! 1126: fmoved sp@+,fp0 ! 1127: ! 1128:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.