|
|
1.1.1.7 root 1: This is Info file gcc.info, produced by Makeinfo-1.55 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:
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.