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