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