![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-9 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-9 CVS log | Up to [GCC 2.x] / gcc |
1.1 ! 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: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc ! 28: ! 29: Everything about Instruction Patterns ! 30: ===================================== ! 31: ! 32: Each instruction pattern contains an incomplete RTL expression, ! 33: with pieces to be filled in later, operand constraints that restrict ! 34: how the pieces can be filled in, and an output pattern or C code to ! 35: generate the assembler output, all wrapped up in a `define_insn' ! 36: expression. ! 37: ! 38: A `define_insn' is an RTL expression containing four or five ! 39: operands: ! 40: ! 41: 1. An optional name. The presence of a name indicate that this ! 42: instruction pattern can perform a certain standard job for the ! 43: RTL-generation pass of the compiler. This pass knows certain ! 44: names and will use the instruction patterns with those names, if ! 45: the names are defined in the machine description. ! 46: ! 47: The absence of a name is indicated by writing an empty string ! 48: where the name should go. Nameless instruction patterns are never ! 49: used for generating RTL code, but they may permit several simpler ! 50: insns to be combined later on. ! 51: ! 52: Names that are not thus known and used in RTL-generation have ! 53: no effect; they are equivalent to no name at all. ! 54: ! 55: 2. The "RTL template" (*note RTL Template::.) is a vector of ! 56: incomplete RTL expressions which show what the instruction should ! 57: look like. It is incomplete because it may contain ! 58: `match_operand', `match_operator', and `match_dup' expressions ! 59: that stand for operands of the instruction. ! 60: ! 61: If the vector has only one element, that element is the ! 62: template for the instruction pattern. If the vector has multiple ! 63: elements, then the instruction pattern is a `parallel' expression ! 64: containing the elements described. ! 65: ! 66: 3. A condition. This is a string which contains a C expression that ! 67: is the final test to decide whether an insn body matches this ! 68: pattern. ! 69: ! 70: For a named pattern, the condition (if present) may not depend ! 71: on the data in the insn being matched, but only the ! 72: target-machine-type flags. The compiler needs to test these ! 73: conditions during initialization in order to learn exactly which ! 74: named instructions are available in a particular run. ! 75: ! 76: For nameless patterns, the condition is applied only when ! 77: matching an individual insn, and only after the insn has matched ! 78: the pattern's recognition template. The insn's operands may be ! 79: found in the vector `operands'. ! 80: ! 81: 4. The "output template": a string that says how to output matching ! 82: insns as assembler code. `%' in this string specifies where to ! 83: substitute the value of an operand. *Note Output Template::. ! 84: ! 85: When simple substitution isn't general enough, you can specify ! 86: a piece of C code to compute the output. *Note Output ! 87: Statement::. ! 88: ! 89: 5. Optionally, a vector containing the values of attributes for ! 90: insns matching this pattern. *Note Insn Attributes::. ! 91: ! 92: ! 93: File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc ! 94: ! 95: Example of `define_insn' ! 96: ======================== ! 97: ! 98: Here is an actual example of an instruction pattern, for the ! 99: 68000/68020. ! 100: ! 101: (define_insn "tstsi" ! 102: [(set (cc0) ! 103: (match_operand:SI 0 "general_operand" "rm"))] ! 104: "" ! 105: "* ! 106: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) ! 107: return \"tstl %0\"; ! 108: return \"cmpl #0,%0\"; }") ! 109: ! 110: This is an instruction that sets the condition codes based on the ! 111: value of a general operand. It has no condition, so any insn whose ! 112: RTL description has the form shown may be handled according to this ! 113: pattern. The name `tstsi' means "test a `SImode' value" and tells the ! 114: RTL generation pass that, when it is necessary to test such a value, ! 115: an insn to do so can be constructed using this pattern. ! 116: ! 117: The output control string is a piece of C code which chooses which ! 118: output template to return based on the kind of operand and the specific ! 119: type of CPU for which code is being generated. ! 120: ! 121: `"rm"' is an operand constraint. Its meaning is explained below. ! 122: ! 123: ! 124: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc ! 125: ! 126: RTL Template for Generating and Recognizing Insns ! 127: ================================================= ! 128: ! 129: The RTL template is used to define which insns match the particular ! 130: pattern and how to find their operands. For named patterns, the RTL ! 131: template also says how to construct an insn from specified operands. ! 132: ! 133: Construction involves substituting specified operands into a copy ! 134: of the template. Matching involves determining the values that serve ! 135: as the operands in the insn being matched. Both of these activities ! 136: are controlled by special expression types that direct matching and ! 137: substitution of the operands. ! 138: ! 139: `(match_operand:M N PREDICATE CONSTRAINT)' ! 140: This expression is a placeholder for operand number N of the ! 141: insn. When constructing an insn, operand number N will be ! 142: substituted at this point. When matching an insn, whatever ! 143: appears at this position in the insn will be taken as operand ! 144: number N; but it must satisfy PREDICATE or this instruction ! 145: pattern will not match at all. ! 146: ! 147: Operand numbers must be chosen consecutively counting from zero in ! 148: each instruction pattern. There may be only one `match_operand' ! 149: expression in the pattern for each operand number. Usually ! 150: operands are numbered in the order of appearance in ! 151: `match_operand' expressions. ! 152: ! 153: PREDICATE is a string that is the name of a C function that ! 154: accepts two arguments, an expression and a machine mode. During ! 155: matching, the function will be called with the putative operand ! 156: as the expression and M as the mode argument (if M is not ! 157: specified, `VOIDmode' will be used, which normally causes ! 158: PREDICATE to accept any mode). If it returns zero, this ! 159: instruction pattern fails to match. PREDICATE may be an empty ! 160: string; then it means no test is to be done on the operand, so ! 161: anything which occurs in this position is valid. ! 162: ! 163: Most of the time, PREDICATE will reject modes other than M--but ! 164: not always. For example, the predicate `address_operand' uses M ! 165: as the mode of memory ref that the address should be valid for. ! 166: Many predicates accept `const_int' nodes even though their mode is ! 167: `VOIDmode'. ! 168: ! 169: CONSTRAINT controls reloading and the choice of the best register ! 170: class to use for a value, as explained later (*note ! 171: Constraints::.). ! 172: ! 173: People are often unclear on the difference between the constraint ! 174: and the predicate. The predicate helps decide whether a given ! 175: insn matches the pattern. The constraint plays no role in this ! 176: decision; instead, it controls various decisions in the case of ! 177: an insn which does match. ! 178: ! 179: On CISC machines, PREDICATE is most often `"general_operand"'. ! 180: This function checks that the putative operand is either a ! 181: constant, a register or a memory reference, and that it is valid ! 182: for mode M. ! 183: ! 184: For an operand that must be a register, PREDICATE should be ! 185: `"register_operand"'. It would be valid to use ! 186: `"general_operand"', since the reload pass would copy any ! 187: non-register operands through registers, but this would make GNU ! 188: CC do extra work, it would prevent invariant operands (such as ! 189: constant) from being removed from loops, and it would prevent the ! 190: register allocator from doing the best possible job. On RISC ! 191: machines, it is usually most efficient to allow PREDICATE to ! 192: accept only objects that the constraints allow. ! 193: ! 194: For an operand that must be a constant, either use ! 195: `"immediate_operand"' for PREDICATE, or make the instruction ! 196: pattern's extra condition require a constant, or both. You cannot ! 197: expect the constraints to do this work! If the constraints allow ! 198: only constants, but the predicate allows something else, the ! 199: compiler will crash when that case arises. ! 200: ! 201: `(match_scratch:M N CONSTRAINT)' ! 202: This expression is also a placeholder for operand number N and ! 203: indicates that operand must be a `scratch' or `reg' expression. ! 204: ! 205: When matching patterns, this is completely equivalent to ! 206: ! 207: (match_operand:M N "scratch_operand" PRED) ! 208: ! 209: but, when generating RTL, it produces a (`scratch':M) expression. ! 210: ! 211: If the last few expressions in a `parallel' are `clobber' ! 212: expressions whose operands are either a hard register or ! 213: `match_scratch', the combiner can add them when necessary. *Note ! 214: Side Effects::. ! 215: ! 216: `(match_dup N)' ! 217: This expression is also a placeholder for operand number N. It ! 218: is used when the operand needs to appear more than once in the ! 219: insn. ! 220: ! 221: In construction, `match_dup' behaves exactly like ! 222: `match_operand': the operand is substituted into the insn being ! 223: constructed. But in matching, `match_dup' behaves differently. ! 224: It assumes that operand number N has already been determined by a ! 225: `match_operand' appearing earlier in the recognition template, ! 226: and it matches only an identical-looking expression. ! 227: ! 228: `(match_operator:M N PREDICATE [OPERANDS...])' ! 229: This pattern is a kind of placeholder for a variable RTL ! 230: expression code. ! 231: ! 232: When constructing an insn, it stands for an RTL expression whose ! 233: expression code is taken from that of operand N, and whose ! 234: operands are constructed from the patterns OPERANDS. ! 235: ! 236: When matching an expression, it matches an expression if the ! 237: function PREDICATE returns nonzero on that expression *and* the ! 238: patterns OPERANDS match the operands of the expression. ! 239: ! 240: Suppose that the function `commutative_operator' is defined as ! 241: follows, to match any expression whose operator is one of the ! 242: commutative arithmetic operators of RTL and whose mode is MODE: ! 243: ! 244: int ! 245: commutative_operator (x, mode) ! 246: rtx x; ! 247: enum machine_mode mode; ! 248: { ! 249: enum rtx_code code = GET_CODE (x); ! 250: if (GET_MODE (x) != mode) ! 251: return 0; ! 252: return GET_RTX_CLASS (code) == 'c' || code == EQ || code == NE; ! 253: } ! 254: ! 255: Then the following pattern will match any RTL expression ! 256: consisting of a commutative operator applied to two general ! 257: operands: ! 258: ! 259: (match_operator:SI 3 "commutative_operator" ! 260: [(match_operand:SI 1 "general_operand" "g") ! 261: (match_operand:SI 2 "general_operand" "g")]) ! 262: ! 263: Here the vector `[OPERANDS...]' contains two patterns because the ! 264: expressions to be matched all contain two operands. ! 265: ! 266: When this pattern does match, the two operands of the commutative ! 267: operator are recorded as operands 1 and 2 of the insn. (This is ! 268: done by the two instances of `match_operand'.) Operand 3 of the ! 269: insn will be the entire commutative expression: use `GET_CODE ! 270: (operands[3])' to see which commutative operator was used. ! 271: ! 272: The machine mode M of `match_operator' works like that of ! 273: `match_operand': it is passed as the second argument to the ! 274: predicate function, and that function is solely responsible for ! 275: deciding whether the expression to be matched "has" that mode. ! 276: ! 277: When constructing an insn, argument 3 of the gen-function will ! 278: specify the operation (i.e. the expression code) for the ! 279: expression to be made. It should be an RTL expression, whose ! 280: expression code is copied into a new expression whose operands ! 281: are arguments 1 and 2 of the gen-function. The subexpressions of ! 282: argument 3 are not used; only its expression code matters. ! 283: ! 284: When `match_operator' is used in a pattern for matching an insn, ! 285: it usually best if the operand number of the `match_operator' is ! 286: higher than that of the actual operands of the insn. This ! 287: improves register allocation because the register allocator often ! 288: looks at operands 1 and 2 of insns to see if it can do register ! 289: tying. ! 290: ! 291: There is no way to specify constraints in `match_operator'. The ! 292: operand of the insn which corresponds to the `match_operator' ! 293: never has any constraints because it is never reloaded as a whole. ! 294: However, if parts of its OPERANDS are matched by `match_operand' ! 295: patterns, those parts may have constraints of their own. ! 296: ! 297: `(address (match_operand:M N "address_operand" ""))' ! 298: This complex of expressions is a placeholder for an operand number ! 299: N in a "load address" instruction: an operand which specifies a ! 300: memory location in the usual way, but for which the actual operand ! 301: value used is the address of the location, not the contents of the ! 302: location. ! 303: ! 304: `address' expressions never appear in RTL code, only in machine ! 305: descriptions. And they are used only in machine descriptions ! 306: that do not use the operand constraint feature. When operand ! 307: constraints are in use, the letter `p' in the constraint serves ! 308: this purpose. ! 309: ! 310: M is the machine mode of the *memory location being addressed*, ! 311: not the machine mode of the address itself. That mode is always ! 312: the same on a given target machine (it is `Pmode', which normally ! 313: is `SImode'), so there is no point in mentioning it; thus, no ! 314: machine mode is written in the `address' expression. If some day ! 315: support is added for machines in which addresses of different ! 316: kinds of objects appear differently or are used differently (such ! 317: as the PDP-10), different formats would perhaps need different ! 318: machine modes and these modes might be written in the `address' ! 319: expression. ! 320: ! 321: ! 322: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc ! 323: ! 324: Output Templates and Operand Substitution ! 325: ========================================= ! 326: ! 327: The "output template" is a string which specifies how to output the ! 328: assembler code for an instruction pattern. Most of the template is a ! 329: fixed string which is output literally. The character `%' is used to ! 330: specify where to substitute an operand; it can also be used to ! 331: identify places where different variants of the assembler require ! 332: different syntax. ! 333: ! 334: In the simplest case, a `%' followed by a digit N says to output ! 335: operand N at that point in the string. ! 336: ! 337: `%' followed by a letter and a digit says to output an operand in an ! 338: alternate fashion. Four letters have standard, built-in meanings ! 339: described below. The machine description macro `PRINT_OPERAND' can ! 340: define additional letters with nonstandard meanings. ! 341: ! 342: `%cDIGIT' can be used to substitute an operand that is a constant ! 343: value without the syntax that normally indicates an immediate operand. ! 344: ! 345: `%nDIGIT' is like `%cDIGIT' except that the value of the constant ! 346: is negated before printing. ! 347: ! 348: `%aDIGIT' can be used to substitute an operand as if it were a ! 349: memory reference, with the actual operand treated as the address. ! 350: This may be useful when outputting a "load address" instruction, ! 351: because often the assembler syntax for such an instruction requires ! 352: you to write the operand as if it were a memory reference. ! 353: ! 354: `%lDIGIT' is used to substitute a `label_ref' into a jump ! 355: instruction. ! 356: ! 357: `%' followed by a punctuation character specifies a substitution ! 358: that does not use an operand. Only one case is standard: `%%' outputs ! 359: a `%' into the assembler code. Other nonstandard cases can be defined ! 360: in the `PRINT_OPERAND' macro. You must also define which punctuation ! 361: characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. ! 362: ! 363: The template may generate multiple assembler instructions. Write ! 364: the text for the instructions, with `\;' between them. ! 365: ! 366: When the RTL contains two operands which are required by constraint ! 367: to match each other, the output template must refer only to the ! 368: lower-numbered operand. Matching operands are not always identical, ! 369: and the rest of the compiler arranges to put the proper RTL expression ! 370: for printing into the lower-numbered operand. ! 371: ! 372: One use of nonstandard letters or punctuation following `%' is to ! 373: distinguish between different assembler languages for the same ! 374: machine; for example, Motorola syntax versus MIT syntax for the 68000. ! 375: Motorola syntax requires periods in most opcode names, while MIT ! 376: syntax does not. For example, the opcode `movel' in MIT syntax is ! 377: `move.l' in Motorola syntax. The same file of patterns is used for ! 378: both kinds of output syntax, but the character sequence `%.' is used ! 379: in each place where Motorola syntax wants a period. The ! 380: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to ! 381: output a period; the macro for MIT syntax defines it to do nothing. ! 382: ! 383: ! 384: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc ! 385: ! 386: C Statements for Generating Assembler Output ! 387: ============================================ ! 388: ! 389: Often a single fixed template string cannot produce correct and ! 390: efficient assembler code for all the cases that are recognized by a ! 391: single instruction pattern. For example, the opcodes may depend on ! 392: the kinds of operands; or some unfortunate combinations of operands ! 393: may require extra machine instructions. ! 394: ! 395: If the output control string starts with a `@', then it is actually ! 396: a series of templates, each on a separate line. (Blank lines and ! 397: leading spaces and tabs are ignored.) The templates correspond to the ! 398: pattern's constraint alternatives (*note Multi-Alternative::.). For ! 399: example, if a target machine has a two-address add instruction `addr' ! 400: to add into a register and another `addm' to add a register to memory, ! 401: you might write this pattern: ! 402: ! 403: (define_insn "addsi3" ! 404: [(set (match_operand:SI 0 "general_operand" "r,m") ! 405: (plus:SI (match_operand:SI 1 "general_operand" "0,0") ! 406: (match_operand:SI 2 "general_operand" "g,r")))] ! 407: "" ! 408: "@ ! 409: addr %1,%0 ! 410: addm %1,%0") ! 411: ! 412: If the output control string starts with a `*', then it is not an ! 413: output template but rather a piece of C program that should compute a ! 414: template. It should execute a `return' statement to return the ! 415: template-string you want. Most such templates use C string literals, ! 416: which require doublequote characters to delimit them. To include these ! 417: doublequote characters in the string, prefix each one with `\'. ! 418: ! 419: The operands may be found in the array `operands', whose C data type ! 420: is `rtx []'. ! 421: ! 422: It is very common to select different ways of generating assembler ! 423: code based on whether an immediate operand is within a certain range. ! 424: Be careful when doing this, because the result of `INTVAL' is an ! 425: integer on the host machine. If the host machine has more bits in an ! 426: `int' than the target machine has in the mode in which the constant ! 427: will be used, then some of the bits you get from `INTVAL' will be ! 428: superfluous. For proper results, you must carefully disregard the ! 429: values of those bits. ! 430: ! 431: It is possible to output an assembler instruction and then go on to ! 432: output or compute more of them, using the subroutine ! 433: `output_asm_insn'. This receives two arguments: a template-string and ! 434: a vector of operands. The vector may be `operands', or it may be ! 435: another array of `rtx' that you declare locally and initialize ! 436: yourself. ! 437: ! 438: When an insn pattern has multiple alternatives in its constraints, ! 439: often the appearance of the assembler code is determined mostly by ! 440: which alternative was matched. When this is so, the C code can test ! 441: the variable `which_alternative', which is the ordinal number of the ! 442: alternative that was actually satisfied (0 for the first, 1 for the ! 443: second alternative, etc.). ! 444: ! 445: For example, suppose there are two opcodes for storing zero, ! 446: `clrreg' for registers and `clrmem' for memory locations. Here is how ! 447: a pattern could use `which_alternative' to choose between them: ! 448: ! 449: (define_insn "" ! 450: [(set (match_operand:SI 0 "general_operand" "r,m") ! 451: (const_int 0))] ! 452: "" ! 453: "* ! 454: return (which_alternative == 0 ! 455: ? \"clrreg %0\" : \"clrmem %0\"); ! 456: ") ! 457: ! 458: The example above, where the assembler code to generate was ! 459: *solely* determined by the alternative, could also have been specified ! 460: as follows, having the output control string start with a `@': ! 461: ! 462: (define_insn "" ! 463: [(set (match_operand:SI 0 "general_operand" "r,m") ! 464: (const_int 0))] ! 465: "" ! 466: "@ ! 467: clrreg %0 ! 468: clrmem %0") ! 469: ! 470: ! 471: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc ! 472: ! 473: Operand Constraints ! 474: =================== ! 475: ! 476: Each `match_operand' in an instruction pattern can specify a ! 477: constraint for the type of operands allowed. Constraints can say ! 478: whether an operand may be in a register, and which kinds of register; ! 479: whether the operand can be a memory reference, and which kinds of ! 480: address; whether the operand may be an immediate constant, and which ! 481: possible values it may have. Constraints can also require two ! 482: operands to match. ! 483: ! 484: * Menu: ! 485: ! 486: * Simple Constraints:: Basic use of constraints. ! 487: * Multi-Alternative:: When an insn has two alternative constraint-patterns. ! 488: * Class Preferences:: Constraints guide which hard register to put things in. ! 489: * Modifiers:: More precise control over effects of constraints. ! 490: * No Constraints:: Describing a clean machine without constraints. ! 491: ! 492: ! 493: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints ! 494: ! 495: Simple Constraints ! 496: ------------------ ! 497: ! 498: The simplest kind of constraint is a string full of letters, each of ! 499: which describes one kind of operand that is permitted. Here are the ! 500: letters that are allowed: ! 501: ! 502: `m' ! 503: A memory operand is allowed, with any kind of address that the ! 504: machine supports in general. ! 505: ! 506: `o' ! 507: A memory operand is allowed, but only if the address is ! 508: "offsettable". This means that adding a small integer (actually, ! 509: the width in bytes of the operand, as determined by its machine ! 510: mode) may be added to the address and the result is also a valid ! 511: memory address. ! 512: ! 513: For example, an address which is constant is offsettable; so is an ! 514: address that is the sum of a register and a constant (as long as a ! 515: slightly larger constant is also within the range of ! 516: address-offsets supported by the machine); but an autoincrement ! 517: or autodecrement address is not offsettable. More complicated ! 518: indirect/indexed addresses may or may not be offsettable ! 519: depending on the other addressing modes that the machine supports. ! 520: ! 521: Note that in an output operand which can be matched by another ! 522: operand, the constraint letter `o' is valid only when accompanied ! 523: by both `<' (if the target machine has predecrement addressing) ! 524: and `>' (if the target machine has preincrement addressing). ! 525: ! 526: `V' ! 527: A memory operand that is not offsettable. In other words, ! 528: anything that would fit the `m' constraint but not the `o' ! 529: constraint. ! 530: ! 531: `<' ! 532: A memory operand with autodecrement addressing (either ! 533: predecrement or postdecrement) is allowed. ! 534: ! 535: `>' ! 536: A memory operand with autoincrement addressing (either ! 537: preincrement or postincrement) is allowed. ! 538: ! 539: `r' ! 540: A register operand is allowed provided that it is in a general ! 541: register. ! 542: ! 543: `d', `a', `f', ... ! 544: Other letters can be defined in machine-dependent fashion to ! 545: stand for particular classes of registers. `d', `a' and `f' are ! 546: defined on the 68000/68020 to stand for data, address and floating ! 547: point registers. ! 548: ! 549: `i' ! 550: An immediate integer operand (one with constant value) is allowed. ! 551: This includes symbolic constants whose values will be known only ! 552: at assembly time. ! 553: ! 554: `n' ! 555: An immediate integer operand with a known numeric value is ! 556: allowed. Many systems cannot support assembly-time constants for ! 557: operands less than a word wide. Constraints for these operands ! 558: should use `n' rather than `i'. ! 559: ! 560: `I', `J', `K', ... `P' ! 561: Other letters in the range `I' through `P' may be defined in a ! 562: machine-dependent fashion to permit immediate integer operands ! 563: with explicit integer values in specified ranges. For example, ! 564: on the 68000, `I' is defined to stand for the range of values 1 ! 565: to 8. This is the range permitted as a shift count in the shift ! 566: instructions. ! 567: ! 568: `E' ! 569: An immediate floating operand (expression code `const_double') is ! 570: allowed, but only if the target floating point format is the same ! 571: as that of the host machine (on which the compiler is running). ! 572: ! 573: `F' ! 574: An immediate floating operand (expression code `const_double') is ! 575: allowed. ! 576: ! 577: `G', `H' ! 578: `G' and `H' may be defined in a machine-dependent fashion to ! 579: permit immediate floating operands in particular ranges of values. ! 580: ! 581: `s' ! 582: An immediate integer operand whose value is not an explicit ! 583: integer is allowed. ! 584: ! 585: This might appear strange; if an insn allows a constant operand ! 586: with a value not known at compile time, it certainly must allow ! 587: any known value. So why use `s' instead of `i'? Sometimes it ! 588: allows better code to be generated. ! 589: ! 590: For example, on the 68000 in a fullword instruction it is ! 591: possible to use an immediate operand; but if the immediate value ! 592: is between -128 and 127, better code results from loading the ! 593: value into a register and using the register. This is because ! 594: the load into the register can be done with a `moveq' ! 595: instruction. We arrange for this to happen by defining the ! 596: letter `K' to mean "any integer outside the range -128 to 127", ! 597: and then specifying `Ks' in the operand constraints. ! 598: ! 599: `g' ! 600: Any register, memory or immediate integer operand is allowed, ! 601: except for registers that are not general registers. ! 602: ! 603: `X' ! 604: Any operand whatsoever is allowed, even if it does not satisfy ! 605: `general_operand'. This is normally used in the constraint of a ! 606: `match_scratch' when certain alternatives will not actually ! 607: require a scratch register. ! 608: ! 609: `0', `1', `2', ... `9' ! 610: An operand that matches the specified operand number is allowed. ! 611: If a digit is used together with letters within the same ! 612: alternative, the digit should come last. ! 613: ! 614: This is called a "matching constraint" and what it really means is ! 615: that the assembler has only a single operand that fills two roles ! 616: considered separate in the RTL insn. For example, an add insn ! 617: has two input operands and one output operand in the RTL, but on ! 618: most machines an add instruction really has only two operands, ! 619: one of them an input-output operand. ! 620: ! 621: Matching constraints work only in circumstances like that add ! 622: insn. More precisely, the two operands that match must include ! 623: one input-only operand and one output-only operand. Moreover, ! 624: the digit must be a smaller number than the number of the operand ! 625: that uses it in the constraint. ! 626: ! 627: For operands to match in a particular case usually means that they ! 628: are identical-looking RTL expressions. But in a few special cases ! 629: specific kinds of dissimilarity are allowed. For example, `*x' ! 630: as an input operand will match `*x++' as an output operand. For ! 631: proper results in such cases, the output template should always ! 632: use the output-operand's number when printing the operand. ! 633: ! 634: `p' ! 635: An operand that is a valid memory address is allowed. This is ! 636: for "load address" and "push address" instructions. ! 637: ! 638: `p' in the constraint must be accompanied by `address_operand' as ! 639: the predicate in the `match_operand'. This predicate interprets ! 640: the mode specified in the `match_operand' as the mode of the ! 641: memory reference for which the address would be valid. ! 642: ! 643: `Q', `R', `S', ... `U' ! 644: Letters in the range `Q' through `U' may be defined in a ! 645: machine-dependent fashion to stand for arbitrary operand types. ! 646: The machine description macro `EXTRA_CONSTRAINT' is passed the ! 647: operand as its first argument and the constraint letter as its ! 648: second operand. ! 649: ! 650: A typical use for this would be to distinguish certain types of ! 651: memory references that affect other insn operands. ! 652: ! 653: Do not define these constraint letters to accept register ! 654: references (`reg'); the reload pass does not expect this and ! 655: would not handle it properly. ! 656: ! 657: In order to have valid assembler code, each operand must satisfy ! 658: its constraint. But a failure to do so does not prevent the pattern ! 659: from applying to an insn. Instead, it directs the compiler to modify ! 660: the code so that the constraint will be satisfied. Usually this is ! 661: done by copying an operand into a register. ! 662: ! 663: Contrast, therefore, the two instruction patterns that follow: ! 664: ! 665: (define_insn "" ! 666: [(set (match_operand:SI 0 "general_operand" "r") ! 667: (plus:SI (match_dup 0) ! 668: (match_operand:SI 1 "general_operand" "r")))] ! 669: "" ! 670: "...") ! 671: ! 672: which has two operands, one of which must appear in two places, and ! 673: ! 674: (define_insn "" ! 675: [(set (match_operand:SI 0 "general_operand" "r") ! 676: (plus:SI (match_operand:SI 1 "general_operand" "0") ! 677: (match_operand:SI 2 "general_operand" "r")))] ! 678: "" ! 679: "...") ! 680: ! 681: which has three operands, two of which are required by a constraint to ! 682: be identical. If we are considering an insn of the form ! 683: ! 684: (insn N PREV NEXT ! 685: (set (reg:SI 3) ! 686: (plus:SI (reg:SI 6) (reg:SI 109))) ! 687: ...) ! 688: ! 689: the first pattern would not apply at all, because this insn does not ! 690: contain two identical subexpressions in the right place. The pattern ! 691: would say, "That does not look like an add instruction; try other ! 692: patterns." The second pattern would say, "Yes, that's an add ! 693: instruction, but there is something wrong with it." It would direct ! 694: the reload pass of the compiler to generate additional insns to make ! 695: the constraint true. The results might look like this: ! 696: ! 697: (insn N2 PREV N ! 698: (set (reg:SI 3) (reg:SI 6)) ! 699: ...) ! 700: ! 701: (insn N N2 NEXT ! 702: (set (reg:SI 3) ! 703: (plus:SI (reg:SI 3) (reg:SI 109))) ! 704: ...) ! 705: ! 706: It is up to you to make sure that each operand, in each pattern, has ! 707: constraints that can handle any RTL expression that could be present ! 708: for that operand. (When multiple alternatives are in use, each ! 709: pattern must, for each possible combination of operand expressions, ! 710: have at least one alternative which can handle that combination of ! 711: operands.) The constraints don't need to *allow* any possible ! 712: operand--when this is the case, they do not constrain--but they must ! 713: at least point the way to reloading any possible operand so that it ! 714: will fit. ! 715: ! 716: * If the constraint accepts whatever operands the predicate permits, ! 717: there is no problem: reloading is never necessary for this ! 718: operand. ! 719: ! 720: For example, an operand whose constraints permit everything except ! 721: registers is safe provided its predicate rejects registers. ! 722: ! 723: An operand whose predicate accepts only constant values is safe ! 724: provided its constraints include the letter `i'. If any possible ! 725: constant value is accepted, then nothing less than `i' will do; ! 726: if the predicate is more selective, then the constraints may also ! 727: be more selective. ! 728: ! 729: * Any operand expression can be reloaded by copying it into a ! 730: register. So if an operand's constraints allow some kind of ! 731: register, it is certain to be safe. It need not permit all ! 732: classes of registers; the compiler knows how to copy a register ! 733: into another register of the proper class in order to make an ! 734: instruction valid. ! 735: ! 736: * A nonoffsettable memory reference can be reloaded by copying the ! 737: address into a register. So if the constraint uses the letter ! 738: `o', all memory references are taken care of. ! 739: ! 740: * A constant operand can be reloaded by allocating space in memory ! 741: to hold it as preinitialized data. Then the memory reference can ! 742: be used in place of the constant. So if the constraint uses the ! 743: letters `o' or `m', constant operands are not a problem. ! 744: ! 745: * If the constraint permits a constant and a pseudo register used ! 746: in an insn was not allocated to a hard register and is equivalent ! 747: to a constant, the register will be replaced with the constant. ! 748: If the predicate does not permit a constant and the insn is ! 749: re-recognized for some reason, the compiler will crash. Thus the ! 750: predicate must always recognize any objects allowed by the ! 751: constraint. ! 752: ! 753: If the operand's predicate can recognize registers, but the ! 754: constraint does not permit them, it can make the compiler crash. When ! 755: this operand happens to be a register, the reload pass will be ! 756: stymied, because it does not know how to copy a register temporarily ! 757: into memory. ! 758: ! 759: ! 760: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints ! 761: ! 762: Multiple Alternative Constraints ! 763: -------------------------------- ! 764: ! 765: Sometimes a single instruction has multiple alternative sets of ! 766: possible operands. For example, on the 68000, a logical-or ! 767: instruction can combine register or an immediate value into memory, or ! 768: it can combine any kind of operand into a register; but it cannot ! 769: combine one memory location into another. ! 770: ! 771: These constraints are represented as multiple alternatives. An ! 772: alternative can be described by a series of letters for each operand. ! 773: The overall constraint for an operand is made from the letters for ! 774: this operand from the first alternative, a comma, the letters for this ! 775: operand from the second alternative, a comma, and so on until the last ! 776: alternative. Here is how it is done for fullword logical-or on the ! 777: 68000: ! 778: ! 779: (define_insn "iorsi3" ! 780: [(set (match_operand:SI 0 "general_operand" "=m,d") ! 781: (ior:SI (match_operand:SI 1 "general_operand" "%0,0") ! 782: (match_operand:SI 2 "general_operand" "dKs,dmKs")))] ! 783: ...) ! 784: ! 785: The first alternative has `m' (memory) for operand 0, `0' for ! 786: operand 1 (meaning it must match operand 0), and `dKs' for operand 2. ! 787: The second alternative has `d' (data register) for operand 0, `0' for ! 788: operand 1, and `dmKs' for operand 2. The `=' and `%' in the ! 789: constraints apply to all the alternatives; their meaning is explained ! 790: in the next section (*note Class Preferences::.). ! 791: ! 792: If all the operands fit any one alternative, the instruction is ! 793: valid. Otherwise, for each alternative, the compiler counts how many ! 794: instructions must be added to copy the operands so that that ! 795: alternative applies. The alternative requiring the least copying is ! 796: chosen. If two alternatives need the same amount of copying, the one ! 797: that comes first is chosen. These choices can be altered with the `?' ! 798: and `!' characters: ! 799: ! 800: `?' ! 801: Disparage slightly the alternative that the `?' appears in, as a ! 802: choice when no alternative applies exactly. The compiler regards ! 803: this alternative as one unit more costly for each `?' that appears ! 804: in it. ! 805: ! 806: `!' ! 807: Disparage severely the alternative that the `!' appears in. This ! 808: alternative can still be used if it fits without reloading, but ! 809: if reloading is needed, some other alternative will be used. ! 810: ! 811: When an insn pattern has multiple alternatives in its constraints, ! 812: often the appearance of the assembler code is determined mostly by ! 813: which alternative was matched. When this is so, the C code for ! 814: writing the assembler code can use the variable `which_alternative', ! 815: which is the ordinal number of the alternative that was actually ! 816: satisfied (0 for the first, 1 for the second alternative, etc.). ! 817: *Note Output Statement::. ! 818: ! 819: ! 820: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints ! 821: ! 822: Register Class Preferences ! 823: -------------------------- ! 824: ! 825: The operand constraints have another function: they enable the ! 826: compiler to decide which kind of hardware register a pseudo register ! 827: is best allocated to. The compiler examines the constraints that ! 828: apply to the insns that use the pseudo register, looking for the ! 829: machine-dependent letters such as `d' and `a' that specify classes of ! 830: registers. The pseudo register is put in whichever class gets the ! 831: most "votes". The constraint letters `g' and `r' also vote: they vote ! 832: in favor of a general register. The machine description says which ! 833: registers are considered general. ! 834: ! 835: Of course, on some machines all registers are equivalent, and no ! 836: register classes are defined. Then none of this complexity is ! 837: relevant. ! 838: ! 839: ! 840: File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints ! 841: ! 842: Constraint Modifier Characters ! 843: ------------------------------ ! 844: ! 845: `=' ! 846: Means that this operand is write-only for this instruction: the ! 847: previous value is discarded and replaced by output data. ! 848: ! 849: `+' ! 850: Means that this operand is both read and written by the ! 851: instruction. ! 852: ! 853: When the compiler fixes up the operands to satisfy the ! 854: constraints, it needs to know which operands are inputs to the ! 855: instruction and which are outputs from it. `=' identifies an ! 856: output; `+' identifies an operand that is both input and output; ! 857: all other operands are assumed to be input only. ! 858: ! 859: `&' ! 860: Means (in a particular alternative) that this operand is written ! 861: before the instruction is finished using the input operands. ! 862: Therefore, this operand may not lie in a register that is used as ! 863: an input operand or as part of any memory address. ! 864: ! 865: `&' applies only to the alternative in which it is written. In ! 866: constraints with multiple alternatives, sometimes one alternative ! 867: requires `&' while others do not. See, for example, the `movdf' ! 868: insn of the 68000. ! 869: ! 870: `&' does not obviate the need to write `='. ! 871: ! 872: `%' ! 873: Declares the instruction to be commutative for this operand and ! 874: the following operand. This means that the compiler may ! 875: interchange the two operands if that is the cheapest way to make ! 876: all operands fit the constraints. This is often used in patterns ! 877: for addition instructions that really have only two operands: the ! 878: result must go in one of the arguments. Here for example, is how ! 879: the 68000 halfword-add instruction is defined: ! 880: ! 881: (define_insn "addhi3" ! 882: [(set (match_operand:HI 0 "general_operand" "=m,r") ! 883: (plus:HI (match_operand:HI 1 "general_operand" "%0,0") ! 884: (match_operand:HI 2 "general_operand" "di,g")))] ! 885: ...) ! 886: ! 887: `#' ! 888: Says that all following characters, up to the next comma, are to ! 889: be ignored as a constraint. They are significant only for ! 890: choosing register preferences. ! 891: ! 892: `*' ! 893: Says that the following character should be ignored when choosing ! 894: register preferences. `*' has no effect on the meaning of the ! 895: constraint as a constraint, and no effect on reloading. ! 896: ! 897: Here is an example: the 68000 has an instruction to sign-extend a ! 898: halfword in a data register, and can also sign-extend a value by ! 899: copying it into an address register. While either kind of ! 900: register is acceptable, the constraints on an address-register ! 901: destination are less strict, so it is best if register allocation ! 902: makes an address register its goal. Therefore, `*' is used so ! 903: that the `d' constraint letter (for data register) is ignored ! 904: when computing register preferences. ! 905: ! 906: (define_insn "extendhisi2" ! 907: [(set (match_operand:SI 0 "general_operand" "=*d,a") ! 908: (sign_extend:SI ! 909: (match_operand:HI 1 "general_operand" "0,g")))] ! 910: ...) ! 911: ! 912: ! 913: File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints ! 914: ! 915: Not Using Constraints ! 916: --------------------- ! 917: ! 918: Some machines are so clean that operand constraints are not ! 919: required. For example, on the Vax, an operand valid in one context is ! 920: valid in any other context. On such a machine, every operand ! 921: constraint would be `g', excepting only operands of "load address" ! 922: instructions which are written as if they referred to a memory ! 923: location's contents but actual refer to its address. They would have ! 924: constraint `p'. ! 925: ! 926: For such machines, instead of writing `g' and `p' for all the ! 927: constraints, you can choose to write a description with empty ! 928: constraints. Then you write `""' for the constraint in every ! 929: `match_operand'. Address operands are identified by writing an ! 930: `address' expression around the `match_operand', not by their ! 931: constraints. ! 932: ! 933: When the machine description has just empty constraints, certain ! 934: parts of compilation are skipped, making the compiler faster. However, ! 935: few machines actually do not need constraints; all machine descriptions ! 936: now in existence use constraints. ! 937: ! 938:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.