![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-4 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled ``GNU CC General Public License'' is
15: included exactly as in the original, and provided that the entire
16: resulting derived work is distributed under the terms of a permission
17: notice 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 CC 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:
28: File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL
29:
30: Comparison Operations
31: =====================
32:
33: Comparison operators test a relation on two operands and are
34: considered to represent the value 1 if the relation holds, or zero if
35: it does not. The mode of the comparison is determined by the
36: operands; they must both be valid for a common machine mode. A
37: comparison with both operands constant would be invalid as the
38: machine mode could not be deduced from it, but such a comparison
39: should never exist in RTL due to constant folding.
40:
41: Inequality comparisons come in two flavors, signed and unsigned.
42: Thus, there are distinct expression codes `gt' and `gtu' for signed
43: and unsigned greater-than. These can produce different results for
44: the same pair of integer values: for example, 1 is signed
45: greater-than -1 but not unsigned greater-than, because -1 when
46: regarded as unsigned is actually `0xffffffff' which is greater than 1.
47:
48: The signed comparisons are also used for floating point values.
49: Floating point comparisons are distinguished by the machine modes of
50: the operands.
51:
52: The comparison operators may be used to compare the condition codes
53: `(cc0)' against zero, as in `(eq (cc0) (const_int 0))'. Such a
54: construct actually refers to the result of the preceding instruction
55: in which the condition codes were set. The above example stands for
56: 1 if the condition codes were set to say ``zero'' or ``equal'', 0
57: otherwise. Although the same comparison operators are used for this
58: as may be used in other contexts on actual data, no confusion can
59: result since the machine description would never allow both kinds of
60: uses in the same context.
61:
62: `(eq X Y)'
63: 1 if the values represented by X and Y are equal, otherwise 0.
64:
65: `(ne X Y)'
66: 1 if the values represented by X and Y are not equal, otherwise 0.
67:
68: `(gt X Y)'
69: 1 if the X is greater than Y. If they are fixed-point, the
70: comparison is done in a signed sense.
71:
72: `(gtu X Y)'
73: Like `gt' but does unsigned comparison, on fixed-point numbers
74: only.
75:
76: `(lt X Y)'
77: `(ltu X Y)'
78: Like `gt' and `gtu' but test for ``less than''.
79:
80: `(ge X Y)'
81: `(geu X Y)'
82: Like `gt' and `gtu' but test for ``greater than or equal''.
83:
84: `(le X Y)'
85: `(leu X Y)'
86: Like `gt' and `gtu' but test for ``less than or equal''.
87:
88: `(if_then_else COND THEN ELSE)'
89: This is not a comparison operation but is listed here because it
90: is always used in conjunction with a comparison operation. To
91: be precise, COND is a comparison expression. This expression
92: represents a choice, according to COND, between the value
93: represented by THEN and the one represented by ELSE.
94:
95: On most machines, `if_then_else' expressions are valid only to
96: express conditional jumps.
97:
98:
99:
100: File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL
101:
102: Bit-fields
103: ==========
104:
105: Special expression codes exist to represent bit-field instructions.
106: These types of expressions are lvalues in RTL; they may appear on the
107: left side of a assignment, indicating insertion of a value into the
108: specified bit field.
109:
110: `(sign_extract:SI LOC SIZE POS)'
111: This represents a reference to a sign-extended bit-field
112: contained or starting in LOC (a memory or register reference).
113: The bit field is SIZE bits wide and starts at bit POS. The
114: compilation option `BITS_BIG_ENDIAN' says which end of the
115: memory unit POS counts from.
116:
117: Which machine modes are valid for LOC depends on the machine,
118: but typically LOC should be a single byte when in memory or a
119: full word in a register.
120:
121: `(zero_extract:SI LOC SIZE POS)'
122: Like `sign_extract' but refers to an unsigned or zero-extended
123: bit field. The same sequence of bits are extracted, but they
124: are filled to an entire word with zeros instead of by
125: sign-extension.
126:
127:
128:
129: File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL
130:
131: Conversions
132: ===========
133:
134: All conversions between machine modes must be represented by explicit
135: conversion operations. For example, an expression which is the sum
136: of a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
137: (reg:SI 80))' because the `plus' operation requires two operands of
138: the same machine mode. Therefore, the byte-sized operand is enclosed
139: in a conversion operation, as in
140:
141: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
142:
143: The conversion operation is not a mere placeholder, because there may
144: be more than one way of converting from a given starting mode to the
145: desired final mode. The conversion operation code says how to do it.
146:
147: `(sign_extend:M X)'
148: Represents the result of sign-extending the value X to machine
149: mode M. M must be a fixed-point mode and X a fixed-point value
150: of a mode narrower than M.
151:
152: `(zero_extend:M X)'
153: Represents the result of zero-extending the value X to machine
154: mode M. M must be a fixed-point mode and X a fixed-point value
155: of a mode narrower than M.
156:
157: `(float_extend:M X)'
158: Represents the result of extending the value X to machine mode
159: M. M must be a floating point mode and X a floating point value
160: of a mode narrower than M.
161:
162: `(truncate:M X)'
163: Represents the result of truncating the value X to machine mode
164: M. M must be a fixed-point mode and X a fixed-point value of a
165: mode wider than M.
166:
167: `(float_truncate:M X)'
168: Represents the result of truncating the value X to machine mode
169: M. M must be a floating point mode and X a floating point value
170: of a mode wider than M.
171:
172: `(float:M X)'
173: Represents the result of converting fixed point value X,
174: regarded as signed, to floating point mode M.
175:
176: `(unsigned_float:M X)'
177: Represents the result of converting fixed point value X,
178: regarded as unsigned, to floating point mode M.
179:
180: `(fix:M X)'
181: When M is a fixed point mode, represents the result of
182: converting floating point value X to mode M, regarded as signed.
183: How rounding is done is not specified, so this operation may be
184: used validly in compiling C code only for integer-valued operands.
185:
186: `(unsigned_fix:M X)'
187: Represents the result of converting floating point value X to
188: fixed point mode M, regarded as unsigned. How rounding is done
189: is not specified.
190:
191: `(fix:M X)'
192: When M is a floating point mode, represents the result of
193: converting floating point value X (valid for mode M) to an
194: integer, still represented in floating point mode M, by rounding
195: towards zero.
196:
197:
198:
199: File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
200:
201: Declarations
202: ============
203:
204: Declaration expression codes do not represent arithmetic operations
205: but rather state assertions about their operands.
206:
207: `(strict_low_part (subreg:M (reg:N R) 0))'
208: This expression code is used in only one context: operand 0 of a
209: `set' expression. In addition, the operand of this expression
210: must be a `subreg' expression.
211:
212: The presence of `strict_low_part' says that the part of the
213: register which is meaningful in mode N, but is not part of mode
214: M, is not to be altered. Normally, an assignment to such a
215: subreg is allowed to have undefined effects on the rest of the
216: register when M is less than a word.
217:
218:
219:
220: File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
221:
222: Side Effect Expressions
223: =======================
224:
225: The expression codes described so far represent values, not actions.
226: But machine instructions never produce values; they are meaningful
227: only for their side effects on the state of the machine. Special
228: expression codes are used to represent side effects.
229:
230: The body of an instruction is always one of these side effect codes;
231: the codes described above, which represent values, appear only as the
232: operands of these.
233:
234: `(set LVAL X)'
235: Represents the action of storing the value of X into the place
236: represented by LVAL. LVAL must be an expression representing a
237: place that can be stored in: `reg' (or `subreg' or
238: `strict_low_part'), `mem', `pc' or `cc0'.
239:
240: If LVAL is a `reg', `subreg' or `mem', it has a machine mode;
241: then X must be valid for that mode.
242:
243: If LVAL is a `reg' whose machine mode is less than the full
244: width of the register, then it means that the part of the
245: register specified by the machine mode is given the specified
246: value and the rest of the register receives an undefined value.
247: Likewise, if LVAL is a `subreg' whose machine mode is narrower
248: than `SImode', the rest of the register can be changed in an
249: undefined way.
250:
251: If LVAL is a `strict_low_part' of a `subreg', then the part of
252: the register specified by the machine mode of the `subreg' is
253: given the value X and the rest of the register is not changed.
254:
255: If LVAL is `(cc0)', it has no machine mode, and X may have any
256: mode. This represents a ``test'' or ``compare'' instruction.
257:
258: If LVAL is `(pc)', we have a jump instruction, and the
259: possibilities for X are very limited. It may be a `label_ref'
260: expression (unconditional jump). It may be an `if_then_else'
261: (conditional jump), in which case either the second or the third
262: operand must be `(pc)' (for the case which does not jump) and
263: the other of the two must be a `label_ref' (for the case which
264: does jump). X may also be a `mem' or `(plus:SI (pc) Y)', where
265: Y may be a `reg' or a `mem'; these unusual patterns are used to
266: represent jumps through branch tables.
267:
268: `(return)'
269: Represents a return from the current function, on machines where
270: this can be done with one instruction, such as Vaxes. On
271: machines where a multi-instruction ``epilogue'' must be executed
272: in order to return from the function, returning is done by
273: jumping to a label which precedes the epilogue, and the `return'
274: expression code is never used.
275:
276: `(call FUNCTION NARGS)'
277: Represents a function call. FUNCTION is a `mem' expression
278: whose address is the address of the function to be called.
279: NARGS is an expression which can be used for two purposes: on
280: some machines it represents the number of bytes of stack
281: argument; on others, it represents the number of argument
282: registers.
283:
284: Each machine has a standard machine mode which FUNCTION must
285: have. The machine description defines macro `FUNCTION_MODE' to
286: expand into the requisite mode name. The purpose of this mode
287: is to specify what kind of addressing is allowed, on machines
288: where the allowed kinds of addressing depend on the machine mode
289: being addressed.
290:
291: `(clobber X)'
292: Represents the storing or possible storing of an unpredictable,
293: undescribed value into X, which must be a `reg' or `mem'
294: expression.
295:
296: One place this is used is in string instructions that store
297: standard values into particular hard registers. It may not be
298: worth the trouble to describe the values that are stored, but it
299: is essential to inform the compiler that the registers will be
300: altered, lest it attempt to keep data in them across the string
301: instruction.
302:
303: X may also be null--a null C pointer, no expression at all.
304: Such a `(clobber (null))' expression means that all memory
305: locations must be presumed clobbered.
306:
307: Note that the machine description classifies certain hard
308: registers as ``call-clobbered''. All function call instructions
309: are assumed by default to clobber these registers, so there is
310: no need to use `clobber' expressions to indicate this fact.
311: Also, each function call is assumed to have the potential to
312: alter any memory location.
313:
314: `(use X)'
315: Represents the use of the value of X. It indicates that the
316: value in X at this point in the program is needed, even though
317: it may not be apparent why this is so. Therefore, the compiler
318: will not attempt to delete instructions whose only effect is to
319: store a value in X. X must be a `reg' expression.
320:
321: `(parallel [X0 X1 ...])'
322: Represents several side effects performed in parallel. The
323: square brackets stand for a vector; the operand of `parallel' is
324: a vector of expressions. X0, X1 and so on are individual side
325: effects--expressions of code `set', `call', `return', `clobber'
326: or `use'.
327:
328: ``In parallel'' means that first all the values used in the
329: individual side-effects are computed, and second all the actual
330: side-effects are performed. For example,
331:
332: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
333: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
334:
335: says unambiguously that the values of hard register 1 and the
336: memory location addressed by it are interchanged. In both
337: places where `(reg:SI 1)' appears as a memory address it refers
338: to the value in register 1 *before* the execution of the
339: instruction.
340:
341: Peephole optimization, which takes place in the last
342: jump-optimization pass, can produce insns whose patterns consist
343: of a `parallel' whose elements are the operands needed to output
344: the resulting assembler code--often `reg', `mem' or constant
345: expressions. This would not be well-formed RTL at any other
346: stage in compilation, but it is ok then because no further
347: optimization remains to be done. However, the definition of the
348: macro `NOTICE_UPDATE_CC' may need to deal with such insns.
349:
350: `(sequence [INSNS ...])'
351: Represents a sequence of insns. Each of the INSNS that appears
352: in the vector is suitable for appearing in the chain of insns,
353: so it must be an `insn', `jump_insn', `call_insn', `code_label',
354: `barrier' or `note'.
355:
356: A `sequence' RTX never appears in an actual insn. It represents
357: the sequence of insns that result from a `define_expand'
358: *before* those insns are passed to `emit_insn' to insert them in
359: the chain of insns. When actually inserted, the individual
360: sub-insns are separated out and the `sequence' is forgotten.
361:
362: Three expression codes appear in place of a side effect, as the body
363: of an insn, though strictly speaking they do not describe side
364: effects as such:
365:
366: `(asm_input S)'
367: Represents literal assembler code as described by the string S.
368:
369: `(addr_vec:M [LR0 LR1 ...])'
370: Represents a table of jump addresses. The vector elements LR0,
371: etc., are `label_ref' expressions. The mode M specifies how
372: much space is given to each address; normally M would be `Pmode'.
373:
374: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
375: Represents a table of jump addresses expressed as offsets from
376: BASE. The vector elements LR0, etc., are `label_ref'
377: expressions and so is BASE. The mode M specifies how much space
378: is given to each address-difference.
379:
380:
381:
382: File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
383:
384: Embedded Side-Effects on Addresses
385: ==================================
386:
387: Four special side-effect expression codes appear as memory addresses.
388:
389: `(pre_dec:M X)'
390: Represents the side effect of decrementing X by a standard
391: amount and represents also the value that X has after being
392: decremented. X must be a `reg' or `mem', but most machines
393: allow only a `reg'. M must be the machine mode for pointers on
394: the machine in use. The amount X is decremented by is the
395: length in bytes of the machine mode of the containing memory
396: reference of which this expression serves as the address. Here
397: is an example of its use:
398:
399: (mem:DF (pre_dec:SI (reg:SI 39)))
400:
401: This says to decrement pseudo register 39 by the length of a
402: `DFmode' value and use the result to address a `DFmode' value.
403:
404: `(pre_inc:M X)'
405: Similar, but specifies incrementing X instead of decrementing it.
406:
407: `(post_dec:M X)'
408: Represents the same side effect as `pre_decrement' but a
409: different value. The value represented here is the value X has
410: before being decremented.
411:
412: `(post_inc:M X)'
413: Similar, but specifies incrementing X instead of decrementing it.
414:
415: These embedded side effect expressions must be used with care.
416: Instruction patterns may not use them. Until the `flow' pass of the
417: compiler, they may occur only to represent pushes onto the stack.
418: The `flow' pass finds cases where registers are incremented or
419: decremented in one instruction and used as an address shortly before
420: or after; these cases are then transformed to use pre- or
421: post-increment or -decrement.
422:
423: Explicit popping of the stack could be represented with these
424: embedded side effect operators, but that would not be safe; the
425: instruction combination pass could move the popping past pushes, thus
426: changing the meaning of the code.
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
433: as additional parallel stores would require doubling the number of
434: entries in the machine description.
435:
436:
437:
438: File: gcc.info, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL
439:
440: Assembler Instructions as Expressions
441: =====================================
442:
443: The RTX code `asm_operands' represents a value produced by a
444: user-specified assembler instruction. It is used to represent an
445: `asm' statement with arguments. An `asm' statement with a single
446: output operand, like this:
447:
448: asm ("foo %1,%2,%0" : "a" (outputvar) : "g" (x + y), "di" (*z));
449:
450: is represented using a single `asm_operands' RTX which represents the
451: value that is stored in `outputvar':
452:
453: (set RTX-FOR-OUTPUTVAR
454: (asm_operands "foo %1,%2,%0" "a" 0
455: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
456: [(asm_input:M1 "g")
457: (asm_input:M2 "di")]))
458:
459: Here the operands of the `asm_operands' RTX are the assembler
460: template string, the output-operand's constraint, the index-number of
461: the output operand among the output operands specified, a vector of
462: input operand RTX's, and a vector of input-operand modes and
463: constraints. The mode M1 is the mode of the sum `x+y'; M2 is that of
464: `*z'.
465:
466: When an `asm' statement has multiple output values, its insn has
467: several such `set' RTX's inside of a `parallel'. Each `set' contains
468: a `asm_operands'; all of these share the same assembler template and
469: vectors, but each contains the constraint for the respective output
470: operand. They are also distinguished by the output-operand index
471: number, which is 0, 1, ... for successive output operands.
472:
473:
474:
475: File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
476:
477: Insns
478: =====
479:
480: The RTL representation of the code for a function is a doubly-linked
481: chain of objects called "insns". Insns are expressions with special
482: codes that are used for no other purpose. Some insns are actual
483: instructions; others represent dispatch tables for `switch'
484: statements; others represent labels to jump to or various sorts of
485: declarative information.
486:
487: In addition to its own specific data, each insn must have a unique
488: id-number that distinguishes it from all other insns in the current
489: function, and chain pointers to the preceding and following insns.
490: These three fields occupy the same position in every insn,
491: independent of the expression code of the insn. They could be
492: accessed with `XEXP' and `XINT', but instead three special macros are
493: always used:
494:
495: `INSN_UID (I)'
496: Accesses the unique id of insn I.
497:
498: `PREV_INSN (I)'
499: Accesses the chain pointer to the insn preceding I. If I is the
500: first insn, this is a null pointer.
501:
502: `NEXT_INSN (I)'
503: Accesses the chain pointer to the insn following I. If I is the
504: last insn, this is a null pointer.
505:
506: The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if I
507: is not the first insn,
508:
509: NEXT_INSN (PREV_INSN (INSN)) == INSN
510:
511: is always true.
512:
513: Every insn has one of the following six expression codes:
514:
515: `insn'
516: The expression code `insn' is used for instructions that do not
517: jump and do not do function calls. Insns with code `insn' have
518: four additional fields beyond the three mandatory ones listed
519: above. These four are described in a table below.
520:
521: `jump_insn'
522: The expression code `jump_insn' is used for instructions that
523: may jump (or, more generally, may contain `label_ref'
524: expressions). `jump_insn' insns have the same extra fields as
525: `insn' insns, accessed in the same way.
526:
527: `call_insn'
528: The expression code `call_insn' is used for instructions that
529: may do function calls. It is important to distinguish these
530: instructions because they imply that certain registers and
531: memory locations may be altered unpredictably.
532:
533: `call_insn' insns have the same extra fields as `insn' insns,
534: accessed in the same way.
535:
536: `code_label'
537: A `code_label' insn represents a label that a jump insn can jump
538: to. It contains one special field of data in addition to the
539: three standard ones. It is used to hold the "label number", a
540: number that identifies this label uniquely among all the labels
541: in the compilation (not just in the current function).
542: Ultimately, the label is represented in the assembler output as
543: an assembler label `LN' where N is the label number.
544:
545: `barrier'
546: Barriers are placed in the instruction stream after
547: unconditional jump instructions to indicate that the jumps are
548: unconditional. They contain no information beyond the three
549: standard fields.
550:
551: `note'
552: `note' insns are used to represent additional debugging and
553: declarative information. They contain two nonstandard fields,
554: an integer which is accessed with the macro `NOTE_LINE_NUMBER'
555: and a string accessed with `NOTE_SOURCE_FILE'.
556:
557: If `NOTE_LINE_NUMBER' is positive, the note represents the
558: position of a source line and `NOTE_SOURCE_FILE' is the source
559: file name that the line came from. These notes control
560: generation of line number data in the assembler output.
561:
562: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
563: code with one of the following values (and `NOTE_SOURCE_FILE'
564: must contain a null pointer):
565:
566: `NOTE_INSN_DELETED'
567: Such a note is completely ignorable. Some passes of the
568: compiler delete insns by altering them into notes of this
569: kind.
570:
571: `NOTE_INSN_BLOCK_BEG'
572: `NOTE_INSN_BLOCK_END'
573: These types of notes indicate the position of the beginning
574: and end of a level of scoping of variable names. They
575: control the output of debugging information.
576:
577: `NOTE_INSN_LOOP_BEG'
578: `NOTE_INSN_LOOP_END'
579: These types of notes indicate the position of the beginning
580: and end of a `while' or `for' loop. They enable the loop
581: optimizer to find loops quickly.
582:
583: Here is a table of the extra fields of `insn', `jump_insn' and
584: `call_insn' insns:
585:
586: `PATTERN (I)'
587: An expression for the side effect performed by this insn.
588:
589: `REG_NOTES (I)'
590: A list (chain of `expr_list' expressions) giving information
591: about the usage of registers in this insn. This list is set up
592: by the flow analysis pass; it is a null pointer until then.
593:
594: `LOG_LINKS (I)'
595: A list (chain of `insn_list' expressions) of previous
596: ``related'' insns: insns which store into registers values that
597: are used for the first time in this insn. (An additional
598: constraint is that neither a jump nor a label may come between
599: the related insns). This list is set up by the flow analysis
600: pass; it is a null pointer until then.
601:
602: `INSN_CODE (I)'
603: An integer that says which pattern in the machine description
604: matches this insn, or -1 if the matching has not yet been
605: attempted.
606:
607: Such matching is never attempted and this field is not used on
608: an insn whose pattern consists of a single `use', `clobber',
609: `asm', `addr_vec' or `addr_diff_vec' expression.
610:
611: The `LOG_LINKS' field of an insn is a chain of `insn_list'
612: expressions. Each of these has two operands: the first is an insn,
613: and the second is another `insn_list' expression (the next one in the
614: chain). The last `insn_list' in the chain has a null pointer as
615: second operand. The significant thing about the chain is which insns
616: appear in it (as first operands of `insn_list' expressions). Their
617: order is not significant.
618:
619: The `REG_NOTES' field of an insn is a similar chain but of
620: `expr_list' expressions instead of `insn_list'. There are four kinds
621: of register notes, which are distinguished by the machine mode of the
622: `expr_list', which a register note is really understood as being an
623: `enum reg_note'. The first operand OP of the `expr_list' is data
624: whose meaning depends on the kind of note. Here are the four kinds:
625:
626: `REG_DEAD'
627: The register OP dies in this insn; that is to say, altering the
628: value immediately after this insn would not affect the future
629: behavior of the program.
630:
631: `REG_INC'
632: The register OP is incremented (or decremented; at this level
633: there is no distinction) by an embedded side effect inside this
634: insn. This means it appears in a `POST_INC', `PRE_INC',
635: `POST_DEC' or `PRE_DEC' RTX.
636:
637: `REG_EQUIV'
638: The register that is set by this insn will be equal to OP at run
639: time, and could validly be replaced in all its occurrences by
640: OP. (``Validly'' here refers to the data flow of the program;
641: simple replacement may make some insns invalid.)
642:
643: The value which the insn explicitly copies into the register may
644: look different from OP, but they will be equal at run time.
645:
646: For example, when a constant is loaded into a register that is
647: never assigned any other value, this kind of note is used.
648:
649: When a parameter is copied into a pseudo-register at entry to a
650: function, a note of this kind records that the register is
651: equivalent to the stack slot where the parameter was passed.
652: Although in this case the register may be set by other insns, it
653: is still valid to replace the register by the stack slot
654: throughout the function.
655:
656: `REG_EQUAL'
657: The register that is set by this insn will be equal to OP at run
658: time at the end of this insn (but not necessarily elsewhere in
659: the function).
660:
661: The RTX OP is typically an arithmetic expression. For example,
662: when a sequence of insns such as a library call is used to
663: perform an arithmetic operation, this kind of note is attached
664: to the insn that produces or copies the final value. It tells
665: the CSE pass how to think of that value.
666:
667: `REG_RETVAL'
668: This insn copies the value of a library call, and OP is the
669: first insn that was generated to set up the arguments for the
670: library call.
671:
672: Flow analysis uses this note to delete all of a library call
673: whose result is dead.
674:
675: `REG_WAS_0'
676: The register OP contained zero before this insn. You can rely
677: on this note if it is present; its absence implies nothing.
678:
679: `REG_LIBCALL'
680: This is the inverse of `REG_RETVAL': it is placed on the first
681: insn of a library call, and it points to the last one.
682:
683: Loop optimization uses this note to move an entire library call
684: out of a loop when its value is constant.
685:
686: `REG_NONNEG'
687: The register OP is known to have nonnegative value when this
688: insn is reached.
689:
690: (The only difference between the expression codes `insn_list' and
691: `expr_list' is that the first operand of an `insn_list' is assumed to
692: be an insn and is printed in debugging dumps as the insn's unique id;
693: the first operand of an `expr_list' is printed in the ordinary way as
694: an expression.)
695:
696:
697:
698: File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
699:
700: RTL Representation of Function-Call Insns
701: =========================================
702:
703: Insns that call subroutines have the RTL expression code `call_insn'.
704: These insns must satisfy special rules, and their bodies must use a
705: special RTL expression code, `call'.
706:
707: A `call' expression has two operands, as follows:
708:
709: (call NBYTES (mem:FM ADDR))
710:
711: Here NBYTES is an operand that represents the number of bytes of
712: argument data being passed to the subroutine, FM is a machine mode
713: (which must equal as the definition of the `FUNCTION_MODE' macro in
714: the machine description) and ADDR represents the address of the
715: subroutine.
716:
717: For a subroutine that returns no value, the `call' RTX as shown above
718: is the entire body of the insn.
719:
720: For a subroutine that returns a value whose mode is not `BLKmode',
721: the value is returned in a hard register. If this register's number
722: is R, then the body of the call insn looks like this:
723:
724: (set (reg:M R)
725: (call NBYTES (mem:FM ADDR)))
726:
727: This RTL expression makes it clear (to the optimizer passes) that the
728: appropriate register receives a useful value in this insn.
729:
730: Immediately after RTL generation, if the value of the subroutine is
731: actually used, this call insn is always followed closely by an insn
732: which refers to the register R. This remains true through all the
733: optimizer passes until cross jumping occurs.
734:
735: The following insn has one of two forms. Either it copies the value
736: into a pseudo-register, like this:
737:
738: (set (reg:M P) (reg:M R))
739:
740: or (in the case where the calling function will simply return
741: whatever value the call produced, and no operation is needed to do
742: this):
743:
744: (use (reg:M R))
745:
746: Between the call insn and this following insn there may intervene
747: only a stack-adjustment insn (and perhaps some `note' insns).
748:
749: When a subroutine returns a `BLKmode' value, it is handled by passing
750: to the subroutine the address of a place to store the value. So the
751: call insn itself does not ``return'' any value, and it has the same
752: RTL form as a call that returns nothing.
753:
754:
755:
756: File: gcc.info, Node: Sharing, Prev: Calls, Up: RTL
757:
758: Structure Sharing Assumptions
759: =============================
760:
761: The compiler assumes that certain kinds of RTL expressions are
762: unique; there do not exist two distinct objects representing the same
763: value. In other cases, it makes an opposite assumption: that no RTL
764: expression object of a certain kind appears in more than one place in
765: the containing structure.
766:
767: These assumptions refer to a single function; except for the RTL
768: objects that describe global variables and external functions, no RTL
769: objects are common to two functions.
770:
771: * Each pseudo-register has only a single `reg' object to represent
772: it, and therefore only a single machine mode.
773:
774: * For any symbolic label, there is only one `symbol_ref' object
775: referring to it.
776:
777: * There is only one `const_int' expression with value zero, and
778: only one with value one.
779:
780: * There is only one `pc' expression.
781:
782: * There is only one `cc0' expression.
783:
784: * There is only one `const_double' expression with mode `SFmode'
785: and value zero, and only one with mode `DFmode' and value zero.
786:
787: * No `label_ref' appears in more than one place in the RTL
788: structure; in other words, it is safe to do a tree-walk of all
789: the insns in the function and assume that each time a
790: `label_ref' is seen it is distinct from all others that are seen.
791:
792: * Only one `mem' object is normally created for each static
793: variable or stack slot, so these objects are frequently shared
794: in all the places they appear. However, separate but equal
795: objects for these variables are occasionally made.
796:
797: * No RTL object appears in more than one place in the RTL
798: structure except as described above. Many passes of the
799: compiler rely on this by assuming that they can modify RTL
800: objects in place without unwanted side-effects on other insns.
801:
802: * During initial RTL generation, shared structure is freely
803: introduced. After all the RTL for a function has been
804: generated, all shared structure is copied by `unshare_all_rtl'
805: in `emit-rtl.c', after which the above rules are guaranteed to
806: be followed.
807:
808: * During the combiner pass, shared structure with an insn can
809: exist temporarily. However, the shared structure is copied
810: before the combiner is finished with the insn. This is done by
811: `copy_substitutions' in `combine.c'.
812:
813:
814:
815: File: gcc.info, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top
816:
817: Machine Descriptions
818: ********************
819:
820: A machine description has two parts: a file of instruction patterns
821: (`.md' file) and a C header file of macro definitions.
822:
823: The `.md' file for a target machine contains a pattern for each
824: instruction that the target machine supports (or at least each
825: instruction that is worth telling the compiler about). It may also
826: contain comments. A semicolon causes the rest of the line to be a
827: comment, unless the semicolon is inside a quoted string.
828:
829: See the next chapter for information on the C header file.
830:
831: * Menu:
832:
833: * Patterns:: How to write instruction patterns.
834: * Example:: An explained example of a `define_insn' pattern.
835: * RTL Template:: The RTL template defines what insns match a pattern.
836: * Output Template:: The output template says how to make assembler code
837: from such an insn.
838: * Output Statement:: For more generality, write C code to output
839: the assembler code.
840: * Constraints:: When not all operands are general operands.
841: * Standard Names:: Names mark patterns to use for code generation.
842: * Pattern Ordering:: When the order of patterns makes a difference.
843: * Dependent Patterns:: Having one pattern may make you need another.
844: * Jump Patterns:: Special considerations for patterns for jump insns.
845: * Peephole Definitions::Defining machine-specific peephole optimizations.
846: * Expander Definitions::Generating a sequence of several RTL insns
847: for a standard operation.
848:
849:
850:
851: File: gcc.info, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc
852:
853: Everything about Instruction Patterns
854: =====================================
855:
856: Each instruction pattern contains an incomplete RTL expression, with
857: pieces to be filled in later, operand constraints that restrict how
858: the pieces can be filled in, and an output pattern or C code to
859: generate the assembler output, all wrapped up in a `define_insn'
860: expression.
861:
862: A `define_insn' is an RTL expression containing four or five operands:
863:
864: 1. An optional name. The presence of a name indicate that this
865: instruction pattern can perform a certain standard job for the
866: RTL-generation pass of the compiler. This pass knows certain
867: names and will use the instruction patterns with those names, if
868: the names are defined in the machine description.
869:
870: The absence of a name is indicated by writing an empty string
871: where the name should go. Nameless instruction patterns are
872: never used for generating RTL code, but they may permit several
873: simpler insns to be combined later on.
874:
875: Names that are not thus known and used in RTL-generation have no
876: effect; they are equivalent to no name at all.
877:
878: 2. The "RTL template" (*note RTL Template::.) is a vector of
879: incomplete RTL expressions which show what the instruction
880: should look like. It is incomplete because it may contain
881: `match_operand' and `match_dup' expressions that stand for
882: operands of the instruction.
883:
884: If the vector has only one element, that element is what the
885: instruction should look like. If the vector has multiple
886: elements, then the instruction looks like a `parallel'
887: expression containing that many elements as described.
888:
889: 3. A condition. This is a string which contains a C expression
890: that is the final test to decide whether an insn body matches
891: this pattern.
892:
893: For a named pattern, the condition (if present) may not depend
894: on the data in the insn being matched, but only the
895: target-machine-type flags. The compiler needs to test these
896: conditions during initialization in order to learn exactly which
897: named instructions are available in a particular run.
898:
899: For nameless patterns, the condition is applied only when
900: matching an individual insn, and only after the insn has matched
901: the pattern's recognition template. The insn's operands may be
902: found in the vector `operands'.
903:
904: 4. The "output template": a string that says how to output matching
905: insns as assembler code. `%' in this string specifies where to
906: substitute the value of an operand. *Note Output Template::.
907:
908: When simple substitution isn't general enough, you can specify a
909: piece of C code to compute the output. *Note Output Statement::.
910:
911: 5. Optionally, some "machine-specific information". The meaning of
912: this information is defined only by an individual machine
913: description; typically it might say whether this insn alters the
914: condition codes, or how many bytes of output it generates.
915:
916: This operand is written as a string containing a C initializer
917: (complete with braces) for the structure type
918: `INSN_MACHINE_INFO', whose definition is up to you (*note
919: Misc::.).
920:
921:
922:
923: File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
924:
925: Example of `define_insn'
926: ========================
927:
928: Here is an actual example of an instruction pattern, for the
929: 68000/68020.
930:
931: (define_insn "tstsi"
932: [(set (cc0)
933: (match_operand:SI 0 "general_operand" "rm"))]
934: ""
935: "*
936: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
937: return \"tstl %0\";
938: return \"cmpl #0,%0\"; }")
939:
940: This is an instruction that sets the condition codes based on the
941: value of a general operand. It has no condition, so any insn whose
942: RTL description has the form shown may be handled according to this
943: pattern. The name `tstsi' means ``test a `SImode' value'' and tells
944: the RTL generation pass that, when it is necessary to test such a
945: value, an insn to do so can be constructed using this pattern.
946:
947: The output control string is a piece of C code which chooses which
948: output template to return based on the kind of operand and the
949: specific type of CPU for which code is being generated.
950:
951: `"rm"' is an operand constraint. Its meaning is explained below.
952:
953:
954:
955: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
956:
957: RTL Template for Generating and Recognizing Insns
958: =================================================
959:
960: The RTL template is used to define which insns match the particular
961: pattern and how to find their operands. For named patterns, the RTL
962: template also says how to construct an insn from specified operands.
963:
964: Construction involves substituting specified operands into a copy of
965: the template. Matching involves determining the values that serve as
966: the operands in the insn being matched. Both of these activities are
967: controlled by special expression types that direct matching and
968: substitution of the operands.
969:
970: `(match_operand:M N TESTFN CONSTRAINT)'
971: This expression is a placeholder for operand number N of the
972: insn. When constructing an insn, operand number N will be
973: substituted at this point. When matching an insn, whatever
974: appears at this position in the insn will be taken as operand
975: number N; but it must satisfy TESTFN or this instruction pattern
976: will not match at all.
977:
978: Operand numbers must be chosen consecutively counting from zero
979: in each instruction pattern. There may be only one
980: `match_operand' expression in the pattern for each operand
981: number. Usually operands are numbered in the order of
982: appearance in `match_operand' expressions.
983:
984: TESTFN is a string that is the name of a C function that accepts
985: two arguments, a machine mode and an expression. During
986: matching, the function will be called with M as the mode
987: argument and the putative operand as the other argument. If it
988: returns zero, this instruction pattern fails to match. TESTFN
989: may be an empty string; then it means no test is to be done on
990: the operand.
991:
992: CONSTRAINT is explained later (*note Constraints::.).
993:
994: Most often, TESTFN is `"general_operand"'. It checks that the
995: putative operand is either a constant, a register or a memory
996: reference, and that it is valid for mode M.
997:
998: For an operand that must be a register, TESTFN should be
999: `"register_operand"'. It would be valid to use
1000: `"general_operand"', since the reload pass would copy any
1001: non-register operands through registers, but this would make GNU
1002: CC do extra work, and it would prevent the register allocator
1003: from doing the best possible job.
1004:
1005: For an operand that must be a constant, either TESTFN should be
1006: `"immediate_operand"', or the instruction pattern's extra
1007: condition should check for constants, or both. You cannot
1008: expect the constraints to do this work! If the constraints
1009: allow only constants, but the predicate allows something else,
1010: the compiler will crash when that case arises.
1011:
1012: `(match_dup N)'
1013: This expression is also a placeholder for operand number N. It
1014: is used when the operand needs to appear more than once in the
1015: insn.
1016:
1017: In construction, `match_dup' behaves exactly like
1018: `match_operand': the operand is substituted into the insn being
1019: constructed. But in matching, `match_dup' behaves differently.
1020: It assumes that operand number N has already been determined by
1021: a `match_operand' appearing earlier in the recognition template,
1022: and it matches only an identical-looking expression.
1023:
1024: `(address (match_operand:M N "address_operand" ""))'
1025: This complex of expressions is a placeholder for an operand
1026: number N in a ``load address'' instruction: an operand which
1027: specifies a memory location in the usual way, but for which the
1028: actual operand value used is the address of the location, not
1029: the contents of the location.
1030:
1031: `address' expressions never appear in RTL code, only in machine
1032: descriptions. And they are used only in machine descriptions
1033: that do not use the operand constraint feature. When operand
1034: constraints are in use, the letter `p' in the constraint serves
1035: this purpose.
1036:
1037: M is the machine mode of the *memory location being addressed*,
1038: not the machine mode of the address itself. That mode is always
1039: the same on a given target machine (it is `Pmode', which
1040: normally is `SImode'), so there is no point in mentioning it;
1041: thus, no machine mode is written in the `address' expression.
1042: If some day support is added for machines in which addresses of
1043: different kinds of objects appear differently or are used
1044: differently (such as the PDP-10), different formats would
1045: perhaps need different machine modes and these modes might be
1046: written in the `address' expression.
1047:
1048:
1049:
1050: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
1051:
1052: Output Templates and Operand Substitution
1053: =========================================
1054:
1055: The "output template" is a string which specifies how to output the
1056: assembler code for an instruction pattern. Most of the template is a
1057: fixed string which is output literally. The character `%' is used to
1058: specify where to substitute an operand; it can also be used to
1059: identify places different variants of the assembler require different
1060: syntax.
1061:
1062: In the simplest case, a `%' followed by a digit N says to output
1063: operand N at that point in the string.
1064:
1065: `%' followed by a letter and a digit says to output an operand in an
1066: alternate fashion. Four letters have standard, built-in meanings
1067: described below. The machine description macro `PRINT_OPERAND' can
1068: define additional letters with nonstandard meanings.
1069:
1070: `%cDIGIT' can be used to substitute an operand that is a constant
1071: value without the syntax that normally indicates an immediate operand.
1072:
1073: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
1074: negated before printing.
1075:
1076: `%aDIGIT' can be used to substitute an operand as if it were a memory
1077: reference, with the actual operand treated as the address. This may
1078: be useful when outputting a ``load address'' instruction, because
1079: often the assembler syntax for such an instruction requires you to
1080: write the operand as if it were a memory reference.
1081:
1082: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
1083:
1084: `%' followed by a punctuation character specifies a substitution that
1085: does not use an operand. Only one case is standard: `%%' outputs a
1086: `%' into the assembler code. Other nonstandard cases can be defined
1087: in the `PRINT_OPERAND' macro.
1088:
1089: The template may generate multiple assembler instructions. Write the
1090: text for the instructions, with `\;' between them.
1091:
1092: When the RTL contains two operand which are required by constraint to
1093: match each other, the output template must refer only to the
1094: lower-numbered operand. Matching operands are not always identical,
1095: and the rest of the compiler arranges to put the proper RTL
1096: expression for printing into the lower-numbered operand.
1097:
1098: One use of nonstandard letters or punctuation following `%' is to
1099: distinguish between different assembler languages for the same
1100: machine; for example, Motorola syntax versus MIT syntax for the
1101: 68000. Motorola syntax requires periods in most opcode names, while
1102: MIT syntax does not. For example, the opcode `movel' in MIT syntax
1103: is `move.l' in Motorola syntax. The same file of patterns is used
1104: for both kinds of output syntax, but the character sequence `%.' is
1105: used in each place where Motorola syntax wants a period. The
1106: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to
1107: output a period; the macro for MIT syntax defines it to do nothing.
1108:
1109:
1110:
1111: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
1112:
1113: C Statements for Generating Assembler Output
1114: ============================================
1115:
1116: Often a single fixed template string cannot produce correct and
1117: efficient assembler code for all the cases that are recognized by a
1118: single instruction pattern. For example, the opcodes may depend on
1119: the kinds of operands; or some unfortunate combinations of operands
1120: may require extra machine instructions.
1121:
1122: If the output control string starts with a `*', then it is not an
1123: output template but rather a piece of C program that should compute a
1124: template. It should execute a `return' statement to return the
1125: template-string you want. Most such templates use C string literals,
1126: which require doublequote characters to delimit them. To include
1127: these doublequote characters in the string, prefix each one with `\'.
1128:
1129: The operands may be found in the array `operands', whose C data type
1130: is `rtx []'.
1131:
1132: It is possible to output an assembler instruction and then go on to
1133: output or compute more of them, using the subroutine
1134: `output_asm_insn'. This receives two arguments: a template-string
1135: and a vector of operands. The vector may be `operands', or it may be
1136: another array of `rtx' that you declare locally and initialize
1137: yourself.
1138:
1139: When an insn pattern has multiple alternatives in its constraints,
1140: often the appearance of the assembler code determined mostly by which
1141: alternative was matched. When this is so, the C code can test the
1142: variable `which_alternative', which is the ordinal number of the
1143: alternative that was actually satisfied (0 for the first, 1 for the
1144: second alternative, etc.).
1145:
1146: For example, suppose there are two opcodes for storing zero, `clrreg'
1147: for registers and `clrmem' for memory locations. Here is how a
1148: pattern could use `which_alternative' to choose between them:
1149:
1150: (define_insn ""
1151: [(set (match_operand:SI 0 "general_operand" "r,m")
1152: (const_int 0))]
1153: ""
1154: "*
1155: return (which_alternative == 0
1156: ? \"clrreg %0\" : \"clrmem %0\");
1157: ")
1158:
1159:
1160:
1161: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
1162:
1163: Operand Constraints
1164: ===================
1165:
1166: Each `match_operand' in an instruction pattern can specify a
1167: constraint for the type of operands allowed. Constraints can say
1168: whether an operand may be in a register, and which kinds of register;
1169: whether the operand can be a memory reference, and which kinds of
1170: address; whether the operand may be an immediate constant, and which
1171: possible values it may have. Constraints can also require two
1172: operands to match.
1173:
1174: * Menu:
1175:
1176: * Simple Constraints:: Basic use of constraints.
1177: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
1178: * Class Preferences:: Constraints guide which hard register to put things in.
1179: * Modifiers:: More precise control over effects of constraints.
1180: * No Constraints:: Describing a clean machine without constraints.
1181:
1182:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.