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