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