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