![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-16 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-16 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.9 ! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.8 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330 7: Boston, MA 02111-1307 USA 1.1.1.5 root 8: 1.1.1.8 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software 10: Foundation, Inc. 1.1 root 11: 1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 1.1 root 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.7 root 18: that the sections entitled "GNU General Public License," "Funding for 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are 20: included exactly as in the original, and provided that the entire 21: resulting derived work is distributed under the terms of a permission 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public 1.1.1.7 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight 28: `Look And Feel'", and this permission notice, may be included in 29: translations approved by the Free Software Foundation instead of in the 30: original English. 1.1.1.4 root 31: 32: 1.1.1.8 root 33: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 1.1.1.4 root 34: 1.1.1.8 root 35: RTL Template 36: ============ 1.1.1.5 root 37: 1.1.1.8 root 38: The RTL template is used to define which insns match the particular 39: pattern and how to find their operands. For named patterns, the RTL 40: template also says how to construct an insn from specified operands. 41: 42: Construction involves substituting specified operands into a copy of 43: the template. Matching involves determining the values that serve as 44: the operands in the insn being matched. Both of these activities are 45: controlled by special expression types that direct matching and 46: substitution of the operands. 47: 48: `(match_operand:M N PREDICATE CONSTRAINT)' 49: This expression is a placeholder for operand number N of the insn. 50: When constructing an insn, operand number N will be substituted 51: at this point. When matching an insn, whatever appears at this 52: position in the insn will be taken as operand number N; but it 53: must satisfy PREDICATE or this instruction pattern will not match 54: at all. 55: 56: Operand numbers must be chosen consecutively counting from zero in 57: each instruction pattern. There may be only one `match_operand' 58: expression in the pattern for each operand number. Usually 59: operands are numbered in the order of appearance in `match_operand' 60: expressions. 61: 62: PREDICATE is a string that is the name of a C function that 63: accepts two arguments, an expression and a machine mode. During 64: matching, the function will be called with the putative operand as 65: the expression and M as the mode argument (if M is not specified, 66: `VOIDmode' will be used, which normally causes PREDICATE to accept 67: any mode). If it returns zero, this instruction pattern fails to 68: match. PREDICATE may be an empty string; then it means no test is 69: to be done on the operand, so anything which occurs in this 70: position is valid. 71: 72: Most of the time, PREDICATE will reject modes other than M--but 73: not always. For example, the predicate `address_operand' uses M 74: as the mode of memory ref that the address should be valid for. 75: Many predicates accept `const_int' nodes even though their mode is 76: `VOIDmode'. 77: 78: CONSTRAINT controls reloading and the choice of the best register 79: class to use for a value, as explained later (*note 80: Constraints::.). 81: 82: People are often unclear on the difference between the constraint 83: and the predicate. The predicate helps decide whether a given 84: insn matches the pattern. The constraint plays no role in this 85: decision; instead, it controls various decisions in the case of an 86: insn which does match. 87: 88: On CISC machines, the most common PREDICATE is 89: `"general_operand"'. This function checks that the putative 90: operand is either a constant, a register or a memory reference, 91: and that it is valid for mode M. 92: 93: For an operand that must be a register, PREDICATE should be 94: `"register_operand"'. Using `"general_operand"' would be valid, 95: since the reload pass would copy any non-register operands through 96: registers, but this would make GNU CC do extra work, it would 97: prevent invariant operands (such as constant) from being removed 98: from loops, and it would prevent the register allocator from doing 99: the best possible job. On RISC machines, it is usually most 100: efficient to allow PREDICATE to accept only objects that the 101: constraints allow. 102: 103: For an operand that must be a constant, you must be sure to either 104: use `"immediate_operand"' for PREDICATE, or make the instruction 105: pattern's extra condition require a constant, or both. You cannot 106: expect the constraints to do this work! If the constraints allow 107: only constants, but the predicate allows something else, the 108: compiler will crash when that case arises. 109: 110: `(match_scratch:M N CONSTRAINT)' 111: This expression is also a placeholder for operand number N and 112: indicates that operand must be a `scratch' or `reg' expression. 113: 114: When matching patterns, this is equivalent to 115: 116: (match_operand:M N "scratch_operand" PRED) 117: 118: but, when generating RTL, it produces a (`scratch':M) expression. 119: 120: If the last few expressions in a `parallel' are `clobber' 121: expressions whose operands are either a hard register or 122: `match_scratch', the combiner can add or delete them when 123: necessary. *Note Side Effects::. 124: 125: `(match_dup N)' 126: This expression is also a placeholder for operand number N. It is 127: used when the operand needs to appear more than once in the insn. 128: 129: In construction, `match_dup' acts just like `match_operand': the 130: operand is substituted into the insn being constructed. But in 131: matching, `match_dup' behaves differently. It assumes that operand 132: number N has already been determined by a `match_operand' 133: appearing earlier in the recognition template, and it matches only 134: an identical-looking expression. 1.1.1.7 root 135: 1.1.1.8 root 136: `(match_operator:M N PREDICATE [OPERANDS...])' 137: This pattern is a kind of placeholder for a variable RTL expression 138: code. 1.1.1.7 root 139: 1.1.1.8 root 140: When constructing an insn, it stands for an RTL expression whose 141: expression code is taken from that of operand N, and whose 142: operands are constructed from the patterns OPERANDS. 143: 144: When matching an expression, it matches an expression if the 145: function PREDICATE returns nonzero on that expression *and* the 146: patterns OPERANDS match the operands of the expression. 147: 148: Suppose that the function `commutative_operator' is defined as 149: follows, to match any expression whose operator is one of the 150: commutative arithmetic operators of RTL and whose mode is MODE: 151: 152: int 153: commutative_operator (x, mode) 154: rtx x; 155: enum machine_mode mode; 156: { 157: enum rtx_code code = GET_CODE (x); 158: if (GET_MODE (x) != mode) 159: return 0; 160: return (GET_RTX_CLASS (code) == 'c' 161: || code == EQ || code == NE); 162: } 163: 164: Then the following pattern will match any RTL expression consisting 165: of a commutative operator applied to two general operands: 166: 167: (match_operator:SI 3 "commutative_operator" 168: [(match_operand:SI 1 "general_operand" "g") 169: (match_operand:SI 2 "general_operand" "g")]) 170: 171: Here the vector `[OPERANDS...]' contains two patterns because the 172: expressions to be matched all contain two operands. 173: 174: When this pattern does match, the two operands of the commutative 175: operator are recorded as operands 1 and 2 of the insn. (This is 176: done by the two instances of `match_operand'.) Operand 3 of the 177: insn will be the entire commutative expression: use `GET_CODE 178: (operands[3])' to see which commutative operator was used. 179: 180: The machine mode M of `match_operator' works like that of 181: `match_operand': it is passed as the second argument to the 182: predicate function, and that function is solely responsible for 183: deciding whether the expression to be matched "has" that mode. 184: 185: When constructing an insn, argument 3 of the gen-function will 186: specify the operation (i.e. the expression code) for the 187: expression to be made. It should be an RTL expression, whose 188: expression code is copied into a new expression whose operands are 189: arguments 1 and 2 of the gen-function. The subexpressions of 190: argument 3 are not used; only its expression code matters. 191: 192: When `match_operator' is used in a pattern for matching an insn, 193: it usually best if the operand number of the `match_operator' is 194: higher than that of the actual operands of the insn. This improves 195: register allocation because the register allocator often looks at 196: operands 1 and 2 of insns to see if it can do register tying. 197: 198: There is no way to specify constraints in `match_operator'. The 199: operand of the insn which corresponds to the `match_operator' 200: never has any constraints because it is never reloaded as a whole. 201: However, if parts of its OPERANDS are matched by `match_operand' 202: patterns, those parts may have constraints of their own. 203: 204: `(match_op_dup:M N[OPERANDS...])' 205: Like `match_dup', except that it applies to operators instead of 206: operands. When constructing an insn, operand number N will be 207: substituted at this point. But in matching, `match_op_dup' behaves 208: differently. It assumes that operand number N has already been 209: determined by a `match_operator' appearing earlier in the 210: recognition template, and it matches only an identical-looking 211: expression. 212: 213: `(match_parallel N PREDICATE [SUBPAT...])' 214: This pattern is a placeholder for an insn that consists of a 215: `parallel' expression with a variable number of elements. This 216: expression should only appear at the top level of an insn pattern. 217: 218: When constructing an insn, operand number N will be substituted at 219: this point. When matching an insn, it matches if the body of the 220: insn is a `parallel' expression with at least as many elements as 221: the vector of SUBPAT expressions in the `match_parallel', if each 222: SUBPAT matches the corresponding element of the `parallel', *and* 223: the function PREDICATE returns nonzero on the `parallel' that is 224: the body of the insn. It is the responsibility of the predicate 225: to validate elements of the `parallel' beyond those listed in the 226: `match_parallel'. 227: 228: A typical use of `match_parallel' is to match load and store 229: multiple expressions, which can contain a variable number of 230: elements in a `parallel'. For example, 1.1.1.7 root 231: 1.1.1.8 root 232: (define_insn "" 233: [(match_parallel 0 "load_multiple_operation" 234: [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 235: (match_operand:SI 2 "memory_operand" "m")) 236: (use (reg:SI 179)) 237: (clobber (reg:SI 179))])] 238: "" 239: "loadm 0,0,%1,%2") 240: 241: This example comes from `a29k.md'. The function 242: `load_multiple_operations' is defined in `a29k.c' and checks that 243: subsequent elements in the `parallel' are the same as the `set' in 244: the pattern, except that they are referencing subsequent registers 245: and memory locations. 246: 247: An insn that matches this pattern might look like: 248: 249: (parallel 250: [(set (reg:SI 20) (mem:SI (reg:SI 100))) 251: (use (reg:SI 179)) 252: (clobber (reg:SI 179)) 253: (set (reg:SI 21) 254: (mem:SI (plus:SI (reg:SI 100) 255: (const_int 4)))) 256: (set (reg:SI 22) 257: (mem:SI (plus:SI (reg:SI 100) 258: (const_int 8))))]) 259: 260: `(match_par_dup N [SUBPAT...])' 261: Like `match_op_dup', but for `match_parallel' instead of 262: `match_operator'. 263: 264: `(address (match_operand:M N "address_operand" ""))' 265: This complex of expressions is a placeholder for an operand number 266: N in a "load address" instruction: an operand which specifies a 267: memory location in the usual way, but for which the actual operand 268: value used is the address of the location, not the contents of the 269: location. 270: 271: `address' expressions never appear in RTL code, only in machine 272: descriptions. And they are used only in machine descriptions that 273: do not use the operand constraint feature. When operand 274: constraints are in use, the letter `p' in the constraint serves 275: this purpose. 276: 277: M is the machine mode of the *memory location being addressed*, 278: not the machine mode of the address itself. That mode is always 279: the same on a given target machine (it is `Pmode', which normally 280: is `SImode'), so there is no point in mentioning it; thus, no 281: machine mode is written in the `address' expression. If some day 282: support is added for machines in which addresses of different 283: kinds of objects appear differently or are used differently (such 284: as the PDP-10), different formats would perhaps need different 285: machine modes and these modes might be written in the `address' 286: expression. 1.1.1.7 root 287: 1.1.1.8 root 288: 289: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 1.1.1.7 root 290: 1.1.1.8 root 291: Output Templates and Operand Substitution 292: ========================================= 1.1.1.7 root 293: 1.1.1.8 root 294: The "output template" is a string which specifies how to output the 295: assembler code for an instruction pattern. Most of the template is a 296: fixed string which is output literally. The character `%' is used to 297: specify where to substitute an operand; it can also be used to identify 298: places where different variants of the assembler require different 299: syntax. 300: 301: In the simplest case, a `%' followed by a digit N says to output 302: operand N at that point in the string. 303: 304: `%' followed by a letter and a digit says to output an operand in an 305: alternate fashion. Four letters have standard, built-in meanings 306: described below. The machine description macro `PRINT_OPERAND' can 307: define additional letters with nonstandard meanings. 308: 309: `%cDIGIT' can be used to substitute an operand that is a constant 310: value without the syntax that normally indicates an immediate operand. 311: 312: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 313: negated before printing. 314: 315: `%aDIGIT' can be used to substitute an operand as if it were a 316: memory reference, with the actual operand treated as the address. This 317: may be useful when outputting a "load address" instruction, because 318: often the assembler syntax for such an instruction requires you to 319: write the operand as if it were a memory reference. 320: 321: `%lDIGIT' is used to substitute a `label_ref' into a jump 322: instruction. 323: 324: `%=' outputs a number which is unique to each instruction in the 325: entire compilation. This is useful for making local labels to be 326: referred to more than once in a single template that generates multiple 327: assembler instructions. 328: 329: `%' followed by a punctuation character specifies a substitution that 330: does not use an operand. Only one case is standard: `%%' outputs a `%' 331: into the assembler code. Other nonstandard cases can be defined in the 332: `PRINT_OPERAND' macro. You must also define which punctuation 333: characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 334: 335: The template may generate multiple assembler instructions. Write 336: the text for the instructions, with `\;' between them. 337: 338: When the RTL contains two operands which are required by constraint 339: to match each other, the output template must refer only to the 340: lower-numbered operand. Matching operands are not always identical, 341: and the rest of the compiler arranges to put the proper RTL expression 342: for printing into the lower-numbered operand. 343: 344: One use of nonstandard letters or punctuation following `%' is to 345: distinguish between different assembler languages for the same machine; 346: for example, Motorola syntax versus MIT syntax for the 68000. Motorola 347: syntax requires periods in most opcode names, while MIT syntax does 348: not. For example, the opcode `movel' in MIT syntax is `move.l' in 349: Motorola syntax. The same file of patterns is used for both kinds of 350: output syntax, but the character sequence `%.' is used in each place 351: where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 352: Motorola syntax defines the sequence to output a period; the macro for 353: MIT syntax defines it to do nothing. 354: 355: As a special case, a template consisting of the single character `#' 356: instructs the compiler to first split the insn, and then output the 357: resulting instructions separately. This helps eliminate redundancy in 358: the output templates. If you have a `define_insn' that needs to emit 359: multiple assembler instructions, and there is an matching `define_split' 360: already defined, then you can simply use `#' as the output template 361: instead of writing an output template that emits the multiple assembler 362: instructions. 363: 364: If `ASSEMBLER_DIALECT' is defined, you can use 365: `{option0|option1|option2}' constructs in the templates. These 366: describe multiple variants of assembler language syntax. *Note 367: Instruction Output::. 1.1.1.7 root 368: 1.1.1.8 root 369: 370: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc 1.1.1.7 root 371: 1.1.1.8 root 372: C Statements for Assembler Output 373: ================================= 1.1.1.7 root 374: 1.1.1.8 root 375: Often a single fixed template string cannot produce correct and 376: efficient assembler code for all the cases that are recognized by a 377: single instruction pattern. For example, the opcodes may depend on the 378: kinds of operands; or some unfortunate combinations of operands may 379: require extra machine instructions. 380: 381: If the output control string starts with a `@', then it is actually 382: a series of templates, each on a separate line. (Blank lines and 383: leading spaces and tabs are ignored.) The templates correspond to the 384: pattern's constraint alternatives (*note Multi-Alternative::.). For 385: example, if a target machine has a two-address add instruction `addr' 386: to add into a register and another `addm' to add a register to memory, 387: you might write this pattern: 388: 389: (define_insn "addsi3" 390: [(set (match_operand:SI 0 "general_operand" "=r,m") 391: (plus:SI (match_operand:SI 1 "general_operand" "0,0") 392: (match_operand:SI 2 "general_operand" "g,r")))] 393: "" 394: "@ 395: addr %2,%0 396: addm %2,%0") 397: 398: If the output control string starts with a `*', then it is not an 399: output template but rather a piece of C program that should compute a 400: template. It should execute a `return' statement to return the 401: template-string you want. Most such templates use C string literals, 402: which require doublequote characters to delimit them. To include these 403: doublequote characters in the string, prefix each one with `\'. 404: 405: The operands may be found in the array `operands', whose C data type 406: is `rtx []'. 407: 408: It is very common to select different ways of generating assembler 409: code based on whether an immediate operand is within a certain range. 410: Be careful when doing this, because the result of `INTVAL' is an 411: integer on the host machine. If the host machine has more bits in an 412: `int' than the target machine has in the mode in which the constant 413: will be used, then some of the bits you get from `INTVAL' will be 414: superfluous. For proper results, you must carefully disregard the 415: values of those bits. 416: 417: It is possible to output an assembler instruction and then go on to 418: output or compute more of them, using the subroutine `output_asm_insn'. 419: This receives two arguments: a template-string and a vector of 420: operands. The vector may be `operands', or it may be another array of 421: `rtx' that you declare locally and initialize yourself. 422: 423: When an insn pattern has multiple alternatives in its constraints, 424: often the appearance of the assembler code is determined mostly by 425: which alternative was matched. When this is so, the C code can test 426: the variable `which_alternative', which is the ordinal number of the 427: alternative that was actually satisfied (0 for the first, 1 for the 428: second alternative, etc.). 429: 430: For example, suppose there are two opcodes for storing zero, `clrreg' 431: for registers and `clrmem' for memory locations. Here is how a pattern 432: could use `which_alternative' to choose between them: 433: 434: (define_insn "" 435: [(set (match_operand:SI 0 "general_operand" "=r,m") 436: (const_int 0))] 437: "" 438: "* 439: return (which_alternative == 0 440: ? \"clrreg %0\" : \"clrmem %0\"); 441: ") 442: 443: The example above, where the assembler code to generate was *solely* 444: determined by the alternative, could also have been specified as 445: follows, having the output control string start with a `@': 446: 447: (define_insn "" 448: [(set (match_operand:SI 0 "general_operand" "=r,m") 449: (const_int 0))] 450: "" 451: "@ 452: clrreg %0 453: clrmem %0") 1.1.1.5 root 454: 1.1.1.6 root 455: 1.1.1.8 root 456: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc 1.1.1.4 root 457: 1.1.1.8 root 458: Operand Constraints 459: =================== 1.1.1.4 root 460: 1.1.1.8 root 461: Each `match_operand' in an instruction pattern can specify a 462: constraint for the type of operands allowed. Constraints can say 463: whether an operand may be in a register, and which kinds of register; 464: whether the operand can be a memory reference, and which kinds of 465: address; whether the operand may be an immediate constant, and which 466: possible values it may have. Constraints can also require two operands 467: to match. 468: 469: * Menu: 470: 471: * Simple Constraints:: Basic use of constraints. 472: * Multi-Alternative:: When an insn has two alternative constraint-patterns. 473: * Class Preferences:: Constraints guide which hard register to put things in. 474: * Modifiers:: More precise control over effects of constraints. 475: * Machine Constraints:: Existing constraints for some particular machines. 476: * No Constraints:: Describing a clean machine without constraints. 1.1.1.4 root 477: 478: 1.1.1.8 root 479: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 1.1.1.5 root 480: 1.1.1.8 root 481: Simple Constraints 482: ------------------ 1.1.1.4 root 483: 1.1.1.8 root 484: The simplest kind of constraint is a string full of letters, each of 485: which describes one kind of operand that is permitted. Here are the 486: letters that are allowed: 487: 488: `m' 489: A memory operand is allowed, with any kind of address that the 490: machine supports in general. 491: 492: `o' 493: A memory operand is allowed, but only if the address is 494: "offsettable". This means that adding a small integer (actually, 495: the width in bytes of the operand, as determined by its machine 496: mode) may be added to the address and the result is also a valid 497: memory address. 498: 499: For example, an address which is constant is offsettable; so is an 500: address that is the sum of a register and a constant (as long as a 501: slightly larger constant is also within the range of 502: address-offsets supported by the machine); but an autoincrement or 503: autodecrement address is not offsettable. More complicated 504: indirect/indexed addresses may or may not be offsettable depending 505: on the other addressing modes that the machine supports. 506: 507: Note that in an output operand which can be matched by another 508: operand, the constraint letter `o' is valid only when accompanied 509: by both `<' (if the target machine has predecrement addressing) 510: and `>' (if the target machine has preincrement addressing). 511: 512: `V' 513: A memory operand that is not offsettable. In other words, 514: anything that would fit the `m' constraint but not the `o' 515: constraint. 516: 517: `<' 518: A memory operand with autodecrement addressing (either 519: predecrement or postdecrement) is allowed. 520: 521: `>' 522: A memory operand with autoincrement addressing (either 523: preincrement or postincrement) is allowed. 524: 525: `r' 526: A register operand is allowed provided that it is in a general 527: register. 528: 529: `d', `a', `f', ... 530: Other letters can be defined in machine-dependent fashion to stand 531: for particular classes of registers. `d', `a' and `f' are defined 532: on the 68000/68020 to stand for data, address and floating point 533: registers. 534: 535: `i' 536: An immediate integer operand (one with constant value) is allowed. 537: This includes symbolic constants whose values will be known only at 538: assembly time. 539: 540: `n' 541: An immediate integer operand with a known numeric value is allowed. 542: Many systems cannot support assembly-time constants for operands 543: less than a word wide. Constraints for these operands should use 544: `n' rather than `i'. 545: 546: `I', `J', `K', ... `P' 547: Other letters in the range `I' through `P' may be defined in a 548: machine-dependent fashion to permit immediate integer operands with 549: explicit integer values in specified ranges. For example, on the 550: 68000, `I' is defined to stand for the range of values 1 to 8. 551: This is the range permitted as a shift count in the shift 552: instructions. 553: 554: `E' 555: An immediate floating operand (expression code `const_double') is 556: allowed, but only if the target floating point format is the same 557: as that of the host machine (on which the compiler is running). 558: 559: `F' 560: An immediate floating operand (expression code `const_double') is 561: allowed. 562: 563: `G', `H' 564: `G' and `H' may be defined in a machine-dependent fashion to 565: permit immediate floating operands in particular ranges of values. 566: 567: `s' 568: An immediate integer operand whose value is not an explicit 569: integer is allowed. 570: 571: This might appear strange; if an insn allows a constant operand 572: with a value not known at compile time, it certainly must allow 573: any known value. So why use `s' instead of `i'? Sometimes it 574: allows better code to be generated. 575: 576: For example, on the 68000 in a fullword instruction it is possible 577: to use an immediate operand; but if the immediate value is between 578: -128 and 127, better code results from loading the value into a 579: register and using the register. This is because the load into 580: the register can be done with a `moveq' instruction. We arrange 581: for this to happen by defining the letter `K' to mean "any integer 582: outside the range -128 to 127", and then specifying `Ks' in the 583: operand constraints. 584: 585: `g' 586: Any register, memory or immediate integer operand is allowed, 587: except for registers that are not general registers. 588: 589: `X' 590: Any operand whatsoever is allowed, even if it does not satisfy 591: `general_operand'. This is normally used in the constraint of a 592: `match_scratch' when certain alternatives will not actually 593: require a scratch register. 594: 595: `0', `1', `2', ... `9' 596: An operand that matches the specified operand number is allowed. 597: If a digit is used together with letters within the same 598: alternative, the digit should come last. 599: 600: This is called a "matching constraint" and what it really means is 601: that the assembler has only a single operand that fills two roles 602: considered separate in the RTL insn. For example, an add insn has 603: two input operands and one output operand in the RTL, but on most 604: CISC machines an add instruction really has only two operands, one 605: of them an input-output operand: 606: 607: addl #35,r12 608: 609: Matching constraints are used in these circumstances. More 610: precisely, the two operands that match must include one input-only 611: operand and one output-only operand. Moreover, the digit must be a 612: smaller number than the number of the operand that uses it in the 613: constraint. 614: 615: For operands to match in a particular case usually means that they 616: are identical-looking RTL expressions. But in a few special cases 617: specific kinds of dissimilarity are allowed. For example, `*x' as 618: an input operand will match `*x++' as an output operand. For 619: proper results in such cases, the output template should always 620: use the output-operand's number when printing the operand. 621: 622: `p' 623: An operand that is a valid memory address is allowed. This is for 624: "load address" and "push address" instructions. 625: 626: `p' in the constraint must be accompanied by `address_operand' as 627: the predicate in the `match_operand'. This predicate interprets 628: the mode specified in the `match_operand' as the mode of the memory 629: reference for which the address would be valid. 630: 631: `Q', `R', `S', ... `U' 632: Letters in the range `Q' through `U' may be defined in a 633: machine-dependent fashion to stand for arbitrary operand types. 634: The machine description macro `EXTRA_CONSTRAINT' is passed the 635: operand as its first argument and the constraint letter as its 636: second operand. 637: 638: A typical use for this would be to distinguish certain types of 639: memory references that affect other insn operands. 640: 641: Do not define these constraint letters to accept register 642: references (`reg'); the reload pass does not expect this and would 643: not handle it properly. 644: 645: In order to have valid assembler code, each operand must satisfy its 646: constraint. But a failure to do so does not prevent the pattern from 647: applying to an insn. Instead, it directs the compiler to modify the 648: code so that the constraint will be satisfied. Usually this is done by 649: copying an operand into a register. 650: 651: Contrast, therefore, the two instruction patterns that follow: 1.1.1.4 root 652: 1.1.1.7 root 653: (define_insn "" 1.1.1.8 root 654: [(set (match_operand:SI 0 "general_operand" "=r") 655: (plus:SI (match_dup 0) 656: (match_operand:SI 1 "general_operand" "r")))] 657: "" 1.1.1.7 root 658: "...") 1.1.1.6 root 659: 1.1.1.8 root 660: which has two operands, one of which must appear in two places, and 1.1.1.6 root 661: 1.1.1.8 root 662: (define_insn "" 663: [(set (match_operand:SI 0 "general_operand" "=r") 664: (plus:SI (match_operand:SI 1 "general_operand" "0") 665: (match_operand:SI 2 "general_operand" "r")))] 666: "" 667: "...") 668: 669: which has three operands, two of which are required by a constraint to 670: be identical. If we are considering an insn of the form 671: 672: (insn N PREV NEXT 673: (set (reg:SI 3) 674: (plus:SI (reg:SI 6) (reg:SI 109))) 675: ...) 676: 677: the first pattern would not apply at all, because this insn does not 678: contain two identical subexpressions in the right place. The pattern 679: would say, "That does not look like an add instruction; try other 680: patterns." The second pattern would say, "Yes, that's an add 681: instruction, but there is something wrong with it." It would direct 682: the reload pass of the compiler to generate additional insns to make 683: the constraint true. The results might look like this: 684: 685: (insn N2 PREV N 686: (set (reg:SI 3) (reg:SI 6)) 687: ...) 1.1.1.6 root 688: 1.1.1.8 root 689: (insn N N2 NEXT 690: (set (reg:SI 3) 691: (plus:SI (reg:SI 3) (reg:SI 109))) 692: ...) 1.1.1.6 root 693: 1.1.1.8 root 694: It is up to you to make sure that each operand, in each pattern, has 695: constraints that can handle any RTL expression that could be present for 696: that operand. (When multiple alternatives are in use, each pattern 697: must, for each possible combination of operand expressions, have at 698: least one alternative which can handle that combination of operands.) 699: The constraints don't need to *allow* any possible operand--when this is 700: the case, they do not constrain--but they must at least point the way to 701: reloading any possible operand so that it will fit. 702: 703: * If the constraint accepts whatever operands the predicate permits, 704: there is no problem: reloading is never necessary for this operand. 705: 706: For example, an operand whose constraints permit everything except 707: registers is safe provided its predicate rejects registers. 708: 709: An operand whose predicate accepts only constant values is safe 710: provided its constraints include the letter `i'. If any possible 711: constant value is accepted, then nothing less than `i' will do; if 712: the predicate is more selective, then the constraints may also be 713: more selective. 714: 715: * Any operand expression can be reloaded by copying it into a 716: register. So if an operand's constraints allow some kind of 717: register, it is certain to be safe. It need not permit all 718: classes of registers; the compiler knows how to copy a register 719: into another register of the proper class in order to make an 720: instruction valid. 721: 722: * A nonoffsettable memory reference can be reloaded by copying the 723: address into a register. So if the constraint uses the letter 724: `o', all memory references are taken care of. 725: 726: * A constant operand can be reloaded by allocating space in memory to 727: hold it as preinitialized data. Then the memory reference can be 728: used in place of the constant. So if the constraint uses the 729: letters `o' or `m', constant operands are not a problem. 730: 731: * If the constraint permits a constant and a pseudo register used in 732: an insn was not allocated to a hard register and is equivalent to 733: a constant, the register will be replaced with the constant. If 734: the predicate does not permit a constant and the insn is 735: re-recognized for some reason, the compiler will crash. Thus the 736: predicate must always recognize any objects allowed by the 737: constraint. 738: 739: If the operand's predicate can recognize registers, but the 740: constraint does not permit them, it can make the compiler crash. When 741: this operand happens to be a register, the reload pass will be stymied, 742: because it does not know how to copy a register temporarily into memory. 1.1.1.4 root 743: 744: 1.1.1.8 root 745: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 746: 747: Multiple Alternative Constraints 748: -------------------------------- 1.1.1.4 root 749: 1.1.1.8 root 750: Sometimes a single instruction has multiple alternative sets of 751: possible operands. For example, on the 68000, a logical-or instruction 752: can combine register or an immediate value into memory, or it can 753: combine any kind of operand into a register; but it cannot combine one 754: memory location into another. 755: 756: These constraints are represented as multiple alternatives. An 757: alternative can be described by a series of letters for each operand. 758: The overall constraint for an operand is made from the letters for this 759: operand from the first alternative, a comma, the letters for this 760: operand from the second alternative, a comma, and so on until the last 761: alternative. Here is how it is done for fullword logical-or on the 762: 68000: 763: 764: (define_insn "iorsi3" 765: [(set (match_operand:SI 0 "general_operand" "=m,d") 766: (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 767: (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 768: ...) 1.1.1.6 root 769: 1.1.1.8 root 770: The first alternative has `m' (memory) for operand 0, `0' for 771: operand 1 (meaning it must match operand 0), and `dKs' for operand 2. 772: The second alternative has `d' (data register) for operand 0, `0' for 773: operand 1, and `dmKs' for operand 2. The `=' and `%' in the 774: constraints apply to all the alternatives; their meaning is explained 775: in the next section (*note Class Preferences::.). 776: 777: If all the operands fit any one alternative, the instruction is 778: valid. Otherwise, for each alternative, the compiler counts how many 779: instructions must be added to copy the operands so that that 780: alternative applies. The alternative requiring the least copying is 781: chosen. If two alternatives need the same amount of copying, the one 782: that comes first is chosen. These choices can be altered with the `?' 783: and `!' characters: 784: 785: `?' 786: Disparage slightly the alternative that the `?' appears in, as a 787: choice when no alternative applies exactly. The compiler regards 788: this alternative as one unit more costly for each `?' that appears 789: in it. 790: 791: `!' 792: Disparage severely the alternative that the `!' appears in. This 793: alternative can still be used if it fits without reloading, but if 794: reloading is needed, some other alternative will be used. 795: 796: When an insn pattern has multiple alternatives in its constraints, 797: often the appearance of the assembler code is determined mostly by which 798: alternative was matched. When this is so, the C code for writing the 799: assembler code can use the variable `which_alternative', which is the 800: ordinal number of the alternative that was actually satisfied (0 for 801: the first, 1 for the second alternative, etc.). *Note Output 802: Statement::. 1.1.1.6 root 803: 1.1.1.8 root 804: 805: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 1.1.1.4 root 806: 1.1.1.8 root 807: Register Class Preferences 808: -------------------------- 809: 810: The operand constraints have another function: they enable the 811: compiler to decide which kind of hardware register a pseudo register is 812: best allocated to. The compiler examines the constraints that apply to 813: the insns that use the pseudo register, looking for the 814: machine-dependent letters such as `d' and `a' that specify classes of 815: registers. The pseudo register is put in whichever class gets the most 816: "votes". The constraint letters `g' and `r' also vote: they vote in 817: favor of a general register. The machine description says which 818: registers are considered general. 819: 820: Of course, on some machines all registers are equivalent, and no 821: register classes are defined. Then none of this complexity is relevant. 1.1.1.5 root 822: 823: 1.1.1.8 root 824: File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 1.1.1.5 root 825: 1.1.1.8 root 826: Constraint Modifier Characters 827: ------------------------------ 1.1.1.5 root 828: 1.1.1.8 root 829: Here are constraint modifier characters. 1.1.1.7 root 830: 1.1.1.8 root 831: `=' 832: Means that this operand is write-only for this instruction: the 833: previous value is discarded and replaced by output data. 1.1.1.7 root 834: 1.1.1.8 root 835: `+' 836: Means that this operand is both read and written by the 837: instruction. 1.1.1.7 root 838: 1.1.1.8 root 839: When the compiler fixes up the operands to satisfy the constraints, 840: it needs to know which operands are inputs to the instruction and 841: which are outputs from it. `=' identifies an output; `+' 842: identifies an operand that is both input and output; all other 843: operands are assumed to be input only. 844: 845: `&' 846: Means (in a particular alternative) that this operand is written 847: before the instruction is finished using the input operands. 848: Therefore, this operand may not lie in a register that is used as 849: an input operand or as part of any memory address. 850: 851: `&' applies only to the alternative in which it is written. In 852: constraints with multiple alternatives, sometimes one alternative 853: requires `&' while others do not. See, for example, the `movdf' 854: insn of the 68000. 855: 856: `&' does not obviate the need to write `='. 857: 858: `%' 859: Declares the instruction to be commutative for this operand and the 860: following operand. This means that the compiler may interchange 861: the two operands if that is the cheapest way to make all operands 862: fit the constraints. This is often used in patterns for addition 863: instructions that really have only two operands: the result must 864: go in one of the arguments. Here for example, is how the 68000 865: halfword-add instruction is defined: 866: 867: (define_insn "addhi3" 868: [(set (match_operand:HI 0 "general_operand" "=m,r") 869: (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 870: (match_operand:HI 2 "general_operand" "di,g")))] 871: ...) 872: 873: `#' 874: Says that all following characters, up to the next comma, are to be 875: ignored as a constraint. They are significant only for choosing 876: register preferences. 877: 878: `*' 879: Says that the following character should be ignored when choosing 880: register preferences. `*' has no effect on the meaning of the 881: constraint as a constraint, and no effect on reloading. 882: 883: Here is an example: the 68000 has an instruction to sign-extend a 884: halfword in a data register, and can also sign-extend a value by 885: copying it into an address register. While either kind of 886: register is acceptable, the constraints on an address-register 887: destination are less strict, so it is best if register allocation 888: makes an address register its goal. Therefore, `*' is used so 889: that the `d' constraint letter (for data register) is ignored when 890: computing register preferences. 891: 892: (define_insn "extendhisi2" 893: [(set (match_operand:SI 0 "general_operand" "=*d,a") 894: (sign_extend:SI 895: (match_operand:HI 1 "general_operand" "0,g")))] 896: ...) 1.1.1.5 root 897: 898: 1.1.1.8 root 899: File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints 1.1.1.5 root 900: 1.1.1.8 root 901: Constraints for Particular Machines 902: ----------------------------------- 1.1.1.5 root 903: 1.1.1.8 root 904: Whenever possible, you should use the general-purpose constraint 905: letters in `asm' arguments, since they will convey meaning more readily 906: to people reading your code. Failing that, use the constraint letters 907: that usually have very similar meanings across architectures. The most 908: commonly used constraints are `m' and `r' (for memory and 909: general-purpose registers respectively; *note Simple Constraints::.), 910: and `I', usually the letter indicating the most common 911: immediate-constant format. 1.1.1.5 root 912: 1.1.1.8 root 913: For each machine architecture, the `config/MACHINE.h' file defines 914: additional constraints. These constraints are used by the compiler 915: itself for instruction generation, as well as for `asm' statements; 916: therefore, some of the constraints are not particularly interesting for 917: `asm'. The constraints are defined through these macros: 918: 919: `REG_CLASS_FROM_LETTER' 920: Register class constraints (usually lower case). 921: 922: `CONST_OK_FOR_LETTER_P' 923: Immediate constant constraints, for non-floating point constants of 924: word size or smaller precision (usually upper case). 925: 926: `CONST_DOUBLE_OK_FOR_LETTER_P' 927: Immediate constant constraints, for all floating point constants 928: and for constants of greater than word size precision (usually 929: upper case). 930: 931: `EXTRA_CONSTRAINT' 932: Special cases of registers or memory. This macro is not required, 933: and is only defined for some machines. 934: 935: Inspecting these macro definitions in the compiler source for your 936: machine is the best way to be certain you have the right constraints. 937: However, here is a summary of the machine-dependent constraints 938: available on some particular machines. 939: 940: *ARM family--`arm.h'* 941: `f' 942: Floating-point register 943: 944: `F' 945: One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 946: 4.0, 5.0 or 10.0 947: 948: `G' 949: Floating-point constant that would satisfy the constraint `F' 950: if it were negated 951: 952: `I' 953: Integer that is valid as an immediate operand in a data 954: processing instruction. That is, an integer in the range 0 955: to 255 rotated by a multiple of 2 956: 957: `J' 958: Integer in the range -4095 to 4095 959: 960: `K' 961: Integer that satisfies constraint `I' when inverted (ones 962: complement) 963: 964: `L' 965: Integer that satisfies constraint `I' when negated (twos 966: complement) 967: 968: `M' 969: Integer in the range 0 to 32 970: 971: `Q' 972: A memory reference where the exact address is in a single 973: register (``m'' is preferable for `asm' statements) 974: 975: `R' 976: An item in the constant pool 977: 978: `S' 979: A symbol in the text segment of the current file 980: 981: *AMD 29000 family--`a29k.h'* 982: `l' 983: Local register 0 984: 985: `b' 986: Byte Pointer (`BP') register 987: 988: `q' 989: `Q' register 990: 991: `h' 992: Special purpose register 993: 994: `A' 995: First accumulator register 996: 997: `a' 998: Other accumulator register 999: 1000: `f' 1001: Floating point register 1002: 1003: `I' 1004: Constant greater than 0, less than 0x100 1005: 1006: `J' 1007: Constant greater than 0, less than 0x10000 1008: 1009: `K' 1010: Constant whose high 24 bits are on (1) 1011: 1012: `L' 1013: 16 bit constant whose high 8 bits are on (1) 1014: 1015: `M' 1016: 32 bit constant whose high 16 bits are on (1) 1017: 1018: `N' 1019: 32 bit negative constant that fits in 8 bits 1020: 1021: `O' 1022: The constant 0x80000000 or, on the 29050, any 32 bit constant 1023: whose low 16 bits are 0. 1024: 1025: `P' 1026: 16 bit negative constant that fits in 8 bits 1027: 1028: `G' 1029: `H' 1030: A floating point constant (in `asm' statements, use the 1031: machine independent `E' or `F' instead) 1032: 1033: *IBM RS6000--`rs6000.h'* 1034: `b' 1035: Address base register 1036: 1037: `f' 1038: Floating point register 1039: 1040: `h' 1041: `MQ', `CTR', or `LINK' register 1042: 1043: `q' 1044: `MQ' register 1045: 1046: `c' 1047: `CTR' register 1048: 1049: `l' 1050: `LINK' register 1051: 1052: `x' 1053: `CR' register (condition register) number 0 1054: 1055: `y' 1056: `CR' register (condition register) 1057: 1058: `I' 1059: Signed 16 bit constant 1060: 1061: `J' 1062: Constant whose low 16 bits are 0 1063: 1064: `K' 1065: Constant whose high 16 bits are 0 1066: 1067: `L' 1068: Constant suitable as a mask operand 1069: 1070: `M' 1071: Constant larger than 31 1072: 1073: `N' 1074: Exact power of 2 1075: 1076: `O' 1077: Zero 1078: 1079: `P' 1080: Constant whose negation is a signed 16 bit constant 1081: 1082: `G' 1083: Floating point constant that can be loaded into a register 1084: with one instruction per word 1085: 1086: `Q' 1087: Memory operand that is an offset from a register (`m' is 1088: preferable for `asm' statements) 1089: 1090: *Intel 386--`i386.h'* 1091: `q' 1092: `a', `b', `c', or `d' register 1093: 1094: `A' 1095: `a', or `d' register (for 64-bit ints) 1096: 1097: `f' 1098: Floating point register 1099: 1100: `t' 1101: First (top of stack) floating point register 1102: 1103: `u' 1104: Second floating point register 1105: 1106: `a' 1107: `a' register 1108: 1109: `b' 1110: `b' register 1111: 1112: `c' 1113: `c' register 1114: 1115: `d' 1116: `d' register 1117: 1118: `D' 1119: `di' register 1120: 1121: `S' 1122: `si' register 1123: 1124: `I' 1125: Constant in range 0 to 31 (for 32 bit shifts) 1126: 1127: `J' 1128: Constant in range 0 to 63 (for 64 bit shifts) 1129: 1130: `K' 1131: `0xff' 1132: 1133: `L' 1134: `0xffff' 1135: 1136: `M' 1137: 0, 1, 2, or 3 (shifts for `lea' instruction) 1138: 1139: `N' 1140: Constant in range 0 to 255 (for `out' instruction) 1141: 1142: `G' 1143: Standard 80387 floating point constant 1144: 1145: *Intel 960--`i960.h'* 1146: `f' 1147: Floating point register (`fp0' to `fp3') 1148: 1149: `l' 1150: Local register (`r0' to `r15') 1151: 1152: `b' 1153: Global register (`g0' to `g15') 1154: 1155: `d' 1156: Any local or global register 1157: 1158: `I' 1159: Integers from 0 to 31 1160: 1161: `J' 1162: 0 1163: 1164: `K' 1165: Integers from -31 to 0 1166: 1167: `G' 1168: Floating point 0 1169: 1170: `H' 1171: Floating point 1 1172: 1173: *MIPS--`mips.h'* 1174: `d' 1175: General-purpose integer register 1176: 1177: `f' 1178: Floating-point register (if available) 1179: 1180: `h' 1181: `Hi' register 1182: 1183: `l' 1184: `Lo' register 1185: 1186: `x' 1187: `Hi' or `Lo' register 1188: 1189: `y' 1190: General-purpose integer register 1191: 1192: `z' 1193: Floating-point status register 1194: 1195: `I' 1196: Signed 16 bit constant (for arithmetic instructions) 1197: 1198: `J' 1199: Zero 1200: 1201: `K' 1202: Zero-extended 16-bit constant (for logic instructions) 1203: 1204: `L' 1205: Constant with low 16 bits zero (can be loaded with `lui') 1206: 1207: `M' 1208: 32 bit constant which requires two instructions to load (a 1209: constant which is not `I', `K', or `L') 1210: 1211: `N' 1212: Negative 16 bit constant 1213: 1214: `O' 1215: Exact power of two 1216: 1217: `P' 1218: Positive 16 bit constant 1219: 1220: `G' 1221: Floating point zero 1222: 1223: `Q' 1224: Memory reference that can be loaded with more than one 1225: instruction (`m' is preferable for `asm' statements) 1226: 1227: `R' 1228: Memory reference that can be loaded with one instruction (`m' 1229: is preferable for `asm' statements) 1230: 1231: `S' 1232: Memory reference in external OSF/rose PIC format (`m' is 1233: preferable for `asm' statements) 1234: 1235: *Motorola 680x0--`m68k.h'* 1236: `a' 1237: Address register 1238: 1239: `d' 1240: Data register 1241: 1242: `f' 1243: 68881 floating-point register, if available 1244: 1245: `x' 1246: Sun FPA (floating-point) register, if available 1247: 1248: `y' 1249: First 16 Sun FPA registers, if available 1250: 1251: `I' 1252: Integer in the range 1 to 8 1253: 1254: `J' 1255: 16 bit signed number 1256: 1257: `K' 1258: Signed number whose magnitude is greater than 0x80 1259: 1260: `L' 1261: Integer in the range -8 to -1 1262: 1263: `G' 1264: Floating point constant that is not a 68881 constant 1265: 1266: `H' 1267: Floating point constant that can be used by Sun FPA 1268: 1269: *SPARC--`sparc.h'* 1270: `f' 1271: Floating-point register 1272: 1273: `I' 1274: Signed 13 bit constant 1275: 1276: `J' 1277: Zero 1278: 1279: `K' 1280: 32 bit constant with the low 12 bits clear (a constant that 1281: can be loaded with the `sethi' instruction) 1282: 1283: `G' 1284: Floating-point zero 1285: 1286: `H' 1287: Signed 13 bit constant, sign-extended to 32 or 64 bits 1288: 1289: `Q' 1290: Memory reference that can be loaded with one instruction 1291: (`m' is more appropriate for `asm' statements) 1292: 1293: `S' 1294: Constant, or memory address 1295: 1296: `T' 1297: Memory address aligned to an 8-byte boundary 1298: 1299: `U' 1300: Even register 1301: 1302: 1303: File: gcc.info, Node: No Constraints, Prev: Machine Constraints, Up: Constraints 1304: 1305: Not Using Constraints 1306: --------------------- 1307: 1308: Some machines are so clean that operand constraints are not 1309: required. For example, on the Vax, an operand valid in one context is 1310: valid in any other context. On such a machine, every operand 1311: constraint would be `g', excepting only operands of "load address" 1312: instructions which are written as if they referred to a memory 1313: location's contents but actual refer to its address. They would have 1314: constraint `p'. 1315: 1316: For such machines, instead of writing `g' and `p' for all the 1317: constraints, you can choose to write a description with empty 1318: constraints. Then you write `""' for the constraint in every 1319: `match_operand'. Address operands are identified by writing an 1320: `address' expression around the `match_operand', not by their 1321: constraints. 1322: 1323: When the machine description has just empty constraints, certain 1324: parts of compilation are skipped, making the compiler faster. However, 1325: few machines actually do not need constraints; all machine descriptions 1326: now in existence use constraints. 1.1 root 1327:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.