![[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:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.4 root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.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:
20: Permission is granted to copy and distribute translations of this
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:
27:
28:
1.1.1.5 ! root 29: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
! 30:
! 31: RTL Template for Generating and Recognizing Insns
! 32: =================================================
! 33:
! 34: The RTL template is used to define which insns match the particular
! 35: pattern and how to find their operands. For named patterns, the RTL
! 36: template also says how to construct an insn from specified operands.
! 37:
! 38: Construction involves substituting specified operands into a copy of
! 39: the template. Matching involves determining the values that serve as
! 40: the operands in the insn being matched. Both of these activities are
! 41: controlled by special expression types that direct matching and
! 42: substitution of the operands.
! 43:
! 44: `(match_operand:M N PRED CONSTRAINT)'
! 45: This expression is a placeholder for operand number N of the
! 46: insn. When constructing an insn, operand number N will be
! 47: substituted at this point. When matching an insn, whatever
! 48: appears at this position in the insn will be taken as operand
! 49: number N; but it must satisfy PRED or this instruction pattern
! 50: will not match at all.
! 51:
! 52: Operand numbers must be chosen consecutively counting from zero
! 53: in each instruction pattern. There may be only one
! 54: `match_operand' expression in the pattern for each operand
! 55: number. Usually operands are numbered in the order of
! 56: appearance in `match_operand' expressions.
! 57:
! 58: PRED is a string that is the name of a C function that accepts
! 59: two arguments, an expression and a machine mode. During
! 60: matching, the function will be called with the putative operand
! 61: as the expression and M as the mode argument. If it returns
! 62: zero, this instruction pattern fails to match. PRED may be an
! 63: empty string; then it means no test is to be done on the
! 64: operand, so anything which occurs in this position is valid.
! 65:
! 66: CONSTRAINT controls reloading and the choice of the best
! 67: register class to use for a value, as explained later (*note
! 68: Constraints::.).
! 69:
! 70: People are often unclear on the difference between the
! 71: constraint and the predicate. The predicate helps decide
! 72: whether a given insn matches the pattern. The constraint plays
! 73: no role in this decision; instead, it controls various decisions
! 74: in the case of an insn which does match.
! 75:
! 76: Most often, PRED is `"general_operand"'. This function checks
! 77: that the putative operand is either a constant, a register or a
! 78: memory reference, and that it is valid for mode M.
! 79:
! 80: For an operand that must be a register, PRED should be
! 81: `"register_operand"'. It would be valid to use
! 82: `"general_operand"', since the reload pass would copy any
! 83: non-register operands through registers, but this would make GNU
! 84: CC do extra work, and it would prevent the register allocator
! 85: from doing the best possible job.
! 86:
! 87: For an operand that must be a constant, either PRED should be
! 88: `"immediate_operand"', or the instruction pattern's extra
! 89: condition should check for constants, or both. You cannot
! 90: expect the constraints to do this work! If the constraints
! 91: allow only constants, but the predicate allows something else,
! 92: the compiler will crash when that case arises.
! 93:
! 94: `(match_dup N)'
! 95: This expression is also a placeholder for operand number N. It
! 96: is used when the operand needs to appear more than once in the
! 97: insn.
! 98:
! 99: In construction, `match_dup' behaves exactly like
! 100: `match_operand': the operand is substituted into the insn being
! 101: constructed. But in matching, `match_dup' behaves differently.
! 102: It assumes that operand number N has already been determined by
! 103: a `match_operand' appearing earlier in the recognition template,
! 104: and it matches only an identical-looking expression.
! 105:
! 106: `(match_operator:M N "PREDICATE" [OPERANDS...])'
! 107: This pattern is a kind of placeholder for a variable RTL
! 108: expression code.
! 109:
! 110: When constructing an insn, it stands for an RTL expression whose
! 111: expression code is taken from that of operand N, and whose
! 112: operands are constructed from the patterns OPERANDS.
! 113:
! 114: When matching an expression, it matches an expression if the
! 115: function PREDICATE returns nonzero on that expression *and* the
! 116: patterns OPERANDS match the operands of the expression.
! 117:
! 118: Suppose that the function `commutative_operator' is defined as
! 119: follows, to match any expression whose operator is one of the
! 120: six commutative arithmetic operators of RTL and whose mode is
! 121: MODE:
! 122:
! 123: int
! 124: commutative_operator (x, mode)
! 125: rtx x;
! 126: enum machine_mode mode;
! 127: {
! 128: enum rtx_code code = GET_CODE (x);
! 129: if (GET_MODE (x) != mode)
! 130: return 0;
! 131: return (code == PLUS || code == MULT || code == UMULT
! 132: || code == AND || code == IOR || code == XOR);
! 133: }
! 134:
! 135: Then the following pattern will match any RTL expression
! 136: consisting of a commutative operator applied to two general
! 137: operands:
! 138:
! 139: (match_operator:SI 2 "commutative_operator"
! 140: [(match_operand:SI 3 "general_operand" "g")
! 141: (match_operand:SI 4 "general_operand" "g")])
! 142:
! 143: Here the vector `[OPERANDS...]' contains two patterns because
! 144: the expressions to be matched all contain two operands.
! 145:
! 146: When this pattern does match, the two operands of the
! 147: commutative operator are recorded as operands 3 and 4 of the
! 148: insn. (This is done by the two instances of `match_operand'.)
! 149: Operand 2 of the insn will be the entire commutative expression:
! 150: use `GET_CODE (operands[2])' to see which commutative operator
! 151: was used.
! 152:
! 153: The machine mode M of `match_operator' works like that of
! 154: `match_operand': it is passed as the second argument to the
! 155: predicate function, and that function is solely responsible for
! 156: deciding whether the expression to be matched "has" that mode.
! 157:
! 158: When constructing an insn, argument 2 of the gen-function will
! 159: specify the operation (i.e. the expression code) for the
! 160: expression to be made. It should be an RTL expression, whose
! 161: expression code is copied into a new expression whose operands
! 162: are arguments 3 and 4 of the gen-function. The subexpressions
! 163: of argument 2 are not used; only its expression code matters.
! 164:
! 165: There is no way to specify constraints in `match_operator'. The
! 166: operand of the insn which corresponds to the `match_operator'
! 167: never has any constraints because it is never reloaded as a whole.
! 168: However, if parts of its OPERANDS are matched by `match_operand'
! 169: patterns, those parts may have constraints of their own.
! 170:
! 171: `(address (match_operand:M N "address_operand" ""))'
! 172: This complex of expressions is a placeholder for an operand
! 173: number N in a "load address" instruction: an operand which
! 174: specifies a memory location in the usual way, but for which the
! 175: actual operand value used is the address of the location, not
! 176: the contents of the location.
! 177:
! 178: `address' expressions never appear in RTL code, only in machine
! 179: descriptions. And they are used only in machine descriptions
! 180: that do not use the operand constraint feature. When operand
! 181: constraints are in use, the letter `p' in the constraint serves
! 182: this purpose.
! 183:
! 184: M is the machine mode of the *memory location being addressed*,
! 185: not the machine mode of the address itself. That mode is always
! 186: the same on a given target machine (it is `Pmode', which
! 187: normally is `SImode'), so there is no point in mentioning it;
! 188: thus, no machine mode is written in the `address' expression.
! 189: If some day support is added for machines in which addresses of
! 190: different kinds of objects appear differently or are used
! 191: differently (such as the PDP-10), different formats would
! 192: perhaps need different machine modes and these modes might be
! 193: written in the `address' expression.
! 194:
! 195:
! 196:
1.1.1.4 root 197: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
198:
199: Output Templates and Operand Substitution
200: =========================================
201:
202: The "output template" is a string which specifies how to output the
203: assembler code for an instruction pattern. Most of the template is a
204: fixed string which is output literally. The character `%' is used to
205: specify where to substitute an operand; it can also be used to
206: identify places where different variants of the assembler require
207: different syntax.
208:
209: In the simplest case, a `%' followed by a digit N says to output
210: operand N at that point in the string.
211:
212: `%' followed by a letter and a digit says to output an operand in an
213: alternate fashion. Four letters have standard, built-in meanings
214: described below. The machine description macro `PRINT_OPERAND' can
215: define additional letters with nonstandard meanings.
216:
217: `%cDIGIT' can be used to substitute an operand that is a constant
218: value without the syntax that normally indicates an immediate operand.
219:
220: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
221: negated before printing.
222:
223: `%aDIGIT' can be used to substitute an operand as if it were a memory
224: reference, with the actual operand treated as the address. This may
225: be useful when outputting a "load address" instruction, because often
226: the assembler syntax for such an instruction requires you to write
227: the operand as if it were a memory reference.
228:
229: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
230:
231: `%' followed by a punctuation character specifies a substitution that
232: does not use an operand. Only one case is standard: `%%' outputs a
233: `%' into the assembler code. Other nonstandard cases can be defined
234: in the `PRINT_OPERAND' macro. You must also define which punctuation
235: characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
236:
237: The template may generate multiple assembler instructions. Write the
238: text for the instructions, with `\;' between them.
239:
240: When the RTL contains two operands which are required by constraint
241: to match each other, the output template must refer only to the
242: lower-numbered operand. Matching operands are not always identical,
243: and the rest of the compiler arranges to put the proper RTL
244: expression for printing into the lower-numbered operand.
245:
246: One use of nonstandard letters or punctuation following `%' is to
247: distinguish between different assembler languages for the same
248: machine; for example, Motorola syntax versus MIT syntax for the
249: 68000. Motorola syntax requires periods in most opcode names, while
250: MIT syntax does not. For example, the opcode `movel' in MIT syntax
251: is `move.l' in Motorola syntax. The same file of patterns is used
252: for both kinds of output syntax, but the character sequence `%.' is
253: used in each place where Motorola syntax wants a period. The
254: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to
255: output a period; the macro for MIT syntax defines it to do nothing.
1.1.1.2 root 256:
1.1.1.3 root 257:
258:
259: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
260:
261: C Statements for Generating Assembler Output
262: ============================================
263:
264: Often a single fixed template string cannot produce correct and
265: efficient assembler code for all the cases that are recognized by a
266: single instruction pattern. For example, the opcodes may depend on
267: the kinds of operands; or some unfortunate combinations of operands
268: may require extra machine instructions.
269:
270: If the output control string starts with a `*', then it is not an
271: output template but rather a piece of C program that should compute a
272: template. It should execute a `return' statement to return the
273: template-string you want. Most such templates use C string literals,
274: which require doublequote characters to delimit them. To include
275: these doublequote characters in the string, prefix each one with `\'.
276:
277: The operands may be found in the array `operands', whose C data type
278: is `rtx []'.
279:
280: It is possible to output an assembler instruction and then go on to
281: output or compute more of them, using the subroutine
282: `output_asm_insn'. This receives two arguments: a template-string
283: and a vector of operands. The vector may be `operands', or it may be
284: another array of `rtx' that you declare locally and initialize
285: yourself.
286:
287: When an insn pattern has multiple alternatives in its constraints,
288: often the appearance of the assembler code is determined mostly by
289: which alternative was matched. When this is so, the C code can test
290: the variable `which_alternative', which is the ordinal number of the
291: alternative that was actually satisfied (0 for the first, 1 for the
292: second alternative, etc.).
293:
294: For example, suppose there are two opcodes for storing zero, `clrreg'
295: for registers and `clrmem' for memory locations. Here is how a
296: pattern could use `which_alternative' to choose between them:
297:
298: (define_insn ""
299: [(set (match_operand:SI 0 "general_operand" "r,m")
300: (const_int 0))]
301: ""
302: "*
303: return (which_alternative == 0
304: ? \"clrreg %0\" : \"clrmem %0\");
305: ")
306:
307:
308:
309: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
310:
311: Operand Constraints
312: ===================
313:
314: Each `match_operand' in an instruction pattern can specify a
315: constraint for the type of operands allowed. Constraints can say
316: whether an operand may be in a register, and which kinds of register;
317: whether the operand can be a memory reference, and which kinds of
318: address; whether the operand may be an immediate constant, and which
319: possible values it may have. Constraints can also require two
320: operands to match.
321:
322: * Menu:
323:
324: * Simple Constraints:: Basic use of constraints.
325: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
326: * Class Preferences:: Constraints guide which hard register to put things in.
327: * Modifiers:: More precise control over effects of constraints.
328: * No Constraints:: Describing a clean machine without constraints.
329:
330:
331:
332: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints
333:
334: Simple Constraints
335: ------------------
336:
337: The simplest kind of constraint is a string full of letters, each of
338: which describes one kind of operand that is permitted. Here are the
339: letters that are allowed:
340:
341: `m'
342: A memory operand is allowed, with any kind of address that the
343: machine supports in general.
344:
345: `o'
346: A memory operand is allowed, but only if the address is
347: "offsettable". This means that adding a small integer
348: (actually, the width in bytes of the operand, as determined by
349: its machine mode) may be added to the address and the result is
350: also a valid memory address.
351:
352: For example, an address which is constant is offsettable; so is
353: an address that is the sum of a register and a constant (as long
354: as a slightly larger constant is also within the range of
355: address-offsets supported by the machine); but an autoincrement
356: or autodecrement address is not offsettable. More complicated
357: indirect/indexed addresses may or may not be offsettable
358: depending on the other addressing modes that the machine supports.
359:
360: Note that in an output operand which can be matched by another
361: operand, the constraint letter `o' is valid only when
362: accompanied by both `<' (if the target machine has predecrement
363: addressing) and `>' (if the target machine has preincrement
364: addressing).
365:
366: When the constraint letter `o' is used, the reload pass may
367: generate instructions which copy a nonoffsettable address into
368: an index register. The idea is that the register can be used as
369: a replacement offsettable address. But this method requires
370: that there be patterns to copy any kind of address into a
371: register. Auto-increment and auto-decrement addresses are an
372: exception; there need not be an instruction that can copy such
373: an address into a register, because reload handles these cases
374: specially.
375:
1.1.1.4 root 376: Most older machine designs have "load address" instructions
1.1.1.3 root 377: which do just what is needed here. Some RISC machines do not
378: advertise such instructions, but the possible addresses on these
379: machines are very limited, so it is easy to fake them.
380:
381: `<'
382: A memory operand with autodecrement addressing (either
383: predecrement or postdecrement) is allowed.
384:
385: `>'
386: A memory operand with autoincrement addressing (either
387: preincrement or postincrement) is allowed.
388:
389: `r'
390: A register operand is allowed provided that it is in a general
391: register.
392:
393: `d', `a', `f', ...
394: Other letters can be defined in machine-dependent fashion to
395: stand for particular classes of registers. `d', `a' and `f' are
396: defined on the 68000/68020 to stand for data, address and
397: floating point registers.
398:
399: `i'
400: An immediate integer operand (one with constant value) is allowed.
401: This includes symbolic constants whose values will be known only
402: at assembly time.
403:
404: `n'
405: An immediate integer operand with a known numeric value is
406: allowed. Many systems cannot support assembly-time constants
407: for operands less than a word wide. Constraints for these
408: operands should use `n' rather than `i'.
409:
410: `I', `J', `K', ...
411: Other letters in the range `I' through `M' may be defined in a
412: machine-dependent fashion to permit immediate integer operands
413: with explicit integer values in specified ranges. For example,
414: on the 68000, `I' is defined to stand for the range of values 1
415: to 8. This is the range permitted as a shift count in the shift
416: instructions.
417:
418: `F'
419: An immediate floating operand (expression code `const_double')
420: is allowed.
421:
422: `G', `H'
423: `G' and `H' may be defined in a machine-dependent fashion to
424: permit immediate floating operands in particular ranges of values.
425:
426: `s'
427: An immediate integer operand whose value is not an explicit
428: integer is allowed.
429:
430: This might appear strange; if an insn allows a constant operand
431: with a value not known at compile time, it certainly must allow
432: any known value. So why use `s' instead of `i'? Sometimes it
433: allows better code to be generated.
434:
435: For example, on the 68000 in a fullword instruction it is
436: possible to use an immediate operand; but if the immediate value
437: is between -128 and 127, better code results from loading the
438: value into a register and using the register. This is because
439: the load into the register can be done with a `moveq'
440: instruction. We arrange for this to happen by defining the
1.1.1.4 root 441: letter `K' to mean "any integer outside the range -128 to 127",
442: and then specifying `Ks' in the operand constraints.
1.1.1.3 root 443:
444: `g'
445: Any register, memory or immediate integer operand is allowed,
446: except for registers that are not general registers.
447:
448: `N' (a digit)
449: An operand that matches operand number N is allowed. If a digit
450: is used together with letters, the digit should come last.
451:
452: This is called a "matching constraint" and what it really means
453: is that the assembler has only a single operand that fills two
454: roles considered separate in the RTL insn. For example, an add
455: insn has two input operands and one output operand in the RTL,
456: but on most machines an add instruction really has only two
457: operands, one of them an input-output operand.
458:
459: Matching constraints work only in circumstances like that add
460: insn. More precisely, the matching constraint must appear in an
461: input-only operand and the operand that it matches must be an
462: output-only operand with a lower number. Thus, operand N must
463: have `=' in its constraint.
464:
465: For operands to match in a particular case usually means that
466: they are identical-looking RTL expressions. But in a few
467: special cases specific kinds of dissimilarity are allowed. For
468: example, `*x' as an input operand will match `*x++' as an output
469: operand. For proper results in such cases, the output template
470: should always use the output-operand's number when printing the
471: operand.
472:
473: `p'
474: An operand that is a valid memory address is allowed. This is
1.1.1.4 root 475: for "load address" and "push address" instructions.
1.1.1.3 root 476:
477: `p' in the constraint must be accompanies by `address_operand'
478: as the predicate in the `match_operand'.
479:
480: In order to have valid assembler code, each operand must satisfy its
481: constraint. But a failure to do so does not prevent the pattern from
482: applying to an insn. Instead, it directs the compiler to modify the
483: code so that the constraint will be satisfied. Usually this is done
484: by copying an operand into a register.
485:
486: Contrast, therefore, the two instruction patterns that follow:
487:
488: (define_insn ""
489: [(set (match_operand:SI 0 "general_operand" "r")
490: (plus:SI (match_dup 0)
491: (match_operand:SI 1 "general_operand" "r")))]
492: ""
493: "...")
494:
495: which has two operands, one of which must appear in two places, and
496:
497: (define_insn ""
498: [(set (match_operand:SI 0 "general_operand" "r")
499: (plus:SI (match_operand:SI 1 "general_operand" "0")
500: (match_operand:SI 2 "general_operand" "r")))]
501: ""
502: "...")
503:
504: which has three operands, two of which are required by a constraint
505: to be identical. If we are considering an insn of the form
506:
507: (insn N PREV NEXT
508: (set (reg:SI 3)
509: (plus:SI (reg:SI 6) (reg:SI 109)))
510: ...)
511:
512: the first pattern would not apply at all, because this insn does not
513: contain two identical subexpressions in the right place. The pattern
1.1.1.4 root 514: would say, "That does not look like an add instruction; try other
515: patterns." The second pattern would say, "Yes, that's an add
516: instruction, but there is something wrong with it." It would direct
1.1.1.3 root 517: the reload pass of the compiler to generate additional insns to make
518: the constraint true. The results might look like this:
519:
520: (insn N2 PREV N
521: (set (reg:SI 3) (reg:SI 6))
522: ...)
523:
524: (insn N N2 NEXT
525: (set (reg:SI 3)
526: (plus:SI (reg:SI 3) (reg:SI 109)))
527: ...)
528:
529: It is up to you to make sure that each operand, in each pattern, has
530: constraints that can handle any RTL expression that could be present
531: for that operand. (When multiple alternatives are in use, each
532: pattern must, for each possible combination of operand expressions,
533: have at least one alternative which can handle that combination of
534: operands.) The constraints don't need to *allow* any possible
535: operand--when this is the case, they do not constrain--but they must
536: at least point the way to reloading any possible operand so that it
537: will fit.
538:
539: * If the constraint accepts whatever operands the predicate
540: permits, there is no problem: reloading is never necessary for
541: this operand.
542:
543: For example, an operand whose constraints permit everything
544: except registers is safe provided its predicate rejects registers.
545:
546: An operand whose predicate accepts only constant values is safe
547: provided its constraints include the letter `i'. If any
548: possible constant value is accepted, then nothing less than `i'
549: will do; if the predicate is more selective, then the
550: constraints may also be more selective.
551:
552: * Any operand expression can be reloaded by copying it into a
553: register. So if an operand's constraints allow some kind of
554: register, it is certain to be safe. It need not permit all
555: classes of registers; the compiler knows how to copy a register
556: into another register of the proper class in order to make an
557: instruction valid.
558:
559: * A nonoffsettable memory reference can be reloaded by copying the
560: address into a register. So if the constraint uses the letter
561: `o', all memory references are taken care of.
562:
563: * A constant operand can be reloaded by allocating space in memory
564: to hold it as preinitialized data. Then the memory reference
565: can be used in place of the constant. So if the constraint uses
566: the letters `o' or `m', constant operands are not a problem.
567:
568: If the operand's predicate can recognize registers, but the
569: constraint does not permit them, it can make the compiler crash.
570: When this operand happens to be a register, the reload pass will be
571: stymied, because it does not know how to copy a register temporarily
572: into memory.
573:
574:
575:
576: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
577:
578: Multiple Alternative Constraints
579: --------------------------------
580:
581: Sometimes a single instruction has multiple alternative sets of
582: possible operands. For example, on the 68000, a logical-or
583: instruction can combine register or an immediate value into memory,
584: or it can combine any kind of operand into a register; but it cannot
585: combine one memory location into another.
586:
587: These constraints are represented as multiple alternatives. An
588: alternative can be described by a series of letters for each operand.
589: The overall constraint for an operand is made from the letters for
590: this operand from the first alternative, a comma, the letters for
591: this operand from the second alternative, a comma, and so on until
592: the last alternative. Here is how it is done for fullword logical-or
593: on the 68000:
594:
595: (define_insn "iorsi3"
596: [(set (match_operand:SI 0 "general_operand" "=m,d")
597: (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
598: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
599: ...)
600:
601: The first alternative has `m' (memory) for operand 0, `0' for operand
602: 1 (meaning it must match operand 0), and `dKs' for operand 2. The
603: second alternative has `d' (data register) for operand 0, `0' for
604: operand 1, and `dmKs' for operand 2. The `=' and `%' in the
605: constraints apply to all the alternatives; their meaning is explained
606: in the next section.
607:
608: If all the operands fit any one alternative, the instruction is valid.
609: Otherwise, for each alternative, the compiler counts how many
610: instructions must be added to copy the operands so that that
611: alternative applies. The alternative requiring the least copying is
612: chosen. If two alternatives need the same amount of copying, the one
613: that comes first is chosen. These choices can be altered with the
614: `?' and `!' characters:
615:
616: `?'
617: Disparage slightly the alternative that the `?' appears in, as a
618: choice when no alternative applies exactly. The compiler
619: regards this alternative as one unit more costly for each `?'
620: that appears in it.
621:
622: `!'
623: Disparage severely the alternative that the `!' appears in.
624: When operands must be copied into registers, the compiler will
625: never choose this alternative as the one to strive for.
626:
627: When an insn pattern has multiple alternatives in its constraints,
628: often the appearance of the assembler code is determined mostly by
629: which alternative was matched. When this is so, the C code for
630: writing the assembler code can use the variable `which_alternative',
631: which is the ordinal number of the alternative that was actually
632: satisfied (0 for the first, 1 for the second alternative, etc.). For
633: example:
634:
635: (define_insn ""
636: [(set (match_operand:SI 0 "general_operand" "r,m")
637: (const_int 0))]
638: ""
639: "*
640: return (which_alternative == 0
641: ? \"clrreg %0\" : \"clrmem %0\");
642: ")
643:
644:
645:
646: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
647:
648: Register Class Preferences
649: --------------------------
650:
651: The operand constraints have another function: they enable the
652: compiler to decide which kind of hardware register a pseudo register
653: is best allocated to. The compiler examines the constraints that
654: apply to the insns that use the pseudo register, looking for the
655: machine-dependent letters such as `d' and `a' that specify classes of
656: registers. The pseudo register is put in whichever class gets the
1.1.1.4 root 657: most "votes". The constraint letters `g' and `r' also vote: they
1.1.1.3 root 658: vote in favor of a general register. The machine description says
659: which registers are considered general.
660:
661: Of course, on some machines all registers are equivalent, and no
662: register classes are defined. Then none of this complexity is
663: relevant.
664:
665:
666:
667: File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints
668:
669: Constraint Modifier Characters
670: ------------------------------
671:
672: `='
673: Means that this operand is write-only for this instruction: the
674: previous value is discarded and replaced by output data.
675:
676: `+'
677: Means that this operand is both read and written by the
678: instruction.
679:
680: When the compiler fixes up the operands to satisfy the
681: constraints, it needs to know which operands are inputs to the
682: instruction and which are outputs from it. `=' identifies an
683: output; `+' identifies an operand that is both input and output;
684: all other operands are assumed to be input only.
685:
686: `&'
687: Means (in a particular alternative) that this operand is written
688: before the instruction is finished using the input operands.
689: Therefore, this operand may not lie in a register that is used
690: as an input operand or as part of any memory address.
691:
692: `&' applies only to the alternative in which it is written. In
693: constraints with multiple alternatives, sometimes one
694: alternative requires `&' while others do not. See, for example,
695: the `movdf' insn of the 68000.
696:
697: `&' does not obviate the need to write `='.
698:
699: `%'
700: Declares the instruction to be commutative for this operand and
701: the following operand. This means that the compiler may
702: interchange the two operands if that is the cheapest way to make
703: all operands fit the constraints. This is often used in
704: patterns for addition instructions that really have only two
705: operands: the result must go in one of the arguments. Here for
706: example, is how the 68000 halfword-add instruction is defined:
707:
708: (define_insn "addhi3"
709: [(set (match_operand:HI 0 "general_operand" "=m,r")
710: (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
711: (match_operand:HI 2 "general_operand" "di,g")))]
712: ...)
713:
714: Note that in previous versions of GNU CC the `%' constraint
715: modifier always applied to operands 1 and 2 regardless of which
716: operand it was written in. The usual custom was to write it in
717: operand 0. Now it must be in operand 1 if the operands to be
718: exchanged are 1 and 2.
719:
720: `#'
721: Says that all following characters, up to the next comma, are to
722: be ignored as a constraint. They are significant only for
723: choosing register preferences.
724:
725: `*'
726: Says that the following character should be ignored when
727: choosing register preferences. `*' has no effect on the meaning
728: of the constraint as a constraint.
729:
730: Here is an example: the 68000 has an instruction to sign-extend
731: a halfword in a data register, and can also sign-extend a value
732: by copying it into an address register. While either kind of
733: register is acceptable, the constraints on an address-register
734: destination are less strict, so it is best if register
735: allocation makes an address register its goal. Therefore, `*'
736: is used so that the `d' constraint letter (for data register) is
737: ignored when computing register preferences.
738:
739: (define_insn "extendhisi2"
740: [(set (match_operand:SI 0 "general_operand" "=*d,a")
741: (sign_extend:SI
742: (match_operand:HI 1 "general_operand" "0,g")))]
743: ...)
744:
745:
746:
747: File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints
748:
749: Not Using Constraints
750: ---------------------
751:
752: Some machines are so clean that operand constraints are not required.
753: For example, on the Vax, an operand valid in one context is valid in
754: any other context. On such a machine, every operand constraint would
1.1.1.4 root 755: be `g', excepting only operands of "load address" instructions which
756: are written as if they referred to a memory location's contents but
757: actual refer to its address. They would have constraint `p'.
1.1.1.3 root 758:
759: For such machines, instead of writing `g' and `p' for all the
760: constraints, you can choose to write a description with empty
761: constraints. Then you write `""' for the constraint in every
762: `match_operand'. Address operands are identified by writing an
763: `address' expression around the `match_operand', not by their
764: constraints.
765:
766: When the machine description has just empty constraints, certain
767: parts of compilation are skipped, making the compiler faster.
768: However, few machines actually do not need constraints; all machine
769: descriptions now in existence use constraints.
770:
771:
772:
773: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
774:
775: Standard Names for Patterns Used in Generation
776: ==============================================
777:
778: Here is a table of the instruction names that are meaningful in the
779: RTL generation pass of the compiler. Giving one of these names to an
780: instruction pattern tells the RTL generation pass that it can use the
781: pattern in to accomplish a certain task.
782:
783: `movM'
784: Here M stands for a two-letter machine mode name, in lower case.
785: This instruction pattern moves data with that machine mode from
786: operand 1 to operand 0. For example, `movsi' moves full-word
787: data.
788:
789: If operand 0 is a `subreg' with mode M of a register whose own
790: mode is wider than M, the effect of this instruction is to store
791: the specified value in the part of the register that corresponds
792: to mode M. The effect on the rest of the register is undefined.
793:
794: This class of patterns is special in several ways. First of
795: all, each of these names *must* be defined, because there is no
796: other way to copy a datum from one place to another.
797:
798: Second, these patterns are not used solely in the RTL generation
799: pass. Even the reload pass can generate move insns to copy
800: values from stack slots into temporary registers. When it does
801: so, one of the operands is a hard register and the other is an
802: operand that can need to be reloaded into a register.
803:
804: Therefore, when given such a pair of operands, the pattern must
805: generate RTL which needs no reloading and needs no temporary
806: registers--no registers other than the operands. For example,
807: if you support the pattern with a `define_expand', then in such
808: a case the `define_expand' mustn't call `force_reg' or any other
809: such function which might generate new pseudo registers.
810:
811: This requirement exists even for subword modes on a RISC machine
812: where fetching those modes from memory normally requires several
813: insns and some temporary registers. Look in `spur.md' to see
814: how the requirement can be satisfied.
815:
816: The variety of operands that have reloads depends on the rest of
817: the machine description, but typically on a RISC machine these
818: can only be pseudo registers that did not get hard registers,
819: while on other machines explicit memory references will get
820: optional reloads.
821:
822: The constraints on a `moveM' must allow any hard register to be
823: moved to any other hard register (provided that
824: `HARD_REGNO_MODE_OK' permits mode M in both registers).
825:
826: It is obligatory to support floating point `moveM' instructions
1.1.1.2 root 827: into and out of any registers that can hold fixed point values,
828: because unions and structures (which have modes `SImode' or
829: `DImode') can be in those registers and they may have floating
830: point members.
831:
1.1.1.3 root 832: There may also be a need to support fixed point `moveM'
1.1.1.2 root 833: instructions in and out of floating point registers.
834: Unfortunately, I have forgotten why this was so, and I don't
835: know whether it is still true. If `HARD_REGNO_MODE_OK' rejects
836: fixed point values in floating point registers, then the
1.1.1.3 root 837: constraints of the fixed point `moveM' instructions must be
1.1.1.2 root 838: designed to avoid ever trying to reload into a floating point
839: register.
840:
1.1.1.3 root 841: `movstrictM'
842: Like `movM' except that if operand 0 is a `subreg' with mode M
843: of a register whose natural mode is wider, the `movstrictM'
844: instruction is guaranteed not to alter any of the register
845: except the part which belongs to mode M.
846:
847: `addM3'
848: Add operand 2 and operand 1, storing the result in operand 0.
849: All operands must have mode M. This can be used even on
850: two-address machines, by means of constraints requiring operands
851: 1 and 0 to be the same location.
852:
853: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3'
854: Similar, for other arithmetic operations.
855:
856: There are special considerations for register classes for
857: logical-and instructions, affecting also the macro
858: `PREFERRED_RELOAD_CLASS'. They apply not only to the patterns
859: with these standard names, but to any patterns that will match
860: such an instruction. *Note Register Classes::.
861:
862: `mulhisi3'
863: Multiply operands 1 and 2, which have mode `HImode', and store a
864: `SImode' product in operand 0.
865:
866: `mulqihi3', `mulsidi3'
867: Similar widening-multiplication instructions of other widths.
868:
869: `umulqihi3', `umulhisi3', `umulsidi3'
870: Similar widening-multiplication instructions that do unsigned
871: multiplication.
872:
873: `divmodM4'
874: Signed division that produces both a quotient and a remainder.
875: Operand 1 is divided by operand 2 to produce a quotient stored
876: in operand 0 and a remainder stored in operand 3.
877:
878: `udivmodM4'
879: Similar, but does unsigned division.
880:
881: `ashlM3'
882: Arithmetic-shift operand 1 left by a number of bits specified by
883: operand 2, and store the result in operand 0. Operand 2 has
884: mode `SImode', not mode M.
885:
886: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
887: Other shift and rotate instructions.
888:
889: Logical and arithmetic left shift are the same. Machines that
890: do not allow negative shift counts often have only one
891: instruction for shifting left. On such machines, you should
892: define a pattern named `ashlM3' and leave `lshlM3' undefined.
893:
894: There are special considerations for register classes for shift
895: instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'.
896: They apply not only to the patterns with these standard names,
897: but to any patterns that will match such an instruction. *Note
898: Register Classes::.
899:
900: `negM2'
901: Negate operand 1 and store the result in operand 0.
902:
903: `absM2'
904: Store the absolute value of operand 1 into operand 0.
905:
906: `sqrtM2'
907: Store the square root of operand 1 into operand 0.
908:
909: `ffsM2'
910: Store into operand 0 one plus the index of the least significant
911: 1-bit of operand 1. If operand 1 is zero, store zero. M is the
912: mode of operand 0; operand 1's mode is specified by the
913: instruction pattern, and the compiler will convert the operand
914: to that mode before generating the instruction.
915:
916: `one_cmplM2'
917: Store the bitwise-complement of operand 1 into operand 0.
918:
919: `cmpM'
920: Compare operand 0 and operand 1, and set the condition codes.
921: The RTL pattern should look like this:
922:
923: (set (cc0) (compare (match_operand:M 0 ...)
924: (match_operand:M 1 ...)))
925:
926: Each such definition in the machine description, for integer
927: mode M, must have a corresponding `tstM' pattern, because
928: optimization can simplify the compare into a test when operand 1
929: is zero.
930:
931: `tstM'
932: Compare operand 0 against zero, and set the condition codes.
933: The RTL pattern should look like this:
934:
935: (set (cc0) (match_operand:M 0 ...))
936:
937: `movstrM'
938: Block move instruction. The addresses of the destination and
939: source strings are the first two operands, and both are in mode
940: `Pmode'. The number of bytes to move is the third operand, in
941: mode M. The fourth operand is the known shared alignment of the
942: source and destination, in the form of a `const_int' rtx.
943:
944: `cmpstrM'
945: Block compare instruction, with operands like `movstrM' except
946: that the two memory blocks are compared byte by byte in
947: lexicographic order. The effect of the instruction is to set
948: the condition codes.
949:
950: `floatMN2'
951: Convert signed integer operand 1 (valid for fixed point mode M)
952: to floating point mode N and store in operand 0 (which has mode
953: N).
954:
955: `floatunsMN2'
956: Convert unsigned integer operand 1 (valid for fixed point mode
957: M) to floating point mode N and store in operand 0 (which has
958: mode N).
959:
960: `fixMN2'
961: Convert operand 1 (valid for floating point mode M) to fixed
962: point mode N as a signed number and store in operand 0 (which
963: has mode N). This instruction's result is defined only when the
964: value of operand 1 is an integer.
965:
966: `fixunsMN2'
967: Convert operand 1 (valid for floating point mode M) to fixed
968: point mode N as an unsigned number and store in operand 0 (which
969: has mode N). This instruction's result is defined only when the
970: value of operand 1 is an integer.
971:
972: `ftruncM2'
973: Convert operand 1 (valid for floating point mode M) to an
974: integer value, still represented in floating point mode M, and
975: store it in operand 0 (valid for floating point mode M).
976:
977: `fix_truncMN2'
978: Like `fixMN2' but works for any floating point value of mode M
979: by converting the value to an integer.
980:
981: `fixuns_truncMN2'
982: Like `fixunsMN2' but works for any floating point value of mode
983: M by converting the value to an integer.
984:
985: `truncMN'
986: Truncate operand 1 (valid for mode M) to mode N and store in
987: operand 0 (which has mode N). Both modes must be fixed point or
988: both floating point.
989:
990: `extendMN'
991: Sign-extend operand 1 (valid for mode M) to mode N and store in
992: operand 0 (which has mode N). Both modes must be fixed point or
993: both floating point.
994:
995: `zero_extendMN'
996: Zero-extend operand 1 (valid for mode M) to mode N and store in
997: operand 0 (which has mode N). Both modes must be fixed point.
998:
999: `extv'
1000: Extract a bit-field from operand 1 (a register or memory
1001: operand), where operand 2 specifies the width in bits and
1002: operand 3 the starting bit, and store it in operand 0. Operand
1.1.1.4 root 1003: 0 must have `SImode'. Operand 1 may have mode `QImode' or
1.1.1.3 root 1004: `SImode'; often `SImode' is allowed only for registers.
1005: Operands 2 and 3 must be valid for `SImode'.
1006:
1007: The RTL generation pass generates this instruction only with
1008: constants for operands 2 and 3.
1009:
1010: The bit-field value is sign-extended to a full word integer
1011: before it is stored in operand 0.
1012:
1013: `extzv'
1014: Like `extv' except that the bit-field value is zero-extended.
1015:
1016: `insv'
1017: Store operand 3 (which must be valid for `SImode') into a
1018: bit-field in operand 0, where operand 1 specifies the width in
1019: bits and operand 2 the starting bit. Operand 0 may have mode
1020: `QImode' or `SImode'; often `SImode' is allowed only for
1021: registers. Operands 1 and 2 must be valid for `SImode'.
1022:
1023: The RTL generation pass generates this instruction only with
1024: constants for operands 1 and 2.
1025:
1026: `sCOND'
1027: Store zero or nonzero in the operand according to the condition
1028: codes. Value stored is nonzero iff the condition COND is true.
1029: COND is the name of a comparison operation expression code, such
1030: as `eq', `lt' or `leu'.
1031:
1032: You specify the mode that the operand must have when you write
1033: the `match_operand' expression. The compiler automatically sees
1034: which mode you have used and supplies an operand of that mode.
1035:
1036: The value stored for a true condition must have 1 as its low
1037: bit, or else must be negative. Otherwise the instruction is not
1038: suitable and must be omitted from the machine description. You
1039: must tell the compiler exactly which value is stored by defining
1040: the macro `STORE_FLAG_VALUE'.
1041:
1042: `bCOND'
1043: Conditional branch instruction. Operand 0 is a `label_ref' that
1044: refers to the label to jump to. Jump if the condition codes
1045: meet condition COND.
1046:
1047: `call'
1048: Subroutine call instruction returning no value. Operand 0 is
1049: the function to call; operand 1 is the number of bytes of
1050: arguments pushed (in mode `SImode', except it is normally a
1051: `const_int'); operand 2 is the number of registers used as
1052: operands.
1053:
1054: On most machines, operand 2 is not actually stored into the RTL
1055: pattern. It is supplied for the sake of some RISC machines
1056: which need to put this information into the assembler code; they
1057: can put it in the RTL instead of operand 1.
1058:
1059: Operand 0 should be a `mem' RTX whose address is the address of
1060: the function.
1061:
1062: `call_value'
1063: Subroutine call instruction returning a value. Operand 0 is the
1064: hard register in which the value is returned. There are three
1065: more operands, the same as the three operands of the `call'
1066: instruction (but with numbers increased by one).
1067:
1068: Subroutines that return `BLKmode' objects use the `call' insn.
1069:
1070: `return'
1071: Subroutine return instruction. This instruction pattern name
1072: should be defined only if a single instruction can do all the
1073: work of returning from a function.
1074:
1075: `nop'
1076: No-op instruction. This instruction pattern name should always
1077: be defined to output a no-op in assembler code. `(const_int 0)'
1078: will do as an RTL pattern.
1079:
1080: `casesi'
1081: Instruction to jump through a dispatch table, including bounds
1082: checking. This instruction takes five operands:
1083:
1084: 1. The index to dispatch on, which has mode `SImode'.
1085:
1086: 2. The lower bound for indices in the table, an integer
1087: constant.
1088:
1089: 3. The total range of indices in the table--the largest index
1090: minus the smallest one (both inclusive).
1091:
1092: 4. A label to jump to if the index has a value outside the
1093: bounds. (If the machine-description macro
1094: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds
1095: index drops through to the code following the jump table
1096: instead of jumping to this label. In that case, this label
1097: is not actually used by the `casesi' instruction, but it is
1098: always provided as an operand.)
1099:
1100: 5. A label that precedes the table itself.
1101:
1102: The table is a `addr_vec' or `addr_diff_vec' inside of a
1103: `jump_insn'. The number of elements in the table is one plus
1104: the difference between the upper bound and the lower bound.
1105:
1106: `tablejump'
1107: Instruction to jump to a variable address. This is a low-level
1108: capability which can be used to implement a dispatch table when
1109: there is no `casesi' pattern.
1110:
1111: This pattern requires two operands: the address or offset, and a
1112: label which should immediately precede the jump table. If the
1113: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first
1.1.1.4 root 1114: operand is an offset that counts from the address of the table;
1115: otherwise, it is an absolute address to jump to.
1.1.1.3 root 1116:
1117: The `tablejump' insn is always the last insn before the jump
1118: table it uses. Its assembler code normally has no need to use
1119: the second operand, but you should incorporate it in the RTL
1120: pattern so that the jump optimizer will not delete the table as
1121: unreachable code.
1122:
1123:
1124:
1125: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
1126:
1127: When the Order of Patterns Matters
1128: ==================================
1129:
1130: Sometimes an insn can match more than one instruction pattern. Then
1131: the pattern that appears first in the machine description is the one
1132: used. Therefore, more specific patterns (patterns that will match
1133: fewer things) and faster instructions (those that will produce better
1134: code when they do match) should usually go first in the description.
1135:
1136: In some cases the effect of ordering the patterns can be used to hide
1137: a pattern when it is not valid. For example, the 68000 has an
1138: instruction for converting a fullword to floating point and another
1139: for converting a byte to floating point. An instruction converting
1140: an integer to floating point could match either one. We put the
1141: pattern to convert the fullword first to make sure that one will be
1142: used rather than the other. (Otherwise a large integer might be
1143: generated as a single-byte immediate quantity, which would not work.)
1144: Instead of using this pattern ordering it would be possible to make
1145: the pattern for convert-a-byte smart enough to deal properly with any
1146: constant value.
1147:
1148:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.