![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-16 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-16 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc
32:
33: Defining RTL Sequences for Code Generation
34: ==========================================
35:
36: On some target machines, some standard pattern names for RTL
37: generation cannot be handled with single insn, but a sequence of RTL
38: insns can represent them. For these target machines, you can write a
39: `define_expand' to specify how to generate the sequence of RTL.
40:
41: A `define_expand' is an RTL expression that looks almost like a
42: `define_insn'; but, unlike the latter, a `define_expand' is used only
43: for RTL generation and it can produce more than one RTL insn.
44:
45: A `define_expand' RTX has four operands:
46:
47: * The name. Each `define_expand' must have a name, since the only
48: use for it is to refer to it by name.
49:
50: * The RTL template. This is just like the RTL template for a
51: `define_peephole' in that it is a vector of RTL expressions each
52: being one insn.
53:
54: * The condition, a string containing a C expression. This
55: expression is used to express how the availability of this pattern
56: depends on subclasses of target machine, selected by command-line
57: options when GNU CC is run. This is just like the condition of a
58: `define_insn' that has a standard name.
59:
60: * The preparation statements, a string containing zero or more C
61: statements which are to be executed before RTL code is generated
62: from the RTL template.
63:
64: Usually these statements prepare temporary registers for use as
65: internal operands in the RTL template, but they can also generate
66: RTL insns directly by calling routines such as `emit_insn', etc.
67: Any such insns precede the ones that come from the RTL template.
68:
69: Every RTL insn emitted by a `define_expand' must match some
70: `define_insn' in the machine description. Otherwise, the compiler will
71: crash when trying to generate code for the insn or trying to optimize
72: it.
73:
74: The RTL template, in addition to controlling generation of RTL insns,
75: also describes the operands that need to be specified when this pattern
76: is used. In particular, it gives a predicate for each operand.
77:
78: A true operand, which needs to be specified in order to generate RTL
79: from the pattern, should be described with a `match_operand' in its
80: first occurrence in the RTL template. This enters information on the
81: operand's predicate into the tables that record such things. GNU CC
82: uses the information to preload the operand into a register if that is
83: required for valid RTL code. If the operand is referred to more than
84: once, subsequent references should use `match_dup'.
85:
86: The RTL template may also refer to internal "operands" which are
87: temporary registers or labels used only within the sequence made by the
88: `define_expand'. Internal operands are substituted into the RTL
89: template with `match_dup', never with `match_operand'. The values of
90: the internal operands are not passed in as arguments by the compiler
91: when it requests use of this pattern. Instead, they are computed
92: within the pattern, in the preparation statements. These statements
93: compute the values and store them into the appropriate elements of
94: `operands' so that `match_dup' can find them.
95:
96: There are two special macros defined for use in the preparation
97: statements: `DONE' and `FAIL'. Use them with a following semicolon, as
98: a statement.
99:
100: `DONE'
101: Use the `DONE' macro to end RTL generation for the pattern. The
102: only RTL insns resulting from the pattern on this occasion will be
103: those already emitted by explicit calls to `emit_insn' within the
104: preparation statements; the RTL template will not be generated.
105:
106: `FAIL'
107: Make the pattern fail on this occasion. When a pattern fails, it
108: means that the pattern was not truly available. The calling
109: routines in the compiler will try other strategies for code
110: generation using other patterns.
111:
112: Failure is currently supported only for binary (addition,
113: multiplication, shifting, etc.) and bitfield (`extv', `extzv', and
114: `insv') operations.
115:
116: Here is an example, the definition of left-shift for the SPUR chip:
117:
118: (define_expand "ashlsi3"
119: [(set (match_operand:SI 0 "register_operand" "")
120: (ashift:SI
121:
122: (match_operand:SI 1 "register_operand" "")
123: (match_operand:SI 2 "nonmemory_operand" "")))]
124: ""
125: "
126:
127: {
128: if (GET_CODE (operands[2]) != CONST_INT
129: || (unsigned) INTVAL (operands[2]) > 3)
130: FAIL;
131: }")
132:
133: This example uses `define_expand' so that it can generate an RTL insn
134: for shifting when the shift-count is in the supported range of 0 to 3
135: but fail in other cases where machine insns aren't available. When it
136: fails, the compiler tries another strategy using different patterns
137: (such as, a library call).
138:
139: If the compiler were able to handle nontrivial condition-strings in
140: patterns with names, then it would be possible to use a `define_insn'
141: in that case. Here is another case (zero-extension on the 68000) which
142: makes more use of the power of `define_expand':
143:
144: (define_expand "zero_extendhisi2"
145: [(set (match_operand:SI 0 "general_operand" "")
146: (const_int 0))
147: (set (strict_low_part
148: (subreg:HI
149: (match_dup 0)
150: 0))
151: (match_operand:HI 1 "general_operand" ""))]
152: ""
153: "operands[1] = make_safe_from (operands[1], operands[0]);")
154:
155: Here two RTL insns are generated, one to clear the entire output operand
156: and the other to copy the input operand into its low half. This
157: sequence is incorrect if the input operand refers to [the old value of]
158: the output operand, so the preparation statement makes sure this isn't
159: so. The function `make_safe_from' copies the `operands[1]' into a
160: temporary register if it refers to `operands[0]'. It does this by
161: emitting another RTL insn.
162:
163: Finally, a third example shows the use of an internal operand.
164: Zero-extension on the SPUR chip is done by `and'-ing the result against
165: a halfword mask. But this mask cannot be represented by a `const_int'
166: because the constant value is too large to be legitimate on this
167: machine. So it must be copied into a register with `force_reg' and
168: then the register used in the `and'.
169:
170: (define_expand "zero_extendhisi2"
171: [(set (match_operand:SI 0 "register_operand" "")
172: (and:SI (subreg:SI
173: (match_operand:HI 1 "register_operand" "")
174: 0)
175: (match_dup 2)))]
176: ""
177: "operands[2]
178: = force_reg (SImode, gen_rtx (CONST_INT,
179: VOIDmode, 65535)); ")
180:
181: *Note:* If the `define_expand' is used to serve a standard binary or
182: unary arithmetic operation or a bitfield operation, then the last insn
183: it generates must not be a `code_label', `barrier' or `note'. It must
184: be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn
185: at the end, emit an insn to copy the result of the operation into
186: itself. Such an insn will generate no code, but it can avoid problems
187: in the compiler.
188:
189:
190: File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc
191:
192: Defining How to Split Instructions
193: ==================================
194:
195: There are two cases where you should specify how to split a pattern
196: into multiple insns. On machines that have instructions requiring delay
197: slots (*note Delay Slots::.) or that have instructions whose output is
198: not available for multiple cycles (*note Function Units::.), the
199: compiler phases that optimize these cases need to be able to move insns
200: into one-instruction delay slots. However, some insns may generate
201: more than one machine instruction. These insns cannot be placed into a
202: delay slot.
203:
204: Often you can rewrite the single insn as a list of individual insns,
205: each corresponding to one machine instruction. The disadvantage of
206: doing so is that it will cause the compilation to be slower and require
207: more space. If the resulting insns are too complex, it may also
208: suppress some optimizations. The compiler splits the insn if there is a
209: reason to believe that it might improve instruction or delay slot
210: scheduling.
211:
212: The insn combiner phase also splits putative insns. If three insns
213: are merged into one insn with a complex expression that cannot be
214: matched by some `define_insn' pattern, the combiner phase attempts to
215: split the complex pattern into two insns that are recognized. Usually
216: it can break the complex pattern into two patterns by splitting out some
217: subexpression. However, in some other cases, such as performing an
218: addition of a large constant in two insns on a RISC machine, the way to
219: split the addition into two insns is machine-dependent.
220:
221: The `define_split' definition tells the compiler how to split a
222: complex insn into several simpler insns. It looks like this:
223:
224: (define_split
225: [INSN-PATTERN]
226: "CONDITION"
227: [NEW-INSN-PATTERN-1
228: NEW-INSN-PATTERN-2
229: ...]
230: "PREPARATION STATEMENTS")
231:
232: INSN-PATTERN is a pattern that needs to be split and CONDITION is
233: the final condition to be tested, as in a `define_insn'. When an insn
234: matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
235: in the insn list with the insns given by NEW-INSN-PATTERN-1,
236: NEW-INSN-PATTERN-2, etc.
237:
238: The PREPARATION STATEMENTS are similar to those statements that are
239: specified for `define_expand' (*note Expander Definitions::.) and are
240: executed before the new RTL is generated to prepare for the generated
241: code or emit some insns whose pattern is not fixed. Unlike those in
242: `define_expand', however, these statements must not generate any new
243: pseudo-registers. Once reload has completed, they also must not
244: allocate any space in the stack frame.
245:
246: Patterns are matched against INSN-PATTERN in two different
247: circumstances. If an insn needs to be split for delay slot scheduling
248: or insn scheduling, the insn is already known to be valid, which means
249: that it must have been matched by some `define_insn' and, if
250: `reload_completed' is non-zero, is known to satisfy the constraints of
251: that `define_insn'. In that case, the new insn patterns must also be
252: insns that are matched by some `define_insn' and, if `reload_completed'
253: is non-zero, must also satisfy the constraints of those definitions.
254:
255: As an example of this usage of `define_split', consider the following
256: example from `a29k.md', which splits a `sign_extend' from `HImode' to
257: `SImode' into a pair of shift insns:
258:
259: (define_split
260: [(set (match_operand:SI 0 "gen_reg_operand" "")
261: (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
262: ""
263: [(set (match_dup 0)
264: (ashift:SI (match_dup 1)
265: (const_int 16)))
266: (set (match_dup 0)
267: (ashiftrt:SI (match_dup 0)
268: (const_int 16)))]
269: "
270: { operands[1] = gen_lowpart (SImode, operands[1]); }")
271:
272: When the combiner phase tries to split an insn pattern, it is always
273: the case that the pattern is *not* matched by any `define_insn'. The
274: combiner pass first tries to split a single `set' expression and then
275: the same `set' expression inside a `parallel', but followed by a
276: `clobber' of a pseudo-reg to use as a scratch register. In these
277: cases, the combiner expects exactly two new insn patterns to be
278: generated. It will verify that these patterns match some `define_insn'
279: definitions, so you need not do this test in the `define_split' (of
280: course, there is no point in writing a `define_split' that will never
281: produce insns that match).
282:
283: Here is an example of this use of `define_split', taken from
284: `rs6000.md':
285:
286: (define_split
287: [(set (match_operand:SI 0 "gen_reg_operand" "")
288: (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
289: (match_operand:SI 2 "non_add_cint_operand" "")))]
290: ""
291: [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
292: (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
293: "
294: {
295: int low = INTVAL (operands[2]) & 0xffff;
296: int high = (unsigned) INTVAL (operands[2]) >> 16;
297:
298: if (low & 0x8000)
299: high++, low |= 0xffff0000;
300:
301: operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16);
302: operands[4] = gen_rtx (CONST_INT, VOIDmode, low);
303: }")
304:
305: Here the predicate `non_add_cint_operand' matches any `const_int'
306: that is *not* a valid operand of a single add insn. The add with the
307: smaller displacement is written so that it can be substituted into the
308: address of a subsequent operation.
309:
310: An example that uses a scratch register, from the same file,
311: generates an equality comparison of a register and a large constant:
312:
313: (define_split
314: [(set (match_operand:CC 0 "cc_reg_operand" "")
315: (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
316: (match_operand:SI 2 "non_short_cint_operand" "")))
317: (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
318: "find_single_use (operands[0], insn, 0)
319: && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
320: || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
321: [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
322: (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
323: "
324: {
325: /* Get the constant we are comparing against, C, and see what it
326: looks like sign-extended to 16 bits. Then see what constant
327: could be XOR'ed with C to get the sign-extended value. */
328:
329: int c = INTVAL (operands[2]);
330: int sextc = (c << 16) >> 16;
331: int xorv = c ^ sextc;
332:
333: operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv);
334: operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc);
335: }")
336:
337: To avoid confusion, don't write a single `define_split' that accepts
338: some insns that match some `define_insn' as well as some insns that
339: don't. Instead, write two separate `define_split' definitions, one for
340: the insns that are valid and one for the insns that are not valid.
341:
342:
343: File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc
344:
345: Instruction Attributes
346: ======================
347:
348: In addition to describing the instruction supported by the target
349: machine, the `md' file also defines a group of "attributes" and a set of
350: values for each. Every generated insn is assigned a value for each
351: attribute. One possible attribute would be the effect that the insn
352: has on the machine's condition code. This attribute can then be used
353: by `NOTICE_UPDATE_CC' to track the condition codes.
354:
355: * Menu:
356:
357: * Defining Attributes:: Specifying attributes and their values.
358: * Expressions:: Valid expressions for attribute values.
359: * Tagging Insns:: Assigning attribute values to insns.
360: * Attr Example:: An example of assigning attributes.
361: * Insn Lengths:: Computing the length of insns.
362: * Constant Attributes:: Defining attributes that are constant.
363: * Delay Slots:: Defining delay slots required for a machine.
364: * Function Units:: Specifying information for insn scheduling.
365:
366:
367: File: gcc.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes
368:
369: Defining Attributes and their Values
370: ------------------------------------
371:
372: The `define_attr' expression is used to define each attribute
373: required by the target machine. It looks like:
374:
375: (define_attr NAME LIST-OF-VALUES DEFAULT)
376:
377: NAME is a string specifying the name of the attribute being defined.
378:
379: LIST-OF-VALUES is either a string that specifies a comma-separated
380: list of values that can be assigned to the attribute, or a null string
381: to indicate that the attribute takes numeric values.
382:
383: DEFAULT is an attribute expression that gives the value of this
384: attribute for insns that match patterns whose definition does not
385: include an explicit value for this attribute. *Note Attr Example::,
386: for more information on the handling of defaults. *Note Constant
387: Attributes::, for information on attributes that do not depend on any
388: particular insn.
389:
390: For each defined attribute, a number of definitions are written to
391: the `insn-attr.h' file. For cases where an explicit set of values is
392: specified for an attribute, the following are defined:
393:
394: * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
395:
396: * An enumeral class is defined for `attr_NAME' with elements of the
397: form `UPPER-NAME_UPPER-VALUE' where the attribute name and value
398: are first converted to upper case.
399:
400: * A function `get_attr_NAME' is defined that is passed an insn and
401: returns the attribute value for that insn.
402:
403: For example, if the following is present in the `md' file:
404:
405: (define_attr "type" "branch,fp,load,store,arith" ...)
406:
407: the following lines will be written to the file `insn-attr.h'.
408:
409: #define HAVE_ATTR_type
410: enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
411: TYPE_STORE, TYPE_ARITH};
412: extern enum attr_type get_attr_type ();
413:
414: If the attribute takes numeric values, no `enum' type will be
415: defined and the function to obtain the attribute's value will return
416: `int'.
417:
418:
419: File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
420:
421: Attribute Expressions
422: ---------------------
423:
424: RTL expressions used to define attributes use the codes described
425: above plus a few specific to attribute definitions, to be discussed
426: below. Attribute value expressions must have one of the following
427: forms:
428:
429: `(const_int I)'
430: The integer I specifies the value of a numeric attribute. I must
431: be non-negative.
432:
433: The value of a numeric attribute can be specified either with a
434: `const_int' or as an integer represented as a string in
435: `const_string', `eq_attr' (see below), and `set_attr' (*note
436: Tagging Insns::.) expressions.
437:
438: `(const_string VALUE)'
439: The string VALUE specifies a constant attribute value. If VALUE
440: is specified as `"*"', it means that the default value of the
441: attribute is to be used for the insn containing this expression.
442: `"*"' obviously cannot be used in the DEFAULT expression of a
443: `define_attr'.
444:
445: If the attribute whose value is being specified is numeric, VALUE
446: must be a string containing a non-negative integer (normally
447: `const_int' would be used in this case). Otherwise, it must
448: contain one of the valid values for the attribute.
449:
450: `(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
451: TEST specifies an attribute test, whose format is defined below.
452: The value of this expression is TRUE-VALUE if TEST is true,
453: otherwise it is FALSE-VALUE.
454:
455: `(cond [TEST1 VALUE1 ...] DEFAULT)'
456: The first operand of this expression is a vector containing an even
457: number of expressions and consisting of pairs of TEST and VALUE
458: expressions. The value of the `cond' expression is that of the
459: VALUE corresponding to the first true TEST expression. If none of
460: the TEST expressions are true, the value of the `cond' expression
461: is that of the DEFAULT expression.
462:
463: TEST expressions can have one of the following forms:
464:
465: `(const_int I)'
466: This test is true if I is non-zero and false otherwise.
467:
468: `(not TEST)'
469: `(ior TEST1 TEST2)'
470: `(and TEST1 TEST2)'
471: These tests are true if the indicated logical function is true.
472:
473: `(match_operand:M N PRED CONSTRAINTS)'
474: This test is true if operand N of the insn whose attribute value
475: is being determined has mode M (this part of the test is ignored
476: if M is `VOIDmode') and the function specified by the string PRED
477: returns a non-zero value when passed operand N and mode M (this
478: part of the test is ignored if PRED is the null string).
479:
480: The CONSTRAINTS operand is ignored and should be the null string.
481:
482: `(le ARITH1 ARITH2)'
483: `(leu ARITH1 ARITH2)'
484: `(lt ARITH1 ARITH2)'
485: `(ltu ARITH1 ARITH2)'
486: `(gt ARITH1 ARITH2)'
487: `(gtu ARITH1 ARITH2)'
488: `(ge ARITH1 ARITH2)'
489: `(geu ARITH1 ARITH2)'
490: `(ne ARITH1 ARITH2)'
491: `(eq ARITH1 ARITH2)'
492: These tests are true if the indicated comparison of the two
493: arithmetic expressions is true. Arithmetic expressions are formed
494: with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and',
495: `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and `ashiftrt'
496: expressions.
497:
498: `const_int' and `symbol_ref' are always valid terms (*note Insn
499: Lengths::.,for additional forms). `symbol_ref' is a string
500: denoting a C expression that yields an `int' when evaluated by the
501: `get_attr_...' routine. It should normally be a global variable.
502:
503: `(eq_attr NAME VALUE)'
504: NAME is a string specifying the name of an attribute.
505:
506: VALUE is a string that is either a valid value for attribute NAME,
507: a comma-separated list of values, or `!' followed by a value or
508: list. If VALUE does not begin with a `!', this test is true if
509: the value of the NAME attribute of the current insn is in the list
510: specified by VALUE. If VALUE begins with a `!', this test is true
511: if the attribute's value is *not* in the specified list.
512:
513: For example,
514:
515: (eq_attr "type" "load,store")
516:
517: is equivalent to
518:
519: (ior (eq_attr "type" "load") (eq_attr "type" "store"))
520:
521: If NAME specifies an attribute of `alternative', it refers to the
522: value of the compiler variable `which_alternative' (*note Output
523: Statement::.) and the values must be small integers. For example,
524:
525: (eq_attr "alternative" "2,3")
526:
527: is equivalent to
528:
529: (ior (eq (symbol_ref "which_alternative") (const_int 2))
530: (eq (symbol_ref "which_alternative") (const_int 3)))
531:
532: Note that, for most attributes, an `eq_attr' test is simplified in
533: cases where the value of the attribute being tested is known for
534: all insns matching a particular pattern. This is by far the most
535: common case.
536:
537: `(attr_flag NAME)'
538: The value of an `attr_flag' expression is true if the flag
539: specified by NAME is true for the `insn' currently being scheduled.
540:
541: NAME is a string specifying one of a fixed set of flags to test.
542: Test the flags `forward' and `backward' to determine the direction
543: of a conditional branch. Test the flags `very_likely', `likely',
544: `very_unlikely', and `unlikely' to determine if a conditional
545: branch is expected to be taken.
546:
547: If the `very_likely' flag is true, then the `likely' flag is also
548: true. Likewise for the `very_unlikely' and `unlikely' flags.
549:
550: This example describes a conditional branch delay slot which can
551: be nullified for forward branches that are taken (annul-true) or
552: for backward branches which are not taken (annul-false).
553:
554: (define_delay (eq_attr "type" "cbranch")
555: [(eq_attr "in_branch_delay" "true")
556: (and (eq_attr "in_branch_delay" "true")
557: (attr_flag "forward"))
558: (and (eq_attr "in_branch_delay" "true")
559: (attr_flag "backward"))])
560:
561: The `forward' and `backward' flags are false if the current `insn'
562: being scheduled is not a conditional branch.
563:
564: The `very_likely' and `likely' flags are true if the `insn' being
565: scheduled is not a conditional branch. The The `very_unlikely'
566: and `unlikely' flags are false if the `insn' being scheduled is
567: not a conditional branch.
568:
569: `attr_flag' is only used during delay slot scheduling and has no
570: meaning to other passes of the compiler.
571:
572:
573: File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
574:
575: Assigning Attribute Values to Insns
576: -----------------------------------
577:
578: The value assigned to an attribute of an insn is primarily
579: determined by which pattern is matched by that insn (or which
580: `define_peephole' generated it). Every `define_insn' and
581: `define_peephole' can have an optional last argument to specify the
582: values of attributes for matching insns. The value of any attribute
583: not specified in a particular insn is set to the default value for that
584: attribute, as specified in its `define_attr'. Extensive use of default
585: values for attributes permits the specification of the values for only
586: one or two attributes in the definition of most insn patterns, as seen
587: in the example in the next section.
588:
589: The optional last argument of `define_insn' and `define_peephole' is
590: a vector of expressions, each of which defines the value for a single
591: attribute. The most general way of assigning an attribute's value is
592: to use a `set' expression whose first operand is an `attr' expression
593: giving the name of the attribute being set. The second operand of the
594: `set' is an attribute expression (*note Expressions::.) giving the
595: value of the attribute.
596:
597: When the attribute value depends on the `alternative' attribute
598: (i.e., which is the applicable alternative in the constraint of the
599: insn), the `set_attr_alternative' expression can be used. It allows
600: the specification of a vector of attribute expressions, one for each
601: alternative.
602:
603: When the generality of arbitrary attribute expressions is not
604: required, the simpler `set_attr' expression can be used, which allows
605: specifying a string giving either a single attribute value or a list of
606: attribute values, one for each alternative.
607:
608: The form of each of the above specifications is shown below. In
609: each case, NAME is a string specifying the attribute to be set.
610:
611: `(set_attr NAME VALUE-STRING)'
612: VALUE-STRING is either a string giving the desired attribute value,
613: or a string containing a comma-separated list giving the values for
614: succeeding alternatives. The number of elements must match the
615: number of alternatives in the constraint of the insn pattern.
616:
617: Note that it may be useful to specify `*' for some alternative, in
618: which case the attribute will assume its default value for insns
619: matching that alternative.
620:
621: `(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
622: Depending on the alternative of the insn, the value will be one of
623: the specified values. This is a shorthand for using a `cond' with
624: tests on the `alternative' attribute.
625:
626: `(set (attr NAME) VALUE)'
627: The first operand of this `set' must be the special RTL expression
628: `attr', whose sole operand is a string giving the name of the
629: attribute being set. VALUE is the value of the attribute.
630:
631: The following shows three different ways of representing the same
632: attribute value specification:
633:
634: (set_attr "type" "load,store,arith")
635:
636: (set_attr_alternative "type"
637: [(const_string "load") (const_string "store")
638: (const_string "arith")])
639:
640: (set (attr "type")
641: (cond [(eq_attr "alternative" "1") (const_string "load")
642: (eq_attr "alternative" "2") (const_string "store")]
643: (const_string "arith")))
644:
645: The `define_asm_attributes' expression provides a mechanism to
646: specify the attributes assigned to insns produced from an `asm'
647: statement. It has the form:
648:
649: (define_asm_attributes [ATTR-SETS])
650:
651: where ATTR-SETS is specified the same as for both the `define_insn' and
652: the `define_peephole' expressions.
653:
654: These values will typically be the "worst case" attribute values.
655: For example, they might indicate that the condition code will be
656: clobbered.
657:
658: A specification for a `length' attribute is handled specially. The
659: way to compute the length of an `asm' insn is to multiply the length
660: specified in the expression `define_asm_attributes' by the number of
661: machine instructions specified in the `asm' statement, determined by
662: counting the number of semicolons and newlines in the string.
663: Therefore, the value of the `length' attribute specified in a
664: `define_asm_attributes' should be the maximum possible length of a
665: single machine instruction.
666:
667:
668: File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
669:
670: Example of Attribute Specifications
671: -----------------------------------
672:
673: The judicious use of defaulting is important in the efficient use of
674: insn attributes. Typically, insns are divided into "types" and an
675: attribute, customarily called `type', is used to represent this value.
676: This attribute is normally used only to define the default value for
677: other attributes. An example will clarify this usage.
678:
679: Assume we have a RISC machine with a condition code and in which only
680: full-word operations are performed in registers. Let us assume that we
681: can divide all insns into loads, stores, (integer) arithmetic
682: operations, floating point operations, and branches.
683:
684: Here we will concern ourselves with determining the effect of an
685: insn on the condition code and will limit ourselves to the following
686: possible effects: The condition code can be set unpredictably
687: (clobbered), not be changed, be set to agree with the results of the
688: operation, or only changed if the item previously set into the
689: condition code has been modified.
690:
691: Here is part of a sample `md' file for such a machine:
692:
693: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
694:
695: (define_attr "cc" "clobber,unchanged,set,change0"
696: (cond [(eq_attr "type" "load")
697: (const_string "change0")
698: (eq_attr "type" "store,branch")
699: (const_string "unchanged")
700: (eq_attr "type" "arith")
701: (if_then_else (match_operand:SI 0 "" "")
702: (const_string "set")
703: (const_string "clobber"))]
704: (const_string "clobber")))
705:
706: (define_insn ""
707: [(set (match_operand:SI 0 "general_operand" "=r,r,m")
708: (match_operand:SI 1 "general_operand" "r,m,r"))]
709: ""
710: "@
711: move %0,%1
712: load %0,%1
713: store %0,%1"
714: [(set_attr "type" "arith,load,store")])
715:
716: Note that we assume in the above example that arithmetic operations
717: performed on quantities smaller than a machine word clobber the
718: condition code since they will set the condition code to a value
719: corresponding to the full-word result.
720:
721:
722: File: gcc.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
723:
724: Computing the Length of an Insn
725: -------------------------------
726:
727: For many machines, multiple types of branch instructions are
728: provided, each for different length branch displacements. In most
729: cases, the assembler will choose the correct instruction to use.
730: However, when the assembler cannot do so, GCC can when a special
731: attribute, the `length' attribute, is defined. This attribute must be
732: defined to have numeric values by specifying a null string in its
733: `define_attr'.
734:
735: In the case of the `length' attribute, two additional forms of
736: arithmetic terms are allowed in test expressions:
737:
738: `(match_dup N)'
739: This refers to the address of operand N of the current insn, which
740: must be a `label_ref'.
741:
742: `(pc)'
743: This refers to the address of the *current* insn. It might have
744: been more consistent with other usage to make this the address of
745: the *next* insn but this would be confusing because the length of
746: the current insn is to be computed.
747:
748: For normal insns, the length will be determined by value of the
749: `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
750: patterns, the length is computed as the number of vectors multiplied by
751: the size of each vector.
752:
753: Lengths are measured in addressable storage units (bytes).
754:
755: The following macros can be used to refine the length computation:
756:
757: `FIRST_INSN_ADDRESS'
758: When the `length' insn attribute is used, this macro specifies the
759: value to be assigned to the address of the first insn in a
760: function. If not specified, 0 is used.
761:
762: `ADJUST_INSN_LENGTH (INSN, LENGTH)'
763: If defined, modifies the length assigned to instruction INSN as a
764: function of the context in which it is used. LENGTH is an lvalue
765: that contains the initially computed length of the insn and should
766: be updated with the correct length of the insn. If updating is
767: required, INSN must not be a varying-length insn.
768:
769: This macro will normally not be required. A case in which it is
770: required is the ROMP. On this machine, the size of an `addr_vec'
771: insn must be increased by two to compensate for the fact that
772: alignment may be required.
773:
774: The routine that returns `get_attr_length' (the value of the
775: `length' attribute) can be used by the output routine to determine the
776: form of the branch instruction to be written, as the example below
777: illustrates.
778:
779: As an example of the specification of variable-length branches,
780: consider the IBM 360. If we adopt the convention that a register will
781: be set to the starting address of a function, we can jump to labels
782: within 4k of the start using a four-byte instruction. Otherwise, we
783: need a six-byte sequence to load the address from memory and then
784: branch to it.
785:
786: On such a machine, a pattern for a branch instruction might be
787: specified as follows:
788:
789: (define_insn "jump"
790: [(set (pc)
791: (label_ref (match_operand 0 "" "")))]
792: ""
793: "*
794: {
795: return (get_attr_length (insn) == 4
796: ? \"b %l0\" : \"l r15,=a(%l0); br r15\");
797: }"
798: [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096))
799: (const_int 4)
800: (const_int 6)))])
801:
802:
803: File: gcc.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
804:
805: Constant Attributes
806: -------------------
807:
808: A special form of `define_attr', where the expression for the
809: default value is a `const' expression, indicates an attribute that is
810: constant for a given run of the compiler. Constant attributes may be
811: used to specify which variety of processor is used. For example,
812:
813: (define_attr "cpu" "m88100,m88110,m88000"
814: (const
815: (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
816: (symbol_ref "TARGET_88110") (const_string "m88110")]
817: (const_string "m88000"))))
818:
819: (define_attr "memory" "fast,slow"
820: (const
821: (if_then_else (symbol_ref "TARGET_FAST_MEM")
822: (const_string "fast")
823: (const_string "slow"))))
824:
825: The routine generated for constant attributes has no parameters as it
826: does not depend on any particular insn. RTL expressions used to define
827: the value of a constant attribute may use the `symbol_ref' form, but
828: may not use either the `match_operand' form or `eq_attr' forms
829: involving insn attributes.
830:
831:
832: File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes
833:
834: Delay Slot Scheduling
835: ---------------------
836:
837: The insn attribute mechanism can be used to specify the requirements
838: for delay slots, if any, on a target machine. An instruction is said to
839: require a "delay slot" if some instructions that are physically after
840: the instruction are executed as if they were located before it.
841: Classic examples are branch and call instructions, which often execute
842: the following instruction before the branch or call is performed.
843:
844: On some machines, conditional branch instructions can optionally
845: "annul" instructions in the delay slot. This means that the
846: instruction will not be executed for certain branch outcomes. Both
847: instructions that annul if the branch is true and instructions that
848: annul if the branch is false are supported.
849:
850: Delay slot scheduling differs from instruction scheduling in that
851: determining whether an instruction needs a delay slot is dependent only
852: on the type of instruction being generated, not on data flow between the
853: instructions. See the next section for a discussion of data-dependent
854: instruction scheduling.
855:
856: The requirement of an insn needing one or more delay slots is
857: indicated via the `define_delay' expression. It has the following form:
858:
859: (define_delay TEST
860: [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
861: DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
862: ...])
863:
864: TEST is an attribute test that indicates whether this `define_delay'
865: applies to a particular insn. If so, the number of required delay
866: slots is determined by the length of the vector specified as the second
867: argument. An insn placed in delay slot N must satisfy attribute test
868: DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
869: may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
870: specifies which insns in the delay slot may be annulled if the branch
871: is false. If annulling is not supported for that delay slot, `(nil)'
872: should be coded.
873:
874: For example, in the common case where branch and call insns require
875: a single delay slot, which may contain any insn other than a branch or
876: call, the following would be placed in the `md' file:
877:
878: (define_delay (eq_attr "type" "branch,call")
879: [(eq_attr "type" "!branch,call") (nil) (nil)])
880:
881: Multiple `define_delay' expressions may be specified. In this case,
882: each such expression specifies different delay slot requirements and
883: there must be no insn for which tests in two `define_delay' expressions
884: are both true.
885:
886: For example, if we have a machine that requires one delay slot for
887: branches but two for calls, no delay slot can contain a branch or call
888: insn, and any valid insn in the delay slot for the branch can be
889: annulled if the branch is true, we might represent this as follows:
890:
891: (define_delay (eq_attr "type" "branch")
892: [(eq_attr "type" "!branch,call")
893: (eq_attr "type" "!branch,call")
894: (nil)])
895:
896: (define_delay (eq_attr "type" "call")
897: [(eq_attr "type" "!branch,call") (nil) (nil)
898: (eq_attr "type" "!branch,call") (nil) (nil)])
899:
900:
901: File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes
902:
903: Specifying Function Units
904: -------------------------
905:
906: On most RISC machines, there are instructions whose results are not
907: available for a specific number of cycles. Common cases are
908: instructions that load data from memory. On many machines, a pipeline
909: stall will result if the data is referenced too soon after the load
910: instruction.
911:
912: In addition, many newer microprocessors have multiple function
913: units, usually one for integer and one for floating point, and often
914: will incur pipeline stalls when a result that is needed is not yet
915: ready.
916:
917: The descriptions in this section allow the specification of how much
918: time must elapse between the execution of an instruction and the time
919: when its result is used. It also allows specification of when the
920: execution of an instruction will delay execution of similar instructions
921: due to function unit conflicts.
922:
923: For the purposes of the specifications in this section, a machine is
924: divided into "function units", each of which execute a specific class
925: of instructions in first-in-first-out order. Function units that
926: accept one instruction each cycle and allow a result to be used in the
927: succeeding instruction (usually via forwarding) need not be specified.
928: Classic RISC microprocessors will normally have a single function unit,
929: which we can call `memory'. The newer "superscalar" processors will
930: often have function units for floating point operations, usually at
931: least a floating point adder and multiplier.
932:
933: Each usage of a function units by a class of insns is specified with
934: a `define_function_unit' expression, which looks like this:
935:
936: (define_function_unit NAME MULTIPLICITY SIMULTANEITY
937: TEST READY-DELAY ISSUE-DELAY
938: [CONFLICT-LIST])
939:
940: NAME is a string giving the name of the function unit.
941:
942: MULTIPLICITY is an integer specifying the number of identical units
943: in the processor. If more than one unit is specified, they will be
944: scheduled independently. Only truly independent units should be
945: counted; a pipelined unit should be specified as a single unit. (The
946: only common example of a machine that has multiple function units for a
947: single instruction class that are truly independent and not pipelined
948: are the two multiply and two increment units of the CDC 6600.)
949:
950: SIMULTANEITY specifies the maximum number of insns that can be
951: executing in each instance of the function unit simultaneously or zero
952: if the unit is pipelined and has no limit.
953:
954: All `define_function_unit' definitions referring to function unit
955: NAME must have the same name and values for MULTIPLICITY and
956: SIMULTANEITY.
957:
958: TEST is an attribute test that selects the insns we are describing
959: in this definition. Note that an insn may use more than one function
960: unit and a function unit may be specified in more than one
961: `define_function_unit'.
962:
963: READY-DELAY is an integer that specifies the number of cycles after
964: which the result of the instruction can be used without introducing any
965: stalls.
966:
967: ISSUE-DELAY is an integer that specifies the number of cycles after
968: the instruction matching the TEST expression begins using this unit
969: until a subsequent instruction can begin. A cost of N indicates an N-1
970: cycle delay. A subsequent instruction may also be delayed if an
971: earlier instruction has a longer READY-DELAY value. This blocking
972: effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY,
973: and CONFLICT-LIST terms. For a normal non-pipelined function unit,
974: SIMULTANEITY is one, the unit is taken to block for the READY-DELAY
975: cycles of the executing insn, and smaller values of ISSUE-DELAY are
976: ignored.
977:
978: CONFLICT-LIST is an optional list giving detailed conflict costs for
979: this unit. If specified, it is a list of condition test expressions to
980: be applied to insns chosen to execute in NAME following the particular
981: insn matching TEST that is already executing in NAME. For each insn in
982: the list, ISSUE-DELAY specifies the conflict cost; for insns not in the
983: list, the cost is zero. If not specified, CONFLICT-LIST defaults to
984: all instructions that use the function unit.
985:
986: Typical uses of this vector are where a floating point function unit
987: can pipeline either single- or double-precision operations, but not
988: both, or where a memory unit can pipeline loads, but not stores, etc.
989:
990: As an example, consider a classic RISC machine where the result of a
991: load instruction is not available for two cycles (a single "delay"
992: instruction is required) and where only one load instruction can be
993: executed simultaneously. This would be specified as:
994:
995: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
996:
997: For the case of a floating point function unit that can pipeline
998: either single or double precision, but not both, the following could be
999: specified:
1000:
1001: (define_function_unit
1002: "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
1003: (define_function_unit
1004: "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
1005:
1006: *Note:* The scheduler attempts to avoid function unit conflicts and
1007: uses all the specifications in the `define_function_unit' expression.
1008: It has recently come to our attention that these specifications may not
1009: allow modeling of some of the newer "superscalar" processors that have
1010: insns using multiple pipelined units. These insns will cause a
1011: potential conflict for the second unit used during their execution and
1012: there is no way of representing that conflict. We welcome any examples
1013: of how function unit conflicts work in such processors and suggestions
1014: for their representation.
1015:
1016:
1017: File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top
1018:
1019: Target Description Macros
1020: *************************
1021:
1022: In addition to the file `MACHINE.md', a machine description includes
1023: a C header file conventionally given the name `MACHINE.h'. This header
1024: file defines numerous macros that convey the information about the
1025: target machine that does not fit into the scheme of the `.md' file.
1026: The file `tm.h' should be a link to `MACHINE.h'. The header file
1027: `config.h' includes `tm.h' and most compiler source files include
1028: `config.h'.
1029:
1030: * Menu:
1031:
1032: * Driver:: Controlling how the driver runs the compilation passes.
1033: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
1034: * Storage Layout:: Defining sizes and alignments of data.
1035: * Type Layout:: Defining sizes and properties of basic user data types.
1036: * Registers:: Naming and describing the hardware registers.
1037: * Register Classes:: Defining the classes of hardware registers.
1038: * Stack and Calling:: Defining which way the stack grows and by how much.
1039: * Varargs:: Defining the varargs macros.
1040: * Trampolines:: Code set up at run time to enter a nested function.
1041: * Library Calls:: Controlling how library routines are implicitly called.
1042: * Addressing Modes:: Defining addressing modes valid for memory operands.
1043: * Condition Code:: Defining how insns update the condition code.
1044: * Costs:: Defining relative costs of different operations.
1045: * Sections:: Dividing storage into text, data, and other sections.
1046: * PIC:: Macros for position independent code.
1047: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
1048: * Debugging Info:: Defining the format of debugging output.
1049: * Cross-compilation:: Handling floating point for cross-compilers.
1050: * Misc:: Everything else.
1051:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.