![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-8 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of
9: this manual provided the copyright notice and this permission notice
10: are preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL
28:
29: Conversions
30: ===========
31:
32: All conversions between machine modes must be represented by
33: explicit conversion operations. For example, an expression which is
34: the sum of a byte and a full word cannot be written as `(plus:SI
35: (reg:QI 34) (reg:SI 80))' because the `plus' operation requires two
36: operands of the same machine mode. Therefore, the byte-sized operand
37: is enclosed in a conversion operation, as in
38:
39: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
40:
41: The conversion operation is not a mere placeholder, because there
42: may be more than one way of converting from a given starting mode to
43: the desired final mode. The conversion operation code says how to do
44: it.
45:
46: For all conversion operations, X must not be `VOIDmode' because the
47: mode in which to do the conversion would not be known. The conversion
48: must either be done at compile-time or X must be placed into a
49: register.
50:
51: `(sign_extend:M X)'
52: Represents the result of sign-extending the value X to machine
53: mode M. M must be a fixed-point mode and X a fixed-point value
54: of a mode narrower than M.
55:
56: `(zero_extend:M X)'
57: Represents the result of zero-extending the value X to machine
58: mode M. M must be a fixed-point mode and X a fixed-point value
59: of a mode narrower than M.
60:
61: `(float_extend:M X)'
62: Represents the result of extending the value X to machine mode M.
63: M must be a floating point mode and X a floating point value of
64: a mode narrower than M.
65:
66: `(truncate:M X)'
67: Represents the result of truncating the value X to machine mode
68: M. M must be a fixed-point mode and X a fixed-point value of a
69: mode wider than M.
70:
71: `(float_truncate:M X)'
72: Represents the result of truncating the value X to machine mode
73: M. M must be a floating point mode and X a floating point value
74: of a mode wider than M.
75:
76: `(float:M X)'
77: Represents the result of converting fixed point value X, regarded
78: as signed, to floating point mode M.
79:
80: `(unsigned_float:M X)'
81: Represents the result of converting fixed point value X, regarded
82: as unsigned, to floating point mode M.
83:
84: `(fix:M X)'
85: When M is a fixed point mode, represents the result of converting
86: floating point value X to mode M, regarded as signed. How
87: rounding is done is not specified, so this operation may be used
88: validly in compiling C code only for integer-valued operands.
89:
90: `(unsigned_fix:M X)'
91: Represents the result of converting floating point value X to
92: fixed point mode M, regarded as unsigned. How rounding is done
93: is not specified.
94:
95: `(fix:M X)'
96: When M is a floating point mode, represents the result of
97: converting floating point value X (valid for mode M) to an
98: integer, still represented in floating point mode M, by rounding
99: towards zero.
100:
101:
102: File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
103:
104: Declarations
105: ============
106:
107: Declaration expression codes do not represent arithmetic operations
108: but rather state assertions about their operands.
109:
110: `(strict_low_part (subreg:M (reg:N R) 0))'
111: This expression code is used in only one context: operand 0 of a
112: `set' expression. In addition, the operand of this expression
113: must be a non-paradoxical `subreg' expression.
114:
115: The presence of `strict_low_part' says that the part of the
116: register which is meaningful in mode N, but is not part of mode
117: M, is not to be altered. Normally, an assignment to such a
118: subreg is allowed to have undefined effects on the rest of the
119: register when M is less than a word.
120:
121:
122: File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
123:
124: Side Effect Expressions
125: =======================
126:
127: The expression codes described so far represent values, not actions.
128: But machine instructions never produce values; they are meaningful
129: only for their side effects on the state of the machine. Special
130: expression codes are used to represent side effects.
131:
132: The body of an instruction is always one of these side effect codes;
133: the codes described above, which represent values, appear only as the
134: operands of these.
135:
136: `(set LVAL X)'
137: Represents the action of storing the value of X into the place
138: represented by LVAL. LVAL must be an expression representing a
139: place that can be stored in: `reg' (or `subreg' or
140: `strict_low_part'), `mem', `pc' or `cc0'.
141:
142: If LVAL is a `reg', `subreg' or `mem', it has a machine mode;
143: then X must be valid for that mode.
144:
145: If LVAL is a `reg' whose machine mode is less than the full width
146: of the register, then it means that the part of the register
147: specified by the machine mode is given the specified value and the
148: rest of the register receives an undefined value. Likewise, if
149: LVAL is a `subreg' whose machine mode is narrower than the mode
150: of the register, the rest of the register can be changed in an
151: undefined way.
152:
153: If LVAL is a `strict_low_part' of a `subreg', then the part of
154: the register specified by the machine mode of the `subreg' is
155: given the value X and the rest of the register is not changed.
156:
157: If LVAL is `(cc0)', it has no machine mode, and X may be either a
158: `compare' expression or a value that may have any mode. The
159: latter case represents a "test" instruction. The expression
160: `(set (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare
161: (reg:M N) (const_int 0)))'. Use the former expression to save
162: space during the compilation.
163:
164: If LVAL is `(pc)', we have a jump instruction, and the
165: possibilities for X are very limited. It may be a `label_ref'
166: expression (unconditional jump). It may be an `if_then_else'
167: (conditional jump), in which case either the second or the third
168: operand must be `(pc)' (for the case which does not jump) and the
169: other of the two must be a `label_ref' (for the case which does
170: jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
171: be a `reg' or a `mem'; these unusual patterns are used to
172: represent jumps through branch tables.
173:
174: If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
175: be `VOIDmode' and the mode of X must be valid for the mode of
176: LVAL.
177:
178: LVAL is customarily accessed with the `SET_DEST' macro and X with
179: the `SET_SRC' macro.
180:
181: `(return)'
182: As the sole expression in a pattern, represents a return from the
183: current function, on machines where this can be done with one
184: instruction, such as Vaxes. On machines where a multi-instruction
185: "epilogue" must be executed in order to return from the function,
186: returning is done by jumping to a label which precedes the
187: epilogue, and the `return' expression code is never used.
188:
189: Inside an `if_then_else' expression, represents the value to be
190: placed in `pc' to return to the caller.
191:
192: Note that an insn pattern of `(return)' is logically equivalent to
193: `(set (pc) (return))', but the latter form is never used.
194:
195: `(call FUNCTION NARGS)'
196: Represents a function call. FUNCTION is a `mem' expression whose
197: address is the address of the function to be called. NARGS is an
198: expression which can be used for two purposes: on some machines
199: it represents the number of bytes of stack argument; on others,
200: it represents the number of argument registers.
201:
202: Each machine has a standard machine mode which FUNCTION must
203: have. The machine description defines macro `FUNCTION_MODE' to
204: expand into the requisite mode name. The purpose of this mode is
205: to specify what kind of addressing is allowed, on machines where
206: the allowed kinds of addressing depend on the machine mode being
207: addressed.
208:
209: `(clobber X)'
210: Represents the storing or possible storing of an unpredictable,
211: undescribed value into X, which must be a `reg', `scratch' or
212: `mem' expression.
213:
214: One place this is used is in string instructions that store
215: standard values into particular hard registers. It may not be
216: worth the trouble to describe the values that are stored, but it
217: is essential to inform the compiler that the registers will be
218: altered, lest it attempt to keep data in them across the string
219: instruction.
220:
221: If X is `(mem:BLK (const_int 0))', it means that all memory
222: locations must be presumed clobbered.
223:
224: Note that the machine description classifies certain hard
225: registers as "call-clobbered". All function call instructions
226: are assumed by default to clobber these registers, so there is no
227: need to use `clobber' expressions to indicate this fact. Also,
228: each function call is assumed to have the potential to alter any
229: memory location, unless the function is declared `const'.
230:
231: If the last group of expressions in a `parallel' are each a
232: `clobber' expression whose arguments are `reg' or `match_scratch'
233: (*note RTL Template::.) expressions, the combiner phase can add
234: the appropriate `clobber' expressions to an insn it has
235: constructed when doing so will cause a pattern to be matched.
236:
237: This feature can be used, for example, on a machine that whose
238: multiply and add instructions don't use an MQ register but which
239: has an add-accumulate instruction that does clobber the MQ
240: register. Similarly, a combined instruction might require a
241: temporary register while the constituent instructions might not.
242:
243: When a `clobber' expression for a register appears inside a
244: `parallel' with other side effects, the register allocator
245: guarantees that the register is unoccupied both before and after
246: that insn. However, the reload phase may allocate a register
247: used for one of the inputs unless the `&' constraint is specified
248: for the selected alternative (*note Modifiers::.). You can
249: clobber either a specific hard register, a pseudo register, or a
250: `scratch' expression; in the latter two cases, GNU CC will
251: allocate a hard register that is available there for use as a
252: temporary.
253:
254: For instructions that require a temporary register, you should use
255: `scratch' instead of a pseudo-register because this will allow the
256: combiner phase to add the `clobber' when required. You do this by
257: coding (`clobber' (`match_scratch' ...)). If you do clobber a
258: pseudo register, use one which appears nowhere else--generate a
259: new one each time. Otherwise, you may confuse CSE.
260:
261: There is one other known use for clobbering a pseudo register in a
262: `parallel': when one of the input operands of the insn is also
263: clobbered by the insn. In this case, using the same pseudo
264: register in the clobber and elsewhere in the insn produces the
265: expected results.
266:
267: `(use X)'
268: Represents the use of the value of X. It indicates that the
269: value in X at this point in the program is needed, even though it
270: may not be apparent why this is so. Therefore, the compiler will
271: not attempt to delete previous instructions whose only effect is
272: to store a value in X. X must be a `reg' expression.
273:
274: During the delayed branch scheduling phase, X may be an insn.
275: This indicates that X previously was located at this place in the
276: code and its data dependencies need to be taken into account.
277: These `use' insns will be deleted before the delayed branch
278: scheduling phase exits.
279:
280: `(parallel [X0 X1 ...])'
281: Represents several side effects performed in parallel. The square
282: brackets stand for a vector; the operand of `parallel' is a
283: vector of expressions. X0, X1 and so on are individual side
284: effect expressions--expressions of code `set', `call', `return',
285: `clobber' or `use'.
286:
287: "In parallel" means that first all the values used in the
288: individual side-effects are computed, and second all the actual
289: side-effects are performed. For example,
290:
291: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
292: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
293:
294: says unambiguously that the values of hard register 1 and the
295: memory location addressed by it are interchanged. In both places
296: where `(reg:SI 1)' appears as a memory address it refers to the
297: value in register 1 *before* the execution of the insn.
298:
299: It follows that it is *incorrect* to use `parallel' and expect
300: the result of one `set' to be available for the next one. For
301: example, people sometimes attempt to represent a jump-if-zero
302: instruction this way:
303:
304: (parallel [(set (cc0) (reg:SI 34))
305: (set (pc) (if_then_else
306: (eq (cc0) (const_int 0))
307: (label_ref ...)
308: (pc)))])
309:
310: But this is incorrect, because it says that the jump condition
311: depends on the condition code value *before* this instruction,
312: not on the new value that is set by this instruction.
313:
314: Peephole optimization, which takes place together with final
315: assembly code output, can produce insns whose patterns consist of
316: a `parallel' whose elements are the operands needed to output the
317: resulting assembler code--often `reg', `mem' or constant
318: expressions. This would not be well-formed RTL at any other
319: stage in compilation, but it is ok then because no further
320: optimization remains to be done. However, the definition of the
321: macro `NOTICE_UPDATE_CC', if any, must deal with such insns if
322: you define any peephole optimizations.
323:
324: `(sequence [INSNS ...])'
325: Represents a sequence of insns. Each of the INSNS that appears
326: in the vector is suitable for appearing in the chain of insns, so
327: it must be an `insn', `jump_insn', `call_insn', `code_label',
328: `barrier' or `note'.
329:
330: A `sequence' RTX is never placed in an actual insn during RTL
331: generation. It represents the sequence of insns that result from
332: a `define_expand' *before* those insns are passed to `emit_insn'
333: to insert them in the chain of insns. When actually inserted,
334: the individual sub-insns are separated out and the `sequence' is
335: forgotten.
336:
337: After delay-slot scheduling is completed, an insn and all the
338: insns that reside in its delay slots are grouped together into a
339: `sequence'. The insn requiring the delay slot is the first insn
340: in the vector; subsequent insns are to be placed in the delay
341: slot.
342:
343: `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
344: indicate that a branch insn should be used that will
345: conditionally annul the effect of the insns in the delay slots.
346: In such a case, `INSN_FROM_TARGET_P' indicates that the insn is
347: from the target of the branch and should be executed only if the
348: branch is taken; otherwise the insn should be executed only if
349: the branch is not taken. *Note Delay Slots::.
350:
351: These expression codes appear in place of a side effect, as the
352: body of an insn, though strictly speaking they do not always describe
353: side effects as such:
354:
355: `(asm_input S)'
356: Represents literal assembler code as described by the string S.
357:
358: `(unspec [OPERANDS ...] INDEX)'
359: `(unspec [OPERANDS ...] INDEX)'
360: Represents a machine-specific operation on OPERANDS. INDEX
361: selects between multiple macine-specific operations.
362: `unspec_volatile' is used for volatile operations and operations
363: that may trap; `unspec' is used for other operations.
364:
365: These codes may appear themselves inside a `pattern' of an insn,
366: inside a `parallel', or inside an expression.
367:
368: `(addr_vec:M [LR0 LR1 ...])'
369: Represents a table of jump addresses. The vector elements LR0,
370: etc., are `label_ref' expressions. The mode M specifies how much
371: space is given to each address; normally M would be `Pmode'.
372:
373: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
374: Represents a table of jump addresses expressed as offsets from
375: BASE. The vector elements LR0, etc., are `label_ref' expressions
376: and so is BASE. The mode M specifies how much space is given to
377: each address-difference.
378:
379:
380: File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
381:
382: Embedded Side-Effects on Addresses
383: ==================================
384:
385: Four special side-effect expression codes appear as memory
386: addresses.
387:
388: `(pre_dec:M X)'
389: Represents the side effect of decrementing X by a standard amount
390: and represents also the value that X has after being decremented.
391: X must be a `reg' or `mem', but most machines allow only a
392: `reg'. M must be the machine mode for pointers on the machine in
393: use. The amount X is decremented by is the length in bytes of
394: the machine mode of the containing memory reference of which this
395: expression serves as the address. Here is an example of its use:
396:
397: (mem:DF (pre_dec:SI (reg:SI 39)))
398:
399: This says to decrement pseudo register 39 by the length of a
400: `DFmode' value and use the result to address a `DFmode' value.
401:
402: `(pre_inc:M X)'
403: Similar, but specifies incrementing X instead of decrementing it.
404:
405: `(post_dec:M X)'
406: Represents the same side effect as `pre_dec' but a different
407: value. The value represented here is the value X has before
408: being decremented.
409:
410: `(post_inc:M X)'
411: Similar, but specifies incrementing X instead of decrementing it.
412:
413: These embedded side effect expressions must be used with care.
414: Instruction patterns may not use them. Until the `flow' pass of the
415: compiler, they may occur only to represent pushes onto the stack. The
416: `flow' pass finds cases where registers are incremented or decremented
417: in one instruction and used as an address shortly before or after;
418: these cases are then transformed to use pre- or post-increment or
419: -decrement.
420:
421: If a register used as the operand of these expressions is used in
422: another address in an insn, the original value of the register is used.
423: Uses of the register outside of an address are not permitted within the
424: same insn as a use in an embedded side effect expression because such
425: insns behave differently on different machines and hence must be
426: treated as ambiguous and disallowed.
427:
428: An instruction that can be represented with an embedded side effect
429: could also be represented using `parallel' containing an additional
430: `set' to describe how the address register is altered. This is not
431: done because machines that allow these operations at all typically
432: allow them wherever a memory address is called for. Describing them as
433: additional parallel stores would require doubling the number of entries
434: in the machine description.
435:
436:
437: File: gcc.info, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL
438:
439: Assembler Instructions as Expressions
440: =====================================
441:
442: The RTX code `asm_operands' represents a value produced by a
443: user-specified assembler instruction. It is used to represent an
444: `asm' statement with arguments. An `asm' statement with a single
445: output operand, like this:
446:
447: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
448:
449: is represented using a single `asm_operands' RTX which represents the
450: value that is stored in `outputvar':
451:
452: (set RTX-FOR-OUTPUTVAR
453: (asm_operands "foo %1,%2,%0" "a" 0
454: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
455: [(asm_input:M1 "g")
456: (asm_input:M2 "di")]))
457:
458: Here the operands of the `asm_operands' RTX are the assembler template
459: string, the output-operand's constraint, the index-number of the
460: output operand among the output operands specified, a vector of input
461: operand RTX's, and a vector of input-operand modes and constraints.
462: The mode M1 is the mode of the sum `x+y'; M2 is that of `*z'.
463:
464: When an `asm' statement has multiple output values, its insn has
465: several such `set' RTX's inside of a `parallel'. Each `set' contains
466: a `asm_operands'; all of these share the same assembler template and
467: vectors, but each contains the constraint for the respective output
468: operand. They are also distinguished by the output-operand index
469: number, which is 0, 1, ... for successive output operands.
470:
471:
472: File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
473:
474: Insns
475: =====
476:
477: The RTL representation of the code for a function is a doubly-linked
478: chain of objects called "insns". Insns are expressions with special
479: codes that are used for no other purpose. Some insns are actual
480: instructions; others represent dispatch tables for `switch'
481: statements; others represent labels to jump to or various sorts of
482: declarative information.
483:
484: In addition to its own specific data, each insn must have a unique
485: id-number that distinguishes it from all other insns in the current
486: function (after delayed branch scheduling, copies of an insn with the
487: same id-number may be present in multiple places in a function, but
488: these copies will always be identical and will only appear inside a
489: `sequence'), and chain pointers to the preceding and following insns.
490: These three fields occupy the same position in every insn, independent
491: of the expression code of the insn. They could be accessed with
492: `XEXP' and `XINT', but instead three special macros are always used:
493:
494: `INSN_UID (I)'
495: Accesses the unique id of insn I.
496:
497: `PREV_INSN (I)'
498: Accesses the chain pointer to the insn preceding I. If I is the
499: first insn, this is a null pointer.
500:
501: `NEXT_INSN (I)'
502: Accesses the chain pointer to the insn following I. If I is the
503: last insn, this is a null pointer.
504:
505: The first insn in the chain is obtained by calling `get_insns'; the
506: last insn is the result of calling `get_last_insn'. Within the chain
507: delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers
508: must always correspond: if INSN is not the first insn,
509:
510: NEXT_INSN (PREV_INSN (INSN)) == INSN
511:
512: is always true and if INSN is not the last insn,
513:
514: PREV_INSN (NEXT_INSN (INSN)) == INSN
515:
516: is always true.
517:
518: After delay slot scheduling, some of the insns in the chain might be
519: `sequence' expressions, which contain a vector of insns. The value of
520: `NEXT_INSN' in all but the last of these insns is the next insn in the
521: vector; the value of `NEXT_INSN' of the last insn in the vector is the
522: same as the value of `NEXT_INSN' for the `sequence' in which it is
523: contained. Similar rules apply for `PREV_INSN'.
524:
525: This means that the above invariants are not necessarily true for
526: insns inside `sequence' expressions. Specifically, if INSN is the
527: first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn
528: containing the `sequence' expression, as is the value of `PREV_INSN
529: (NEXT_INSN (INSN))' is INSN is the last insn in the `sequence'
530: expression. You can use these expressions to find the containing
531: `sequence' expression.
532:
533: Every insn has one of the following six expression codes:
534:
535: `insn'
536: The expression code `insn' is used for instructions that do not
537: jump and do not do function calls. `sequence' expressions are
538: always contained in insns with code `insn' even if one of those
539: insns should jump or do function calls.
540:
541: Insns with code `insn' have four additional fields beyond the
542: three mandatory ones listed above. These four are described in a
543: table below.
544:
545: `jump_insn'
546: The expression code `jump_insn' is used for instructions that may
547: jump (or, more generally, may contain `label_ref' expressions).
548: If there is an instruction to return from the current function,
549: it is recorded as a `jump_insn'.
550:
551: `jump_insn' insns have the same extra fields as `insn' insns,
552: accessed in the same way and in addition contains a field
553: `JUMP_LABEL' which is defined once jump optimization has
554: completed.
555:
556: For simple conditional and unconditional jumps, this field
557: contains the `code_label' to which this insn will (possibly
558: conditionally) branch. In a more complex jump, `JUMP_LABEL'
559: records one of the labels that the insn refers to; the only way
560: to find the others is to scan the entire body of the insn.
561:
562: Return insns count as jumps, but since they do not refer to any
563: labels, they have zero in the `JUMP_LABEL' field.
564:
565: `call_insn'
566: The expression code `call_insn' is used for instructions that may
567: do function calls. It is important to distinguish these
568: instructions because they imply that certain registers and memory
569: locations may be altered unpredictably.
570:
571: A `call_insn' insn may be preceeded by insns that contain a single
572: `use' expression and be followed by insns the contain a single
573: `clobber' expression. If so, these `use' and `clobber'
574: expressions are treated as being part of the function call.
575: There must not even be a `note' between the `call_insn' and the
576: `use' or `clobber' insns for this special treatment to take
577: place. This is somewhat of a kludge and will be removed in a
578: later version of GNU CC.
579:
580: `call_insn' insns have the same extra fields as `insn' insns,
581: accessed in the same way.
582:
583: `code_label'
584: A `code_label' insn represents a label that a jump insn can jump
585: to. It contains two special fields of data in addition to the
586: three standard ones. `CODE_LABEL_NUMBER' is used to hold the
587: "label number", a number that identifies this label uniquely
588: among all the labels in the compilation (not just in the current
589: function). Ultimately, the label is represented in the assembler
590: output as an assembler label, usually of the form `LN' where N is
591: the label number.
592:
593: When a `code_label' appears in an RTL expression, it normally
594: appears within a `label_ref' which represents the address of the
595: label, as a number.
596:
597: The field `LABEL_NUSES' is only defined once the jump optimization
598: phase is completed and contains the number of times this label is
599: referenced in the current function.
600:
601: `barrier'
602: Barriers are placed in the instruction stream when control cannot
603: flow past them. They are placed after unconditional jump
604: instructions to indicate that the jumps are unconditional and
605: after calls to `volatile' functions, which do not return (e.g.,
606: `exit'). They contain no information beyond the three standard
607: fields.
608:
609: `note'
610: `note' insns are used to represent additional debugging and
611: declarative information. They contain two nonstandard fields, an
612: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
613: string accessed with `NOTE_SOURCE_FILE'.
614:
615: If `NOTE_LINE_NUMBER' is positive, the note represents the
616: position of a source line and `NOTE_SOURCE_FILE' is the source
617: file name that the line came from. These notes control
618: generation of line number data in the assembler output.
619:
620: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
621: code with one of the following values (and `NOTE_SOURCE_FILE'
622: must contain a null pointer):
623:
624: `NOTE_INSN_DELETED'
625: Such a note is completely ignorable. Some passes of the
626: compiler delete insns by altering them into notes of this
627: kind.
628:
629: `NOTE_INSN_BLOCK_BEG'
630: `NOTE_INSN_BLOCK_END'
631: These types of notes indicate the position of the beginning
632: and end of a level of scoping of variable names. They
633: control the output of debugging information.
634:
635: `NOTE_INSN_LOOP_BEG'
636: `NOTE_INSN_LOOP_END'
637: These types of notes indicate the position of the beginning
638: and end of a `while' or `for' loop. They enable the loop
639: optimizer to find loops quickly.
640:
641: `NOTE_INSN_LOOP_CONT'
642: Appears at the place in a loop that `continue' statements
643: jump to.
644:
645: `NOTE_INSN_LOOP_VTOP'
646: This note indicates the place in a loop where the exit test
647: begins for those loops in which the exit test has been
648: duplicated. This position becomes another virtual start of
649: the loop when considering loop invariants.
650:
651: `NOTE_INSN_FUNCTION_END'
652: Appears near the end of the function body, just before the
653: label that `return' statements jump to (on machine where a
654: single instruction does not suffice for returning). This
655: note may be deleted by jump optimization.
656:
657: `NOTE_INSN_SETJMP'
658: Appears following each call to `setjmp' or a related
659: function.
660:
661: These codes are printed symbolically when they appear in
662: debugging dumps.
663:
664: The machine mode of an insn is normally `VOIDmode', but some phases
665: use the mode for various purposes; for example, the reload pass sets
666: it to `HImode' if the insn needs reloading but not register
667: elimination and `QImode' if both are required. The common
668: subexpression elimination pass sets the mode of an insn to `QImode'
669: when it is the first insn in a block that has already been processed.
670:
671: Here is a table of the extra fields of `insn', `jump_insn' and
672: `call_insn' insns:
673:
674: `PATTERN (I)'
675: An expression for the side effect performed by this insn. This
676: must be one of the following codes: `set', `call', `use',
677: `clobber', `return', `asm_input', `asm_output', `addr_vec',
678: `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', or
679: `parallel'. If it is a `parallel', each element of the
680: `parallel' must be one these codes, except that `parallel'
681: expressions cannot be nested and `addr_vec' and `addr_diff_vec'
682: are not permitted inside a `parallel' expression.
683:
684: `INSN_CODE (I)'
685: An integer that says which pattern in the machine description
686: matches this insn, or -1 if the matching has not yet been
687: attempted.
688:
689: Such matching is never attempted and this field remains -1 on an
690: insn whose pattern consists of a single `use', `clobber',
691: `asm_input', `addr_vec' or `addr_diff_vec' expression.
692:
693: Matching is also never attempted on insns that result from an
694: `asm' statement. These contain at least one `asm_operands'
695: expression. The function `asm_noperands' returns a non-negative
696: value for such insns.
697:
698: In the debugging output, this field is printed as a number
699: followed by a symbolic representation that locates the pattern in
700: the `md' file as some small positive or negative offset from a
701: named pattern.
702:
703: `LOG_LINKS (I)'
704: A list (chain of `insn_list' expressions) giving information about
705: dependencies between instructions within a basic block. Neither
706: a jump nor a label may come between the related insns.
707:
708: `REG_NOTES (I)'
709: A list (chain of `expr_list' and `insn_list' expressions) giving
710: miscellaneous information about the insn. It is often information
711: pertaining to the registers used in this insn.
712:
713: The `LOG_LINKS' field of an insn is a chain of `insn_list'
714: expressions. Each of these has two operands: the first is an insn,
715: and the second is another `insn_list' expression (the next one in the
716: chain). The last `insn_list' in the chain has a null pointer as
717: second operand. The significant thing about the chain is which insns
718: appear in it (as first operands of `insn_list' expressions). Their
719: order is not significant.
720:
721: This list is originally set up by the flow analysis pass; it is a
722: null pointer until then. Flow only adds links for those data
723: dependencies which can be used for instruction combination. For each
724: insn, the flow analysis pass adds a link to insns which store into
725: registers values that are used for the first time in this insn. The
726: instruction scheduling pass adds extra links so that every dependence
727: will be represented. Links represent data dependencies,
728: antidependencies and output dependencies; the machine mode of the link
729: distinguishes these three types: antidependencies have mode
730: `REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and
731: data dependencies have mode `VOIDmode'.
732:
733: The `REG_NOTES' field of an insn is a chain similar to the
734: `LOG_LINKS' field but it includes `expr_list' expressions in addition
735: to `insn_list' expressions. There are several kinds of register
736: notes, which are distinguished by the machine mode, which in a
737: register note is really understood as being an `enum reg_note'. The
738: first operand OP of the note is data whose meaning depends on the kind
739: of note.
740:
741: The macro `REG_NOTE_KIND (X)' returns the the kind of register
742: note. Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)'
743: sets the register note type of X to be NEWKIND.
744:
745: Register notes are of three classes: They may say something about an
746: input to an insn, they may say something about an output of an insn, or
747: they may create a linkage between two insns. There are also a set of
748: values that are only used in `LOG_LINKS'.
749:
750: These register notes annotate inputs to an insn:
751:
752: `REG_DEAD'
753: The value in OP dies in this insn; that is to say, altering the
754: value immediately after this insn would not affect the future
755: behavior of the program.
756:
757: This does not necessarily mean that the register OP has no useful
758: value after this insn since it may also be an output of the insn.
759: In such a case, however, a `REG_DEAD' note would be redundant
760: and is usually not present until after the reload pass, but no
761: code relies on this fact.
762:
763: `REG_INC'
764: The register OP is incremented (or decremented; at this level
765: there is no distinction) by an embedded side effect inside this
766: insn. This means it appears in a `post_inc', `pre_inc',
767: `post_dec' or `pre_dec' expression.
768:
769: `REG_NONNEG'
770: The register OP is known to have a nonnegative value when this
771: insn is reached. This is used so that decrement and branch until
772: zero instructions, such as the m68k dbra, can be matched.
773:
774: The `REG_NONNEG' note is added to insns only if the machine
775: description contains a pattern named
776: `decrement_and_branch_until_zero'.
777:
778: `REG_NO_CONFLICT'
779: This insn does not cause a conflict between OP and the item being
780: set by this insn even though it might appear that it does. In
781: other words, if the destination register and OP could otherwise
782: be assigned the same register, this insn does not prevent that
783: assignment.
784:
785: Insns with this note are usually part of a block that begins with
786: a `clobber' insn specifying a multi-word pseudo register (which
787: will be the output of the block), a group of insns that each set
788: one word of the value and have the `REG_NO_CONFLICT' note
789: attached, and a final insn that copies the output to itself with
790: an attached `REG_EQUAL' note giving the expression being
791: computed. This block is encapsulated with `REG_LIBCALL' and
792: `REG_RETVAL' notes on the first and last insns, respectively.
793:
794: `REG_LABEL'
795: This insn uses OP, a `code_label', but is not a `jump_insn'. The
796: presence of this note allows jump optimization to be aware that
797: OP is, in fact, being used.
798:
799: The following notes describe attributes of outputs of an insn:
800:
801: `REG_EQUIV'
802: `REG_EQUAL'
803: This note is only valid on an insn that sets only one register and
804: indicates that that register will be equal to OP at run time; the
805: scope of this equivalence differs between the two types of notes.
806: The value which the insn explicitly copies into the register may
807: look different from OP, but they will be equal at run time. If
808: the output of the single `set' is a `strict_low_part' expression,
809: the note refers to the register that is contained in `SUBREG_REG'
810: of the `subreg' expression.
811:
812: For `REG_EQUIV', the register is equivalent to OP throughout the
813: entire function, and could validly be replaced in all its
814: occurrences by OP. ("Validly" here refers to the data flow of
815: the program; simple replacement may make some insns invalid.) For
816: example, when a constant is loaded into a register that is never
817: assigned any other value, this kind of note is used.
818:
819: When a parameter is copied into a pseudo-register at entry to a
820: function, a note of this kind records that the register is
821: equivalent to the stack slot where the parameter was passed.
822: Although in this case the register may be set by other insns, it
823: is still valid to replace the register by the stack slot
824: throughout the function.
825:
826: In the case of `REG_EQUAL', the register that is set by this insn
827: will be equal to OP at run time at the end of this insn but not
828: necessarily elsewhere in the function. In this case, OP is
829: typically an arithmetic expression. For example, when a sequence
830: of insns such as a library call is used to perform an arithmetic
831: operation, this kind of note is attached to the insn that
832: produces or copies the final value.
833:
834: These two notes are used in different ways by the compiler passes.
835: `REG_EQUAL' is used by passes prior to register allocation (such
836: as common subexpression elimination and loop optimization) to
837: tell them how to think of that value. `REG_EQUIV' notes are used
838: by register allocation to indicate that there is an available
839: substitute expression (either a constant or a `mem' expression
840: for the location of a parameter on the stack) that may be used in
841: place of a register if insufficient registers are available.
842:
843: Except for stack homes for parameters, which are indicated by a
844: `REG_EQUIV' note and are not useful to the early optimization
845: passes and pseudo registers that are equivalent to a memory
846: location throughout there entire life, which is not detected
847: until later in the compilation, all equivalences are initially
848: indicated by an attached `REG_EQUAL' note. In the early stages
849: of register allocation, a `REG_EQUAL' note is changed into a
850: `REG_EQUIV' note if OP is a constant and the insn represents the
851: only set of its destination register.
852:
853: Thus, compiler passes prior to register allocation need only
854: check for `REG_EQUAL' notes and passes subsequent to register
855: allocation need only check for `REG_EQUIV' notes.
856:
857: `REG_UNUSED'
858: The register OP being set by this insn will not be used in a
859: subsequent insn. This differs from a `REG_DEAD' note, which
860: indicates that the value in an input will not be used
861: subsequently. These two notes are independent; both may be
862: present for the same register.
863:
864: `REG_WAS_0'
865: The single output of this insn contained zero before this insn.
866: OP is the insn that set it to zero. You can rely on this note if
867: it is present and OP has not been deleted or turned into a `note';
868: its absence implies nothing.
869:
870: These notes describe linkages between insns. They occur in pairs:
871: one insn has one of a pair of notes that points to a second insn,
872: which has the inverse note pointing back to the first insn.
873:
874: `REG_RETVAL'
875: This insn copies the value of a multi-insn sequence (for example,
876: a library call), and OP is the first insn of the sequence (for a
877: library call, the first insn that was generated to set up the
878: arguments for the library call).
879:
880: Loop optimization uses this note to treat such a sequence as a
881: single operation for code motion purposes and flow analysis uses
882: this note to delete such sequences whose results are dead.
883:
884: A `REG_EQUAL' note will also usually be attached to this insn to
885: provide the expression being computed by the sequence.
886:
887: `REG_LIBCALL'
888: This is the inverse of `REG_RETVAL': it is placed on the first
889: insn of a multi-insn sequence, and it points to the last one.
890:
891: `REG_CC_SETTER'
892: `REG_CC_USER'
893: On machines that use `cc0', the insns which set and use `cc0' set
894: and use `cc0' are adjacent. However, when branch delay slot
895: filling is done, this may no longer be true. In this case a
896: `REG_CC_USER' note will be placed on the insn setting `cc0' to
897: point to the insn using `cc0' and a `REG_CC_SETTER' note will be
898: placed on the insn using `cc0' to point to the insn setting `cc0'.
899:
900: These values are only used in the `LOG_LINKS' field, and indicate
901: the type of dependency that each link represents. Links which indicate
902: a data dependence (a read after write dependence) do not use any code,
903: they simply have mode `VOIDmode', and are printed without any
904: descriptive text.
905:
906: `REG_DEP_ANTI'
907: This indicates an anti dependence (a write after read dependence).
908:
909: `REG_DEP_OUTPUT'
910: This indicates an output dependence (a write after write
911: dependence).
912:
913: For convenience, the machine mode in an `insn_list' or `expr_list'
914: is printed using these symbolic codes in debugging dumps.
915:
916: The only difference between the expression codes `insn_list' and
917: `expr_list' is that the first operand of an `insn_list' is assumed to
918: be an insn and is printed in debugging dumps as the insn's unique id;
919: the first operand of an `expr_list' is printed in the ordinary way as
920: an expression.
921:
922:
923: File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
924:
925: RTL Representation of Function-Call Insns
926: =========================================
927:
928: Insns that call subroutines have the RTL expression code
929: `call_insn'. These insns must satisfy special rules, and their bodies
930: must use a special RTL expression code, `call'.
931:
932: A `call' expression has two operands, as follows:
933:
934: (call (mem:FM ADDR) NBYTES)
935:
936: Here NBYTES is an operand that represents the number of bytes of
937: argument data being passed to the subroutine, FM is a machine mode
938: (which must equal as the definition of the `FUNCTION_MODE' macro in
939: the machine description) and ADDR represents the address of the
940: subroutine.
941:
942: For a subroutine that returns no value, the `call' expression as
943: shown above is the entire body of the insn, except that the insn might
944: also contain `use' or `clobber' expressions.
945:
946: For a subroutine that returns a value whose mode is not `BLKmode',
947: the value is returned in a hard register. If this register's number is
948: R, then the body of the call insn looks like this:
949:
950: (set (reg:M R)
951: (call (mem:FM ADDR) NBYTES))
952:
953: This RTL expression makes it clear (to the optimizer passes) that the
954: appropriate register receives a useful value in this insn.
955:
956: When a subroutine returns a `BLKmode' value, it is handled by
957: passing to the subroutine the address of a place to store the value.
958: So the call insn itself does not "return" any value, and it has the
959: same RTL form as a call that returns nothing.
960:
961: On some machines, the call instruction itself clobbers some
962: register, for example to contain the return address. `call_insn' insns
963: on these machines should have a body which is a `parallel' that
964: contains both the `call' expression and `clobber' expressions that
965: indicate which registers are destroyed. Similarly, if the call
966: instruction requires some register other than the stack pointer that
967: is not explicitly mentioned it its RTL, a `use' subexpression should
968: mention that register.
969:
970: Functions that are called are assumed to modify all registers
971: listed in the configuration macro `CALL_USED_REGISTERS' (*note
972: Register Basics::.) and, with the exception of `const' functions and
973: library calls, to modify all of memory.
974:
975: Insns containing just `use' expressions directly precede the
976: `call_insn' insn to indicate which registers contain inputs to the
977: function. Similarly, if registers other than those in
978: `CALL_USED_REGISTERS' are clobbered by the called function, insns
979: containing a single `clobber' follow immediately after the call to
980: indicate which registers.
981:
982:
983: File: gcc.info, Node: Sharing, Prev: Calls, Up: RTL
984:
985: Structure Sharing Assumptions
986: =============================
987:
988: The compiler assumes that certain kinds of RTL expressions are
989: unique; there do not exist two distinct objects representing the same
990: value. In other cases, it makes an opposite assumption: that no RTL
991: expression object of a certain kind appears in more than one place in
992: the containing structure.
993:
994: These assumptions refer to a single function; except for the RTL
995: objects that describe global variables and external functions, and a
996: few standard objects such as small integer constants, no RTL objects
997: are common to two functions.
998:
999: * Each pseudo-register has only a single `reg' object to represent
1000: it, and therefore only a single machine mode.
1001:
1002: * For any symbolic label, there is only one `symbol_ref' object
1003: referring to it.
1004:
1005: * There is only one `const_int' expression with value 0, only one
1006: with value 1, and only one with value -1. Some other integer
1007: values are also stored uniquely.
1008:
1009: * There is only one `pc' expression.
1010:
1011: * There is only one `cc0' expression.
1012:
1013: * There is only one `const_double' expression with value 0 for each
1014: floating point mode. Likewise for values 1 and 2.
1015:
1016: * No `label_ref' or `scratch' appears in more than one place in the
1017: RTL structure; in other words, it is safe to do a tree-walk of all
1018: the insns in the function and assume that each time a `label_ref'
1019: or `scratch' is seen it is distinct from all others that are seen.
1020:
1021: * Only one `mem' object is normally created for each static
1022: variable or stack slot, so these objects are frequently shared in
1023: all the places they appear. However, separate but equal objects
1024: for these variables are occasionally made.
1025:
1026: * When a single `asm' statement has multiple output operands, a
1027: distinct `asm_operands' expression is made for each output
1028: operand. However, these all share the vector which contains the
1029: sequence of input operands. This sharing is used later on to
1030: test whether two `asm_operands' expressions come from the same
1031: statement, so all optimizations must carefully preserve the
1032: sharing if they copy the vector at all.
1033:
1034: * No RTL object appears in more than one place in the RTL structure
1035: except as described above. Many passes of the compiler rely on
1036: this by assuming that they can modify RTL objects in place
1037: without unwanted side-effects on other insns.
1038:
1039: * During initial RTL generation, shared structure is freely
1040: introduced. After all the RTL for a function has been generated,
1041: all shared structure is copied by `unshare_all_rtl' in
1042: `emit-rtl.c', after which the above rules are guaranteed to be
1043: followed.
1044:
1045: * During the combiner pass, shared structure within an insn can
1046: exist temporarily. However, the shared structure is copied
1047: before the combiner is finished with the insn. This is done by
1048: calling `copy_rtx_if_shared', which is a subroutine of
1049: `unshare_all_rtl'.
1050:
1051:
1052: File: gcc.info, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top
1053:
1054: Machine Descriptions
1055: ********************
1056:
1057: A machine description has two parts: a file of instruction patterns
1058: (`.md' file) and a C header file of macro definitions.
1059:
1060: The `.md' file for a target machine contains a pattern for each
1061: instruction that the target machine supports (or at least each
1062: instruction that is worth telling the compiler about). It may also
1063: contain comments. A semicolon causes the rest of the line to be a
1064: comment, unless the semicolon is inside a quoted string.
1065:
1066: See the next chapter for information on the C header file.
1067:
1068: * Menu:
1069:
1070: * Patterns:: How to write instruction patterns.
1071: * Example:: An explained example of a `define_insn' pattern.
1072: * RTL Template:: The RTL template defines what insns match a pattern.
1073: * Output Template:: The output template says how to make assembler code
1074: from such an insn.
1075: * Output Statement:: For more generality, write C code to output
1076: the assembler code.
1077: * Constraints:: When not all operands are general operands.
1078: * Standard Names:: Names mark patterns to use for code generation.
1079: * Pattern Ordering:: When the order of patterns makes a difference.
1080: * Dependent Patterns:: Having one pattern may make you need another.
1081: * Jump Patterns:: Special considerations for patterns for jump insns.
1082: * Insn Canonicalizations::Canonicalization of Instructions
1083: * Peephole Definitions::Defining machine-specific peephole optimizations.
1084: * Expander Definitions::Generating a sequence of several RTL insns
1085: for a standard operation.
1086: * Insn Splitting:: Splitting Instructions into Multiple Instructions
1087: * Insn Attributes:: Specifying the value of attributes for generated insns.
1088:
1089:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.