![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-12 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-12 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
32:
33: Registers and Memory
34: ====================
35:
36: Here are the RTL expression types for describing access to machine
37: registers and to main memory.
38:
39: `(reg:M N)'
40: For small values of the integer N (those that are less than
41: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
42: register number N: a "hard register". For larger values of N, it
43: stands for a temporary value or "pseudo register". The compiler's
44: strategy is to generate code assuming an unlimited number of such
45: pseudo registers, and later convert them into hard registers or
46: into memory references.
47:
48: M is the machine mode of the reference. It is necessary because
49: machines can generally refer to each register in more than one
50: mode. For example, a register may contain a full word but there
51: may be instructions to refer to it as a half word or as a single
52: byte, as well as instructions to refer to it as a floating point
53: number of various precisions.
54:
55: Even for a register that the machine can access in only one mode,
56: the mode must always be specified.
57:
58: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
59: description, since the number of hard registers on the machine is
60: an invariant characteristic of the machine. Note, however, that
61: not all of the machine registers must be general registers. All
62: the machine registers that can be used for storage of data are
63: given hard register numbers, even those that can be used only in
64: certain instructions or can hold only certain types of data.
65:
66: A hard register may be accessed in various modes throughout one
67: function, but each pseudo register is given a natural mode and is
68: accessed only in that mode. When it is necessary to describe an
69: access to a pseudo register using a nonnatural mode, a `subreg'
70: expression is used.
71:
72: A `reg' expression with a machine mode that specifies more than
73: one word of data may actually stand for several consecutive
74: registers. If in addition the register number specifies a
75: hardware register, then it actually represents several consecutive
76: hardware registers starting with the specified one.
77:
78: Each pseudo register number used in a function's RTL code is
79: represented by a unique `reg' expression.
80:
81: Some pseudo register numbers, those within the range of
82: `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
83: during the RTL generation phase and are eliminated before the
84: optimization phases. These represent locations in the stack frame
85: that cannot be determined until RTL generation for the function
86: has been completed. The following virtual register numbers are
87: defined:
88:
89: `VIRTUAL_INCOMING_ARGS_REGNUM'
90: This points to the first word of the incoming arguments
91: passed on the stack. Normally these arguments are placed
92: there by the caller, but the callee may have pushed some
93: arguments that were previously passed in registers.
94:
95: When RTL generation is complete, this virtual register is
96: replaced by the sum of the register given by
97: `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
98:
99: `VIRTUAL_STACK_VARS_REGNUM'
100: If `FRAME_GROWS_DOWNWARD' is defined, this points to
101: immediately above the first variable on the stack.
102: Otherwise, it points to the first variable on the stack.
103:
104: `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
105: register given by `FRAME_POINTER_REGNUM' and the value
106: `STARTING_FRAME_OFFSET'.
107:
108: `VIRTUAL_STACK_DYNAMIC_REGNUM'
109: This points to the location of dynamically allocated memory
110: on the stack immediately after the stack pointer has been
111: adjusted by the amount of memory desired.
112:
113: This virtual register is replaced by the sum of the register
114: given by `STACK_POINTER_REGNUM' and the value
115: `STACK_DYNAMIC_OFFSET'.
116:
117: `VIRTUAL_OUTGOING_ARGS_REGNUM'
118: This points to the location in the stack at which outgoing
119: arguments should be written when the stack is pre-pushed
120: (arguments pushed using push insns should always use
121: `STACK_POINTER_REGNUM').
122:
123: This virtual register is replaced by the sum of the register
124: given by `STACK_POINTER_REGNUM' and the value
125: `STACK_POINTER_OFFSET'.
126:
127: `(subreg:M REG WORDNUM)'
128: `subreg' expressions are used to refer to a register in a machine
129: mode other than its natural one, or to refer to one register of a
130: multi-word `reg' that actually refers to several registers.
131:
132: Each pseudo-register has a natural mode. If it is necessary to
133: operate on it in a different mode--for example, to perform a
134: fullword move instruction on a pseudo-register that contains a
135: single byte--the pseudo-register must be enclosed in a `subreg'.
136: In such a case, WORDNUM is zero.
137:
138: Usually M is at least as narrow as the mode of REG, in which case
139: it is restricting consideration to only the bits of REG that are
140: in M.
141:
142: Sometimes M is wider than the mode of REG. These `subreg'
143: expressions are often called "paradoxical". They are used in
144: cases where we want to refer to an object in a wider mode but do
145: not care what value the additional bits have. The reload pass
146: ensures that paradoxical references are only made to hard
147: registers.
148:
149: The other use of `subreg' is to extract the individual registers of
150: a multi-register value. Machine modes such as `DImode' and
151: `TImode' can indicate values longer than a word, values which
152: usually require two or more consecutive registers. To access one
153: of the registers, use a `subreg' with mode `SImode' and a WORDNUM
154: that says which register.
155:
156: Storing in a non-paradoxical `subreg' has undefined results for
157: bits belonging to the same word as the `subreg'. This laxity makes
158: it easier to generate efficient code for such instructions. To
159: represent an instruction that preserves all the bits outside of
160: those in the `subreg', use `strict_low_part' around the `subreg'.
161:
162: The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says
163: that word number zero is the most significant part; otherwise, it
164: is the least significant part.
165:
166: Between the combiner pass and the reload pass, it is possible to
167: have a paradoxical `subreg' which contains a `mem' instead of a
168: `reg' as its first operand. After the reload pass, it is also
169: possible to have a non-paradoxical `subreg' which contains a
170: `mem'; this usually occurs when the `mem' is a stack slot which
171: replaced a pseudo register.
172:
173: Note that it is not valid to access a `DFmode' value in `SFmode'
174: using a `subreg'. On some machines the most significant part of a
175: `DFmode' value does not have the same format as a single-precision
176: floating value.
177:
178: It is also not valid to access a single word of a multi-word value
179: in a hard register when less registers can hold the value than
180: would be expected from its size. For example, some 32-bit
181: machines have floating-point registers that can hold an entire
182: `DFmode' value. If register 10 were such a register `(subreg:SI
183: (reg:DF 10) 1)' would be invalid because there is no way to
184: convert that reference to a single machine register. The reload
185: pass prevents `subreg' expressions such as these from being formed.
186:
187: The first operand of a `subreg' expression is customarily accessed
188: with the `SUBREG_REG' macro and the second operand is customarily
189: accessed with the `SUBREG_WORD' macro.
190:
191: `(scratch:M)'
192: This represents a scratch register that will be required for the
193: execution of a single instruction and not used subsequently. It is
194: converted into a `reg' by either the local register allocator or
195: the reload pass.
196:
197: `scratch' is usually present inside a `clobber' operation (*note
198: Side Effects::.).
199:
200: `(cc0)'
201: This refers to the machine's condition code register. It has no
202: operands and may not have a machine mode. There are two ways to
203: use it:
204:
205: * To stand for a complete set of condition code flags. This is
206: best on most machines, where each comparison sets the entire
207: series of flags.
208:
209: With this technique, `(cc0)' may be validly used in only two
210: contexts: as the destination of an assignment (in test and
211: compare instructions) and in comparison operators comparing
212: against zero (`const_int' with value zero; that is to say,
213: `const0_rtx').
214:
215: * To stand for a single flag that is the result of a single
216: condition. This is useful on machines that have only a
217: single flag bit, and in which comparison instructions must
218: specify the condition to test.
219:
220: With this technique, `(cc0)' may be validly used in only two
221: contexts: as the destination of an assignment (in test and
222: compare instructions) where the source is a comparison
223: operator, and as the first operand of `if_then_else' (in a
224: conditional branch).
225:
226: There is only one expression object of code `cc0'; it is the value
227: of the variable `cc0_rtx'. Any attempt to create an expression of
228: code `cc0' will return `cc0_rtx'.
229:
230: Instructions can set the condition code implicitly. On many
231: machines, nearly all instructions set the condition code based on
232: the value that they compute or store. It is not necessary to
233: record these actions explicitly in the RTL because the machine
234: description includes a prescription for recognizing the
235: instructions that do so (by means of the macro
236: `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
237: whose sole purpose is to set the condition code, and instructions
238: that use the condition code, need mention `(cc0)'.
239:
240: On some machines, the condition code register is given a register
241: number and a `reg' is used instead of `(cc0)'. This is usually the
242: preferable approach if only a small subset of instructions modify
243: the condition code. Other machines store condition codes in
244: general registers; in such cases a pseudo register should be used.
245:
246: Some machines, such as the Sparc and RS/6000, have two sets of
247: arithmetic instructions, one that sets and one that does not set
248: the condition code. This is best handled by normally generating
249: the instruction that does not set the condition code, and making a
250: pattern that both performs the arithmetic and sets the condition
251: code register (which would not be `(cc0)' in this case). For
252: examples, search for `addcc' and `andcc' in `sparc.md'.
253:
254: `(pc)'
255: This represents the machine's program counter. It has no operands
256: and may not have a machine mode. `(pc)' may be validly used only
257: in certain specific contexts in jump instructions.
258:
259: There is only one expression object of code `pc'; it is the value
260: of the variable `pc_rtx'. Any attempt to create an expression of
261: code `pc' will return `pc_rtx'.
262:
263: All instructions that do not jump alter the program counter
264: implicitly by incrementing it, but there is no need to mention
265: this in the RTL.
266:
267: `(mem:M ADDR)'
268: This RTX represents a reference to main memory at an address
269: represented by the expression ADDR. M specifies how large a unit
270: of memory is accessed.
271:
272:
273: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
274:
275: RTL Expressions for Arithmetic
276: ==============================
277:
278: Unless otherwise specified, all the operands of arithmetic
279: expressions must be valid for mode M. An operand is valid for mode M
280: if it has mode M, or if it is a `const_int' or `const_double' and M is
281: a mode of class `MODE_INT'.
282:
283: For commutative binary operations, constants should be placed in the
284: second operand.
285:
286: `(plus:M X Y)'
287: Represents the sum of the values represented by X and Y carried
288: out in machine mode M.
289:
290: `(lo_sum:M X Y)'
291: Like `plus', except that it represents that sum of X and the
292: low-order bits of Y. The number of low order bits is
293: machine-dependent but is normally the number of bits in a `Pmode'
294: item minus the number of bits set by the `high' code (*note
295: Constants::.).
296:
297: M should be `Pmode'.
298:
299: `(minus:M X Y)'
300: Like `plus' but represents subtraction.
301:
302: `(compare:M X Y)'
303: Represents the result of subtracting Y from X for purposes of
304: comparison. The result is computed without overflow, as if with
305: infinite precision.
306:
307: Of course, machines can't really subtract with infinite precision.
308: However, they can pretend to do so when only the sign of the
309: result will be used, which is the case when the result is stored
310: in the condition code. And that is the only way this kind of
311: expression may validly be used: as a value to be stored in the
312: condition codes.
313:
314: The mode M is not related to the modes of X and Y, but instead is
315: the mode of the condition code value. If `(cc0)' is used, it is
316: `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
317: `CCmode'. *Note Condition Code::.
318:
319: Normally, X and Y must have the same mode. Otherwise, `compare'
320: is valid only if the mode of X is in class `MODE_INT' and Y is a
321: `const_int' or `const_double' with mode `VOIDmode'. The mode of X
322: determines what mode the comparison is to be done in; thus it must
323: not be `VOIDmode'.
324:
325: If one of the operands is a constant, it should be placed in the
326: second operand and the comparison code adjusted as appropriate.
327:
328: A `compare' specifying two `VOIDmode' constants is not valid since
329: there is no way to know in what mode the comparison is to be
330: performed; the comparison must either be folded during the
331: compilation or the first operand must be loaded into a register
332: while its mode is still known.
333:
334: `(neg:M X)'
335: Represents the negation (subtraction from zero) of the value
336: represented by X, carried out in mode M.
337:
338: `(mult:M X Y)'
339: Represents the signed product of the values represented by X and Y
340: carried out in machine mode M.
341:
342: Some machines support a multiplication that generates a product
343: wider than the operands. Write the pattern for this as
344:
345: (mult:M (sign_extend:M X) (sign_extend:M Y))
346:
347: where M is wider than the modes of X and Y, which need not be the
348: same.
349:
350: Write patterns for unsigned widening multiplication similarly using
351: `zero_extend'.
352:
353: `(div:M X Y)'
354: Represents the quotient in signed division of X by Y, carried out
355: in machine mode M. If M is a floating point mode, it represents
356: the exact quotient; otherwise, the integerized quotient.
357:
358: Some machines have division instructions in which the operands and
359: quotient widths are not all the same; you should represent such
360: instructions using `truncate' and `sign_extend' as in,
361:
362: (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
363:
364: `(udiv:M X Y)'
365: Like `div' but represents unsigned division.
366:
367: `(mod:M X Y)'
368: `(umod:M X Y)'
369: Like `div' and `udiv' but represent the remainder instead of the
370: quotient.
371:
372: `(smin:M X Y)'
373: `(smax:M X Y)'
374: Represents the smaller (for `smin') or larger (for `smax') of X
375: and Y, interpreted as signed integers in mode M.
376:
377: `(umin:M X Y)'
378: `(umax:M X Y)'
379: Like `smin' and `smax', but the values are interpreted as unsigned
380: integers.
381:
382: `(not:M X)'
383: Represents the bitwise complement of the value represented by X,
384: carried out in mode M, which must be a fixed-point machine mode.
385:
386: `(and:M X Y)'
387: Represents the bitwise logical-and of the values represented by X
388: and Y, carried out in machine mode M, which must be a fixed-point
389: machine mode.
390:
391: `(ior:M X Y)'
392: Represents the bitwise inclusive-or of the values represented by X
393: and Y, carried out in machine mode M, which must be a fixed-point
394: mode.
395:
396: `(xor:M X Y)'
397: Represents the bitwise exclusive-or of the values represented by X
398: and Y, carried out in machine mode M, which must be a fixed-point
399: mode.
400:
401: `(ashift:M X C)'
402: Represents the result of arithmetically shifting X left by C
403: places. X have mode M, a fixed-point machine mode. C be a
404: fixed-point mode or be a constant with mode `VOIDmode'; which mode
405: is determined by the mode called for in the machine description
406: entry for the left-shift instruction. For example, on the Vax,
407: the mode of C is `QImode' regardless of M.
408:
409: `(lshift:M X C)'
410: Like `ashift' but for logical left shift. `ashift' and `lshift'
411: are identical operations; we customarily use `ashift' for both.
412:
413: `(lshiftrt:M X C)'
414: `(ashiftrt:M X C)'
415: Like `lshift' and `ashift' but for right shift. Unlike the case
416: for left shift, these two operations are distinct.
417:
418: `(rotate:M X C)'
419: `(rotatert:M X C)'
420: Similar but represent left and right rotate. If C is a constant,
421: use `rotate'.
422:
423: `(abs:M X)'
424: Represents the absolute value of X, computed in mode M.
425:
426: `(sqrt:M X)'
427: Represents the square root of X, computed in mode M. Most often M
428: will be a floating point mode.
429:
430: `(ffs:M X)'
431: Represents one plus the index of the least significant 1-bit in X,
432: represented as an integer of mode M. (The value is zero if X is
433: zero.) The mode of X need not be M; depending on the target
434: machine, various mode combinations may be valid.
435:
436:
437: File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL
438:
439: Comparison Operations
440: =====================
441:
442: Comparison operators test a relation on two operands and are
443: considered to represent a machine-dependent nonzero value described by,
444: but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.) if the
445: relation holds, or zero if it does not. The mode of the comparison
446: operation is independent of the mode of the data being compared. If
447: the comparison operation is being tested (e.g., the first operand of an
448: `if_then_else'), the mode must be `VOIDmode'. If the comparison
449: operation is producing data to be stored in some variable, the mode
450: must be in class `MODE_INT'. All comparison operations producing data
451: must use the same mode, which is machine-specific.
452:
453: There are two ways that comparison operations may be used. The
454: comparison operators may be used to compare the condition codes `(cc0)'
455: against zero, as in `(eq (cc0) (const_int 0))'. Such a construct
456: actually refers to the result of the preceding instruction in which the
457: condition codes were set. The instructing setting the condition code
458: must be adjacent to the instruction using the condition code; only
459: `note' insns may separate them.
460:
461: Alternatively, a comparison operation may directly compare two data
462: objects. The mode of the comparison is determined by the operands; they
463: must both be valid for a common machine mode. A comparison with both
464: operands constant would be invalid as the machine mode could not be
465: deduced from it, but such a comparison should never exist in RTL due to
466: constant folding.
467:
468: In the example above, if `(cc0)' were last set to `(compare X Y)',
469: the comparison operation is identical to `(eq X Y)'. Usually only one
470: style of comparisons is supported on a particular machine, but the
471: combine pass will try to merge the operations to produce the `eq' shown
472: in case it exists in the context of the particular insn involved.
473:
474: Inequality comparisons come in two flavors, signed and unsigned.
475: Thus, there are distinct expression codes `gt' and `gtu' for signed and
476: unsigned greater-than. These can produce different results for the same
477: pair of integer values: for example, 1 is signed greater-than -1 but not
478: unsigned greater-than, because -1 when regarded as unsigned is actually
479: `0xffffffff' which is greater than 1.
480:
481: The signed comparisons are also used for floating point values.
482: Floating point comparisons are distinguished by the machine modes of
483: the operands.
484:
485: `(eq:M X Y)'
486: 1 if the values represented by X and Y are equal, otherwise 0.
487:
488: `(ne:M X Y)'
489: 1 if the values represented by X and Y are not equal, otherwise 0.
490:
491: `(gt:M X Y)'
492: 1 if the X is greater than Y. If they are fixed-point, the
493: comparison is done in a signed sense.
494:
495: `(gtu:M X Y)'
496: Like `gt' but does unsigned comparison, on fixed-point numbers
497: only.
498:
499: `(lt:M X Y)'
500: `(ltu:M X Y)'
501: Like `gt' and `gtu' but test for "less than".
502:
503: `(ge:M X Y)'
504: `(geu:M X Y)'
505: Like `gt' and `gtu' but test for "greater than or equal".
506:
507: `(le:M X Y)'
508: `(leu:M X Y)'
509: Like `gt' and `gtu' but test for "less than or equal".
510:
511: `(if_then_else COND THEN ELSE)'
512: This is not a comparison operation but is listed here because it is
513: always used in conjunction with a comparison operation. To be
514: precise, COND is a comparison expression. This expression
515: represents a choice, according to COND, between the value
516: represented by THEN and the one represented by ELSE.
517:
518: On most machines, `if_then_else' expressions are valid only to
519: express conditional jumps.
520:
521: `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
522: Similar to `if_then_else', but more general. Each of TEST1,
523: TEST2, ... is performed in turn. The result of this expression is
524: the VALUE corresponding to the first non-zero test, or DEFAULT if
525: none of the tests are non-zero expressions.
526:
527: This is currently not valid for instruction patterns and is
528: supported only for insn attributes. *Note Insn Attributes::.
529:
530:
531: File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL
532:
533: Bit Fields
534: ==========
535:
536: Special expression codes exist to represent bitfield instructions.
537: These types of expressions are lvalues in RTL; they may appear on the
538: left side of an assignment, indicating insertion of a value into the
539: specified bit field.
540:
541: `(sign_extract:M LOC SIZE POS)'
542: This represents a reference to a sign-extended bit field contained
543: or starting in LOC (a memory or register reference). The bit field
544: is SIZE bits wide and starts at bit POS. The compilation option
545: `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
546: from.
547:
548: If LOC is in memory, its mode must be a single-byte integer mode.
549: If LOC is in a register, the mode to use is specified by the
550: operand of the `insv' or `extv' pattern (*note Standard Names::.)
551: and is usually a full-word integer mode.
552:
553: The mode of POS is machine-specific and is also specified in the
554: `insv' or `extv' pattern.
555:
556: The mode M is the same as the mode that would be used for LOC if
557: it were a register.
558:
559: `(zero_extract:M LOC SIZE POS)'
560: Like `sign_extract' but refers to an unsigned or zero-extended bit
561: field. The same sequence of bits are extracted, but they are
562: filled to an entire word with zeros instead of by sign-extension.
563:
564:
565: File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL
566:
567: Conversions
568: ===========
569:
570: All conversions between machine modes must be represented by
571: explicit conversion operations. For example, an expression which is
572: the sum of a byte and a full word cannot be written as `(plus:SI
573: (reg:QI 34) (reg:SI 80))' because the `plus' operation requires two
574: operands of the same machine mode. Therefore, the byte-sized operand
575: is enclosed in a conversion operation, as in
576:
577: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
578:
579: The conversion operation is not a mere placeholder, because there
580: may be more than one way of converting from a given starting mode to
581: the desired final mode. The conversion operation code says how to do
582: it.
583:
584: For all conversion operations, X must not be `VOIDmode' because the
585: mode in which to do the conversion would not be known. The conversion
586: must either be done at compile-time or X must be placed into a register.
587:
588: `(sign_extend:M X)'
589: Represents the result of sign-extending the value X to machine
590: mode M. M must be a fixed-point mode and X a fixed-point value of
591: a mode narrower than M.
592:
593: `(zero_extend:M X)'
594: Represents the result of zero-extending the value X to machine
595: mode M. M must be a fixed-point mode and X a fixed-point value of
596: a mode narrower than M.
597:
598: `(float_extend:M X)'
599: Represents the result of extending the value X to machine mode M.
600: m must be a floating point mode and X a floating point value of a
601: mode narrower than M.
602:
603: `(truncate:M X)'
604: Represents the result of truncating the value X to machine mode M.
605: M must be a fixed-point mode and X a fixed-point value of a mode
606: wider than M.
607:
608: `(float_truncate:M X)'
609: Represents the result of truncating the value X to machine mode M.
610: M must be a floating point mode and X a floating point value of a
611: mode wider than M.
612:
613: `(float:M X)'
614: Represents the result of converting fixed point value X, regarded
615: as signed, to floating point mode M.
616:
617: `(unsigned_float:M X)'
618: Represents the result of converting fixed point value X, regarded
619: as unsigned, to floating point mode M.
620:
621: `(fix:M X)'
622: When M is a fixed point mode, represents the result of converting
623: floating point value X to mode M, regarded as signed. How
624: rounding is done is not specified, so this operation may be used
625: validly in compiling C code only for integer-valued operands.
626:
627: `(unsigned_fix:M X)'
628: Represents the result of converting floating point value X to
629: fixed point mode M, regarded as unsigned. How rounding is done is
630: not specified.
631:
632: `(fix:M X)'
633: When M is a floating point mode, represents the result of
634: converting floating point value X (valid for mode M) to an
635: integer, still represented in floating point mode M, by rounding
636: towards zero.
637:
638:
639: File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
640:
641: Declarations
642: ============
643:
644: Declaration expression codes do not represent arithmetic operations
645: but rather state assertions about their operands.
646:
647: `(strict_low_part (subreg:M (reg:N R) 0))'
648: This expression code is used in only one context: as the
649: destination operand of a `set' expression. In addition, the
650: operand of this expression must be a non-paradoxical `subreg'
651: expression.
652:
653: The presence of `strict_low_part' says that the part of the
654: register which is meaningful in mode N, but is not part of mode M,
655: is not to be altered. Normally, an assignment to such a subreg is
656: allowed to have undefined effects on the rest of the register when
657: M is less than a word.
658:
659:
660: File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
661:
662: Side Effect Expressions
663: =======================
664:
665: The expression codes described so far represent values, not actions.
666: But machine instructions never produce values; they are meaningful only
667: for their side effects on the state of the machine. Special expression
668: codes are used to represent side effects.
669:
670: The body of an instruction is always one of these side effect codes;
671: the codes described above, which represent values, appear only as the
672: operands of these.
673:
674: `(set LVAL X)'
675: Represents the action of storing the value of X into the place
676: represented by LVAL. LVAL must be an expression representing a
677: place that can be stored in: `reg' (or `subreg' or
678: `strict_low_part'), `mem', `pc' or `cc0'.
679:
680: If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
681: X must be valid for that mode.
682:
683: If LVAL is a `reg' whose machine mode is less than the full width
684: of the register, then it means that the part of the register
685: specified by the machine mode is given the specified value and the
686: rest of the register receives an undefined value. Likewise, if
687: LVAL is a `subreg' whose machine mode is narrower than the mode of
688: the register, the rest of the register can be changed in an
689: undefined way.
690:
691: If LVAL is a `strict_low_part' of a `subreg', then the part of the
692: register specified by the machine mode of the `subreg' is given
693: the value X and the rest of the register is not changed.
694:
695: If LVAL is `(cc0)', it has no machine mode, and X may be either a
696: `compare' expression or a value that may have any mode. The
697: latter case represents a "test" instruction. The expression `(set
698: (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
699: (const_int 0)))'. Use the former expression to save space during
700: the compilation.
701:
702: If LVAL is `(pc)', we have a jump instruction, and the
703: possibilities for X are very limited. It may be a `label_ref'
704: expression (unconditional jump). It may be an `if_then_else'
705: (conditional jump), in which case either the second or the third
706: operand must be `(pc)' (for the case which does not jump) and the
707: other of the two must be a `label_ref' (for the case which does
708: jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
709: be a `reg' or a `mem'; these unusual patterns are used to
710: represent jumps through branch tables.
711:
712: If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
713: be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
714:
715: LVAL is customarily accessed with the `SET_DEST' macro and X with
716: the `SET_SRC' macro.
717:
718: `(return)'
719: As the sole expression in a pattern, represents a return from the
720: current function, on machines where this can be done with one
721: instruction, such as Vaxes. On machines where a multi-instruction
722: "epilogue" must be executed in order to return from the function,
723: returning is done by jumping to a label which precedes the
724: epilogue, and the `return' expression code is never used.
725:
726: Inside an `if_then_else' expression, represents the value to be
727: placed in `pc' to return to the caller.
728:
729: Note that an insn pattern of `(return)' is logically equivalent to
730: `(set (pc) (return))', but the latter form is never used.
731:
732: `(call FUNCTION NARGS)'
733: Represents a function call. FUNCTION is a `mem' expression whose
734: address is the address of the function to be called. NARGS is an
735: expression which can be used for two purposes: on some machines it
736: represents the number of bytes of stack argument; on others, it
737: represents the number of argument registers.
738:
739: Each machine has a standard machine mode which FUNCTION must have.
740: The machine description defines macro `FUNCTION_MODE' to expand
741: into the requisite mode name. The purpose of this mode is to
742: specify what kind of addressing is allowed, on machines where the
743: allowed kinds of addressing depend on the machine mode being
744: addressed.
745:
746: `(clobber X)'
747: Represents the storing or possible storing of an unpredictable,
748: undescribed value into X, which must be a `reg', `scratch' or
749: `mem' expression.
750:
751: One place this is used is in string instructions that store
752: standard values into particular hard registers. It may not be
753: worth the trouble to describe the values that are stored, but it
754: is essential to inform the compiler that the registers will be
755: altered, lest it attempt to keep data in them across the string
756: instruction.
757:
758: If X is `(mem:BLK (const_int 0))', it means that all memory
759: locations must be presumed clobbered.
760:
761: Note that the machine description classifies certain hard
762: registers as "call-clobbered". All function call instructions are
763: assumed by default to clobber these registers, so there is no need
764: to use `clobber' expressions to indicate this fact. Also, each
765: function call is assumed to have the potential to alter any memory
766: location, unless the function is declared `const'.
767:
768: If the last group of expressions in a `parallel' are each a
769: `clobber' expression whose arguments are `reg' or `match_scratch'
770: (*note RTL Template::.) expressions, the combiner phase can add
771: the appropriate `clobber' expressions to an insn it has
772: constructed when doing so will cause a pattern to be matched.
773:
774: This feature can be used, for example, on a machine that whose
775: multiply and add instructions don't use an MQ register but which
776: has an add-accumulate instruction that does clobber the MQ
777: register. Similarly, a combined instruction might require a
778: temporary register while the constituent instructions might not.
779:
780: When a `clobber' expression for a register appears inside a
781: `parallel' with other side effects, the register allocator
782: guarantees that the register is unoccupied both before and after
783: that insn. However, the reload phase may allocate a register used
784: for one of the inputs unless the `&' constraint is specified for
785: the selected alternative (*note Modifiers::.). You can clobber
786: either a specific hard register, a pseudo register, or a `scratch'
787: expression; in the latter two cases, GNU CC will allocate a hard
788: register that is available there for use as a temporary.
789:
790: For instructions that require a temporary register, you should use
791: `scratch' instead of a pseudo-register because this will allow the
792: combiner phase to add the `clobber' when required. You do this by
793: coding (`clobber' (`match_scratch' ...)). If you do clobber a
794: pseudo register, use one which appears nowhere else--generate a
795: new one each time. Otherwise, you may confuse CSE.
796:
797: There is one other known use for clobbering a pseudo register in a
798: `parallel': when one of the input operands of the insn is also
799: clobbered by the insn. In this case, using the same pseudo
800: register in the clobber and elsewhere in the insn produces the
801: expected results.
802:
803: `(use X)'
804: Represents the use of the value of X. It indicates that the value
805: in X at this point in the program is needed, even though it may
806: not be apparent why this is so. Therefore, the compiler will not
807: attempt to delete previous instructions whose only effect is to
808: store a value in X. X must be a `reg' expression.
809:
810: During the delayed branch scheduling phase, X may be an insn.
811: This indicates that X previously was located at this place in the
812: code and its data dependencies need to be taken into account.
813: These `use' insns will be deleted before the delayed branch
814: scheduling phase exits.
815:
816: `(parallel [X0 X1 ...])'
817: Represents several side effects performed in parallel. The square
818: brackets stand for a vector; the operand of `parallel' is a vector
819: of expressions. X0, X1 and so on are individual side effect
820: expressions--expressions of code `set', `call', `return',
821: `clobber' or `use'.
822:
823: "In parallel" means that first all the values used in the
824: individual side-effects are computed, and second all the actual
825: side-effects are performed. For example,
826:
827: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
828: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
829:
830: says unambiguously that the values of hard register 1 and the
831: memory location addressed by it are interchanged. In both places
832: where `(reg:SI 1)' appears as a memory address it refers to the
833: value in register 1 *before* the execution of the insn.
834:
835: It follows that it is *incorrect* to use `parallel' and expect the
836: result of one `set' to be available for the next one. For
837: example, people sometimes attempt to represent a jump-if-zero
838: instruction this way:
839:
840: (parallel [(set (cc0) (reg:SI 34))
841: (set (pc) (if_then_else
842: (eq (cc0) (const_int 0))
843: (label_ref ...)
844: (pc)))])
845:
846: But this is incorrect, because it says that the jump condition
847: depends on the condition code value *before* this instruction, not
848: on the new value that is set by this instruction.
849:
850: Peephole optimization, which takes place together with final
851: assembly code output, can produce insns whose patterns consist of
852: a `parallel' whose elements are the operands needed to output the
853: resulting assembler code--often `reg', `mem' or constant
854: expressions. This would not be well-formed RTL at any other stage
855: in compilation, but it is ok then because no further optimization
856: remains to be done. However, the definition of the macro
857: `NOTICE_UPDATE_CC', if any, must deal with such insns if you
858: define any peephole optimizations.
859:
860: `(sequence [INSNS ...])'
861: Represents a sequence of insns. Each of the INSNS that appears in
862: the vector is suitable for appearing in the chain of insns, so it
863: must be an `insn', `jump_insn', `call_insn', `code_label',
864: `barrier' or `note'.
865:
866: A `sequence' RTX is never placed in an actual insn during RTL
867: generation. It represents the sequence of insns that result from a
868: `define_expand' *before* those insns are passed to `emit_insn' to
869: insert them in the chain of insns. When actually inserted, the
870: individual sub-insns are separated out and the `sequence' is
871: forgotten.
872:
873: After delay-slot scheduling is completed, an insn and all the
874: insns that reside in its delay slots are grouped together into a
875: `sequence'. The insn requiring the delay slot is the first insn
876: in the vector; subsequent insns are to be placed in the delay slot.
877:
878: `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
879: indicate that a branch insn should be used that will conditionally
880: annul the effect of the insns in the delay slots. In such a case,
881: `INSN_FROM_TARGET_P' indicates that the insn is from the target of
882: the branch and should be executed only if the branch is taken;
883: otherwise the insn should be executed only if the branch is not
884: taken. *Note Delay Slots::.
885:
886: These expression codes appear in place of a side effect, as the body
887: of an insn, though strictly speaking they do not always describe side
888: effects as such:
889:
890: `(asm_input S)'
891: Represents literal assembler code as described by the string S.
892:
893: `(unspec [OPERANDS ...] INDEX)'
894: `(unspec_volatile [OPERANDS ...] INDEX)'
895: Represents a machine-specific operation on OPERANDS. INDEX
896: selects between multiple machine-specific operations.
897: `unspec_volatile' is used for volatile operations and operations
898: that may trap; `unspec' is used for other operations.
899:
900: These codes may appear inside a `pattern' of an insn, inside a
901: `parallel', or inside an expression.
902:
903: `(addr_vec:M [LR0 LR1 ...])'
904: Represents a table of jump addresses. The vector elements LR0,
905: etc., are `label_ref' expressions. The mode M specifies how much
906: space is given to each address; normally M would be `Pmode'.
907:
908: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
909: Represents a table of jump addresses expressed as offsets from
910: BASE. The vector elements LR0, etc., are `label_ref' expressions
911: and so is BASE. The mode M specifies how much space is given to
912: each address-difference.
913:
914:
915: File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
916:
917: Embedded Side-Effects on Addresses
918: ==================================
919:
920: Four special side-effect expression codes appear as memory addresses.
921:
922: `(pre_dec:M X)'
923: Represents the side effect of decrementing X by a standard amount
924: and represents also the value that X has after being decremented.
925: x must be a `reg' or `mem', but most machines allow only a `reg'.
926: m must be the machine mode for pointers on the machine in use.
927: The amount X is decremented by is the length in bytes of the
928: machine mode of the containing memory reference of which this
929: expression serves as the address. Here is an example of its use:
930:
931: (mem:DF (pre_dec:SI (reg:SI 39)))
932:
933: This says to decrement pseudo register 39 by the length of a
934: `DFmode' value and use the result to address a `DFmode' value.
935:
936: `(pre_inc:M X)'
937: Similar, but specifies incrementing X instead of decrementing it.
938:
939: `(post_dec:M X)'
940: Represents the same side effect as `pre_dec' but a different
941: value. The value represented here is the value X has before being
942: decremented.
943:
944: `(post_inc:M X)'
945: Similar, but specifies incrementing X instead of decrementing it.
946:
947: These embedded side effect expressions must be used with care.
948: Instruction patterns may not use them. Until the `flow' pass of the
949: compiler, they may occur only to represent pushes onto the stack. The
950: `flow' pass finds cases where registers are incremented or decremented
951: in one instruction and used as an address shortly before or after;
952: these cases are then transformed to use pre- or post-increment or
953: -decrement.
954:
955: If a register used as the operand of these expressions is used in
956: another address in an insn, the original value of the register is used.
957: Uses of the register outside of an address are not permitted within the
958: same insn as a use in an embedded side effect expression because such
959: insns behave differently on different machines and hence must be treated
960: as ambiguous and disallowed.
961:
962: An instruction that can be represented with an embedded side effect
963: could also be represented using `parallel' containing an additional
964: `set' to describe how the address register is altered. This is not
965: done because machines that allow these operations at all typically
966: allow them wherever a memory address is called for. Describing them as
967: additional parallel stores would require doubling the number of entries
968: in the machine description.
969:
970:
971: File: gcc.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
972:
973: Assembler Instructions as Expressions
974: =====================================
975:
976: The RTX code `asm_operands' represents a value produced by a
977: user-specified assembler instruction. It is used to represent an `asm'
978: statement with arguments. An `asm' statement with a single output
979: operand, like this:
980:
981: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
982:
983: is represented using a single `asm_operands' RTX which represents the
984: value that is stored in `outputvar':
985:
986: (set RTX-FOR-OUTPUTVAR
987: (asm_operands "foo %1,%2,%0" "a" 0
988: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
989: [(asm_input:M1 "g")
990: (asm_input:M2 "di")]))
991:
992: Here the operands of the `asm_operands' RTX are the assembler template
993: string, the output-operand's constraint, the index-number of the output
994: operand among the output operands specified, a vector of input operand
995: RTX's, and a vector of input-operand modes and constraints. The mode
996: M1 is the mode of the sum `x+y'; M2 is that of `*z'.
997:
998: When an `asm' statement has multiple output values, its insn has
999: several such `set' RTX's inside of a `parallel'. Each `set' contains a
1000: `asm_operands'; all of these share the same assembler template and
1001: vectors, but each contains the constraint for the respective output
1002: operand. They are also distinguished by the output-operand index
1003: number, which is 0, 1, ... for successive output operands.
1004:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.