![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to md.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to md.texi CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 root 1: @c Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, Inc.
1.1 root 2: @c This is part of the GCC manual.
3: @c For copying conditions, see the file gcc.texi.
4:
5: @ifset INTERNALS
1.1.1.3 root 6: @node Machine Desc
1.1 root 7: @chapter Machine Descriptions
8: @cindex machine descriptions
9:
10: A machine description has two parts: a file of instruction patterns
11: (@file{.md} file) and a C header file of macro definitions.
12:
13: The @file{.md} file for a target machine contains a pattern for each
14: instruction that the target machine supports (or at least each instruction
15: that is worth telling the compiler about). It may also contain comments.
16: A semicolon causes the rest of the line to be a comment, unless the semicolon
17: is inside a quoted string.
18:
19: See the next chapter for information on the C header file.
20:
21: @menu
22: * Patterns:: How to write instruction patterns.
23: * Example:: An explained example of a @code{define_insn} pattern.
24: * RTL Template:: The RTL template defines what insns match a pattern.
25: * Output Template:: The output template says how to make assembler code
26: from such an insn.
27: * Output Statement:: For more generality, write C code to output
28: the assembler code.
29: * Constraints:: When not all operands are general operands.
30: * Standard Names:: Names mark patterns to use for code generation.
31: * Pattern Ordering:: When the order of patterns makes a difference.
32: * Dependent Patterns:: Having one pattern may make you need another.
33: * Jump Patterns:: Special considerations for patterns for jump insns.
34: * Insn Canonicalizations::Canonicalization of Instructions
35: * Peephole Definitions::Defining machine-specific peephole optimizations.
36: * Expander Definitions::Generating a sequence of several RTL insns
37: for a standard operation.
38: * Insn Splitting:: Splitting Instructions into Multiple Instructions
39: * Insn Attributes:: Specifying the value of attributes for generated insns.
40: @end menu
41:
1.1.1.5 root 42: @node Patterns
1.1 root 43: @section Everything about Instruction Patterns
44: @cindex patterns
45: @cindex instruction patterns
46:
47: @findex define_insn
48: Each instruction pattern contains an incomplete RTL expression, with pieces
49: to be filled in later, operand constraints that restrict how the pieces can
50: be filled in, and an output pattern or C code to generate the assembler
51: output, all wrapped up in a @code{define_insn} expression.
52:
53: A @code{define_insn} is an RTL expression containing four or five operands:
54:
55: @enumerate
56: @item
57: An optional name. The presence of a name indicate that this instruction
58: pattern can perform a certain standard job for the RTL-generation
59: pass of the compiler. This pass knows certain names and will use
60: the instruction patterns with those names, if the names are defined
61: in the machine description.
62:
63: The absence of a name is indicated by writing an empty string
64: where the name should go. Nameless instruction patterns are never
65: used for generating RTL code, but they may permit several simpler insns
66: to be combined later on.
67:
68: Names that are not thus known and used in RTL-generation have no
69: effect; they are equivalent to no name at all.
70:
71: @item
72: The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete
73: RTL expressions which show what the instruction should look like. It is
74: incomplete because it may contain @code{match_operand},
75: @code{match_operator}, and @code{match_dup} expressions that stand for
76: operands of the instruction.
77:
78: If the vector has only one element, that element is the template for the
79: instruction pattern. If the vector has multiple elements, then the
80: instruction pattern is a @code{parallel} expression containing the
81: elements described.
82:
83: @item
84: @cindex pattern conditions
85: @cindex conditions, in patterns
86: A condition. This is a string which contains a C expression that is
87: the final test to decide whether an insn body matches this pattern.
88:
89: @cindex named patterns and conditions
90: For a named pattern, the condition (if present) may not depend on
91: the data in the insn being matched, but only the target-machine-type
92: flags. The compiler needs to test these conditions during
93: initialization in order to learn exactly which named instructions are
94: available in a particular run.
95:
96: @findex operands
97: For nameless patterns, the condition is applied only when matching an
98: individual insn, and only after the insn has matched the pattern's
99: recognition template. The insn's operands may be found in the vector
100: @code{operands}.
101:
102: @item
103: The @dfn{output template}: a string that says how to output matching
104: insns as assembler code. @samp{%} in this string specifies where
105: to substitute the value of an operand. @xref{Output Template}.
106:
107: When simple substitution isn't general enough, you can specify a piece
108: of C code to compute the output. @xref{Output Statement}.
109:
110: @item
111: Optionally, a vector containing the values of attributes for insns matching
112: this pattern. @xref{Insn Attributes}.
113: @end enumerate
114:
1.1.1.5 root 115: @node Example
1.1 root 116: @section Example of @code{define_insn}
117: @cindex @code{define_insn} example
118:
119: Here is an actual example of an instruction pattern, for the 68000/68020.
120:
121: @example
122: (define_insn "tstsi"
123: [(set (cc0)
124: (match_operand:SI 0 "general_operand" "rm"))]
125: ""
126: "*
127: @{ if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
128: return \"tstl %0\";
129: return \"cmpl #0,%0\"; @}")
130: @end example
131:
132: This is an instruction that sets the condition codes based on the value of
133: a general operand. It has no condition, so any insn whose RTL description
134: has the form shown may be handled according to this pattern. The name
135: @samp{tstsi} means ``test a @code{SImode} value'' and tells the RTL generation
136: pass that, when it is necessary to test such a value, an insn to do so
137: can be constructed using this pattern.
138:
139: The output control string is a piece of C code which chooses which
140: output template to return based on the kind of operand and the specific
141: type of CPU for which code is being generated.
142:
143: @samp{"rm"} is an operand constraint. Its meaning is explained below.
144:
1.1.1.5 root 145: @node RTL Template
146: @section RTL Template
1.1 root 147: @cindex RTL insn template
148: @cindex generating insns
149: @cindex insns, generating
150: @cindex recognizing insns
151: @cindex insns, recognizing
152:
153: The RTL template is used to define which insns match the particular pattern
154: and how to find their operands. For named patterns, the RTL template also
155: says how to construct an insn from specified operands.
156:
157: Construction involves substituting specified operands into a copy of the
158: template. Matching involves determining the values that serve as the
159: operands in the insn being matched. Both of these activities are
160: controlled by special expression types that direct matching and
161: substitution of the operands.
162:
163: @table @code
164: @findex match_operand
165: @item (match_operand:@var{m} @var{n} @var{predicate} @var{constraint})
166: This expression is a placeholder for operand number @var{n} of
167: the insn. When constructing an insn, operand number @var{n}
168: will be substituted at this point. When matching an insn, whatever
169: appears at this position in the insn will be taken as operand
170: number @var{n}; but it must satisfy @var{predicate} or this instruction
171: pattern will not match at all.
172:
173: Operand numbers must be chosen consecutively counting from zero in
174: each instruction pattern. There may be only one @code{match_operand}
175: expression in the pattern for each operand number. Usually operands
176: are numbered in the order of appearance in @code{match_operand}
177: expressions.
178:
179: @var{predicate} is a string that is the name of a C function that accepts two
180: arguments, an expression and a machine mode. During matching, the
181: function will be called with the putative operand as the expression and
182: @var{m} as the mode argument (if @var{m} is not specified,
183: @code{VOIDmode} will be used, which normally causes @var{predicate} to accept
184: any mode). If it returns zero, this instruction pattern fails to match.
185: @var{predicate} may be an empty string; then it means no test is to be done
186: on the operand, so anything which occurs in this position is valid.
187:
188: Most of the time, @var{predicate} will reject modes other than @var{m}---but
189: not always. For example, the predicate @code{address_operand} uses
190: @var{m} as the mode of memory ref that the address should be valid for.
191: Many predicates accept @code{const_int} nodes even though their mode is
192: @code{VOIDmode}.
193:
194: @var{constraint} controls reloading and the choice of the best register
195: class to use for a value, as explained later (@pxref{Constraints}).
196:
197: People are often unclear on the difference between the constraint and the
198: predicate. The predicate helps decide whether a given insn matches the
199: pattern. The constraint plays no role in this decision; instead, it
200: controls various decisions in the case of an insn which does match.
201:
202: @findex general_operand
1.1.1.5 root 203: On CISC machines, the most common @var{predicate} is
204: @code{"general_operand"}. This function checks that the putative
205: operand is either a constant, a register or a memory reference, and that
206: it is valid for mode @var{m}.
1.1 root 207:
208: @findex register_operand
209: For an operand that must be a register, @var{predicate} should be
1.1.1.5 root 210: @code{"register_operand"}. Using @code{"general_operand"} would be
211: valid, since the reload pass would copy any non-register operands
212: through registers, but this would make GNU CC do extra work, it would
213: prevent invariant operands (such as constant) from being removed from
214: loops, and it would prevent the register allocator from doing the best
215: possible job. On RISC machines, it is usually most efficient to allow
216: @var{predicate} to accept only objects that the constraints allow.
1.1 root 217:
218: @findex immediate_operand
1.1.1.5 root 219: For an operand that must be a constant, you must be sure to either use
1.1 root 220: @code{"immediate_operand"} for @var{predicate}, or make the instruction
221: pattern's extra condition require a constant, or both. You cannot
222: expect the constraints to do this work! If the constraints allow only
223: constants, but the predicate allows something else, the compiler will
224: crash when that case arises.
225:
226: @findex match_scratch
227: @item (match_scratch:@var{m} @var{n} @var{constraint})
228: This expression is also a placeholder for operand number @var{n}
229: and indicates that operand must be a @code{scratch} or @code{reg}
230: expression.
231:
1.1.1.7 root 232: When matching patterns, this is equivalent to
1.1 root 233:
1.1.1.5 root 234: @smallexample
1.1 root 235: (match_operand:@var{m} @var{n} "scratch_operand" @var{pred})
1.1.1.5 root 236: @end smallexample
1.1 root 237:
238: but, when generating RTL, it produces a (@code{scratch}:@var{m})
239: expression.
240:
241: If the last few expressions in a @code{parallel} are @code{clobber}
242: expressions whose operands are either a hard register or
1.1.1.7 root 243: @code{match_scratch}, the combiner can add or delete them when
244: necessary. @xref{Side Effects}.
1.1 root 245:
246: @findex match_dup
247: @item (match_dup @var{n})
248: This expression is also a placeholder for operand number @var{n}.
249: It is used when the operand needs to appear more than once in the
250: insn.
251:
1.1.1.5 root 252: In construction, @code{match_dup} acts just like @code{match_operand}:
253: the operand is substituted into the insn being constructed. But in
254: matching, @code{match_dup} behaves differently. It assumes that operand
255: number @var{n} has already been determined by a @code{match_operand}
256: appearing earlier in the recognition template, and it matches only an
257: identical-looking expression.
1.1 root 258:
259: @findex match_operator
260: @item (match_operator:@var{m} @var{n} @var{predicate} [@var{operands}@dots{}])
261: This pattern is a kind of placeholder for a variable RTL expression
262: code.
263:
264: When constructing an insn, it stands for an RTL expression whose
265: expression code is taken from that of operand @var{n}, and whose
266: operands are constructed from the patterns @var{operands}.
267:
268: When matching an expression, it matches an expression if the function
269: @var{predicate} returns nonzero on that expression @emph{and} the
270: patterns @var{operands} match the operands of the expression.
271:
272: Suppose that the function @code{commutative_operator} is defined as
273: follows, to match any expression whose operator is one of the
274: commutative arithmetic operators of RTL and whose mode is @var{mode}:
275:
1.1.1.5 root 276: @smallexample
1.1 root 277: int
278: commutative_operator (x, mode)
279: rtx x;
280: enum machine_mode mode;
281: @{
282: enum rtx_code code = GET_CODE (x);
283: if (GET_MODE (x) != mode)
284: return 0;
1.1.1.5 root 285: return (GET_RTX_CLASS (code) == 'c'
286: || code == EQ || code == NE);
1.1 root 287: @}
1.1.1.5 root 288: @end smallexample
1.1 root 289:
290: Then the following pattern will match any RTL expression consisting
291: of a commutative operator applied to two general operands:
292:
1.1.1.5 root 293: @smallexample
1.1 root 294: (match_operator:SI 3 "commutative_operator"
295: [(match_operand:SI 1 "general_operand" "g")
296: (match_operand:SI 2 "general_operand" "g")])
1.1.1.5 root 297: @end smallexample
1.1 root 298:
299: Here the vector @code{[@var{operands}@dots{}]} contains two patterns
300: because the expressions to be matched all contain two operands.
301:
302: When this pattern does match, the two operands of the commutative
303: operator are recorded as operands 1 and 2 of the insn. (This is done
304: by the two instances of @code{match_operand}.) Operand 3 of the insn
305: will be the entire commutative expression: use @code{GET_CODE
306: (operands[3])} to see which commutative operator was used.
307:
308: The machine mode @var{m} of @code{match_operator} works like that of
309: @code{match_operand}: it is passed as the second argument to the
310: predicate function, and that function is solely responsible for
311: deciding whether the expression to be matched ``has'' that mode.
312:
313: When constructing an insn, argument 3 of the gen-function will specify
314: the operation (i.e. the expression code) for the expression to be
315: made. It should be an RTL expression, whose expression code is copied
316: into a new expression whose operands are arguments 1 and 2 of the
317: gen-function. The subexpressions of argument 3 are not used;
318: only its expression code matters.
319:
320: When @code{match_operator} is used in a pattern for matching an insn,
321: it usually best if the operand number of the @code{match_operator}
322: is higher than that of the actual operands of the insn. This improves
323: register allocation because the register allocator often looks at
324: operands 1 and 2 of insns to see if it can do register tying.
325:
326: There is no way to specify constraints in @code{match_operator}. The
327: operand of the insn which corresponds to the @code{match_operator}
328: never has any constraints because it is never reloaded as a whole.
329: However, if parts of its @var{operands} are matched by
330: @code{match_operand} patterns, those parts may have constraints of
331: their own.
332:
1.1.1.4 root 333: @findex match_op_dup
334: @item (match_op_dup:@var{m} @var{n}[@var{operands}@dots{}])
335: Like @code{match_dup}, except that it applies to operators instead of
336: operands. When constructing an insn, operand number @var{n} will be
337: substituted at this point. But in matching, @code{match_op_dup} behaves
338: differently. It assumes that operand number @var{n} has already been
339: determined by a @code{match_operator} appearing earlier in the
340: recognition template, and it matches only an identical-looking
341: expression.
342:
1.1.1.3 root 343: @findex match_parallel
344: @item (match_parallel @var{n} @var{predicate} [@var{subpat}@dots{}])
345: This pattern is a placeholder for an insn that consists of a
346: @code{parallel} expression with a variable number of elements. This
347: expression should only appear at the top level of an insn pattern.
348:
349: When constructing an insn, operand number @var{n} will be substituted at
350: this point. When matching an insn, it matches if the body of the insn
351: is a @code{parallel} expression with at least as many elements as the
352: vector of @var{subpat} expressions in the @code{match_parallel}, if each
353: @var{subpat} matches the corresponding element of the @code{parallel},
354: @emph{and} the function @var{predicate} returns nonzero on the
355: @code{parallel} that is the body of the insn. It is the responsibility
356: of the predicate to validate elements of the @code{parallel} beyond
357: those listed in the @code{match_parallel}.@refill
358:
359: A typical use of @code{match_parallel} is to match load and store
1.1.1.7 root 360: multiple expressions, which can contain a variable number of elements
1.1.1.3 root 361: in a @code{parallel}. For example,
1.1.1.5 root 362: @c the following is *still* going over. need to change the code.
363: @c also need to work on grouping of this example. --mew 1feb93
1.1.1.3 root 364:
1.1.1.5 root 365: @smallexample
1.1.1.3 root 366: (define_insn ""
367: [(match_parallel 0 "load_multiple_operation"
1.1.1.5 root 368: [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
369: (match_operand:SI 2 "memory_operand" "m"))
370: (use (reg:SI 179))
371: (clobber (reg:SI 179))])]
1.1.1.3 root 372: ""
373: "loadm 0,0,%1,%2")
1.1.1.5 root 374: @end smallexample
1.1.1.3 root 375:
376: This example comes from @file{a29k.md}. The function
377: @code{load_multiple_operations} is defined in @file{a29k.c} and checks
378: that subsequent elements in the @code{parallel} are the same as the
379: @code{set} in the pattern, except that they are referencing subsequent
380: registers and memory locations.
381:
382: An insn that matches this pattern might look like:
383:
1.1.1.5 root 384: @smallexample
385: (parallel
386: [(set (reg:SI 20) (mem:SI (reg:SI 100)))
387: (use (reg:SI 179))
388: (clobber (reg:SI 179))
389: (set (reg:SI 21)
390: (mem:SI (plus:SI (reg:SI 100)
391: (const_int 4))))
392: (set (reg:SI 22)
393: (mem:SI (plus:SI (reg:SI 100)
394: (const_int 8))))])
395: @end smallexample
1.1.1.3 root 396:
1.1.1.4 root 397: @findex match_par_dup
398: @item (match_par_dup @var{n} [@var{subpat}@dots{}])
399: Like @code{match_op_dup}, but for @code{match_parallel} instead of
400: @code{match_operator}.
401:
1.1 root 402: @findex address
403: @item (address (match_operand:@var{m} @var{n} "address_operand" ""))
404: This complex of expressions is a placeholder for an operand number
405: @var{n} in a ``load address'' instruction: an operand which specifies
406: a memory location in the usual way, but for which the actual operand
407: value used is the address of the location, not the contents of the
408: location.
409:
410: @code{address} expressions never appear in RTL code, only in machine
411: descriptions. And they are used only in machine descriptions that do
412: not use the operand constraint feature. When operand constraints are
413: in use, the letter @samp{p} in the constraint serves this purpose.
414:
415: @var{m} is the machine mode of the @emph{memory location being
416: addressed}, not the machine mode of the address itself. That mode is
417: always the same on a given target machine (it is @code{Pmode}, which
418: normally is @code{SImode}), so there is no point in mentioning it;
419: thus, no machine mode is written in the @code{address} expression. If
420: some day support is added for machines in which addresses of different
421: kinds of objects appear differently or are used differently (such as
422: the PDP-10), different formats would perhaps need different machine
423: modes and these modes might be written in the @code{address}
424: expression.
425: @end table
426:
1.1.1.5 root 427: @node Output Template
1.1 root 428: @section Output Templates and Operand Substitution
429: @cindex output templates
430: @cindex operand substitution
431:
432: @cindex @samp{%} in template
433: @cindex percent sign
434: The @dfn{output template} is a string which specifies how to output the
435: assembler code for an instruction pattern. Most of the template is a
436: fixed string which is output literally. The character @samp{%} is used
437: to specify where to substitute an operand; it can also be used to
438: identify places where different variants of the assembler require
439: different syntax.
440:
441: In the simplest case, a @samp{%} followed by a digit @var{n} says to output
442: operand @var{n} at that point in the string.
443:
444: @samp{%} followed by a letter and a digit says to output an operand in an
445: alternate fashion. Four letters have standard, built-in meanings described
446: below. The machine description macro @code{PRINT_OPERAND} can define
447: additional letters with nonstandard meanings.
448:
449: @samp{%c@var{digit}} can be used to substitute an operand that is a
450: constant value without the syntax that normally indicates an immediate
451: operand.
452:
453: @samp{%n@var{digit}} is like @samp{%c@var{digit}} except that the value of
454: the constant is negated before printing.
455:
456: @samp{%a@var{digit}} can be used to substitute an operand as if it were a
457: memory reference, with the actual operand treated as the address. This may
458: be useful when outputting a ``load address'' instruction, because often the
459: assembler syntax for such an instruction requires you to write the operand
460: as if it were a memory reference.
461:
462: @samp{%l@var{digit}} is used to substitute a @code{label_ref} into a jump
463: instruction.
464:
1.1.1.4 root 465: @samp{%=} outputs a number which is unique to each instruction in the
466: entire compilation. This is useful for making local labels to be
467: referred to more than once in a single template that generates multiple
468: assembler instructions.
469:
1.1 root 470: @samp{%} followed by a punctuation character specifies a substitution that
471: does not use an operand. Only one case is standard: @samp{%%} outputs a
472: @samp{%} into the assembler code. Other nonstandard cases can be
473: defined in the @code{PRINT_OPERAND} macro. You must also define
474: which punctuation characters are valid with the
475: @code{PRINT_OPERAND_PUNCT_VALID_P} macro.
476:
477: @cindex \
478: @cindex backslash
479: The template may generate multiple assembler instructions. Write the text
480: for the instructions, with @samp{\;} between them.
481:
482: @cindex matching operands
483: When the RTL contains two operands which are required by constraint to match
484: each other, the output template must refer only to the lower-numbered operand.
485: Matching operands are not always identical, and the rest of the compiler
486: arranges to put the proper RTL expression for printing into the lower-numbered
487: operand.
488:
489: One use of nonstandard letters or punctuation following @samp{%} is to
490: distinguish between different assembler languages for the same machine; for
491: example, Motorola syntax versus MIT syntax for the 68000. Motorola syntax
492: requires periods in most opcode names, while MIT syntax does not. For
493: example, the opcode @samp{movel} in MIT syntax is @samp{move.l} in Motorola
494: syntax. The same file of patterns is used for both kinds of output syntax,
495: but the character sequence @samp{%.} is used in each place where Motorola
496: syntax wants a period. The @code{PRINT_OPERAND} macro for Motorola syntax
497: defines the sequence to output a period; the macro for MIT syntax defines
498: it to do nothing.
499:
1.1.1.5 root 500: @cindex @code{#} in template
501: As a special case, a template consisting of the single character @code{#}
502: instructs the compiler to first split the insn, and then output the
503: resulting instructions separately. This helps eliminate redundancy in the
504: output templates. If you have a @code{define_insn} that needs to emit
505: multiple assembler instructions, and there is an matching @code{define_split}
506: already defined, then you can simply use @code{#} as the output template
507: instead of writing an output template that emits the multiple assembler
508: instructions.
509:
1.1.1.6 root 510: If @code{ASSEMBLER_DIALECT} is defined, you can use
511: @samp{@{option0|option1|option2@}} constructs in the templates. These
512: describe multiple variants of assembler language syntax.
513: @xref{Instruction Output}.
514:
1.1.1.5 root 515: @node Output Statement
516: @section C Statements for Assembler Output
1.1 root 517: @cindex output statements
518: @cindex C statements for assembler output
519: @cindex generating assembler output
520:
521: Often a single fixed template string cannot produce correct and efficient
522: assembler code for all the cases that are recognized by a single
523: instruction pattern. For example, the opcodes may depend on the kinds of
524: operands; or some unfortunate combinations of operands may require extra
525: machine instructions.
526:
527: If the output control string starts with a @samp{@@}, then it is actually
528: a series of templates, each on a separate line. (Blank lines and
529: leading spaces and tabs are ignored.) The templates correspond to the
530: pattern's constraint alternatives (@pxref{Multi-Alternative}). For example,
531: if a target machine has a two-address add instruction @samp{addr} to add
532: into a register and another @samp{addm} to add a register to memory, you
533: might write this pattern:
534:
1.1.1.5 root 535: @smallexample
1.1 root 536: (define_insn "addsi3"
1.1.1.3 root 537: [(set (match_operand:SI 0 "general_operand" "=r,m")
1.1 root 538: (plus:SI (match_operand:SI 1 "general_operand" "0,0")
539: (match_operand:SI 2 "general_operand" "g,r")))]
540: ""
541: "@@
1.1.1.4 root 542: addr %2,%0
543: addm %2,%0")
1.1.1.5 root 544: @end smallexample
1.1 root 545:
546: @cindex @code{*} in template
547: @cindex asterisk in template
548: If the output control string starts with a @samp{*}, then it is not an
549: output template but rather a piece of C program that should compute a
550: template. It should execute a @code{return} statement to return the
551: template-string you want. Most such templates use C string literals, which
552: require doublequote characters to delimit them. To include these
553: doublequote characters in the string, prefix each one with @samp{\}.
554:
555: The operands may be found in the array @code{operands}, whose C data type
556: is @code{rtx []}.
557:
558: It is very common to select different ways of generating assembler code
559: based on whether an immediate operand is within a certain range. Be
560: careful when doing this, because the result of @code{INTVAL} is an
561: integer on the host machine. If the host machine has more bits in an
562: @code{int} than the target machine has in the mode in which the constant
563: will be used, then some of the bits you get from @code{INTVAL} will be
564: superfluous. For proper results, you must carefully disregard the
565: values of those bits.
566:
567: @findex output_asm_insn
568: It is possible to output an assembler instruction and then go on to output
569: or compute more of them, using the subroutine @code{output_asm_insn}. This
570: receives two arguments: a template-string and a vector of operands. The
571: vector may be @code{operands}, or it may be another array of @code{rtx}
572: that you declare locally and initialize yourself.
573:
574: @findex which_alternative
575: When an insn pattern has multiple alternatives in its constraints, often
576: the appearance of the assembler code is determined mostly by which alternative
577: was matched. When this is so, the C code can test the variable
578: @code{which_alternative}, which is the ordinal number of the alternative
579: that was actually satisfied (0 for the first, 1 for the second alternative,
580: etc.).
581:
582: For example, suppose there are two opcodes for storing zero, @samp{clrreg}
583: for registers and @samp{clrmem} for memory locations. Here is how
584: a pattern could use @code{which_alternative} to choose between them:
585:
1.1.1.5 root 586: @smallexample
1.1 root 587: (define_insn ""
1.1.1.3 root 588: [(set (match_operand:SI 0 "general_operand" "=r,m")
1.1 root 589: (const_int 0))]
590: ""
591: "*
592: return (which_alternative == 0
593: ? \"clrreg %0\" : \"clrmem %0\");
594: ")
1.1.1.5 root 595: @end smallexample
1.1 root 596:
597: The example above, where the assembler code to generate was
598: @emph{solely} determined by the alternative, could also have been specified
599: as follows, having the output control string start with a @samp{@@}:
600:
1.1.1.5 root 601: @smallexample
602: @group
1.1 root 603: (define_insn ""
1.1.1.3 root 604: [(set (match_operand:SI 0 "general_operand" "=r,m")
1.1 root 605: (const_int 0))]
606: ""
607: "@@
608: clrreg %0
609: clrmem %0")
1.1.1.5 root 610: @end group
611: @end smallexample
612: @end ifset
1.1 root 613:
1.1.1.5 root 614: @c Most of this node appears by itself (in a different place) even
615: @c when the INTERNALS flag is clear. Passages that require the full
616: @c manual's context are conditionalized to appear only in the full manual.
617: @ifset INTERNALS
618: @node Constraints
1.1 root 619: @section Operand Constraints
620: @cindex operand constraints
621: @cindex constraints
622:
623: Each @code{match_operand} in an instruction pattern can specify a
1.1.1.5 root 624: constraint for the type of operands allowed.
625: @end ifset
626: @ifclear INTERNALS
627: @node Constraints
628: @section Constraints for @code{asm} Operands
629: @cindex operand constraints, @code{asm}
630: @cindex constraints, @code{asm}
631: @cindex @code{asm} constraints
1.1.1.7 root 632:
1.1.1.5 root 633: Here are specific details on what constraint letters you can use with
634: @code{asm} operands.
635: @end ifclear
636: Constraints can say whether
1.1 root 637: an operand may be in a register, and which kinds of register; whether the
638: operand can be a memory reference, and which kinds of address; whether the
639: operand may be an immediate constant, and which possible values it may
640: have. Constraints can also require two operands to match.
641:
1.1.1.5 root 642: @ifset INTERNALS
1.1 root 643: @menu
644: * Simple Constraints:: Basic use of constraints.
645: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
646: * Class Preferences:: Constraints guide which hard register to put things in.
647: * Modifiers:: More precise control over effects of constraints.
1.1.1.5 root 648: * Machine Constraints:: Existing constraints for some particular machines.
1.1 root 649: * No Constraints:: Describing a clean machine without constraints.
650: @end menu
1.1.1.5 root 651: @end ifset
1.1 root 652:
1.1.1.5 root 653: @ifclear INTERNALS
654: @menu
655: * Simple Constraints:: Basic use of constraints.
656: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
657: * Modifiers:: More precise control over effects of constraints.
658: * Machine Constraints:: Special constraints for some particular machines.
659: @end menu
660: @end ifclear
661:
662: @node Simple Constraints
1.1 root 663: @subsection Simple Constraints
664: @cindex simple constraints
665:
666: The simplest kind of constraint is a string full of letters, each of
667: which describes one kind of operand that is permitted. Here are
668: the letters that are allowed:
669:
670: @table @asis
671: @cindex @samp{m} in constraint
672: @cindex memory references in constraints
673: @item @samp{m}
674: A memory operand is allowed, with any kind of address that the machine
675: supports in general.
676:
677: @cindex offsettable address
678: @cindex @samp{o} in constraint
679: @item @samp{o}
680: A memory operand is allowed, but only if the address is
681: @dfn{offsettable}. This means that adding a small integer (actually,
682: the width in bytes of the operand, as determined by its machine mode)
683: may be added to the address and the result is also a valid memory
684: address.
685:
686: @cindex autoincrement/decrement addressing
687: For example, an address which is constant is offsettable; so is an
688: address that is the sum of a register and a constant (as long as a
689: slightly larger constant is also within the range of address-offsets
690: supported by the machine); but an autoincrement or autodecrement
691: address is not offsettable. More complicated indirect/indexed
692: addresses may or may not be offsettable depending on the other
693: addressing modes that the machine supports.
694:
695: Note that in an output operand which can be matched by another
696: operand, the constraint letter @samp{o} is valid only when accompanied
697: by both @samp{<} (if the target machine has predecrement addressing)
698: and @samp{>} (if the target machine has preincrement addressing).
699:
700: @cindex @samp{V} in constraint
701: @item @samp{V}
702: A memory operand that is not offsettable. In other words, anything that
703: would fit the @samp{m} constraint but not the @samp{o} constraint.
704:
705: @cindex @samp{<} in constraint
706: @item @samp{<}
707: A memory operand with autodecrement addressing (either predecrement or
708: postdecrement) is allowed.
709:
710: @cindex @samp{>} in constraint
711: @item @samp{>}
712: A memory operand with autoincrement addressing (either preincrement or
713: postincrement) is allowed.
714:
715: @cindex @samp{r} in constraint
716: @cindex registers in constraints
717: @item @samp{r}
718: A register operand is allowed provided that it is in a general
719: register.
720:
721: @cindex @samp{d} in constraint
722: @item @samp{d}, @samp{a}, @samp{f}, @dots{}
723: Other letters can be defined in machine-dependent fashion to stand for
724: particular classes of registers. @samp{d}, @samp{a} and @samp{f} are
725: defined on the 68000/68020 to stand for data, address and floating
726: point registers.
727:
728: @cindex constants in constraints
729: @cindex @samp{i} in constraint
730: @item @samp{i}
731: An immediate integer operand (one with constant value) is allowed.
732: This includes symbolic constants whose values will be known only at
733: assembly time.
734:
735: @cindex @samp{n} in constraint
736: @item @samp{n}
737: An immediate integer operand with a known numeric value is allowed.
738: Many systems cannot support assembly-time constants for operands less
739: than a word wide. Constraints for these operands should use @samp{n}
740: rather than @samp{i}.
741:
742: @cindex @samp{I} in constraint
743: @item @samp{I}, @samp{J}, @samp{K}, @dots{} @samp{P}
744: Other letters in the range @samp{I} through @samp{P} may be defined in
745: a machine-dependent fashion to permit immediate integer operands with
746: explicit integer values in specified ranges. For example, on the
747: 68000, @samp{I} is defined to stand for the range of values 1 to 8.
748: This is the range permitted as a shift count in the shift
749: instructions.
750:
751: @cindex @samp{E} in constraint
752: @item @samp{E}
753: An immediate floating operand (expression code @code{const_double}) is
754: allowed, but only if the target floating point format is the same as
755: that of the host machine (on which the compiler is running).
756:
757: @cindex @samp{F} in constraint
758: @item @samp{F}
759: An immediate floating operand (expression code @code{const_double}) is
760: allowed.
761:
762: @cindex @samp{G} in constraint
763: @cindex @samp{H} in constraint
764: @item @samp{G}, @samp{H}
765: @samp{G} and @samp{H} may be defined in a machine-dependent fashion to
766: permit immediate floating operands in particular ranges of values.
767:
768: @cindex @samp{s} in constraint
769: @item @samp{s}
770: An immediate integer operand whose value is not an explicit integer is
771: allowed.
772:
773: This might appear strange; if an insn allows a constant operand with a
774: value not known at compile time, it certainly must allow any known
775: value. So why use @samp{s} instead of @samp{i}? Sometimes it allows
776: better code to be generated.
777:
778: For example, on the 68000 in a fullword instruction it is possible to
779: use an immediate operand; but if the immediate value is between -128
780: and 127, better code results from loading the value into a register and
781: using the register. This is because the load into the register can be
782: done with a @samp{moveq} instruction. We arrange for this to happen
783: by defining the letter @samp{K} to mean ``any integer outside the
784: range -128 to 127'', and then specifying @samp{Ks} in the operand
785: constraints.
786:
787: @cindex @samp{g} in constraint
788: @item @samp{g}
789: Any register, memory or immediate integer operand is allowed, except for
790: registers that are not general registers.
791:
792: @cindex @samp{X} in constraint
793: @item @samp{X}
1.1.1.5 root 794: @ifset INTERNALS
1.1 root 795: Any operand whatsoever is allowed, even if it does not satisfy
796: @code{general_operand}. This is normally used in the constraint of
797: a @code{match_scratch} when certain alternatives will not actually
798: require a scratch register.
1.1.1.5 root 799: @end ifset
800: @ifclear INTERNALS
801: Any operand whatsoever is allowed.
802: @end ifclear
1.1 root 803:
804: @cindex @samp{0} in constraint
805: @cindex digits in constraint
806: @item @samp{0}, @samp{1}, @samp{2}, @dots{} @samp{9}
807: An operand that matches the specified operand number is allowed. If a
808: digit is used together with letters within the same alternative, the
809: digit should come last.
810:
811: @cindex matching constraint
812: @cindex constraint, matching
813: This is called a @dfn{matching constraint} and what it really means is
814: that the assembler has only a single operand that fills two roles
1.1.1.5 root 815: @ifset INTERNALS
1.1 root 816: considered separate in the RTL insn. For example, an add insn has two
1.1.1.3 root 817: input operands and one output operand in the RTL, but on most CISC
1.1.1.5 root 818: @end ifset
819: @ifclear INTERNALS
820: which @code{asm} distinguishes. For example, an add instruction uses
821: two input operands and an output operand, but on most CISC
822: @end ifclear
1.1.1.3 root 823: machines an add instruction really has only two operands, one of them an
824: input-output operand:
825:
1.1.1.5 root 826: @smallexample
1.1.1.3 root 827: addl #35,r12
1.1.1.5 root 828: @end smallexample
1.1 root 829:
1.1.1.3 root 830: Matching constraints are used in these circumstances.
1.1 root 831: More precisely, the two operands that match must include one input-only
832: operand and one output-only operand. Moreover, the digit must be a
833: smaller number than the number of the operand that uses it in the
834: constraint.
835:
1.1.1.5 root 836: @ifset INTERNALS
1.1 root 837: For operands to match in a particular case usually means that they
838: are identical-looking RTL expressions. But in a few special cases
839: specific kinds of dissimilarity are allowed. For example, @code{*x}
840: as an input operand will match @code{*x++} as an output operand.
841: For proper results in such cases, the output template should always
842: use the output-operand's number when printing the operand.
1.1.1.5 root 843: @end ifset
1.1 root 844:
845: @cindex load address instruction
846: @cindex push address instruction
847: @cindex address constraints
848: @cindex @samp{p} in constraint
849: @item @samp{p}
850: An operand that is a valid memory address is allowed. This is
851: for ``load address'' and ``push address'' instructions.
852:
853: @findex address_operand
854: @samp{p} in the constraint must be accompanied by @code{address_operand}
855: as the predicate in the @code{match_operand}. This predicate interprets
856: the mode specified in the @code{match_operand} as the mode of the memory
857: reference for which the address would be valid.
858:
859: @cindex extensible constraints
860: @cindex @samp{Q}, in constraint
861: @item @samp{Q}, @samp{R}, @samp{S}, @dots{} @samp{U}
862: Letters in the range @samp{Q} through @samp{U} may be defined in a
863: machine-dependent fashion to stand for arbitrary operand types.
1.1.1.5 root 864: @ifset INTERNALS
1.1 root 865: The machine description macro @code{EXTRA_CONSTRAINT} is passed the
866: operand as its first argument and the constraint letter as its
867: second operand.
868:
869: A typical use for this would be to distinguish certain types of
870: memory references that affect other insn operands.
871:
872: Do not define these constraint letters to accept register references
873: (@code{reg}); the reload pass does not expect this and would not handle
874: it properly.
1.1.1.5 root 875: @end ifset
1.1 root 876: @end table
877:
1.1.1.5 root 878: @ifset INTERNALS
1.1 root 879: In order to have valid assembler code, each operand must satisfy
880: its constraint. But a failure to do so does not prevent the pattern
881: from applying to an insn. Instead, it directs the compiler to modify
882: the code so that the constraint will be satisfied. Usually this is
883: done by copying an operand into a register.
884:
885: Contrast, therefore, the two instruction patterns that follow:
886:
1.1.1.5 root 887: @smallexample
1.1 root 888: (define_insn ""
1.1.1.3 root 889: [(set (match_operand:SI 0 "general_operand" "=r")
1.1 root 890: (plus:SI (match_dup 0)
891: (match_operand:SI 1 "general_operand" "r")))]
892: ""
893: "@dots{}")
1.1.1.5 root 894: @end smallexample
1.1 root 895:
896: @noindent
897: which has two operands, one of which must appear in two places, and
898:
1.1.1.5 root 899: @smallexample
1.1 root 900: (define_insn ""
1.1.1.3 root 901: [(set (match_operand:SI 0 "general_operand" "=r")
1.1 root 902: (plus:SI (match_operand:SI 1 "general_operand" "0")
903: (match_operand:SI 2 "general_operand" "r")))]
904: ""
905: "@dots{}")
1.1.1.5 root 906: @end smallexample
1.1 root 907:
908: @noindent
909: which has three operands, two of which are required by a constraint to be
910: identical. If we are considering an insn of the form
911:
1.1.1.5 root 912: @smallexample
1.1 root 913: (insn @var{n} @var{prev} @var{next}
914: (set (reg:SI 3)
915: (plus:SI (reg:SI 6) (reg:SI 109)))
916: @dots{})
1.1.1.5 root 917: @end smallexample
1.1 root 918:
919: @noindent
920: the first pattern would not apply at all, because this insn does not
921: contain two identical subexpressions in the right place. The pattern would
922: say, ``That does not look like an add instruction; try other patterns.''
923: The second pattern would say, ``Yes, that's an add instruction, but there
924: is something wrong with it.'' It would direct the reload pass of the
925: compiler to generate additional insns to make the constraint true. The
926: results might look like this:
927:
1.1.1.5 root 928: @smallexample
1.1 root 929: (insn @var{n2} @var{prev} @var{n}
930: (set (reg:SI 3) (reg:SI 6))
931: @dots{})
932:
933: (insn @var{n} @var{n2} @var{next}
934: (set (reg:SI 3)
935: (plus:SI (reg:SI 3) (reg:SI 109)))
936: @dots{})
1.1.1.5 root 937: @end smallexample
1.1 root 938:
939: It is up to you to make sure that each operand, in each pattern, has
940: constraints that can handle any RTL expression that could be present for
941: that operand. (When multiple alternatives are in use, each pattern must,
942: for each possible combination of operand expressions, have at least one
943: alternative which can handle that combination of operands.) The
944: constraints don't need to @emph{allow} any possible operand---when this is
945: the case, they do not constrain---but they must at least point the way to
946: reloading any possible operand so that it will fit.
947:
948: @itemize @bullet
949: @item
950: If the constraint accepts whatever operands the predicate permits,
951: there is no problem: reloading is never necessary for this operand.
952:
953: For example, an operand whose constraints permit everything except
954: registers is safe provided its predicate rejects registers.
955:
956: An operand whose predicate accepts only constant values is safe
957: provided its constraints include the letter @samp{i}. If any possible
958: constant value is accepted, then nothing less than @samp{i} will do;
959: if the predicate is more selective, then the constraints may also be
960: more selective.
961:
962: @item
963: Any operand expression can be reloaded by copying it into a register.
964: So if an operand's constraints allow some kind of register, it is
965: certain to be safe. It need not permit all classes of registers; the
966: compiler knows how to copy a register into another register of the
967: proper class in order to make an instruction valid.
968:
969: @cindex nonoffsettable memory reference
970: @cindex memory reference, nonoffsettable
971: @item
972: A nonoffsettable memory reference can be reloaded by copying the
973: address into a register. So if the constraint uses the letter
974: @samp{o}, all memory references are taken care of.
975:
976: @item
977: A constant operand can be reloaded by allocating space in memory to
978: hold it as preinitialized data. Then the memory reference can be used
979: in place of the constant. So if the constraint uses the letters
980: @samp{o} or @samp{m}, constant operands are not a problem.
981:
982: @item
983: If the constraint permits a constant and a pseudo register used in an insn
984: was not allocated to a hard register and is equivalent to a constant,
985: the register will be replaced with the constant. If the predicate does
986: not permit a constant and the insn is re-recognized for some reason, the
987: compiler will crash. Thus the predicate must always recognize any
988: objects allowed by the constraint.
989: @end itemize
990:
991: If the operand's predicate can recognize registers, but the constraint does
992: not permit them, it can make the compiler crash. When this operand happens
993: to be a register, the reload pass will be stymied, because it does not know
994: how to copy a register temporarily into memory.
1.1.1.5 root 995: @end ifset
1.1 root 996:
1.1.1.5 root 997: @node Multi-Alternative
1.1 root 998: @subsection Multiple Alternative Constraints
999: @cindex multiple alternative constraints
1000:
1001: Sometimes a single instruction has multiple alternative sets of possible
1002: operands. For example, on the 68000, a logical-or instruction can combine
1003: register or an immediate value into memory, or it can combine any kind of
1004: operand into a register; but it cannot combine one memory location into
1005: another.
1006:
1007: These constraints are represented as multiple alternatives. An alternative
1008: can be described by a series of letters for each operand. The overall
1009: constraint for an operand is made from the letters for this operand
1010: from the first alternative, a comma, the letters for this operand from
1011: the second alternative, a comma, and so on until the last alternative.
1.1.1.5 root 1012: @ifset INTERNALS
1.1 root 1013: Here is how it is done for fullword logical-or on the 68000:
1014:
1.1.1.5 root 1015: @smallexample
1.1 root 1016: (define_insn "iorsi3"
1017: [(set (match_operand:SI 0 "general_operand" "=m,d")
1018: (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
1019: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
1020: @dots{})
1.1.1.5 root 1021: @end smallexample
1.1 root 1022:
1023: The first alternative has @samp{m} (memory) for operand 0, @samp{0} for
1024: operand 1 (meaning it must match operand 0), and @samp{dKs} for operand
1025: 2. The second alternative has @samp{d} (data register) for operand 0,
1026: @samp{0} for operand 1, and @samp{dmKs} for operand 2. The @samp{=} and
1027: @samp{%} in the constraints apply to all the alternatives; their
1028: meaning is explained in the next section (@pxref{Class Preferences}).
1.1.1.5 root 1029: @end ifset
1.1 root 1030:
1.1.1.5 root 1031: @c FIXME Is this ? and ! stuff of use in asm()? If not, hide unless INTERNAL
1.1 root 1032: If all the operands fit any one alternative, the instruction is valid.
1033: Otherwise, for each alternative, the compiler counts how many instructions
1034: must be added to copy the operands so that that alternative applies.
1035: The alternative requiring the least copying is chosen. If two alternatives
1036: need the same amount of copying, the one that comes first is chosen.
1037: These choices can be altered with the @samp{?} and @samp{!} characters:
1038:
1039: @table @code
1040: @cindex @samp{?} in constraint
1041: @cindex question mark
1042: @item ?
1043: Disparage slightly the alternative that the @samp{?} appears in,
1044: as a choice when no alternative applies exactly. The compiler regards
1045: this alternative as one unit more costly for each @samp{?} that appears
1046: in it.
1047:
1048: @cindex @samp{!} in constraint
1049: @cindex exclamation point
1050: @item !
1051: Disparage severely the alternative that the @samp{!} appears in.
1052: This alternative can still be used if it fits without reloading,
1053: but if reloading is needed, some other alternative will be used.
1054: @end table
1055:
1.1.1.5 root 1056: @ifset INTERNALS
1.1 root 1057: When an insn pattern has multiple alternatives in its constraints, often
1058: the appearance of the assembler code is determined mostly by which
1059: alternative was matched. When this is so, the C code for writing the
1060: assembler code can use the variable @code{which_alternative}, which is
1061: the ordinal number of the alternative that was actually satisfied (0 for
1062: the first, 1 for the second alternative, etc.). @xref{Output Statement}.
1.1.1.5 root 1063: @end ifset
1.1 root 1064:
1.1.1.5 root 1065: @ifset INTERNALS
1066: @node Class Preferences
1.1 root 1067: @subsection Register Class Preferences
1068: @cindex class preference constraints
1069: @cindex register class preference constraints
1070:
1071: @cindex voting between constraint alternatives
1072: The operand constraints have another function: they enable the compiler
1073: to decide which kind of hardware register a pseudo register is best
1074: allocated to. The compiler examines the constraints that apply to the
1075: insns that use the pseudo register, looking for the machine-dependent
1076: letters such as @samp{d} and @samp{a} that specify classes of registers.
1077: The pseudo register is put in whichever class gets the most ``votes''.
1078: The constraint letters @samp{g} and @samp{r} also vote: they vote in
1079: favor of a general register. The machine description says which registers
1080: are considered general.
1081:
1082: Of course, on some machines all registers are equivalent, and no register
1083: classes are defined. Then none of this complexity is relevant.
1.1.1.5 root 1084: @end ifset
1.1 root 1085:
1.1.1.5 root 1086: @node Modifiers
1.1 root 1087: @subsection Constraint Modifier Characters
1088: @cindex modifiers in constraints
1089: @cindex constraint modifier characters
1090:
1.1.1.7 root 1091: @c prevent bad page break with this line
1092: Here are constraint modifier characters.
1093:
1.1 root 1094: @table @samp
1095: @cindex @samp{=} in constraint
1096: @item =
1097: Means that this operand is write-only for this instruction: the previous
1098: value is discarded and replaced by output data.
1099:
1100: @cindex @samp{+} in constraint
1101: @item +
1102: Means that this operand is both read and written by the instruction.
1103:
1104: When the compiler fixes up the operands to satisfy the constraints,
1105: it needs to know which operands are inputs to the instruction and
1106: which are outputs from it. @samp{=} identifies an output; @samp{+}
1107: identifies an operand that is both input and output; all other operands
1108: are assumed to be input only.
1109:
1110: @cindex @samp{&} in constraint
1111: @item &
1112: Means (in a particular alternative) that this operand is written
1113: before the instruction is finished using the input operands.
1114: Therefore, this operand may not lie in a register that is used as an
1115: input operand or as part of any memory address.
1116:
1117: @samp{&} applies only to the alternative in which it is written. In
1118: constraints with multiple alternatives, sometimes one alternative
1119: requires @samp{&} while others do not. See, for example, the
1120: @samp{movdf} insn of the 68000.
1121:
1122: @samp{&} does not obviate the need to write @samp{=}.
1123:
1124: @cindex @samp{%} in constraint
1125: @item %
1126: Declares the instruction to be commutative for this operand and the
1127: following operand. This means that the compiler may interchange the
1128: two operands if that is the cheapest way to make all operands fit the
1.1.1.5 root 1129: constraints.
1130: @ifset INTERNALS
1131: This is often used in patterns for addition instructions
1.1 root 1132: that really have only two operands: the result must go in one of the
1133: arguments. Here for example, is how the 68000 halfword-add
1134: instruction is defined:
1135:
1.1.1.5 root 1136: @smallexample
1.1 root 1137: (define_insn "addhi3"
1138: [(set (match_operand:HI 0 "general_operand" "=m,r")
1139: (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
1140: (match_operand:HI 2 "general_operand" "di,g")))]
1141: @dots{})
1.1.1.5 root 1142: @end smallexample
1143: @end ifset
1.1 root 1144:
1145: @cindex @samp{#} in constraint
1146: @item #
1147: Says that all following characters, up to the next comma, are to be
1148: ignored as a constraint. They are significant only for choosing
1149: register preferences.
1150:
1.1.1.5 root 1151: @ifset INTERNALS
1.1 root 1152: @cindex @samp{*} in constraint
1153: @item *
1154: Says that the following character should be ignored when choosing
1155: register preferences. @samp{*} has no effect on the meaning of the
1156: constraint as a constraint, and no effect on reloading.
1157:
1158: Here is an example: the 68000 has an instruction to sign-extend a
1159: halfword in a data register, and can also sign-extend a value by
1160: copying it into an address register. While either kind of register is
1161: acceptable, the constraints on an address-register destination are
1162: less strict, so it is best if register allocation makes an address
1163: register its goal. Therefore, @samp{*} is used so that the @samp{d}
1164: constraint letter (for data register) is ignored when computing
1165: register preferences.
1166:
1.1.1.5 root 1167: @smallexample
1.1 root 1168: (define_insn "extendhisi2"
1169: [(set (match_operand:SI 0 "general_operand" "=*d,a")
1170: (sign_extend:SI
1171: (match_operand:HI 1 "general_operand" "0,g")))]
1172: @dots{})
1.1.1.5 root 1173: @end smallexample
1174: @end ifset
1175: @end table
1176:
1177: @node Machine Constraints
1178: @subsection Constraints for Particular Machines
1179: @cindex machine specific constraints
1180: @cindex constraints, machine specific
1181:
1182: Whenever possible, you should use the general-purpose constraint letters
1183: in @code{asm} arguments, since they will convey meaning more readily to
1184: people reading your code. Failing that, use the constraint letters
1185: that usually have very similar meanings across architectures. The most
1186: commonly used constraints are @samp{m} and @samp{r} (for memory and
1187: general-purpose registers respectively; @pxref{Simple Constraints}), and
1188: @samp{I}, usually the letter indicating the most common
1189: immediate-constant format.
1190:
1191: For each machine architecture, the @file{config/@var{machine}.h} file
1192: defines additional constraints. These constraints are used by the
1193: compiler itself for instruction generation, as well as for @code{asm}
1194: statements; therefore, some of the constraints are not particularly
1195: interesting for @code{asm}. The constraints are defined through these
1196: macros:
1197:
1198: @table @code
1199: @item REG_CLASS_FROM_LETTER
1200: Register class constraints (usually lower case).
1201:
1202: @item CONST_OK_FOR_LETTER_P
1203: Immediate constant constraints, for non-floating point constants of
1204: word size or smaller precision (usually upper case).
1205:
1206: @item CONST_DOUBLE_OK_FOR_LETTER_P
1207: Immediate constant constraints, for all floating point constants and for
1208: constants of greater than word size precision (usually upper case).
1209:
1210: @item EXTRA_CONSTRAINT
1211: Special cases of registers or memory. This macro is not required, and
1212: is only defined for some machines.
1213: @end table
1214:
1215: Inspecting these macro definitions in the compiler source for your
1216: machine is the best way to be certain you have the right constraints.
1217: However, here is a summary of the machine-dependent constraints
1218: available on some particular machines.
1219:
1220: @table @emph
1.1.1.7 root 1221: @item ARM family---@file{arm.h}
1222: @table @code
1223: @item f
1224: Floating-point register
1225:
1226: @item F
1227: One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 4.0, 5.0
1228: or 10.0
1229:
1230: @item G
1231: Floating-point constant that would satisfy the constraint @samp{F} if it
1232: were negated
1233:
1234: @item I
1235: Integer that is valid as an immediate operand in a data processing
1236: instruction. That is, an integer in the range 0 to 255 rotated by a
1237: multiple of 2
1238:
1239: @item J
1240: Integer in the range -4095 to 4095
1241:
1242: @item K
1243: Integer that satisfies constraint @samp{I} when inverted (ones complement)
1244:
1245: @item L
1246: Integer that satisfies constraint @samp{I} when negated (twos complement)
1247:
1248: @item M
1249: Integer in the range 0 to 32
1250:
1251: @item Q
1252: A memory reference where the exact address is in a single register
1253: (`@samp{m}' is preferable for @code{asm} statements)
1254:
1255: @item R
1256: An item in the constant pool
1257:
1258: @item S
1259: A symbol in the text segment of the current file
1260: @end table
1261:
1.1.1.5 root 1262: @item AMD 29000 family---@file{a29k.h}
1263: @table @code
1264: @item l
1265: Local register 0
1266:
1267: @item b
1268: Byte Pointer (@samp{BP}) register
1269:
1270: @item q
1271: @samp{Q} register
1272:
1273: @item h
1274: Special purpose register
1275:
1276: @item A
1277: First accumulator register
1278:
1279: @item a
1280: Other accumulator register
1281:
1282: @item f
1283: Floating point register
1284:
1285: @item I
1286: Constant greater than 0, less than 0x100
1287:
1288: @item J
1289: Constant greater than 0, less than 0x10000
1290:
1291: @item K
1292: Constant whose high 24 bits are on (1)
1293:
1294: @item L
1295: 16 bit constant whose high 8 bits are on (1)
1296:
1297: @item M
1298: 32 bit constant whose high 16 bits are on (1)
1299:
1300: @item N
1301: 32 bit negative constant that fits in 8 bits
1302:
1303: @item O
1304: The constant 0x80000000 or, on the 29050, any 32 bit constant
1305: whose low 16 bits are 0.
1306:
1307: @item P
1308: 16 bit negative constant that fits in 8 bits
1309:
1310: @item G
1311: @itemx H
1312: A floating point constant (in @code{asm} statements, use the machine
1313: independent @samp{E} or @samp{F} instead)
1314: @end table
1315:
1316: @item IBM RS6000---@file{rs6000.h}
1317: @table @code
1318: @item b
1319: Address base register
1320:
1321: @item f
1322: Floating point register
1323:
1324: @item h
1325: @samp{MQ}, @samp{CTR}, or @samp{LINK} register
1326:
1327: @item q
1328: @samp{MQ} register
1329:
1330: @item c
1331: @samp{CTR} register
1332:
1333: @item l
1334: @samp{LINK} register
1335:
1336: @item x
1337: @samp{CR} register (condition register) number 0
1338:
1339: @item y
1340: @samp{CR} register (condition register)
1341:
1342: @item I
1343: Signed 16 bit constant
1344:
1345: @item J
1346: Constant whose low 16 bits are 0
1347:
1348: @item K
1349: Constant whose high 16 bits are 0
1350:
1351: @item L
1352: Constant suitable as a mask operand
1353:
1354: @item M
1355: Constant larger than 31
1356:
1357: @item N
1358: Exact power of 2
1359:
1360: @item O
1361: Zero
1362:
1363: @item P
1364: Constant whose negation is a signed 16 bit constant
1365:
1366: @item G
1367: Floating point constant that can be loaded into a register with one
1368: instruction per word
1369:
1370: @item Q
1371: Memory operand that is an offset from a register (@samp{m} is preferable
1372: for @code{asm} statements)
1373: @end table
1374:
1375: @item Intel 386---@file{i386.h}
1376: @table @code
1377: @item q
1378: @samp{a}, @code{b}, @code{c}, or @code{d} register
1379:
1.1.1.7 root 1380: @item A
1381: @samp{a}, or @code{d} register (for 64-bit ints)
1382:
1.1.1.5 root 1383: @item f
1384: Floating point register
1385:
1386: @item t
1387: First (top of stack) floating point register
1388:
1389: @item u
1390: Second floating point register
1391:
1392: @item a
1393: @samp{a} register
1394:
1395: @item b
1396: @samp{b} register
1397:
1398: @item c
1399: @samp{c} register
1400:
1401: @item d
1402: @samp{d} register
1403:
1404: @item D
1405: @samp{di} register
1406:
1407: @item S
1408: @samp{si} register
1409:
1410: @item I
1411: Constant in range 0 to 31 (for 32 bit shifts)
1412:
1413: @item J
1414: Constant in range 0 to 63 (for 64 bit shifts)
1415:
1416: @item K
1417: @samp{0xff}
1418:
1419: @item L
1420: @samp{0xffff}
1421:
1422: @item M
1423: 0, 1, 2, or 3 (shifts for @code{lea} instruction)
1424:
1.1.1.8 ! root 1425: @item N
! 1426: Constant in range 0 to 255 (for @code{out} instruction)
! 1427:
1.1.1.5 root 1428: @item G
1429: Standard 80387 floating point constant
1430: @end table
1431:
1432: @item Intel 960---@file{i960.h}
1433: @table @code
1434: @item f
1435: Floating point register (@code{fp0} to @code{fp3})
1436:
1437: @item l
1438: Local register (@code{r0} to @code{r15})
1439:
1440: @item b
1441: Global register (@code{g0} to @code{g15})
1442:
1443: @item d
1444: Any local or global register
1445:
1446: @item I
1447: Integers from 0 to 31
1448:
1449: @item J
1450: 0
1451:
1452: @item K
1453: Integers from -31 to 0
1454:
1455: @item G
1456: Floating point 0
1457:
1458: @item H
1459: Floating point 1
1460: @end table
1461:
1462: @item MIPS---@file{mips.h}
1463: @table @code
1464: @item d
1465: General-purpose integer register
1466:
1467: @item f
1468: Floating-point register (if available)
1469:
1470: @item h
1471: @samp{Hi} register
1472:
1473: @item l
1474: @samp{Lo} register
1475:
1476: @item x
1477: @samp{Hi} or @samp{Lo} register
1478:
1479: @item y
1480: General-purpose integer register
1481:
1482: @item z
1483: Floating-point status register
1484:
1485: @item I
1486: Signed 16 bit constant (for arithmetic instructions)
1487:
1488: @item J
1489: Zero
1490:
1491: @item K
1492: Zero-extended 16-bit constant (for logic instructions)
1493:
1494: @item L
1495: Constant with low 16 bits zero (can be loaded with @code{lui})
1496:
1497: @item M
1498: 32 bit constant which requires two instructions to load (a constant
1499: which is not @samp{I}, @samp{K}, or @samp{L})
1500:
1501: @item N
1502: Negative 16 bit constant
1503:
1504: @item O
1505: Exact power of two
1506:
1507: @item P
1508: Positive 16 bit constant
1509:
1510: @item G
1511: Floating point zero
1512:
1513: @item Q
1514: Memory reference that can be loaded with more than one instruction
1515: (@samp{m} is preferable for @code{asm} statements)
1516:
1517: @item R
1518: Memory reference that can be loaded with one instruction
1519: (@samp{m} is preferable for @code{asm} statements)
1520:
1521: @item S
1522: Memory reference in external OSF/rose PIC format
1523: (@samp{m} is preferable for @code{asm} statements)
1.1 root 1524: @end table
1525:
1.1.1.5 root 1526: @item Motorola 680x0---@file{m68k.h}
1527: @table @code
1528: @item a
1529: Address register
1530:
1531: @item d
1532: Data register
1533:
1534: @item f
1535: 68881 floating-point register, if available
1536:
1537: @item x
1538: Sun FPA (floating-point) register, if available
1539:
1540: @item y
1541: First 16 Sun FPA registers, if available
1542:
1543: @item I
1544: Integer in the range 1 to 8
1545:
1546: @item J
1547: 16 bit signed number
1548:
1549: @item K
1550: Signed number whose magnitude is greater than 0x80
1551:
1552: @item L
1553: Integer in the range -8 to -1
1554:
1555: @item G
1556: Floating point constant that is not a 68881 constant
1557:
1558: @item H
1559: Floating point constant that can be used by Sun FPA
1560: @end table
1561:
1562: @need 1000
1563: @item SPARC---@file{sparc.h}
1564: @table @code
1565: @item f
1566: Floating-point register
1567:
1568: @item I
1569: Signed 13 bit constant
1570:
1571: @item J
1572: Zero
1573:
1574: @item K
1575: 32 bit constant with the low 12 bits clear (a constant that can be
1576: loaded with the @code{sethi} instruction)
1577:
1578: @item G
1579: Floating-point zero
1580:
1581: @item H
1582: Signed 13 bit constant, sign-extended to 32 or 64 bits
1583:
1584: @item Q
1585: Memory reference that can be loaded with one instruction (@samp{m} is
1586: more appropriate for @code{asm} statements)
1587:
1588: @item S
1589: Constant, or memory address
1590:
1591: @item T
1592: Memory address aligned to an 8-byte boundary
1593:
1594: @item U
1595: Even register
1596: @end table
1597: @end table
1598:
1599: @ifset INTERNALS
1600: @node No Constraints
1.1 root 1601: @subsection Not Using Constraints
1602: @cindex no constraints
1603: @cindex not using constraints
1604:
1605: Some machines are so clean that operand constraints are not required. For
1606: example, on the Vax, an operand valid in one context is valid in any other
1607: context. On such a machine, every operand constraint would be @samp{g},
1608: excepting only operands of ``load address'' instructions which are
1609: written as if they referred to a memory location's contents but actual
1610: refer to its address. They would have constraint @samp{p}.
1611:
1612: @cindex empty constraints
1613: For such machines, instead of writing @samp{g} and @samp{p} for all
1614: the constraints, you can choose to write a description with empty constraints.
1615: Then you write @samp{""} for the constraint in every @code{match_operand}.
1616: Address operands are identified by writing an @code{address} expression
1617: around the @code{match_operand}, not by their constraints.
1618:
1619: When the machine description has just empty constraints, certain parts
1620: of compilation are skipped, making the compiler faster. However,
1621: few machines actually do not need constraints; all machine descriptions
1622: now in existence use constraints.
1.1.1.5 root 1623: @end ifset
1.1 root 1624:
1.1.1.5 root 1625: @ifset INTERNALS
1626: @node Standard Names
1627: @section Standard Pattern Names For Generation
1.1 root 1628: @cindex standard pattern names
1629: @cindex pattern names
1630: @cindex names, pattern
1631:
1632: Here is a table of the instruction names that are meaningful in the RTL
1633: generation pass of the compiler. Giving one of these names to an
1634: instruction pattern tells the RTL generation pass that it can use the
1635: pattern in to accomplish a certain task.
1636:
1637: @table @asis
1638: @cindex @code{mov@var{m}} instruction pattern
1639: @item @samp{mov@var{m}}
1640: Here @var{m} stands for a two-letter machine mode name, in lower case.
1641: This instruction pattern moves data with that machine mode from operand
1642: 1 to operand 0. For example, @samp{movsi} moves full-word data.
1643:
1644: If operand 0 is a @code{subreg} with mode @var{m} of a register whose
1645: own mode is wider than @var{m}, the effect of this instruction is
1646: to store the specified value in the part of the register that corresponds
1647: to mode @var{m}. The effect on the rest of the register is undefined.
1648:
1649: This class of patterns is special in several ways. First of all, each
1650: of these names @emph{must} be defined, because there is no other way
1651: to copy a datum from one place to another.
1652:
1653: Second, these patterns are not used solely in the RTL generation pass.
1654: Even the reload pass can generate move insns to copy values from stack
1655: slots into temporary registers. When it does so, one of the operands is
1656: a hard register and the other is an operand that can need to be reloaded
1657: into a register.
1658:
1659: @findex force_reg
1660: Therefore, when given such a pair of operands, the pattern must generate
1661: RTL which needs no reloading and needs no temporary registers---no
1662: registers other than the operands. For example, if you support the
1663: pattern with a @code{define_expand}, then in such a case the
1664: @code{define_expand} mustn't call @code{force_reg} or any other such
1665: function which might generate new pseudo registers.
1666:
1667: This requirement exists even for subword modes on a RISC machine where
1668: fetching those modes from memory normally requires several insns and
1669: some temporary registers. Look in @file{spur.md} to see how the
1670: requirement can be satisfied.
1671:
1672: @findex change_address
1673: During reload a memory reference with an invalid address may be passed
1674: as an operand. Such an address will be replaced with a valid address
1675: later in the reload pass. In this case, nothing may be done with the
1676: address except to use it as it stands. If it is copied, it will not be
1677: replaced with a valid address. No attempt should be made to make such
1678: an address into a valid address and no routine (such as
1679: @code{change_address}) that will do so may be called. Note that
1680: @code{general_operand} will fail when applied to such an address.
1681:
1682: @findex reload_in_progress
1683: The global variable @code{reload_in_progress} (which must be explicitly
1684: declared if required) can be used to determine whether such special
1685: handling is required.
1686:
1687: The variety of operands that have reloads depends on the rest of the
1688: machine description, but typically on a RISC machine these can only be
1689: pseudo registers that did not get hard registers, while on other
1690: machines explicit memory references will get optional reloads.
1691:
1692: If a scratch register is required to move an object to or from memory,
1693: it can be allocated using @code{gen_reg_rtx} prior to reload. But this
1694: is impossible during and after reload. If there are cases needing
1695: scratch registers after reload, you must define
1.1.1.5 root 1696: @code{SECONDARY_INPUT_RELOAD_CLASS} and perhaps also
1.1 root 1697: @code{SECONDARY_OUTPUT_RELOAD_CLASS} to detect them, and provide
1698: patterns @samp{reload_in@var{m}} or @samp{reload_out@var{m}} to handle
1699: them. @xref{Register Classes}.
1700:
1701: The constraints on a @samp{move@var{m}} must permit moving any hard
1702: register to any other hard register provided that
1703: @code{HARD_REGNO_MODE_OK} permits mode @var{m} in both registers and
1704: @code{REGISTER_MOVE_COST} applied to their classes returns a value of 2.
1705:
1706: It is obligatory to support floating point @samp{move@var{m}}
1707: instructions into and out of any registers that can hold fixed point
1708: values, because unions and structures (which have modes @code{SImode} or
1709: @code{DImode}) can be in those registers and they may have floating
1710: point members.
1711:
1712: There may also be a need to support fixed point @samp{move@var{m}}
1713: instructions in and out of floating point registers. Unfortunately, I
1714: have forgotten why this was so, and I don't know whether it is still
1715: true. If @code{HARD_REGNO_MODE_OK} rejects fixed point values in
1716: floating point registers, then the constraints of the fixed point
1717: @samp{move@var{m}} instructions must be designed to avoid ever trying to
1718: reload into a floating point register.
1719:
1.1.1.3 root 1720: @cindex @code{reload_in} instruction pattern
1721: @cindex @code{reload_out} instruction pattern
1.1 root 1722: @item @samp{reload_in@var{m}}
1723: @itemx @samp{reload_out@var{m}}
1724: Like @samp{mov@var{m}}, but used when a scratch register is required to
1725: move between operand 0 and operand 1. Operand 2 describes the scratch
1726: register. See the discussion of the @code{SECONDARY_RELOAD_CLASS}
1727: macro in @pxref{Register Classes}.
1728:
1729: @cindex @code{movstrict@var{m}} instruction pattern
1730: @item @samp{movstrict@var{m}}
1731: Like @samp{mov@var{m}} except that if operand 0 is a @code{subreg}
1732: with mode @var{m} of a register whose natural mode is wider,
1733: the @samp{movstrict@var{m}} instruction is guaranteed not to alter
1734: any of the register except the part which belongs to mode @var{m}.
1735:
1.1.1.3 root 1736: @cindex @code{load_multiple} instruction pattern
1.1.1.7 root 1737: @item @samp{load_multiple}
1.1.1.3 root 1738: Load several consecutive memory locations into consecutive registers.
1739: Operand 0 is the first of the consecutive registers, operand 1
1740: is the first memory location, and operand 2 is a constant: the
1741: number of consecutive registers.
1742:
1743: Define this only if the target machine really has such an instruction;
1744: do not define this if the most efficient way of loading consecutive
1745: registers from memory is to do them one at a time.
1746:
1747: On some machines, there are restrictions as to which consecutive
1748: registers can be stored into memory, such as particular starting or
1749: ending register numbers or only a range of valid counts. For those
1750: machines, use a @code{define_expand} (@pxref{Expander Definitions})
1751: and make the pattern fail if the restrictions are not met.
1752:
1753: Write the generated insn as a @code{parallel} with elements being a
1754: @code{set} of one register from the appropriate memory location (you may
1755: also need @code{use} or @code{clobber} elements). Use a
1756: @code{match_parallel} (@pxref{RTL Template}) to recognize the insn. See
1757: @file{a29k.md} and @file{rs6000.md} for examples of the use of this insn
1758: pattern.
1759:
1760: @cindex @samp{store_multiple} instruction pattern
1.1.1.7 root 1761: @item @samp{store_multiple}
1.1.1.3 root 1762: Similar to @samp{load_multiple}, but store several consecutive registers
1763: into consecutive memory locations. Operand 0 is the first of the
1764: consecutive memory locations, operand 1 is the first register, and
1765: operand 2 is a constant: the number of consecutive registers.
1766:
1.1 root 1767: @cindex @code{add@var{m}3} instruction pattern
1768: @item @samp{add@var{m}3}
1769: Add operand 2 and operand 1, storing the result in operand 0. All operands
1770: must have mode @var{m}. This can be used even on two-address machines, by
1771: means of constraints requiring operands 1 and 0 to be the same location.
1772:
1773: @cindex @code{sub@var{m}3} instruction pattern
1774: @cindex @code{mul@var{m}3} instruction pattern
1775: @cindex @code{div@var{m}3} instruction pattern
1776: @cindex @code{udiv@var{m}3} instruction pattern
1777: @cindex @code{mod@var{m}3} instruction pattern
1778: @cindex @code{umod@var{m}3} instruction pattern
1779: @cindex @code{min@var{m}3} instruction pattern
1780: @cindex @code{max@var{m}3} instruction pattern
1781: @cindex @code{umin@var{m}3} instruction pattern
1782: @cindex @code{umax@var{m}3} instruction pattern
1783: @cindex @code{and@var{m}3} instruction pattern
1784: @cindex @code{ior@var{m}3} instruction pattern
1785: @cindex @code{xor@var{m}3} instruction pattern
1786: @item @samp{sub@var{m}3}, @samp{mul@var{m}3}
1787: @itemx @samp{div@var{m}3}, @samp{udiv@var{m}3}, @samp{mod@var{m}3}, @samp{umod@var{m}3}
1788: @itemx @samp{smin@var{m}3}, @samp{smax@var{m}3}, @samp{umin@var{m}3}, @samp{umax@var{m}3}
1789: @itemx @samp{and@var{m}3}, @samp{ior@var{m}3}, @samp{xor@var{m}3}
1790: Similar, for other arithmetic operations.
1791:
1792: @cindex @code{mulhisi3} instruction pattern
1793: @item @samp{mulhisi3}
1794: Multiply operands 1 and 2, which have mode @code{HImode}, and store
1795: a @code{SImode} product in operand 0.
1796:
1797: @cindex @code{mulqihi3} instruction pattern
1798: @cindex @code{mulsidi3} instruction pattern
1799: @item @samp{mulqihi3}, @samp{mulsidi3}
1800: Similar widening-multiplication instructions of other widths.
1801:
1802: @cindex @code{umulqihi3} instruction pattern
1803: @cindex @code{umulhisi3} instruction pattern
1804: @cindex @code{umulsidi3} instruction pattern
1805: @item @samp{umulqihi3}, @samp{umulhisi3}, @samp{umulsidi3}
1806: Similar widening-multiplication instructions that do unsigned
1807: multiplication.
1808:
1.1.1.8 ! root 1809: @cindex @code{smul@var{m}3_highpart} instruction pattern
! 1810: @item @samp{mul@var{m}3_highpart}
! 1811: Perform a signed multiplication of operands 1 and 2, which have mode
! 1812: @var{m}, and store the most significant half of the product in operand 0.
! 1813: The least significant half of the product is discarded.
! 1814:
! 1815: @cindex @code{umul@var{m}3_highpart} instruction pattern
! 1816: @item @samp{umul@var{m}3_highpart}
! 1817: Similar, but the multiplication is unsigned.
! 1818:
1.1 root 1819: @cindex @code{divmod@var{m}4} instruction pattern
1820: @item @samp{divmod@var{m}4}
1821: Signed division that produces both a quotient and a remainder.
1822: Operand 1 is divided by operand 2 to produce a quotient stored
1823: in operand 0 and a remainder stored in operand 3.
1824:
1825: For machines with an instruction that produces both a quotient and a
1826: remainder, provide a pattern for @samp{divmod@var{m}4} but do not
1827: provide patterns for @samp{div@var{m}3} and @samp{mod@var{m}3}. This
1828: allows optimization in the relatively common case when both the quotient
1829: and remainder are computed.
1830:
1831: If an instruction that just produces a quotient or just a remainder
1832: exists and is more efficient than the instruction that produces both,
1833: write the output routine of @samp{divmod@var{m}4} to call
1834: @code{find_reg_note} and look for a @code{REG_UNUSED} note on the
1835: quotient or remainder and generate the appropriate instruction.
1836:
1837: @cindex @code{udivmod@var{m}4} instruction pattern
1838: @item @samp{udivmod@var{m}4}
1839: Similar, but does unsigned division.
1840:
1841: @cindex @code{ashl@var{m}3} instruction pattern
1842: @item @samp{ashl@var{m}3}
1.1.1.3 root 1843: Arithmetic-shift operand 1 left by a number of bits specified by operand
1844: 2, and store the result in operand 0. Here @var{m} is the mode of
1845: operand 0 and operand 1; operand 2's mode is specified by the
1846: instruction pattern, and the compiler will convert the operand to that
1847: mode before generating the instruction.
1.1 root 1848:
1849: @cindex @code{ashr@var{m}3} instruction pattern
1850: @cindex @code{lshr@var{m}3} instruction pattern
1851: @cindex @code{rotl@var{m}3} instruction pattern
1852: @cindex @code{rotr@var{m}3} instruction pattern
1.1.1.7 root 1853: @item @samp{ashr@var{m}3}, @samp{lshr@var{m}3}, @samp{rotl@var{m}3}, @samp{rotr@var{m}3}
1.1.1.3 root 1854: Other shift and rotate instructions, analogous to the
1855: @code{ashl@var{m}3} instructions.
1.1 root 1856:
1857: @cindex @code{neg@var{m}2} instruction pattern
1858: @item @samp{neg@var{m}2}
1859: Negate operand 1 and store the result in operand 0.
1860:
1861: @cindex @code{abs@var{m}2} instruction pattern
1862: @item @samp{abs@var{m}2}
1863: Store the absolute value of operand 1 into operand 0.
1864:
1865: @cindex @code{sqrt@var{m}2} instruction pattern
1866: @item @samp{sqrt@var{m}2}
1867: Store the square root of operand 1 into operand 0.
1868:
1.1.1.3 root 1869: The @code{sqrt} built-in function of C always uses the mode which
1870: corresponds to the C data type @code{double}.
1871:
1.1 root 1872: @cindex @code{ffs@var{m}2} instruction pattern
1873: @item @samp{ffs@var{m}2}
1874: Store into operand 0 one plus the index of the least significant 1-bit
1875: of operand 1. If operand 1 is zero, store zero. @var{m} is the mode
1876: of operand 0; operand 1's mode is specified by the instruction
1877: pattern, and the compiler will convert the operand to that mode before
1878: generating the instruction.
1879:
1.1.1.3 root 1880: The @code{ffs} built-in function of C always uses the mode which
1881: corresponds to the C data type @code{int}.
1882:
1.1 root 1883: @cindex @code{one_cmpl@var{m}2} instruction pattern
1884: @item @samp{one_cmpl@var{m}2}
1885: Store the bitwise-complement of operand 1 into operand 0.
1886:
1887: @cindex @code{cmp@var{m}} instruction pattern
1888: @item @samp{cmp@var{m}}
1889: Compare operand 0 and operand 1, and set the condition codes.
1890: The RTL pattern should look like this:
1891:
1.1.1.5 root 1892: @smallexample
1.1 root 1893: (set (cc0) (compare (match_operand:@var{m} 0 @dots{})
1894: (match_operand:@var{m} 1 @dots{})))
1.1.1.5 root 1895: @end smallexample
1.1 root 1896:
1897: @cindex @code{tst@var{m}} instruction pattern
1898: @item @samp{tst@var{m}}
1899: Compare operand 0 against zero, and set the condition codes.
1900: The RTL pattern should look like this:
1901:
1.1.1.5 root 1902: @smallexample
1.1 root 1903: (set (cc0) (match_operand:@var{m} 0 @dots{}))
1.1.1.5 root 1904: @end smallexample
1.1 root 1905:
1906: @samp{tst@var{m}} patterns should not be defined for machines that do
1907: not use @code{(cc0)}. Doing so would confuse the optimizer since it
1908: would no longer be clear which @code{set} operations were comparisons.
1909: The @samp{cmp@var{m}} patterns should be used instead.
1910:
1911: @cindex @code{movstr@var{m}} instruction pattern
1912: @item @samp{movstr@var{m}}
1913: Block move instruction. The addresses of the destination and source
1914: strings are the first two operands, and both are in mode @code{Pmode}.
1915: The number of bytes to move is the third operand, in mode @var{m}.
1916:
1917: The fourth operand is the known shared alignment of the source and
1918: destination, in the form of a @code{const_int} rtx. Thus, if the
1919: compiler knows that both source and destination are word-aligned,
1920: it may provide the value 4 for this operand.
1921:
1922: These patterns need not give special consideration to the possibility
1923: that the source and destination strings might overlap.
1924:
1925: @cindex @code{cmpstr@var{m}} instruction pattern
1926: @item @samp{cmpstr@var{m}}
1927: Block compare instruction, with five operands. Operand 0 is the output;
1928: it has mode @var{m}. The remaining four operands are like the operands
1929: of @samp{movstr@var{m}}. The two memory blocks specified are compared
1930: byte by byte in lexicographic order. The effect of the instruction is
1931: to store a value in operand 0 whose sign indicates the result of the
1932: comparison.
1933:
1.1.1.5 root 1934: @cindex @code{strlen@var{m}} instruction pattern
1935: Compute the length of a string, with three operands.
1936: Operand 0 is the result (of mode @var{m}), operand 1 is
1937: a @code{mem} referring to the first character of the string,
1938: operand 2 is the character to search for (normally zero),
1939: and operand 3 is a constant describing the known alignment
1940: of the beginning of the string.
1941:
1.1 root 1942: @cindex @code{float@var{mn}2} instruction pattern
1943: @item @samp{float@var{m}@var{n}2}
1944: Convert signed integer operand 1 (valid for fixed point mode @var{m}) to
1945: floating point mode @var{n} and store in operand 0 (which has mode
1946: @var{n}).
1947:
1948: @cindex @code{floatuns@var{mn}2} instruction pattern
1949: @item @samp{floatuns@var{m}@var{n}2}
1950: Convert unsigned integer operand 1 (valid for fixed point mode @var{m})
1951: to floating point mode @var{n} and store in operand 0 (which has mode
1952: @var{n}).
1953:
1954: @cindex @code{fix@var{mn}2} instruction pattern
1955: @item @samp{fix@var{m}@var{n}2}
1956: Convert operand 1 (valid for floating point mode @var{m}) to fixed
1957: point mode @var{n} as a signed number and store in operand 0 (which
1958: has mode @var{n}). This instruction's result is defined only when
1959: the value of operand 1 is an integer.
1960:
1961: @cindex @code{fixuns@var{mn}2} instruction pattern
1962: @item @samp{fixuns@var{m}@var{n}2}
1963: Convert operand 1 (valid for floating point mode @var{m}) to fixed
1964: point mode @var{n} as an unsigned number and store in operand 0 (which
1965: has mode @var{n}). This instruction's result is defined only when the
1966: value of operand 1 is an integer.
1967:
1968: @cindex @code{ftrunc@var{m}2} instruction pattern
1969: @item @samp{ftrunc@var{m}2}
1970: Convert operand 1 (valid for floating point mode @var{m}) to an
1971: integer value, still represented in floating point mode @var{m}, and
1972: store it in operand 0 (valid for floating point mode @var{m}).
1973:
1974: @cindex @code{fix_trunc@var{mn}2} instruction pattern
1975: @item @samp{fix_trunc@var{m}@var{n}2}
1976: Like @samp{fix@var{m}@var{n}2} but works for any floating point value
1977: of mode @var{m} by converting the value to an integer.
1978:
1979: @cindex @code{fixuns_trunc@var{mn}2} instruction pattern
1980: @item @samp{fixuns_trunc@var{m}@var{n}2}
1981: Like @samp{fixuns@var{m}@var{n}2} but works for any floating point
1982: value of mode @var{m} by converting the value to an integer.
1983:
1984: @cindex @code{trunc@var{mn}} instruction pattern
1985: @item @samp{trunc@var{m}@var{n}}
1986: Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and
1987: store in operand 0 (which has mode @var{n}). Both modes must be fixed
1988: point or both floating point.
1989:
1990: @cindex @code{extend@var{mn}} instruction pattern
1991: @item @samp{extend@var{m}@var{n}}
1992: Sign-extend operand 1 (valid for mode @var{m}) to mode @var{n} and
1993: store in operand 0 (which has mode @var{n}). Both modes must be fixed
1994: point or both floating point.
1995:
1996: @cindex @code{zero_extend@var{mn}} instruction pattern
1997: @item @samp{zero_extend@var{m}@var{n}}
1998: Zero-extend operand 1 (valid for mode @var{m}) to mode @var{n} and
1999: store in operand 0 (which has mode @var{n}). Both modes must be fixed
2000: point.
2001:
2002: @cindex @code{extv} instruction pattern
2003: @item @samp{extv}
2004: Extract a bit field from operand 1 (a register or memory operand), where
2005: operand 2 specifies the width in bits and operand 3 the starting bit,
2006: and store it in operand 0. Operand 0 must have mode @code{word_mode}.
2007: Operand 1 may have mode @code{byte_mode} or @code{word_mode}; often
2008: @code{word_mode} is allowed only for registers. Operands 2 and 3 must
2009: be valid for @code{word_mode}.
2010:
2011: The RTL generation pass generates this instruction only with constants
2012: for operands 2 and 3.
2013:
2014: The bit-field value is sign-extended to a full word integer
2015: before it is stored in operand 0.
2016:
2017: @cindex @code{extzv} instruction pattern
2018: @item @samp{extzv}
2019: Like @samp{extv} except that the bit-field value is zero-extended.
2020:
2021: @cindex @code{insv} instruction pattern
2022: @item @samp{insv}
2023: Store operand 3 (which must be valid for @code{word_mode}) into a bit
2024: field in operand 0, where operand 1 specifies the width in bits and
2025: operand 2 the starting bit. Operand 0 may have mode @code{byte_mode} or
2026: @code{word_mode}; often @code{word_mode} is allowed only for registers.
2027: Operands 1 and 2 must be valid for @code{word_mode}.
2028:
2029: The RTL generation pass generates this instruction only with constants
2030: for operands 1 and 2.
2031:
1.1.1.8 ! root 2032: @cindex @code{mov@var{mode}cc} instruction pattern
! 2033: @item @samp{mov@var{mode}cc}
! 2034: Conditionally move operand 2 or operand 3 into operand 0 according to the
! 2035: comparison in operand 1. If the comparison is true, operand 2 is moved
! 2036: into operand 0, otherwise operand 3 is moved.
! 2037:
! 2038: The mode of the operands being compared need not be the same as the operands
! 2039: being moved. Some machines, sparc64 for example, have instructions that
! 2040: conditionally move an integer value based on the floating point condition
! 2041: codes and vice versa.
! 2042:
! 2043: If the machine does not have conditional move instructions, do not
! 2044: define these patterns.
! 2045:
1.1 root 2046: @cindex @code{s@var{cond}} instruction pattern
2047: @item @samp{s@var{cond}}
2048: Store zero or nonzero in the operand according to the condition codes.
2049: Value stored is nonzero iff the condition @var{cond} is true.
2050: @var{cond} is the name of a comparison operation expression code, such
2051: as @code{eq}, @code{lt} or @code{leu}.
2052:
2053: You specify the mode that the operand must have when you write the
2054: @code{match_operand} expression. The compiler automatically sees
2055: which mode you have used and supplies an operand of that mode.
2056:
2057: The value stored for a true condition must have 1 as its low bit, or
2058: else must be negative. Otherwise the instruction is not suitable and
2059: you should omit it from the machine description. You describe to the
2060: compiler exactly which value is stored by defining the macro
2061: @code{STORE_FLAG_VALUE} (@pxref{Misc}). If a description cannot be
2062: found that can be used for all the @samp{s@var{cond}} patterns, you
2063: should omit those operations from the machine description.
2064:
2065: These operations may fail, but should do so only in relatively
2066: uncommon cases; if they would fail for common cases involving
2067: integer comparisons, it is best to omit these patterns.
2068:
2069: If these operations are omitted, the compiler will usually generate code
2070: that copies the constant one to the target and branches around an
2071: assignment of zero to the target. If this code is more efficient than
2072: the potential instructions used for the @samp{s@var{cond}} pattern
2073: followed by those required to convert the result into a 1 or a zero in
2074: @code{SImode}, you should omit the @samp{s@var{cond}} operations from
2075: the machine description.
2076:
2077: @cindex @code{b@var{cond}} instruction pattern
2078: @item @samp{b@var{cond}}
2079: Conditional branch instruction. Operand 0 is a @code{label_ref} that
2080: refers to the label to jump to. Jump if the condition codes meet
2081: condition @var{cond}.
2082:
2083: Some machines do not follow the model assumed here where a comparison
2084: instruction is followed by a conditional branch instruction. In that
2085: case, the @samp{cmp@var{m}} (and @samp{tst@var{m}}) patterns should
2086: simply store the operands away and generate all the required insns in a
2087: @code{define_expand} (@pxref{Expander Definitions}) for the conditional
1.1.1.4 root 2088: branch operations. All calls to expand @samp{b@var{cond}} patterns are
1.1 root 2089: immediately preceded by calls to expand either a @samp{cmp@var{m}}
2090: pattern or a @samp{tst@var{m}} pattern.
2091:
2092: Machines that use a pseudo register for the condition code value, or
2093: where the mode used for the comparison depends on the condition being
2094: tested, should also use the above mechanism. @xref{Jump Patterns}
2095:
1.1.1.8 ! root 2096: The above discussion also applies to the @samp{mov@var{mode}cc} and
! 2097: @samp{s@var{cond}} patterns.
1.1 root 2098:
2099: @cindex @code{call} instruction pattern
2100: @item @samp{call}
2101: Subroutine call instruction returning no value. Operand 0 is the
2102: function to call; operand 1 is the number of bytes of arguments pushed
2103: (in mode @code{SImode}, except it is normally a @code{const_int});
2104: operand 2 is the number of registers used as operands.
2105:
2106: On most machines, operand 2 is not actually stored into the RTL
2107: pattern. It is supplied for the sake of some RISC machines which need
2108: to put this information into the assembler code; they can put it in
2109: the RTL instead of operand 1.
2110:
2111: Operand 0 should be a @code{mem} RTX whose address is the address of the
2112: function. Note, however, that this address can be a @code{symbol_ref}
2113: expression even if it would not be a legitimate memory address on the
2114: target machine. If it is also not a valid argument for a call
2115: instruction, the pattern for this operation should be a
2116: @code{define_expand} (@pxref{Expander Definitions}) that places the
2117: address into a register and uses that register in the call instruction.
2118:
2119: @cindex @code{call_value} instruction pattern
2120: @item @samp{call_value}
2121: Subroutine call instruction returning a value. Operand 0 is the hard
2122: register in which the value is returned. There are three more
2123: operands, the same as the three operands of the @samp{call}
2124: instruction (but with numbers increased by one).
2125:
2126: Subroutines that return @code{BLKmode} objects use the @samp{call}
2127: insn.
2128:
2129: @cindex @code{call_pop} instruction pattern
2130: @cindex @code{call_value_pop} instruction pattern
2131: @item @samp{call_pop}, @samp{call_value_pop}
2132: Similar to @samp{call} and @samp{call_value}, except used if defined and
2133: if @code{RETURN_POPS_ARGS} is non-zero. They should emit a @code{parallel}
2134: that contains both the function call and a @code{set} to indicate the
2135: adjustment made to the frame pointer.
2136:
2137: For machines where @code{RETURN_POPS_ARGS} can be non-zero, the use of these
2138: patterns increases the number of functions for which the frame pointer
2139: can be eliminated, if desired.
2140:
1.1.1.5 root 2141: @cindex @code{untyped_call} instruction pattern
2142: @item @samp{untyped_call}
2143: Subroutine call instruction returning a value of any type. Operand 0 is
2144: the function to call; operand 1 is a memory location where the result of
2145: calling the function is to be stored; operand 2 is a @code{parallel}
2146: expression where each element is a @code{set} expression that indicates
2147: the saving of a function return value into the result block.
2148:
2149: This instruction pattern should be defined to support
2150: @code{__builtin_apply} on machines where special instructions are needed
2151: to call a subroutine with arbitrary arguments or to save the value
2152: returned. This instruction pattern is required on machines that have
2153: multiple registers that can hold a return value (i.e.
2154: @code{FUNCTION_VALUE_REGNO_P} is true for more than one register).
2155:
1.1 root 2156: @cindex @code{return} instruction pattern
2157: @item @samp{return}
2158: Subroutine return instruction. This instruction pattern name should be
2159: defined only if a single instruction can do all the work of returning
2160: from a function.
2161:
2162: Like the @samp{mov@var{m}} patterns, this pattern is also used after the
2163: RTL generation phase. In this case it is to support machines where
2164: multiple instructions are usually needed to return from a function, but
2165: some class of functions only requires one instruction to implement a
2166: return. Normally, the applicable functions are those which do not need
2167: to save any registers or allocate stack space.
2168:
2169: @findex reload_completed
2170: @findex leaf_function_p
2171: For such machines, the condition specified in this pattern should only
2172: be true when @code{reload_completed} is non-zero and the function's
2173: epilogue would only be a single instruction. For machines with register
2174: windows, the routine @code{leaf_function_p} may be used to determine if
2175: a register window push is required.
2176:
2177: Machines that have conditional return instructions should define patterns
2178: such as
2179:
1.1.1.5 root 2180: @smallexample
1.1 root 2181: (define_insn ""
2182: [(set (pc)
1.1.1.5 root 2183: (if_then_else (match_operator
2184: 0 "comparison_operator"
2185: [(cc0) (const_int 0)])
1.1.1.4 root 2186: (return)
2187: (pc)))]
1.1 root 2188: "@var{condition}"
2189: "@dots{}")
1.1.1.5 root 2190: @end smallexample
1.1 root 2191:
2192: where @var{condition} would normally be the same condition specified on the
2193: named @samp{return} pattern.
2194:
1.1.1.5 root 2195: @cindex @code{untyped_return} instruction pattern
2196: @item @samp{untyped_return}
2197: Untyped subroutine return instruction. This instruction pattern should
2198: be defined to support @code{__builtin_return} on machines where special
2199: instructions are needed to return a value of any type.
2200:
2201: Operand 0 is a memory location where the result of calling a function
2202: with @code{__builtin_apply} is stored; operand 1 is a @code{parallel}
2203: expression where each element is a @code{set} expression that indicates
2204: the restoring of a function return value from the result block.
2205:
1.1 root 2206: @cindex @code{nop} instruction pattern
2207: @item @samp{nop}
2208: No-op instruction. This instruction pattern name should always be defined
2209: to output a no-op in assembler code. @code{(const_int 0)} will do as an
2210: RTL pattern.
2211:
2212: @cindex @code{indirect_jump} instruction pattern
2213: @item @samp{indirect_jump}
2214: An instruction to jump to an address which is operand zero.
2215: This pattern name is mandatory on all machines.
2216:
2217: @cindex @code{casesi} instruction pattern
2218: @item @samp{casesi}
2219: Instruction to jump through a dispatch table, including bounds checking.
2220: This instruction takes five operands:
2221:
2222: @enumerate
2223: @item
2224: The index to dispatch on, which has mode @code{SImode}.
2225:
2226: @item
2227: The lower bound for indices in the table, an integer constant.
2228:
2229: @item
2230: The total range of indices in the table---the largest index
2231: minus the smallest one (both inclusive).
2232:
2233: @item
2234: A label that precedes the table itself.
2235:
2236: @item
2237: A label to jump to if the index has a value outside the bounds.
2238: (If the machine-description macro @code{CASE_DROPS_THROUGH} is defined,
2239: then an out-of-bounds index drops through to the code following
2240: the jump table instead of jumping to this label. In that case,
2241: this label is not actually used by the @samp{casesi} instruction,
2242: but it is always provided as an operand.)
2243: @end enumerate
2244:
2245: The table is a @code{addr_vec} or @code{addr_diff_vec} inside of a
2246: @code{jump_insn}. The number of elements in the table is one plus the
2247: difference between the upper bound and the lower bound.
2248:
2249: @cindex @code{tablejump} instruction pattern
2250: @item @samp{tablejump}
2251: Instruction to jump to a variable address. This is a low-level
2252: capability which can be used to implement a dispatch table when there
2253: is no @samp{casesi} pattern.
2254:
2255: This pattern requires two operands: the address or offset, and a label
2256: which should immediately precede the jump table. If the macro
2257: @code{CASE_VECTOR_PC_RELATIVE} is defined then the first operand is an
2258: offset which counts from the address of the table; otherwise, it is an
1.1.1.3 root 2259: absolute address to jump to. In either case, the first operand has
2260: mode @code{Pmode}.
1.1 root 2261:
2262: The @samp{tablejump} insn is always the last insn before the jump
2263: table it uses. Its assembler code normally has no need to use the
2264: second operand, but you should incorporate it in the RTL pattern so
2265: that the jump optimizer will not delete the table as unreachable code.
1.1.1.3 root 2266:
2267: @cindex @code{save_stack_block} instruction pattern
2268: @cindex @code{save_stack_function} instruction pattern
2269: @cindex @code{save_stack_nonlocal} instruction pattern
2270: @cindex @code{restore_stack_block} instruction pattern
2271: @cindex @code{restore_stack_function} instruction pattern
2272: @cindex @code{restore_stack_nonlocal} instruction pattern
2273: @item @samp{save_stack_block}
2274: @itemx @samp{save_stack_function}
2275: @itemx @samp{save_stack_nonlocal}
2276: @itemx @samp{restore_stack_block}
2277: @itemx @samp{restore_stack_function}
2278: @itemx @samp{restore_stack_nonlocal}
2279: Most machines save and restore the stack pointer by copying it to or
2280: from an object of mode @code{Pmode}. Do not define these patterns on
2281: such machines.
2282:
2283: Some machines require special handling for stack pointer saves and
2284: restores. On those machines, define the patterns corresponding to the
2285: non-standard cases by using a @code{define_expand} (@pxref{Expander
2286: Definitions}) that produces the required insns. The three types of
2287: saves and restores are:
2288:
2289: @enumerate
2290: @item
2291: @samp{save_stack_block} saves the stack pointer at the start of a block
1.1.1.5 root 2292: that allocates a variable-sized object, and @samp{restore_stack_block}
1.1.1.3 root 2293: restores the stack pointer when the block is exited.
2294:
2295: @item
1.1.1.5 root 2296: @samp{save_stack_function} and @samp{restore_stack_function} do a
2297: similar job for the outermost block of a function and are used when the
1.1.1.3 root 2298: function allocates variable-sized objects or calls @code{alloca}. Only
2299: the epilogue uses the restored stack pointer, allowing a simpler save or
2300: restore sequence on some machines.
2301:
2302: @item
2303: @samp{save_stack_nonlocal} is used in functions that contain labels
2304: branched to by nested functions. It saves the stack pointer in such a
2305: way that the inner function can use @samp{restore_stack_nonlocal} to
2306: restore the stack pointer. The compiler generates code to restore the
2307: frame and argument pointer registers, but some machines require saving
2308: and restoring additional data such as register window information or
2309: stack backchains. Place insns in these patterns to save and restore any
2310: such required data.
2311: @end enumerate
2312:
2313: When saving the stack pointer, operand 0 is the save area and operand 1
2314: is the stack pointer. The mode used to allocate the save area is the
2315: mode of operand 0. You must specify an integral mode, or
2316: @code{VOIDmode} if no save area is needed for a particular type of save
2317: (either because no save is needed or because a machine-specific save
2318: area can be used). Operand 0 is the stack pointer and operand 1 is the
2319: save area for restore operations. If @samp{save_stack_block} is
2320: defined, operand 0 must not be @code{VOIDmode} since these saves can be
2321: arbitrarily nested.
2322:
2323: A save area is a @code{mem} that is at a constant offset from
2324: @code{virtual_stack_vars_rtx} when the stack pointer is saved for use by
2325: nonlocal gotos and a @code{reg} in the other two cases.
2326:
2327: @cindex @code{allocate_stack} instruction pattern
2328: @item @samp{allocate_stack}
1.1.1.6 root 2329: Subtract (or add if @code{STACK_GROWS_DOWNWARD} is undefined) operand 0 from
2330: the stack pointer to create space for dynamically allocated data.
1.1.1.3 root 2331:
2332: Do not define this pattern if all that must be done is the subtraction.
1.1.1.6 root 2333: Some machines require other operations such as stack probes or
1.1.1.3 root 2334: maintaining the back chain. Define this pattern to emit those
2335: operations in addition to updating the stack pointer.
1.1 root 2336: @end table
2337:
1.1.1.5 root 2338: @node Pattern Ordering
1.1 root 2339: @section When the Order of Patterns Matters
2340: @cindex Pattern Ordering
2341: @cindex Ordering of Patterns
2342:
2343: Sometimes an insn can match more than one instruction pattern. Then the
2344: pattern that appears first in the machine description is the one used.
2345: Therefore, more specific patterns (patterns that will match fewer things)
2346: and faster instructions (those that will produce better code when they
2347: do match) should usually go first in the description.
2348:
2349: In some cases the effect of ordering the patterns can be used to hide
2350: a pattern when it is not valid. For example, the 68000 has an
2351: instruction for converting a fullword to floating point and another
2352: for converting a byte to floating point. An instruction converting
2353: an integer to floating point could match either one. We put the
2354: pattern to convert the fullword first to make sure that one will
2355: be used rather than the other. (Otherwise a large integer might
2356: be generated as a single-byte immediate quantity, which would not work.)
2357: Instead of using this pattern ordering it would be possible to make the
2358: pattern for convert-a-byte smart enough to deal properly with any
2359: constant value.
2360:
1.1.1.5 root 2361: @node Dependent Patterns
1.1 root 2362: @section Interdependence of Patterns
2363: @cindex Dependent Patterns
2364: @cindex Interdependence of Patterns
2365:
2366: Every machine description must have a named pattern for each of the
2367: conditional branch names @samp{b@var{cond}}. The recognition template
2368: must always have the form
2369:
2370: @example
2371: (set (pc)
2372: (if_then_else (@var{cond} (cc0) (const_int 0))
2373: (label_ref (match_operand 0 "" ""))
2374: (pc)))
2375: @end example
2376:
2377: @noindent
2378: In addition, every machine description must have an anonymous pattern
2379: for each of the possible reverse-conditional branches. Their templates
2380: look like
2381:
2382: @example
2383: (set (pc)
2384: (if_then_else (@var{cond} (cc0) (const_int 0))
2385: (pc)
2386: (label_ref (match_operand 0 "" ""))))
2387: @end example
2388:
2389: @noindent
2390: They are necessary because jump optimization can turn direct-conditional
2391: branches into reverse-conditional branches.
2392:
2393: It is often convenient to use the @code{match_operator} construct to
2394: reduce the number of patterns that must be specified for branches. For
2395: example,
2396:
2397: @example
2398: (define_insn ""
2399: [(set (pc)
2400: (if_then_else (match_operator 0 "comparison_operator"
1.1.1.4 root 2401: [(cc0) (const_int 0)])
2402: (pc)
2403: (label_ref (match_operand 1 "" ""))))]
1.1 root 2404: "@var{condition}"
2405: "@dots{}")
2406: @end example
2407:
2408: In some cases machines support instructions identical except for the
2409: machine mode of one or more operands. For example, there may be
2410: ``sign-extend halfword'' and ``sign-extend byte'' instructions whose
2411: patterns are
2412:
2413: @example
2414: (set (match_operand:SI 0 @dots{})
2415: (extend:SI (match_operand:HI 1 @dots{})))
2416:
2417: (set (match_operand:SI 0 @dots{})
2418: (extend:SI (match_operand:QI 1 @dots{})))
2419: @end example
2420:
2421: @noindent
2422: Constant integers do not specify a machine mode, so an instruction to
2423: extend a constant value could match either pattern. The pattern it
2424: actually will match is the one that appears first in the file. For correct
2425: results, this must be the one for the widest possible mode (@code{HImode},
2426: here). If the pattern matches the @code{QImode} instruction, the results
2427: will be incorrect if the constant value does not actually fit that mode.
2428:
2429: Such instructions to extend constants are rarely generated because they are
2430: optimized away, but they do occasionally happen in nonoptimized
2431: compilations.
2432:
2433: If a constraint in a pattern allows a constant, the reload pass may
2434: replace a register with a constant permitted by the constraint in some
1.1.1.8 ! root 2435: cases. Similarly for memory references. Because of this substitution,
! 2436: you should not provide separate patterns for increment and decrement
! 2437: instructions. Instead, they should be generated from the same pattern
! 2438: that supports register-register add insns by examining the operands and
! 2439: generating the appropriate machine instruction.
1.1 root 2440:
1.1.1.5 root 2441: @node Jump Patterns
1.1 root 2442: @section Defining Jump Instruction Patterns
2443: @cindex jump instruction patterns
2444: @cindex defining jump instruction patterns
2445:
2446: For most machines, GNU CC assumes that the machine has a condition code.
2447: A comparison insn sets the condition code, recording the results of both
2448: signed and unsigned comparison of the given operands. A separate branch
2449: insn tests the condition code and branches or not according its value.
2450: The branch insns come in distinct signed and unsigned flavors. Many
2451: common machines, such as the Vax, the 68000 and the 32000, work this
2452: way.
2453:
2454: Some machines have distinct signed and unsigned compare instructions, and
2455: only one set of conditional branch instructions. The easiest way to handle
2456: these machines is to treat them just like the others until the final stage
2457: where assembly code is written. At this time, when outputting code for the
2458: compare instruction, peek ahead at the following branch using
2459: @code{next_cc0_user (insn)}. (The variable @code{insn} refers to the insn
2460: being output, in the output-writing code in an instruction pattern.) If
2461: the RTL says that is an unsigned branch, output an unsigned compare;
2462: otherwise output a signed compare. When the branch itself is output, you
2463: can treat signed and unsigned branches identically.
2464:
2465: The reason you can do this is that GNU CC always generates a pair of
2466: consecutive RTL insns, possibly separated by @code{note} insns, one to
2467: set the condition code and one to test it, and keeps the pair inviolate
2468: until the end.
2469:
2470: To go with this technique, you must define the machine-description macro
2471: @code{NOTICE_UPDATE_CC} to do @code{CC_STATUS_INIT}; in other words, no
2472: compare instruction is superfluous.
2473:
2474: Some machines have compare-and-branch instructions and no condition code.
2475: A similar technique works for them. When it is time to ``output'' a
2476: compare instruction, record its operands in two static variables. When
2477: outputting the branch-on-condition-code instruction that follows, actually
2478: output a compare-and-branch instruction that uses the remembered operands.
2479:
2480: It also works to define patterns for compare-and-branch instructions.
2481: In optimizing compilation, the pair of compare and branch instructions
2482: will be combined according to these patterns. But this does not happen
2483: if optimization is not requested. So you must use one of the solutions
2484: above in addition to any special patterns you define.
2485:
2486: In many RISC machines, most instructions do not affect the condition
2487: code and there may not even be a separate condition code register. On
2488: these machines, the restriction that the definition and use of the
2489: condition code be adjacent insns is not necessary and can prevent
2490: important optimizations. For example, on the IBM RS/6000, there is a
2491: delay for taken branches unless the condition code register is set three
2492: instructions earlier than the conditional branch. The instruction
2493: scheduler cannot perform this optimization if it is not permitted to
2494: separate the definition and use of the condition code register.
2495:
2496: On these machines, do not use @code{(cc0)}, but instead use a register
2497: to represent the condition code. If there is a specific condition code
2498: register in the machine, use a hard register. If the condition code or
2499: comparison result can be placed in any general register, or if there are
2500: multiple condition registers, use a pseudo register.
2501:
2502: @findex prev_cc0_setter
2503: @findex next_cc0_user
2504: On some machines, the type of branch instruction generated may depend on
2505: the way the condition code was produced; for example, on the 68k and
2506: Sparc, setting the condition code directly from an add or subtract
2507: instruction does not clear the overflow bit the way that a test
2508: instruction does, so a different branch instruction must be used for
2509: some conditional branches. For machines that use @code{(cc0)}, the set
2510: and use of the condition code must be adjacent (separated only by
2511: @code{note} insns) allowing flags in @code{cc_status} to be used.
2512: (@xref{Condition Code}.) Also, the comparison and branch insns can be
2513: located from each other by using the functions @code{prev_cc0_setter}
2514: and @code{next_cc0_user}.
2515:
2516: However, this is not true on machines that do not use @code{(cc0)}. On
2517: those machines, no assumptions can be made about the adjacency of the
2518: compare and branch insns and the above methods cannot be used. Instead,
2519: we use the machine mode of the condition code register to record
2520: different formats of the condition code register.
2521:
2522: Registers used to store the condition code value should have a mode that
2523: is in class @code{MODE_CC}. Normally, it will be @code{CCmode}. If
2524: additional modes are required (as for the add example mentioned above in
2525: the Sparc), define the macro @code{EXTRA_CC_MODES} to list the
2526: additional modes required (@pxref{Condition Code}). Also define
2527: @code{EXTRA_CC_NAMES} to list the names of those modes and
2528: @code{SELECT_CC_MODE} to choose a mode given an operand of a compare.
2529:
2530: If it is known during RTL generation that a different mode will be
2531: required (for example, if the machine has separate compare instructions
2532: for signed and unsigned quantities, like most IBM processors), they can
2533: be specified at that time.
2534:
2535: If the cases that require different modes would be made by instruction
2536: combination, the macro @code{SELECT_CC_MODE} determines which machine
2537: mode should be used for the comparison result. The patterns should be
2538: written using that mode. To support the case of the add on the Sparc
2539: discussed above, we have the pattern
2540:
1.1.1.5 root 2541: @smallexample
1.1 root 2542: (define_insn ""
2543: [(set (reg:CC_NOOV 0)
1.1.1.5 root 2544: (compare:CC_NOOV
2545: (plus:SI (match_operand:SI 0 "register_operand" "%r")
2546: (match_operand:SI 1 "arith_operand" "rI"))
2547: (const_int 0)))]
1.1 root 2548: ""
2549: "@dots{}")
1.1.1.5 root 2550: @end smallexample
1.1 root 2551:
2552: The @code{SELECT_CC_MODE} macro on the Sparc returns @code{CC_NOOVmode}
2553: for comparisons whose argument is a @code{plus}.
2554:
1.1.1.5 root 2555: @node Insn Canonicalizations
1.1 root 2556: @section Canonicalization of Instructions
2557: @cindex canonicalization of instructions
2558: @cindex insn canonicalization
2559:
2560: There are often cases where multiple RTL expressions could represent an
1.1.1.2 root 2561: operation performed by a single machine instruction. This situation is
1.1 root 2562: most commonly encountered with logical, branch, and multiply-accumulate
2563: instructions. In such cases, the compiler attempts to convert these
2564: multiple RTL expressions into a single canonical form to reduce the
2565: number of insn patterns required.
2566:
2567: In addition to algebraic simplifications, following canonicalizations
2568: are performed:
2569:
2570: @itemize @bullet
2571: @item
2572: For commutative and comparison operators, a constant is always made the
2573: second operand. If a machine only supports a constant as the second
2574: operand, only patterns that match a constant in the second operand need
2575: be supplied.
2576:
2577: @cindex @code{neg}, canonicalization of
2578: @cindex @code{not}, canonicalization of
2579: @cindex @code{mult}, canonicalization of
2580: @cindex @code{plus}, canonicalization of
2581: @cindex @code{minus}, canonicalization of
2582: For these operators, if only one operand is a @code{neg}, @code{not},
2583: @code{mult}, @code{plus}, or @code{minus} expression, it will be the
2584: first operand.
2585:
2586: @cindex @code{compare}, canonicalization of
2587: @item
2588: For the @code{compare} operator, a constant is always the second operand
2589: on machines where @code{cc0} is used (@pxref{Jump Patterns}). On other
2590: machines, there are rare cases where the compiler might want to construct
2591: a @code{compare} with a constant as the first operand. However, these
2592: cases are not common enough for it to be worthwhile to provide a pattern
2593: matching a constant as the first operand unless the machine actually has
2594: such an instruction.
2595:
2596: An operand of @code{neg}, @code{not}, @code{mult}, @code{plus}, or
2597: @code{minus} is made the first operand under the same conditions as
2598: above.
2599:
2600: @item
2601: @code{(minus @var{x} (const_int @var{n}))} is converted to
2602: @code{(plus @var{x} (const_int @var{-n}))}.
2603:
2604: @item
2605: Within address computations (i.e., inside @code{mem}), a left shift is
2606: converted into the appropriate multiplication by a power of two.
2607:
2608: @cindex @code{ior}, canonicalization of
2609: @cindex @code{and}, canonicalization of
2610: @cindex De Morgan's law
2611: De`Morgan's Law is used to move bitwise negation inside a bitwise
2612: logical-and or logical-or operation. If this results in only one
2613: operand being a @code{not} expression, it will be the first one.
2614:
2615: A machine that has an instruction that performs a bitwise logical-and of one
2616: operand with the bitwise negation of the other should specify the pattern
2617: for that instruction as
2618:
2619: @example
2620: (define_insn ""
2621: [(set (match_operand:@var{m} 0 @dots{})
1.1.1.4 root 2622: (and:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{}))
2623: (match_operand:@var{m} 2 @dots{})))]
1.1 root 2624: "@dots{}"
2625: "@dots{}")
2626: @end example
2627:
2628: @noindent
2629: Similarly, a pattern for a ``NAND'' instruction should be written
2630:
2631: @example
2632: (define_insn ""
2633: [(set (match_operand:@var{m} 0 @dots{})
1.1.1.4 root 2634: (ior:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{}))
2635: (not:@var{m} (match_operand:@var{m} 2 @dots{}))))]
1.1 root 2636: "@dots{}"
2637: "@dots{}")
2638: @end example
2639:
2640: In both cases, it is not necessary to include patterns for the many
2641: logically equivalent RTL expressions.
2642:
2643: @cindex @code{xor}, canonicalization of
2644: @item
2645: The only possible RTL expressions involving both bitwise exclusive-or
1.1.1.6 root 2646: and bitwise negation are @code{(xor:@var{m} @var{x} @var{y})}
1.1 root 2647: and @code{(not:@var{m} (xor:@var{m} @var{x} @var{y}))}.@refill
2648:
2649: @item
2650: The sum of three items, one of which is a constant, will only appear in
2651: the form
2652:
2653: @example
2654: (plus:@var{m} (plus:@var{m} @var{x} @var{y}) @var{constant})
2655: @end example
2656:
2657: @item
2658: On machines that do not use @code{cc0},
2659: @code{(compare @var{x} (const_int 0))} will be converted to
2660: @var{x}.@refill
2661:
2662: @cindex @code{zero_extract}, canonicalization of
2663: @cindex @code{sign_extract}, canonicalization of
2664: @item
2665: Equality comparisons of a group of bits (usually a single bit) with zero
2666: will be written using @code{zero_extract} rather than the equivalent
2667: @code{and} or @code{sign_extract} operations.
2668:
2669: @end itemize
2670:
1.1.1.5 root 2671: @node Peephole Definitions
2672: @section Machine-Specific Peephole Optimizers
1.1 root 2673: @cindex peephole optimizer definitions
2674: @cindex defining peephole optimizers
2675:
2676: In addition to instruction patterns the @file{md} file may contain
2677: definitions of machine-specific peephole optimizations.
2678:
2679: The combiner does not notice certain peephole optimizations when the data
2680: flow in the program does not suggest that it should try them. For example,
2681: sometimes two consecutive insns related in purpose can be combined even
2682: though the second one does not appear to use a register computed in the
2683: first one. A machine-specific peephole optimizer can detect such
2684: opportunities.
2685:
1.1.1.5 root 2686: @need 1000
1.1 root 2687: A definition looks like this:
2688:
1.1.1.5 root 2689: @smallexample
1.1 root 2690: (define_peephole
2691: [@var{insn-pattern-1}
2692: @var{insn-pattern-2}
2693: @dots{}]
2694: "@var{condition}"
2695: "@var{template}"
2696: "@var{optional insn-attributes}")
1.1.1.5 root 2697: @end smallexample
1.1 root 2698:
2699: @noindent
2700: The last string operand may be omitted if you are not using any
2701: machine-specific information in this machine description. If present,
2702: it must obey the same rules as in a @code{define_insn}.
2703:
2704: In this skeleton, @var{insn-pattern-1} and so on are patterns to match
2705: consecutive insns. The optimization applies to a sequence of insns when
2706: @var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches
2707: the next, and so on.@refill
2708:
2709: Each of the insns matched by a peephole must also match a
2710: @code{define_insn}. Peepholes are checked only at the last stage just
2711: before code generation, and only optionally. Therefore, any insn which
2712: would match a peephole but no @code{define_insn} will cause a crash in code
2713: generation in an unoptimized compilation, or at various optimization
2714: stages.
2715:
2716: The operands of the insns are matched with @code{match_operands},
2717: @code{match_operator}, and @code{match_dup}, as usual. What is not
2718: usual is that the operand numbers apply to all the insn patterns in the
2719: definition. So, you can check for identical operands in two insns by
2720: using @code{match_operand} in one insn and @code{match_dup} in the
2721: other.
2722:
2723: The operand constraints used in @code{match_operand} patterns do not have
2724: any direct effect on the applicability of the peephole, but they will
2725: be validated afterward, so make sure your constraints are general enough
2726: to apply whenever the peephole matches. If the peephole matches
2727: but the constraints are not satisfied, the compiler will crash.
2728:
2729: It is safe to omit constraints in all the operands of the peephole; or
2730: you can write constraints which serve as a double-check on the criteria
2731: previously tested.
2732:
2733: Once a sequence of insns matches the patterns, the @var{condition} is
2734: checked. This is a C expression which makes the final decision whether to
2735: perform the optimization (we do so if the expression is nonzero). If
2736: @var{condition} is omitted (in other words, the string is empty) then the
2737: optimization is applied to every sequence of insns that matches the
2738: patterns.
2739:
2740: The defined peephole optimizations are applied after register allocation
2741: is complete. Therefore, the peephole definition can check which
2742: operands have ended up in which kinds of registers, just by looking at
2743: the operands.
2744:
1.1.1.8 ! root 2745: @findex prev_active_insn
1.1 root 2746: The way to refer to the operands in @var{condition} is to write
2747: @code{operands[@var{i}]} for operand number @var{i} (as matched by
2748: @code{(match_operand @var{i} @dots{})}). Use the variable @code{insn}
2749: to refer to the last of the insns being matched; use
1.1.1.8 ! root 2750: @code{prev_active_insn} to find the preceding insns.
1.1 root 2751:
2752: @findex dead_or_set_p
2753: When optimizing computations with intermediate results, you can use
2754: @var{condition} to match only when the intermediate results are not used
2755: elsewhere. Use the C expression @code{dead_or_set_p (@var{insn},
2756: @var{op})}, where @var{insn} is the insn in which you expect the value
2757: to be used for the last time (from the value of @code{insn}, together
2758: with use of @code{prev_nonnote_insn}), and @var{op} is the intermediate
2759: value (from @code{operands[@var{i}]}).@refill
2760:
2761: Applying the optimization means replacing the sequence of insns with one
2762: new insn. The @var{template} controls ultimate output of assembler code
2763: for this combined insn. It works exactly like the template of a
2764: @code{define_insn}. Operand numbers in this template are the same ones
2765: used in matching the original sequence of insns.
2766:
2767: The result of a defined peephole optimizer does not need to match any of
2768: the insn patterns in the machine description; it does not even have an
2769: opportunity to match them. The peephole optimizer definition itself serves
2770: as the insn pattern to control how the insn is output.
2771:
2772: Defined peephole optimizers are run as assembler code is being output,
2773: so the insns they produce are never combined or rearranged in any way.
2774:
2775: Here is an example, taken from the 68000 machine description:
2776:
1.1.1.5 root 2777: @smallexample
1.1 root 2778: (define_peephole
2779: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
1.1.1.3 root 2780: (set (match_operand:DF 0 "register_operand" "=f")
1.1 root 2781: (match_operand:DF 1 "register_operand" "ad"))]
2782: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
2783: "*
2784: @{
2785: rtx xoperands[2];
2786: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
2787: #ifdef MOTOROLA
2788: output_asm_insn (\"move.l %1,(sp)\", xoperands);
2789: output_asm_insn (\"move.l %1,-(sp)\", operands);
2790: return \"fmove.d (sp)+,%0\";
2791: #else
2792: output_asm_insn (\"movel %1,sp@@\", xoperands);
2793: output_asm_insn (\"movel %1,sp@@-\", operands);
2794: return \"fmoved sp@@+,%0\";
2795: #endif
2796: @}
2797: ")
1.1.1.5 root 2798: @end smallexample
1.1 root 2799:
1.1.1.5 root 2800: @need 1000
1.1 root 2801: The effect of this optimization is to change
2802:
1.1.1.5 root 2803: @smallexample
2804: @group
1.1 root 2805: jbsr _foobar
2806: addql #4,sp
2807: movel d1,sp@@-
2808: movel d0,sp@@-
2809: fmoved sp@@+,fp0
1.1.1.5 root 2810: @end group
2811: @end smallexample
1.1 root 2812:
2813: @noindent
2814: into
2815:
1.1.1.5 root 2816: @smallexample
2817: @group
1.1 root 2818: jbsr _foobar
2819: movel d1,sp@@
2820: movel d0,sp@@-
2821: fmoved sp@@+,fp0
1.1.1.5 root 2822: @end group
2823: @end smallexample
1.1 root 2824:
2825: @ignore
2826: @findex CC_REVERSED
2827: If a peephole matches a sequence including one or more jump insns, you must
2828: take account of the flags such as @code{CC_REVERSED} which specify that the
2829: condition codes are represented in an unusual manner. The compiler
2830: automatically alters any ordinary conditional jumps which occur in such
2831: situations, but the compiler cannot alter jumps which have been replaced by
2832: peephole optimizations. So it is up to you to alter the assembler code
2833: that the peephole produces. Supply C code to write the assembler output,
2834: and in this C code check the condition code status flags and change the
2835: assembler code as appropriate.
2836: @end ignore
2837:
2838: @var{insn-pattern-1} and so on look @emph{almost} like the second
2839: operand of @code{define_insn}. There is one important difference: the
2840: second operand of @code{define_insn} consists of one or more RTX's
2841: enclosed in square brackets. Usually, there is only one: then the same
2842: action can be written as an element of a @code{define_peephole}. But
2843: when there are multiple actions in a @code{define_insn}, they are
2844: implicitly enclosed in a @code{parallel}. Then you must explicitly
2845: write the @code{parallel}, and the square brackets within it, in the
2846: @code{define_peephole}. Thus, if an insn pattern looks like this,
2847:
1.1.1.5 root 2848: @smallexample
1.1 root 2849: (define_insn "divmodsi4"
2850: [(set (match_operand:SI 0 "general_operand" "=d")
2851: (div:SI (match_operand:SI 1 "general_operand" "0")
2852: (match_operand:SI 2 "general_operand" "dmsK")))
2853: (set (match_operand:SI 3 "general_operand" "=d")
2854: (mod:SI (match_dup 1) (match_dup 2)))]
2855: "TARGET_68020"
2856: "divsl%.l %2,%3:%0")
1.1.1.5 root 2857: @end smallexample
1.1 root 2858:
2859: @noindent
2860: then the way to mention this insn in a peephole is as follows:
2861:
1.1.1.5 root 2862: @smallexample
1.1 root 2863: (define_peephole
2864: [@dots{}
2865: (parallel
2866: [(set (match_operand:SI 0 "general_operand" "=d")
2867: (div:SI (match_operand:SI 1 "general_operand" "0")
2868: (match_operand:SI 2 "general_operand" "dmsK")))
2869: (set (match_operand:SI 3 "general_operand" "=d")
2870: (mod:SI (match_dup 1) (match_dup 2)))])
2871: @dots{}]
2872: @dots{})
1.1.1.5 root 2873: @end smallexample
1.1 root 2874:
1.1.1.5 root 2875: @node Expander Definitions
1.1 root 2876: @section Defining RTL Sequences for Code Generation
2877: @cindex expander definitions
2878: @cindex code generation RTL sequences
2879: @cindex defining RTL sequences for code generation
2880:
2881: On some target machines, some standard pattern names for RTL generation
2882: cannot be handled with single insn, but a sequence of RTL insns can
2883: represent them. For these target machines, you can write a
2884: @code{define_expand} to specify how to generate the sequence of RTL.
2885:
2886: @findex define_expand
2887: A @code{define_expand} is an RTL expression that looks almost like a
2888: @code{define_insn}; but, unlike the latter, a @code{define_expand} is used
2889: only for RTL generation and it can produce more than one RTL insn.
2890:
2891: A @code{define_expand} RTX has four operands:
2892:
2893: @itemize @bullet
2894: @item
2895: The name. Each @code{define_expand} must have a name, since the only
2896: use for it is to refer to it by name.
2897:
2898: @findex define_peephole
2899: @item
2900: The RTL template. This is just like the RTL template for a
2901: @code{define_peephole} in that it is a vector of RTL expressions
2902: each being one insn.
2903:
2904: @item
2905: The condition, a string containing a C expression. This expression is
2906: used to express how the availability of this pattern depends on
1.1.1.8 ! root 2907: subclasses of target machine, selected by command-line options when GNU
! 2908: CC is run. This is just like the condition of a @code{define_insn} that
! 2909: has a standard name. Therefore, the condition (if present) may not
! 2910: depend on the data in the insn being matched, but only the
! 2911: target-machine-type flags. The compiler needs to test these conditions
! 2912: during initialization in order to learn exactly which named instructions
! 2913: are available in a particular run.
1.1 root 2914:
2915: @item
2916: The preparation statements, a string containing zero or more C
2917: statements which are to be executed before RTL code is generated from
2918: the RTL template.
2919:
2920: Usually these statements prepare temporary registers for use as
2921: internal operands in the RTL template, but they can also generate RTL
2922: insns directly by calling routines such as @code{emit_insn}, etc.
2923: Any such insns precede the ones that come from the RTL template.
2924: @end itemize
2925:
2926: Every RTL insn emitted by a @code{define_expand} must match some
2927: @code{define_insn} in the machine description. Otherwise, the compiler
2928: will crash when trying to generate code for the insn or trying to optimize
2929: it.
2930:
2931: The RTL template, in addition to controlling generation of RTL insns,
2932: also describes the operands that need to be specified when this pattern
2933: is used. In particular, it gives a predicate for each operand.
2934:
2935: A true operand, which needs to be specified in order to generate RTL from
2936: the pattern, should be described with a @code{match_operand} in its first
2937: occurrence in the RTL template. This enters information on the operand's
2938: predicate into the tables that record such things. GNU CC uses the
2939: information to preload the operand into a register if that is required for
2940: valid RTL code. If the operand is referred to more than once, subsequent
2941: references should use @code{match_dup}.
2942:
2943: The RTL template may also refer to internal ``operands'' which are
2944: temporary registers or labels used only within the sequence made by the
2945: @code{define_expand}. Internal operands are substituted into the RTL
2946: template with @code{match_dup}, never with @code{match_operand}. The
2947: values of the internal operands are not passed in as arguments by the
2948: compiler when it requests use of this pattern. Instead, they are computed
2949: within the pattern, in the preparation statements. These statements
2950: compute the values and store them into the appropriate elements of
2951: @code{operands} so that @code{match_dup} can find them.
2952:
2953: There are two special macros defined for use in the preparation statements:
2954: @code{DONE} and @code{FAIL}. Use them with a following semicolon,
2955: as a statement.
2956:
2957: @table @code
2958:
2959: @findex DONE
2960: @item DONE
2961: Use the @code{DONE} macro to end RTL generation for the pattern. The
2962: only RTL insns resulting from the pattern on this occasion will be
2963: those already emitted by explicit calls to @code{emit_insn} within the
2964: preparation statements; the RTL template will not be generated.
2965:
2966: @findex FAIL
2967: @item FAIL
2968: Make the pattern fail on this occasion. When a pattern fails, it means
2969: that the pattern was not truly available. The calling routines in the
2970: compiler will try other strategies for code generation using other patterns.
2971:
2972: Failure is currently supported only for binary (addition, multiplication,
2973: shifting, etc.) and bitfield (@code{extv}, @code{extzv}, and @code{insv})
2974: operations.
2975: @end table
2976:
2977: Here is an example, the definition of left-shift for the SPUR chip:
2978:
1.1.1.5 root 2979: @smallexample
2980: @group
1.1 root 2981: (define_expand "ashlsi3"
2982: [(set (match_operand:SI 0 "register_operand" "")
2983: (ashift:SI
1.1.1.5 root 2984: @end group
2985: @group
1.1 root 2986: (match_operand:SI 1 "register_operand" "")
2987: (match_operand:SI 2 "nonmemory_operand" "")))]
2988: ""
2989: "
1.1.1.5 root 2990: @end group
2991: @end smallexample
2992:
2993: @smallexample
2994: @group
1.1 root 2995: @{
2996: if (GET_CODE (operands[2]) != CONST_INT
2997: || (unsigned) INTVAL (operands[2]) > 3)
2998: FAIL;
2999: @}")
1.1.1.5 root 3000: @end group
3001: @end smallexample
1.1 root 3002:
3003: @noindent
3004: This example uses @code{define_expand} so that it can generate an RTL insn
3005: for shifting when the shift-count is in the supported range of 0 to 3 but
3006: fail in other cases where machine insns aren't available. When it fails,
3007: the compiler tries another strategy using different patterns (such as, a
3008: library call).
3009:
3010: If the compiler were able to handle nontrivial condition-strings in
3011: patterns with names, then it would be possible to use a
3012: @code{define_insn} in that case. Here is another case (zero-extension
3013: on the 68000) which makes more use of the power of @code{define_expand}:
3014:
1.1.1.5 root 3015: @smallexample
1.1 root 3016: (define_expand "zero_extendhisi2"
3017: [(set (match_operand:SI 0 "general_operand" "")
3018: (const_int 0))
3019: (set (strict_low_part
3020: (subreg:HI
3021: (match_dup 0)
3022: 0))
3023: (match_operand:HI 1 "general_operand" ""))]
3024: ""
3025: "operands[1] = make_safe_from (operands[1], operands[0]);")
1.1.1.5 root 3026: @end smallexample
1.1 root 3027:
3028: @noindent
3029: @findex make_safe_from
3030: Here two RTL insns are generated, one to clear the entire output operand
3031: and the other to copy the input operand into its low half. This sequence
3032: is incorrect if the input operand refers to [the old value of] the output
3033: operand, so the preparation statement makes sure this isn't so. The
3034: function @code{make_safe_from} copies the @code{operands[1]} into a
3035: temporary register if it refers to @code{operands[0]}. It does this
3036: by emitting another RTL insn.
3037:
3038: Finally, a third example shows the use of an internal operand.
3039: Zero-extension on the SPUR chip is done by @code{and}-ing the result
3040: against a halfword mask. But this mask cannot be represented by a
3041: @code{const_int} because the constant value is too large to be legitimate
3042: on this machine. So it must be copied into a register with
3043: @code{force_reg} and then the register used in the @code{and}.
3044:
1.1.1.5 root 3045: @smallexample
1.1 root 3046: (define_expand "zero_extendhisi2"
3047: [(set (match_operand:SI 0 "register_operand" "")
3048: (and:SI (subreg:SI
3049: (match_operand:HI 1 "register_operand" "")
3050: 0)
3051: (match_dup 2)))]
3052: ""
3053: "operands[2]
3054: = force_reg (SImode, gen_rtx (CONST_INT,
3055: VOIDmode, 65535)); ")
1.1.1.5 root 3056: @end smallexample
1.1 root 3057:
3058: @strong{Note:} If the @code{define_expand} is used to serve a
3059: standard binary or unary arithmetic operation or a bitfield operation,
3060: then the last insn it generates must not be a @code{code_label},
3061: @code{barrier} or @code{note}. It must be an @code{insn},
3062: @code{jump_insn} or @code{call_insn}. If you don't need a real insn
3063: at the end, emit an insn to copy the result of the operation into
3064: itself. Such an insn will generate no code, but it can avoid problems
3065: in the compiler.@refill
3066:
1.1.1.5 root 3067: @node Insn Splitting
3068: @section Defining How to Split Instructions
1.1 root 3069: @cindex insn splitting
3070: @cindex instruction splitting
3071: @cindex splitting instructions
3072:
1.1.1.3 root 3073: There are two cases where you should specify how to split a pattern into
3074: multiple insns. On machines that have instructions requiring delay
3075: slots (@pxref{Delay Slots}) or that have instructions whose output is
3076: not available for multiple cycles (@pxref{Function Units}), the compiler
3077: phases that optimize these cases need to be able to move insns into
1.1.1.6 root 3078: one-instruction delay slots. However, some insns may generate more than one
1.1.1.3 root 3079: machine instruction. These insns cannot be placed into a delay slot.
3080:
3081: Often you can rewrite the single insn as a list of individual insns,
3082: each corresponding to one machine instruction. The disadvantage of
3083: doing so is that it will cause the compilation to be slower and require
3084: more space. If the resulting insns are too complex, it may also
3085: suppress some optimizations. The compiler splits the insn if there is a
3086: reason to believe that it might improve instruction or delay slot
3087: scheduling.
3088:
3089: The insn combiner phase also splits putative insns. If three insns are
3090: merged into one insn with a complex expression that cannot be matched by
3091: some @code{define_insn} pattern, the combiner phase attempts to split
3092: the complex pattern into two insns that are recognized. Usually it can
3093: break the complex pattern into two patterns by splitting out some
3094: subexpression. However, in some other cases, such as performing an
3095: addition of a large constant in two insns on a RISC machine, the way to
3096: split the addition into two insns is machine-dependent.
1.1 root 3097:
1.1.1.3 root 3098: @cindex define_split
1.1 root 3099: The @code{define_split} definition tells the compiler how to split a
1.1.1.3 root 3100: complex insn into several simpler insns. It looks like this:
1.1 root 3101:
1.1.1.5 root 3102: @smallexample
1.1 root 3103: (define_split
3104: [@var{insn-pattern}]
3105: "@var{condition}"
3106: [@var{new-insn-pattern-1}
3107: @var{new-insn-pattern-2}
3108: @dots{}]
3109: "@var{preparation statements}")
1.1.1.5 root 3110: @end smallexample
1.1 root 3111:
3112: @var{insn-pattern} is a pattern that needs to be split and
3113: @var{condition} is the final condition to be tested, as in a
1.1.1.3 root 3114: @code{define_insn}. When an insn matching @var{insn-pattern} and
3115: satisfying @var{condition} is found, it is replaced in the insn list
3116: with the insns given by @var{new-insn-pattern-1},
3117: @var{new-insn-pattern-2}, etc.
1.1 root 3118:
1.1.1.5 root 3119: The @var{preparation statements} are similar to those statements that
3120: are specified for @code{define_expand} (@pxref{Expander Definitions})
3121: and are executed before the new RTL is generated to prepare for the
3122: generated code or emit some insns whose pattern is not fixed. Unlike
3123: those in @code{define_expand}, however, these statements must not
3124: generate any new pseudo-registers. Once reload has completed, they also
1.1.1.4 root 3125: must not allocate any space in the stack frame.
1.1 root 3126:
1.1.1.3 root 3127: Patterns are matched against @var{insn-pattern} in two different
3128: circumstances. If an insn needs to be split for delay slot scheduling
3129: or insn scheduling, the insn is already known to be valid, which means
3130: that it must have been matched by some @code{define_insn} and, if
3131: @code{reload_completed} is non-zero, is known to satisfy the constraints
3132: of that @code{define_insn}. In that case, the new insn patterns must
3133: also be insns that are matched by some @code{define_insn} and, if
3134: @code{reload_completed} is non-zero, must also satisfy the constraints
3135: of those definitions.
3136:
3137: As an example of this usage of @code{define_split}, consider the following
3138: example from @file{a29k.md}, which splits a @code{sign_extend} from
1.1 root 3139: @code{HImode} to @code{SImode} into a pair of shift insns:
3140:
1.1.1.5 root 3141: @smallexample
1.1 root 3142: (define_split
3143: [(set (match_operand:SI 0 "gen_reg_operand" "")
1.1.1.4 root 3144: (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
1.1 root 3145: ""
3146: [(set (match_dup 0)
1.1.1.4 root 3147: (ashift:SI (match_dup 1)
3148: (const_int 16)))
1.1 root 3149: (set (match_dup 0)
1.1.1.4 root 3150: (ashiftrt:SI (match_dup 0)
3151: (const_int 16)))]
1.1 root 3152: "
3153: @{ operands[1] = gen_lowpart (SImode, operands[1]); @}")
1.1.1.5 root 3154: @end smallexample
1.1 root 3155:
1.1.1.3 root 3156: When the combiner phase tries to split an insn pattern, it is always the
3157: case that the pattern is @emph{not} matched by any @code{define_insn}.
3158: The combiner pass first tries to split a single @code{set} expression
3159: and then the same @code{set} expression inside a @code{parallel}, but
3160: followed by a @code{clobber} of a pseudo-reg to use as a scratch
3161: register. In these cases, the combiner expects exactly two new insn
3162: patterns to be generated. It will verify that these patterns match some
3163: @code{define_insn} definitions, so you need not do this test in the
3164: @code{define_split} (of course, there is no point in writing a
3165: @code{define_split} that will never produce insns that match).
3166:
3167: Here is an example of this use of @code{define_split}, taken from
3168: @file{rs6000.md}:
3169:
1.1.1.5 root 3170: @smallexample
1.1.1.3 root 3171: (define_split
3172: [(set (match_operand:SI 0 "gen_reg_operand" "")
1.1.1.4 root 3173: (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
3174: (match_operand:SI 2 "non_add_cint_operand" "")))]
1.1.1.3 root 3175: ""
3176: [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
3177: (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
3178: "
3179: @{
3180: int low = INTVAL (operands[2]) & 0xffff;
3181: int high = (unsigned) INTVAL (operands[2]) >> 16;
3182:
3183: if (low & 0x8000)
3184: high++, low |= 0xffff0000;
3185:
3186: operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16);
3187: operands[4] = gen_rtx (CONST_INT, VOIDmode, low);
3188: @}")
1.1.1.5 root 3189: @end smallexample
1.1.1.3 root 3190:
3191: Here the predicate @code{non_add_cint_operand} matches any
3192: @code{const_int} that is @emph{not} a valid operand of a single add
1.1.1.6 root 3193: insn. The add with the smaller displacement is written so that it
1.1.1.3 root 3194: can be substituted into the address of a subsequent operation.
3195:
3196: An example that uses a scratch register, from the same file, generates
3197: an equality comparison of a register and a large constant:
3198:
1.1.1.5 root 3199: @smallexample
1.1.1.3 root 3200: (define_split
3201: [(set (match_operand:CC 0 "cc_reg_operand" "")
1.1.1.4 root 3202: (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
3203: (match_operand:SI 2 "non_short_cint_operand" "")))
1.1.1.3 root 3204: (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
3205: "find_single_use (operands[0], insn, 0)
3206: && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
3207: || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
3208: [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
3209: (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
3210: "
3211: @{
1.1.1.5 root 3212: /* Get the constant we are comparing against, C, and see what it
3213: looks like sign-extended to 16 bits. Then see what constant
3214: could be XOR'ed with C to get the sign-extended value. */
1.1.1.3 root 3215:
3216: int c = INTVAL (operands[2]);
3217: int sextc = (c << 16) >> 16;
3218: int xorv = c ^ sextc;
3219:
3220: operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv);
3221: operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc);
3222: @}")
1.1.1.5 root 3223: @end smallexample
1.1.1.3 root 3224:
3225: To avoid confusion, don't write a single @code{define_split} that
3226: accepts some insns that match some @code{define_insn} as well as some
3227: insns that don't. Instead, write two separate @code{define_split}
3228: definitions, one for the insns that are valid and one for the insns that
3229: are not valid.
3230:
1.1.1.5 root 3231: @node Insn Attributes
1.1 root 3232: @section Instruction Attributes
3233: @cindex insn attributes
3234: @cindex instruction attributes
3235:
3236: In addition to describing the instruction supported by the target machine,
3237: the @file{md} file also defines a group of @dfn{attributes} and a set of
3238: values for each. Every generated insn is assigned a value for each attribute.
3239: One possible attribute would be the effect that the insn has on the machine's
3240: condition code. This attribute can then be used by @code{NOTICE_UPDATE_CC}
3241: to track the condition codes.
3242:
3243: @menu
3244: * Defining Attributes:: Specifying attributes and their values.
3245: * Expressions:: Valid expressions for attribute values.
3246: * Tagging Insns:: Assigning attribute values to insns.
3247: * Attr Example:: An example of assigning attributes.
3248: * Insn Lengths:: Computing the length of insns.
1.1.1.2 root 3249: * Constant Attributes:: Defining attributes that are constant.
1.1 root 3250: * Delay Slots:: Defining delay slots required for a machine.
3251: * Function Units:: Specifying information for insn scheduling.
3252: @end menu
3253:
1.1.1.5 root 3254: @node Defining Attributes
1.1 root 3255: @subsection Defining Attributes and their Values
3256: @cindex defining attributes and their values
3257: @cindex attributes, defining
3258:
3259: @findex define_attr
3260: The @code{define_attr} expression is used to define each attribute required
3261: by the target machine. It looks like:
3262:
1.1.1.5 root 3263: @smallexample
1.1 root 3264: (define_attr @var{name} @var{list-of-values} @var{default})
1.1.1.5 root 3265: @end smallexample
1.1 root 3266:
3267: @var{name} is a string specifying the name of the attribute being defined.
3268:
3269: @var{list-of-values} is either a string that specifies a comma-separated
3270: list of values that can be assigned to the attribute, or a null string to
3271: indicate that the attribute takes numeric values.
3272:
3273: @var{default} is an attribute expression that gives the value of this
3274: attribute for insns that match patterns whose definition does not include
3275: an explicit value for this attribute. @xref{Attr Example}, for more
1.1.1.2 root 3276: information on the handling of defaults. @xref{Constant Attributes},
3277: for information on attributes that do not depend on any particular insn.
1.1 root 3278:
3279: @findex insn-attr.h
3280: For each defined attribute, a number of definitions are written to the
3281: @file{insn-attr.h} file. For cases where an explicit set of values is
3282: specified for an attribute, the following are defined:
3283:
3284: @itemize @bullet
3285: @item
3286: A @samp{#define} is written for the symbol @samp{HAVE_ATTR_@var{name}}.
3287:
3288: @item
3289: An enumeral class is defined for @samp{attr_@var{name}} with
3290: elements of the form @samp{@var{upper-name}_@var{upper-value}} where
3291: the attribute name and value are first converted to upper case.
3292:
3293: @item
3294: A function @samp{get_attr_@var{name}} is defined that is passed an insn and
3295: returns the attribute value for that insn.
3296: @end itemize
3297:
3298: For example, if the following is present in the @file{md} file:
3299:
1.1.1.5 root 3300: @smallexample
1.1 root 3301: (define_attr "type" "branch,fp,load,store,arith" @dots{})
1.1.1.5 root 3302: @end smallexample
1.1 root 3303:
3304: @noindent
3305: the following lines will be written to the file @file{insn-attr.h}.
3306:
1.1.1.5 root 3307: @smallexample
1.1 root 3308: #define HAVE_ATTR_type
3309: enum attr_type @{TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
1.1.1.4 root 3310: TYPE_STORE, TYPE_ARITH@};
1.1 root 3311: extern enum attr_type get_attr_type ();
1.1.1.5 root 3312: @end smallexample
1.1 root 3313:
3314: If the attribute takes numeric values, no @code{enum} type will be
3315: defined and the function to obtain the attribute's value will return
3316: @code{int}.
3317:
1.1.1.5 root 3318: @node Expressions
1.1 root 3319: @subsection Attribute Expressions
3320: @cindex attribute expressions
3321:
3322: RTL expressions used to define attributes use the codes described above
3323: plus a few specific to attribute definitions, to be discussed below.
3324: Attribute value expressions must have one of the following forms:
3325:
3326: @table @code
3327: @cindex @code{const_int} and attributes
3328: @item (const_int @var{i})
3329: The integer @var{i} specifies the value of a numeric attribute. @var{i}
3330: must be non-negative.
3331:
3332: The value of a numeric attribute can be specified either with a
3333: @code{const_int} or as an integer represented as a string in
3334: @code{const_string}, @code{eq_attr} (see below), and @code{set_attr}
3335: (@pxref{Tagging Insns}) expressions.
3336:
3337: @cindex @code{const_string} and attributes
3338: @item (const_string @var{value})
3339: The string @var{value} specifies a constant attribute value.
3340: If @var{value} is specified as @samp{"*"}, it means that the default value of
3341: the attribute is to be used for the insn containing this expression.
3342: @samp{"*"} obviously cannot be used in the @var{default} expression
3343: of a @code{define_attr}.@refill
3344:
3345: If the attribute whose value is being specified is numeric, @var{value}
3346: must be a string containing a non-negative integer (normally
3347: @code{const_int} would be used in this case). Otherwise, it must
3348: contain one of the valid values for the attribute.
3349:
3350: @cindex @code{if_then_else} and attributes
3351: @item (if_then_else @var{test} @var{true-value} @var{false-value})
3352: @var{test} specifies an attribute test, whose format is defined below.
3353: The value of this expression is @var{true-value} if @var{test} is true,
3354: otherwise it is @var{false-value}.
3355:
3356: @cindex @code{cond} and attributes
3357: @item (cond [@var{test1} @var{value1} @dots{}] @var{default})
3358: The first operand of this expression is a vector containing an even
3359: number of expressions and consisting of pairs of @var{test} and @var{value}
3360: expressions. The value of the @code{cond} expression is that of the
3361: @var{value} corresponding to the first true @var{test} expression. If
3362: none of the @var{test} expressions are true, the value of the @code{cond}
3363: expression is that of the @var{default} expression.
3364: @end table
3365:
3366: @var{test} expressions can have one of the following forms:
3367:
3368: @table @code
3369: @cindex @code{const_int} and attribute tests
3370: @item (const_int @var{i})
3371: This test is true if @var{i} is non-zero and false otherwise.
3372:
3373: @cindex @code{not} and attributes
3374: @cindex @code{ior} and attributes
3375: @cindex @code{and} and attributes
3376: @item (not @var{test})
3377: @itemx (ior @var{test1} @var{test2})
3378: @itemx (and @var{test1} @var{test2})
3379: These tests are true if the indicated logical function is true.
3380:
3381: @cindex @code{match_operand} and attributes
3382: @item (match_operand:@var{m} @var{n} @var{pred} @var{constraints})
3383: This test is true if operand @var{n} of the insn whose attribute value
3384: is being determined has mode @var{m} (this part of the test is ignored
3385: if @var{m} is @code{VOIDmode}) and the function specified by the string
3386: @var{pred} returns a non-zero value when passed operand @var{n} and mode
3387: @var{m} (this part of the test is ignored if @var{pred} is the null
3388: string).
3389:
3390: The @var{constraints} operand is ignored and should be the null string.
3391:
3392: @cindex @code{le} and attributes
3393: @cindex @code{leu} and attributes
3394: @cindex @code{lt} and attributes
3395: @cindex @code{gt} and attributes
3396: @cindex @code{gtu} and attributes
3397: @cindex @code{ge} and attributes
3398: @cindex @code{geu} and attributes
3399: @cindex @code{ne} and attributes
3400: @cindex @code{eq} and attributes
3401: @cindex @code{plus} and attributes
3402: @cindex @code{minus} and attributes
3403: @cindex @code{mult} and attributes
3404: @cindex @code{div} and attributes
3405: @cindex @code{mod} and attributes
3406: @cindex @code{abs} and attributes
3407: @cindex @code{neg} and attributes
3408: @cindex @code{ashift} and attributes
3409: @cindex @code{lshiftrt} and attributes
3410: @cindex @code{ashiftrt} and attributes
3411: @item (le @var{arith1} @var{arith2})
3412: @itemx (leu @var{arith1} @var{arith2})
3413: @itemx (lt @var{arith1} @var{arith2})
3414: @itemx (ltu @var{arith1} @var{arith2})
3415: @itemx (gt @var{arith1} @var{arith2})
3416: @itemx (gtu @var{arith1} @var{arith2})
3417: @itemx (ge @var{arith1} @var{arith2})
3418: @itemx (geu @var{arith1} @var{arith2})
3419: @itemx (ne @var{arith1} @var{arith2})
3420: @itemx (eq @var{arith1} @var{arith2})
3421: These tests are true if the indicated comparison of the two arithmetic
3422: expressions is true. Arithmetic expressions are formed with
3423: @code{plus}, @code{minus}, @code{mult}, @code{div}, @code{mod},
3424: @code{abs}, @code{neg}, @code{and}, @code{ior}, @code{xor}, @code{not},
1.1.1.7 root 3425: @code{ashift}, @code{lshiftrt}, and @code{ashiftrt} expressions.@refill
1.1 root 3426:
3427: @findex get_attr
3428: @code{const_int} and @code{symbol_ref} are always valid terms (@pxref{Insn
3429: Lengths},for additional forms). @code{symbol_ref} is a string
3430: denoting a C expression that yields an @code{int} when evaluated by the
3431: @samp{get_attr_@dots{}} routine. It should normally be a global
3432: variable.@refill
3433:
3434: @findex eq_attr
3435: @item (eq_attr @var{name} @var{value})
3436: @var{name} is a string specifying the name of an attribute.
3437:
3438: @var{value} is a string that is either a valid value for attribute
3439: @var{name}, a comma-separated list of values, or @samp{!} followed by a
3440: value or list. If @var{value} does not begin with a @samp{!}, this
3441: test is true if the value of the @var{name} attribute of the current
3442: insn is in the list specified by @var{value}. If @var{value} begins
3443: with a @samp{!}, this test is true if the attribute's value is
3444: @emph{not} in the specified list.
3445:
3446: For example,
3447:
1.1.1.5 root 3448: @smallexample
1.1 root 3449: (eq_attr "type" "load,store")
1.1.1.5 root 3450: @end smallexample
1.1 root 3451:
3452: @noindent
3453: is equivalent to
3454:
1.1.1.5 root 3455: @smallexample
1.1 root 3456: (ior (eq_attr "type" "load") (eq_attr "type" "store"))
1.1.1.5 root 3457: @end smallexample
1.1 root 3458:
3459: If @var{name} specifies an attribute of @samp{alternative}, it refers to the
3460: value of the compiler variable @code{which_alternative}
3461: (@pxref{Output Statement}) and the values must be small integers. For
3462: example,@refill
3463:
1.1.1.5 root 3464: @smallexample
1.1 root 3465: (eq_attr "alternative" "2,3")
1.1.1.5 root 3466: @end smallexample
1.1 root 3467:
3468: @noindent
3469: is equivalent to
3470:
1.1.1.5 root 3471: @smallexample
1.1 root 3472: (ior (eq (symbol_ref "which_alternative") (const_int 2))
3473: (eq (symbol_ref "which_alternative") (const_int 3)))
1.1.1.5 root 3474: @end smallexample
1.1 root 3475:
3476: Note that, for most attributes, an @code{eq_attr} test is simplified in cases
3477: where the value of the attribute being tested is known for all insns matching
3478: a particular pattern. This is by far the most common case.@refill
1.1.1.5 root 3479:
3480: @findex attr_flag
3481: @item (attr_flag @var{name})
3482: The value of an @code{attr_flag} expression is true if the flag
3483: specified by @var{name} is true for the @code{insn} currently being
3484: scheduled.
3485:
3486: @var{name} is a string specifying one of a fixed set of flags to test.
3487: Test the flags @code{forward} and @code{backward} to determine the
3488: direction of a conditional branch. Test the flags @code{very_likely},
3489: @code{likely}, @code{very_unlikely}, and @code{unlikely} to determine
3490: if a conditional branch is expected to be taken.
3491:
3492: If the @code{very_likely} flag is true, then the @code{likely} flag is also
3493: true. Likewise for the @code{very_unlikely} and @code{unlikely} flags.
3494:
3495: This example describes a conditional branch delay slot which
3496: can be nullified for forward branches that are taken (annul-true) or
3497: for backward branches which are not taken (annul-false).
3498:
3499: @smallexample
3500: (define_delay (eq_attr "type" "cbranch")
3501: [(eq_attr "in_branch_delay" "true")
3502: (and (eq_attr "in_branch_delay" "true")
3503: (attr_flag "forward"))
3504: (and (eq_attr "in_branch_delay" "true")
3505: (attr_flag "backward"))])
3506: @end smallexample
3507:
3508: The @code{forward} and @code{backward} flags are false if the current
3509: @code{insn} being scheduled is not a conditional branch.
3510:
3511: The @code{very_likely} and @code{likely} flags are true if the
3512: @code{insn} being scheduled is not a conditional branch. The
3513: The @code{very_unlikely} and @code{unlikely} flags are false if the
3514: @code{insn} being scheduled is not a conditional branch.
3515:
3516: @code{attr_flag} is only used during delay slot scheduling and has no
3517: meaning to other passes of the compiler.
1.1 root 3518: @end table
3519:
1.1.1.5 root 3520: @node Tagging Insns
1.1 root 3521: @subsection Assigning Attribute Values to Insns
3522: @cindex tagging insns
3523: @cindex assigning attribute values to insns
3524:
3525: The value assigned to an attribute of an insn is primarily determined by
3526: which pattern is matched by that insn (or which @code{define_peephole}
3527: generated it). Every @code{define_insn} and @code{define_peephole} can
3528: have an optional last argument to specify the values of attributes for
3529: matching insns. The value of any attribute not specified in a particular
3530: insn is set to the default value for that attribute, as specified in its
3531: @code{define_attr}. Extensive use of default values for attributes
3532: permits the specification of the values for only one or two attributes
3533: in the definition of most insn patterns, as seen in the example in the
3534: next section.@refill
3535:
3536: The optional last argument of @code{define_insn} and
3537: @code{define_peephole} is a vector of expressions, each of which defines
3538: the value for a single attribute. The most general way of assigning an
3539: attribute's value is to use a @code{set} expression whose first operand is an
3540: @code{attr} expression giving the name of the attribute being set. The
3541: second operand of the @code{set} is an attribute expression
3542: (@pxref{Expressions}) giving the value of the attribute.@refill
3543:
3544: When the attribute value depends on the @samp{alternative} attribute
3545: (i.e., which is the applicable alternative in the constraint of the
1.1.1.4 root 3546: insn), the @code{set_attr_alternative} expression can be used. It
1.1 root 3547: allows the specification of a vector of attribute expressions, one for
3548: each alternative.
3549:
3550: @findex set_attr
3551: When the generality of arbitrary attribute expressions is not required,
3552: the simpler @code{set_attr} expression can be used, which allows
3553: specifying a string giving either a single attribute value or a list
3554: of attribute values, one for each alternative.
3555:
3556: The form of each of the above specifications is shown below. In each case,
3557: @var{name} is a string specifying the attribute to be set.
3558:
3559: @table @code
3560: @item (set_attr @var{name} @var{value-string})
3561: @var{value-string} is either a string giving the desired attribute value,
3562: or a string containing a comma-separated list giving the values for
3563: succeeding alternatives. The number of elements must match the number
3564: of alternatives in the constraint of the insn pattern.
3565:
3566: Note that it may be useful to specify @samp{*} for some alternative, in
3567: which case the attribute will assume its default value for insns matching
3568: that alternative.
3569:
3570: @findex set_attr_alternative
3571: @item (set_attr_alternative @var{name} [@var{value1} @var{value2} @dots{}])
3572: Depending on the alternative of the insn, the value will be one of the
3573: specified values. This is a shorthand for using a @code{cond} with
3574: tests on the @samp{alternative} attribute.
3575:
3576: @findex attr
3577: @item (set (attr @var{name}) @var{value})
3578: The first operand of this @code{set} must be the special RTL expression
3579: @code{attr}, whose sole operand is a string giving the name of the
3580: attribute being set. @var{value} is the value of the attribute.
3581: @end table
3582:
3583: The following shows three different ways of representing the same
3584: attribute value specification:
3585:
1.1.1.5 root 3586: @smallexample
1.1 root 3587: (set_attr "type" "load,store,arith")
3588:
3589: (set_attr_alternative "type"
3590: [(const_string "load") (const_string "store")
3591: (const_string "arith")])
3592:
3593: (set (attr "type")
3594: (cond [(eq_attr "alternative" "1") (const_string "load")
3595: (eq_attr "alternative" "2") (const_string "store")]
3596: (const_string "arith")))
1.1.1.5 root 3597: @end smallexample
1.1 root 3598:
1.1.1.5 root 3599: @need 1000
1.1 root 3600: @findex define_asm_attributes
3601: The @code{define_asm_attributes} expression provides a mechanism to
3602: specify the attributes assigned to insns produced from an @code{asm}
1.1.1.5 root 3603: statement. It has the form:
1.1 root 3604:
1.1.1.5 root 3605: @smallexample
1.1 root 3606: (define_asm_attributes [@var{attr-sets}])
1.1.1.5 root 3607: @end smallexample
1.1 root 3608:
3609: @noindent
1.1.1.5 root 3610: where @var{attr-sets} is specified the same as for both the
3611: @code{define_insn} and the @code{define_peephole} expressions.
1.1 root 3612:
3613: These values will typically be the ``worst case'' attribute values. For
3614: example, they might indicate that the condition code will be clobbered.
3615:
1.1.1.5 root 3616: A specification for a @code{length} attribute is handled specially. The
3617: way to compute the length of an @code{asm} insn is to multiply the
3618: length specified in the expression @code{define_asm_attributes} by the
3619: number of machine instructions specified in the @code{asm} statement,
3620: determined by counting the number of semicolons and newlines in the
3621: string. Therefore, the value of the @code{length} attribute specified
3622: in a @code{define_asm_attributes} should be the maximum possible length
3623: of a single machine instruction.
1.1 root 3624:
1.1.1.5 root 3625: @node Attr Example
1.1 root 3626: @subsection Example of Attribute Specifications
3627: @cindex attribute specifications example
3628: @cindex attribute specifications
3629:
3630: The judicious use of defaulting is important in the efficient use of
3631: insn attributes. Typically, insns are divided into @dfn{types} and an
3632: attribute, customarily called @code{type}, is used to represent this
3633: value. This attribute is normally used only to define the default value
3634: for other attributes. An example will clarify this usage.
3635:
3636: Assume we have a RISC machine with a condition code and in which only
3637: full-word operations are performed in registers. Let us assume that we
3638: can divide all insns into loads, stores, (integer) arithmetic
3639: operations, floating point operations, and branches.
3640:
3641: Here we will concern ourselves with determining the effect of an insn on
3642: the condition code and will limit ourselves to the following possible
3643: effects: The condition code can be set unpredictably (clobbered), not
3644: be changed, be set to agree with the results of the operation, or only
3645: changed if the item previously set into the condition code has been
3646: modified.
3647:
3648: Here is part of a sample @file{md} file for such a machine:
3649:
1.1.1.5 root 3650: @smallexample
1.1 root 3651: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
3652:
3653: (define_attr "cc" "clobber,unchanged,set,change0"
3654: (cond [(eq_attr "type" "load")
3655: (const_string "change0")
3656: (eq_attr "type" "store,branch")
3657: (const_string "unchanged")
3658: (eq_attr "type" "arith")
3659: (if_then_else (match_operand:SI 0 "" "")
3660: (const_string "set")
3661: (const_string "clobber"))]
3662: (const_string "clobber")))
3663:
3664: (define_insn ""
3665: [(set (match_operand:SI 0 "general_operand" "=r,r,m")
3666: (match_operand:SI 1 "general_operand" "r,m,r"))]
3667: ""
3668: "@@
3669: move %0,%1
3670: load %0,%1
3671: store %0,%1"
3672: [(set_attr "type" "arith,load,store")])
1.1.1.5 root 3673: @end smallexample
1.1 root 3674:
3675: Note that we assume in the above example that arithmetic operations
3676: performed on quantities smaller than a machine word clobber the condition
3677: code since they will set the condition code to a value corresponding to the
3678: full-word result.
3679:
1.1.1.5 root 3680: @node Insn Lengths
1.1 root 3681: @subsection Computing the Length of an Insn
3682: @cindex insn lengths, computing
3683: @cindex computing the length of an insn
3684:
3685: For many machines, multiple types of branch instructions are provided, each
3686: for different length branch displacements. In most cases, the assembler
3687: will choose the correct instruction to use. However, when the assembler
3688: cannot do so, GCC can when a special attribute, the @samp{length}
3689: attribute, is defined. This attribute must be defined to have numeric
3690: values by specifying a null string in its @code{define_attr}.
3691:
3692: In the case of the @samp{length} attribute, two additional forms of
3693: arithmetic terms are allowed in test expressions:
3694:
3695: @table @code
3696: @cindex @code{match_dup} and attributes
3697: @item (match_dup @var{n})
3698: This refers to the address of operand @var{n} of the current insn, which
3699: must be a @code{label_ref}.
3700:
3701: @cindex @code{pc} and attributes
3702: @item (pc)
3703: This refers to the address of the @emph{current} insn. It might have
3704: been more consistent with other usage to make this the address of the
3705: @emph{next} insn but this would be confusing because the length of the
3706: current insn is to be computed.
3707: @end table
3708:
3709: @cindex @code{addr_vec}, length of
3710: @cindex @code{addr_diff_vec}, length of
3711: For normal insns, the length will be determined by value of the
3712: @samp{length} attribute. In the case of @code{addr_vec} and
1.1.1.5 root 3713: @code{addr_diff_vec} insn patterns, the length is computed as
3714: the number of vectors multiplied by the size of each vector.
3715:
3716: Lengths are measured in addressable storage units (bytes).
1.1 root 3717:
3718: The following macros can be used to refine the length computation:
3719:
3720: @table @code
3721: @findex FIRST_INSN_ADDRESS
3722: @item FIRST_INSN_ADDRESS
3723: When the @code{length} insn attribute is used, this macro specifies the
3724: value to be assigned to the address of the first insn in a function. If
3725: not specified, 0 is used.
3726:
3727: @findex ADJUST_INSN_LENGTH
3728: @item ADJUST_INSN_LENGTH (@var{insn}, @var{length})
3729: If defined, modifies the length assigned to instruction @var{insn} as a
3730: function of the context in which it is used. @var{length} is an lvalue
3731: that contains the initially computed length of the insn and should be
3732: updated with the correct length of the insn. If updating is required,
3733: @var{insn} must not be a varying-length insn.
3734:
3735: This macro will normally not be required. A case in which it is
3736: required is the ROMP. On this machine, the size of an @code{addr_vec}
3737: insn must be increased by two to compensate for the fact that alignment
3738: may be required.
3739: @end table
3740:
1.1.1.2 root 3741: @findex get_attr_length
1.1.1.5 root 3742: The routine that returns @code{get_attr_length} (the value of the
3743: @code{length} attribute) can be used by the output routine to
3744: determine the form of the branch instruction to be written, as the
3745: example below illustrates.
1.1 root 3746:
3747: As an example of the specification of variable-length branches, consider
3748: the IBM 360. If we adopt the convention that a register will be set to
1.1.1.5 root 3749: the starting address of a function, we can jump to labels within 4k of
1.1 root 3750: the start using a four-byte instruction. Otherwise, we need a six-byte
3751: sequence to load the address from memory and then branch to it.
3752:
3753: On such a machine, a pattern for a branch instruction might be specified
3754: as follows:
3755:
1.1.1.5 root 3756: @smallexample
1.1 root 3757: (define_insn "jump"
3758: [(set (pc)
3759: (label_ref (match_operand 0 "" "")))]
3760: ""
3761: "*
3762: @{
3763: return (get_attr_length (insn) == 4
3764: ? \"b %l0\" : \"l r15,=a(%l0); br r15\");
3765: @}"
3766: [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096))
3767: (const_int 4)
3768: (const_int 6)))])
1.1.1.5 root 3769: @end smallexample
1.1 root 3770:
1.1.1.5 root 3771: @node Constant Attributes
1.1.1.2 root 3772: @subsection Constant Attributes
3773: @cindex constant attributes
3774:
1.1.1.3 root 3775: A special form of @code{define_attr}, where the expression for the
3776: default value is a @code{const} expression, indicates an attribute that
3777: is constant for a given run of the compiler. Constant attributes may be
3778: used to specify which variety of processor is used. For example,
1.1.1.2 root 3779:
1.1.1.5 root 3780: @smallexample
1.1.1.2 root 3781: (define_attr "cpu" "m88100,m88110,m88000"
3782: (const
3783: (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
1.1.1.4 root 3784: (symbol_ref "TARGET_88110") (const_string "m88110")]
3785: (const_string "m88000"))))
1.1.1.2 root 3786:
3787: (define_attr "memory" "fast,slow"
3788: (const
3789: (if_then_else (symbol_ref "TARGET_FAST_MEM")
1.1.1.4 root 3790: (const_string "fast")
3791: (const_string "slow"))))
1.1.1.5 root 3792: @end smallexample
1.1.1.2 root 3793:
3794: The routine generated for constant attributes has no parameters as it
1.1.1.3 root 3795: does not depend on any particular insn. RTL expressions used to define
3796: the value of a constant attribute may use the @code{symbol_ref} form,
3797: but may not use either the @code{match_operand} form or @code{eq_attr}
3798: forms involving insn attributes.
1.1.1.2 root 3799:
1.1.1.5 root 3800: @node Delay Slots
1.1 root 3801: @subsection Delay Slot Scheduling
3802: @cindex delay slots, defining
3803:
3804: The insn attribute mechanism can be used to specify the requirements for
3805: delay slots, if any, on a target machine. An instruction is said to
3806: require a @dfn{delay slot} if some instructions that are physically
3807: after the instruction are executed as if they were located before it.
3808: Classic examples are branch and call instructions, which often execute
3809: the following instruction before the branch or call is performed.
3810:
3811: On some machines, conditional branch instructions can optionally
3812: @dfn{annul} instructions in the delay slot. This means that the
3813: instruction will not be executed for certain branch outcomes. Both
3814: instructions that annul if the branch is true and instructions that
3815: annul if the branch is false are supported.
3816:
3817: Delay slot scheduling differs from instruction scheduling in that
3818: determining whether an instruction needs a delay slot is dependent only
3819: on the type of instruction being generated, not on data flow between the
3820: instructions. See the next section for a discussion of data-dependent
3821: instruction scheduling.
3822:
3823: @findex define_delay
3824: The requirement of an insn needing one or more delay slots is indicated
3825: via the @code{define_delay} expression. It has the following form:
3826:
1.1.1.5 root 3827: @smallexample
1.1 root 3828: (define_delay @var{test}
3829: [@var{delay-1} @var{annul-true-1} @var{annul-false-1}
3830: @var{delay-2} @var{annul-true-2} @var{annul-false-2}
3831: @dots{}])
1.1.1.5 root 3832: @end smallexample
1.1 root 3833:
3834: @var{test} is an attribute test that indicates whether this
3835: @code{define_delay} applies to a particular insn. If so, the number of
3836: required delay slots is determined by the length of the vector specified
3837: as the second argument. An insn placed in delay slot @var{n} must
3838: satisfy attribute test @var{delay-n}. @var{annul-true-n} is an
3839: attribute test that specifies which insns may be annulled if the branch
3840: is true. Similarly, @var{annul-false-n} specifies which insns in the
3841: delay slot may be annulled if the branch is false. If annulling is not
3842: supported for that delay slot, @code{(nil)} should be coded.@refill
3843:
3844: For example, in the common case where branch and call insns require
3845: a single delay slot, which may contain any insn other than a branch or
3846: call, the following would be placed in the @file{md} file:
3847:
1.1.1.5 root 3848: @smallexample
1.1 root 3849: (define_delay (eq_attr "type" "branch,call")
3850: [(eq_attr "type" "!branch,call") (nil) (nil)])
1.1.1.5 root 3851: @end smallexample
1.1 root 3852:
3853: Multiple @code{define_delay} expressions may be specified. In this
3854: case, each such expression specifies different delay slot requirements
3855: and there must be no insn for which tests in two @code{define_delay}
3856: expressions are both true.
3857:
3858: For example, if we have a machine that requires one delay slot for branches
3859: but two for calls, no delay slot can contain a branch or call insn,
3860: and any valid insn in the delay slot for the branch can be annulled if the
3861: branch is true, we might represent this as follows:
3862:
1.1.1.5 root 3863: @smallexample
1.1 root 3864: (define_delay (eq_attr "type" "branch")
1.1.1.5 root 3865: [(eq_attr "type" "!branch,call")
3866: (eq_attr "type" "!branch,call")
3867: (nil)])
1.1 root 3868:
3869: (define_delay (eq_attr "type" "call")
3870: [(eq_attr "type" "!branch,call") (nil) (nil)
3871: (eq_attr "type" "!branch,call") (nil) (nil)])
1.1.1.5 root 3872: @end smallexample
3873: @c the above is *still* too long. --mew 4feb93
1.1 root 3874:
1.1.1.5 root 3875: @node Function Units
1.1 root 3876: @subsection Specifying Function Units
3877: @cindex function units, for scheduling
3878:
3879: On most RISC machines, there are instructions whose results are not
3880: available for a specific number of cycles. Common cases are instructions
3881: that load data from memory. On many machines, a pipeline stall will result
3882: if the data is referenced too soon after the load instruction.
3883:
3884: In addition, many newer microprocessors have multiple function units, usually
3885: one for integer and one for floating point, and often will incur pipeline
3886: stalls when a result that is needed is not yet ready.
3887:
3888: The descriptions in this section allow the specification of how much
3889: time must elapse between the execution of an instruction and the time
3890: when its result is used. It also allows specification of when the
3891: execution of an instruction will delay execution of similar instructions
3892: due to function unit conflicts.
3893:
3894: For the purposes of the specifications in this section, a machine is
3895: divided into @dfn{function units}, each of which execute a specific
1.1.1.4 root 3896: class of instructions in first-in-first-out order. Function units that
3897: accept one instruction each cycle and allow a result to be used in the
3898: succeeding instruction (usually via forwarding) need not be specified.
3899: Classic RISC microprocessors will normally have a single function unit,
3900: which we can call @samp{memory}. The newer ``superscalar'' processors
3901: will often have function units for floating point operations, usually at
3902: least a floating point adder and multiplier.
1.1 root 3903:
3904: @findex define_function_unit
3905: Each usage of a function units by a class of insns is specified with a
3906: @code{define_function_unit} expression, which looks like this:
3907:
1.1.1.5 root 3908: @smallexample
1.1 root 3909: (define_function_unit @var{name} @var{multiplicity} @var{simultaneity}
1.1.1.4 root 3910: @var{test} @var{ready-delay} @var{issue-delay}
3911: [@var{conflict-list}])
1.1.1.5 root 3912: @end smallexample
1.1 root 3913:
3914: @var{name} is a string giving the name of the function unit.
3915:
3916: @var{multiplicity} is an integer specifying the number of identical
3917: units in the processor. If more than one unit is specified, they will
3918: be scheduled independently. Only truly independent units should be
3919: counted; a pipelined unit should be specified as a single unit. (The
3920: only common example of a machine that has multiple function units for a
3921: single instruction class that are truly independent and not pipelined
3922: are the two multiply and two increment units of the CDC 6600.)
3923:
3924: @var{simultaneity} specifies the maximum number of insns that can be
3925: executing in each instance of the function unit simultaneously or zero
3926: if the unit is pipelined and has no limit.
3927:
3928: All @code{define_function_unit} definitions referring to function unit
3929: @var{name} must have the same name and values for @var{multiplicity} and
3930: @var{simultaneity}.
3931:
3932: @var{test} is an attribute test that selects the insns we are describing
3933: in this definition. Note that an insn may use more than one function
3934: unit and a function unit may be specified in more than one
3935: @code{define_function_unit}.
3936:
3937: @var{ready-delay} is an integer that specifies the number of cycles
3938: after which the result of the instruction can be used without
3939: introducing any stalls.
3940:
1.1.1.4 root 3941: @var{issue-delay} is an integer that specifies the number of cycles
3942: after the instruction matching the @var{test} expression begins using
3943: this unit until a subsequent instruction can begin. A cost of @var{N}
3944: indicates an @var{N-1} cycle delay. A subsequent instruction may also
3945: be delayed if an earlier instruction has a longer @var{ready-delay}
3946: value. This blocking effect is computed using the @var{simultaneity},
3947: @var{ready-delay}, @var{issue-delay}, and @var{conflict-list} terms.
3948: For a normal non-pipelined function unit, @var{simultaneity} is one, the
3949: unit is taken to block for the @var{ready-delay} cycles of the executing
3950: insn, and smaller values of @var{issue-delay} are ignored.
1.1 root 3951:
3952: @var{conflict-list} is an optional list giving detailed conflict costs
3953: for this unit. If specified, it is a list of condition test expressions
1.1.1.4 root 3954: to be applied to insns chosen to execute in @var{name} following the
3955: particular insn matching @var{test} that is already executing in
3956: @var{name}. For each insn in the list, @var{issue-delay} specifies the
3957: conflict cost; for insns not in the list, the cost is zero. If not
3958: specified, @var{conflict-list} defaults to all instructions that use the
3959: function unit.
1.1 root 3960:
3961: Typical uses of this vector are where a floating point function unit can
3962: pipeline either single- or double-precision operations, but not both, or
3963: where a memory unit can pipeline loads, but not stores, etc.
3964:
3965: As an example, consider a classic RISC machine where the result of a
3966: load instruction is not available for two cycles (a single ``delay''
3967: instruction is required) and where only one load instruction can be executed
3968: simultaneously. This would be specified as:
3969:
1.1.1.5 root 3970: @smallexample
1.1.1.4 root 3971: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
1.1.1.5 root 3972: @end smallexample
1.1 root 3973:
3974: For the case of a floating point function unit that can pipeline either
3975: single or double precision, but not both, the following could be specified:
3976:
1.1.1.5 root 3977: @smallexample
1.1 root 3978: (define_function_unit
1.1.1.4 root 3979: "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
1.1 root 3980: (define_function_unit
1.1.1.4 root 3981: "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
1.1.1.5 root 3982: @end smallexample
1.1 root 3983:
1.1.1.4 root 3984: @strong{Note:} The scheduler attempts to avoid function unit conflicts
3985: and uses all the specifications in the @code{define_function_unit}
3986: expression. It has recently come to our attention that these
3987: specifications may not allow modeling of some of the newer
3988: ``superscalar'' processors that have insns using multiple pipelined
3989: units. These insns will cause a potential conflict for the second unit
3990: used during their execution and there is no way of representing that
3991: conflict. We welcome any examples of how function unit conflicts work
3992: in such processors and suggestions for their representation.
1.1 root 3993: @end ifset
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.