![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of
9: this manual provided the copyright notice and this permission notice
10: are preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL
28:
29: Access to Operands
30: ==================
31:
32: For each expression type `rtl.def' specifies the number of contained
33: objects and their kinds, with four possibilities: `e' for expression
34: (actually a pointer to an expression), `i' for integer, `s' for
35: string, and `E' for vector of expressions. The sequence of letters
36: for an expression code is called its "format". Thus, the format of
37: `subreg' is `ei'.
38:
39: A few other format characters are used occasionally:
40:
41: `u'
42: `u' is equivalent to `e' except that it is printed differently in
43: debugging dumps. It is used for pointers to insns.
44:
45: `n'
46: `n' is equivalent to `i' except that it is printed differently in
47: debugging dumps. It is used for the line number or code number
48: of a `note' insn.
49:
50: `S'
51: `S' indicates a string which is optional. In the RTL objects in
52: core, `S' is equivalent to `s', but when the object is read, from
53: an `md' file, the string value of this operand may be omitted.
54: An omitted string is taken to be the null string.
55:
56: `V'
57: `V' indicates a vector which is optional. In the RTL objects in
58: core, `V' is equivalent to `E', but when the object is read from
59: an `md' file, the vector value of this operand may be omitted.
60: An omitted vector is effectively the same as a vector of no
61: elements.
62:
63: `0'
64: `0' means a slot whose contents do not fit any normal category.
65: `0' slots are not printed at all in dumps, and are often used in
66: special ways by small parts of the compiler.
67:
68: There are macros to get the number of operands, the format, and the
69: class of an expression code:
70:
71: `GET_RTX_LENGTH (CODE)'
72: Number of operands of an RTX of code CODE.
73:
74: `GET_RTX_FORMAT (CODE)'
75: The format of an RTX of code CODE, as a C string.
76:
77: `GET_RTX_CLASS (CODE)'
78: A single character representing the type of RTX operation that
79: code CODE performs.
80:
81: The following classes are defined:
82:
83: `o'
84: An RTX code that represents an actual object, such as `reg'
85: or `mem'. `subreg' is not in this class.
86:
87: `<'
88: An RTX code for a comparison. The codes in this class are
89: `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU',
90: `GTU'.
91:
92: `1'
93: An RTX code for a unary arithmetic operation, such as `neg'.
94:
95: `c'
96: An RTX code for a commutative binary operation, other than
97: `NE' and `EQ' (which have class `<').
98:
99: `2'
100: An RTX code for a noncommutative binary operation, such as
101: `MINUS'.
102:
103: `b'
104: An RTX code for a bitfield operation (`ZERO_EXTRACT' and
105: `SIGN_EXTRACT').
106:
107: `3'
108: An RTX code for other three input operations, such as
109: `IF_THEN_ELSE'.
110:
111: `i'
112: An RTX code for a machine insn (`INSN', `JUMP_INSN', and
113: `CALL_INSN').
114:
115: `m'
116: An RTX code for something that matches in insns, such as
117: `MATCH_DUP'.
118:
119: `x'
120: All other RTX codes.
121:
122: Operands of expressions are accessed using the macros `XEXP',
123: `XINT' and `XSTR'. Each of these macros takes two arguments: an
124: expression-pointer (RTX) and an operand number (counting from zero).
125: Thus,
126:
127: XEXP (X, 2)
128:
129: accesses operand 2 of expression X, as an expression.
130:
131: XINT (X, 2)
132:
133: accesses the same operand as an integer. `XSTR', used in the same
134: fashion, would access it as a string.
135:
136: Any operand can be accessed as an integer, as an expression or as a
137: string. You must choose the correct method of access for the kind of
138: value actually stored in the operand. You would do this based on the
139: expression code of the containing expression. That is also how you
140: would know how many operands there are.
141:
142: For example, if X is a `subreg' expression, you know that it has
143: two operands which can be correctly accessed as `XEXP (X, 0)' and
144: `XINT (X, 1)'. If you did `XINT (X, 0)', you would get the address of
145: the expression operand but cast as an integer; that might occasionally
146: be useful, but it would be cleaner to write `(int) XEXP (X, 0)'.
147: `XEXP (X, 1)' would also compile without error, and would return the
148: second, integer operand cast as an expression pointer, which would
149: probably result in a crash when accessed. Nothing stops you from
150: writing `XEXP (X, 28)' either, but this will access memory past the
151: end of the expression with unpredictable results.
152:
153: Access to operands which are vectors is more complicated. You can
154: use the macro `XVEC' to get the vector-pointer itself, or the macros
155: `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
156:
157: `XVEC (EXP, IDX)'
158: Access the vector-pointer which is operand number IDX in EXP.
159:
160: `XVECLEN (EXP, IDX)'
161: Access the length (number of elements) in the vector which is in
162: operand number IDX in EXP. This value is an `int'.
163:
164: `XVECEXP (EXP, IDX, ELTNUM)'
165: Access element number ELTNUM in the vector which is in operand
166: number IDX in EXP. This value is an RTX.
167:
168: It is up to you to make sure that ELTNUM is not negative and is
169: less than `XVECLEN (EXP, IDX)'.
170:
171: All the macros defined in this section expand into lvalues and
172: therefore can be used to assign the operands, lengths and vector
173: elements as well as to access them.
174:
175:
176: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL
177:
178: Flags in an RTL Expression
179: ==========================
180:
181: RTL expressions contain several flags (one-bit bit-fields) that are
182: used in certain types of expression. Most often they are accessed
183: with the following macros:
184:
185: `MEM_VOLATILE_P (X)'
186: In `mem' expressions, nonzero for volatile memory references.
187: Stored in the `volatil' field and printed as `/v'.
188:
189: `MEM_IN_STRUCT_P (X)'
190: In `mem' expressions, nonzero for reference to an entire
191: structure, union or array, or to a component of one. Zero for
192: references to a scalar variable or through a pointer to a scalar.
193: Stored in the `in_struct' field and printed as `/s'.
194:
195: `REG_LOOP_TEST_P'
196: In `reg' expressions, nonzero if this register's entire life is
197: contained in the exit test code for some loop. Stored in the
198: `in_struct' field and printed as `/s'.
199:
200: `REG_USERVAR_P (X)'
201: In a `reg', nonzero if it corresponds to a variable present in
202: the user's source code. Zero for temporaries generated
203: internally by the compiler. Stored in the `volatil' field and
204: printed as `/v'.
205:
206: `REG_FUNCTION_VALUE_P (X)'
207: Nonzero in a `reg' if it is the place in which this function's
208: value is going to be returned. (This happens only in a hard
209: register.) Stored in the `integrated' field and printed as `/i'.
210:
211: The same hard register may be used also for collecting the values
212: of functions called by this one, but `REG_FUNCTION_VALUE_P' is
213: zero in this kind of use.
214:
215: `RTX_UNCHANGING_P (X)'
216: Nonzero in a `reg' or `mem' if the value is not changed. (This
217: flag is not set for memory references via pointers to constants.
218: Such pointers only guarantee that the object will not be changed
219: explicitly by the current function. The object might be changed
220: by other functions or by aliasing.) Stored in the `unchanging'
221: field and printed as `/u'.
222:
223: `RTX_INTEGRATED_P (INSN)'
224: Nonzero in an insn if it resulted from an in-line function call.
225: Stored in the `integrated' field and printed as `/i'. This may
226: be deleted; nothing currently depends on it.
227:
228: `SYMBOL_REF_USED (X)'
229: In a `symbol_ref', indicates that X has been used. This is
230: normally only used to ensure that X is only declared external
231: once. Stored in the `used' field.
232:
233: `SYMBOL_REF_FLAG (X)'
234: In a `symbol_ref', this is used as a flag for machine-specific
235: purposes. Stored in the `volatil' field and printed as `/v'.
236:
237: `LABEL_OUTSIDE_LOOP_P'
238: In `label_ref' expressions, nonzero if this is a reference to a
239: label that is outside the innermost loop containing the reference
240: to the label. Stored in the `in_struct' field and printed as
241: `/s'.
242:
243: `INSN_DELETED_P (INSN)'
244: In an insn, nonzero if the insn has been deleted. Stored in the
245: `volatil' field and printed as `/v'.
246:
247: `INSN_ANNULLED_BRANCH_P (INSN)'
248: In an `insn' in the delay slot of a branch insn, indicates that an
249: annulling branch should be used. See the discussion under
250: `sequence' below. Stored in the `unchanging' field and printed
251: as `/u'.
252:
253: `INSN_FROM_TARGET_P (INSN)'
254: In an `insn' in a delay slot of a branch, indicates that the insn
255: is from the target of the branch. If the branch insn has
256: `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if
257: the branch is taken. For annulled branches with this bit clear,
258: the insn should be executed only if the branch is not taken.
259: Stored in the `in_struct' field and printed as `/s'.
260:
261: `CONSTANT_POOL_ADDRESS_P (X)'
262: Nonzero in a `symbol_ref' if it refers to part of the current
263: function's "constants pool". These are addresses close to the
264: beginning of the function, and GNU CC assumes they can be
265: addressed directly (perhaps with the help of base registers).
266: Stored in the `unchanging' field and printed as `/u'.
267:
268: `CONST_CALL_P (X)'
269: In a `call_insn', indicates that the insn represents a call to a
270: const function. Stored in the `unchanging' field and printed as
271: `/u'.
272:
273: `LABEL_PRESERVE_P (X)'
274: In a `code_label', indicates that the label can never be deleted.
275: Labels referenced by a a non-local goto will have this bit set.
276: Stored in the `in_struct' field and printed as `/s'.
277:
278: `SCHED_GROUP_P (INSN)'
279: During instruction scheduling, in an insn, indicates that the
280: previous insn must be scheduled together with this insn. This is
281: used to ensure that certain groups of instructions will not be
282: split up by the instruction scheduling pass, for example, `use'
283: insns before a `call_insn' may not be separated from the
284: `call_insn'. Stored in the `in_struct' field and printed as `/s'.
285:
286: These are the fields which the above macros refer to:
287:
288: `used'
289: Normally, this flag is used only momentarily, at the end of RTL
290: generation for a function, to count the number of times an
291: expression appears in insns. Expressions that appear more than
292: once are copied, according to the rules for shared structure
293: (*note Sharing::.).
294:
295: In a `symbol_ref', it indicates that an external declaration for
296: the symbol has already been written.
297:
298: In a `reg', it is used by the leaf register renumbering code to
299: ensure that each register is only renumbered once.
300:
301: `volatil'
302: This flag is used in `mem',`symbol_ref' and `reg' expressions and
303: in insns. In RTL dump files, it is printed as `/v'.
304:
305: In a `mem' expression, it is 1 if the memory reference is
306: volatile. Volatile memory references may not be deleted,
307: reordered or combined.
308:
309: In a `symbol_ref' expression, it is used for machine-specific
310: purposes.
311:
312: In a `reg' expression, it is 1 if the value is a user-level
313: variable. 0 indicates an internal compiler temporary.
314:
315: In an insn, 1 means the insn has been deleted.
316:
317: `in_struct'
318: In `mem' expressions, it is 1 if the memory datum referred to is
319: all or part of a structure or array; 0 if it is (or might be) a
320: scalar variable. A reference through a C pointer has 0 because
321: the pointer might point to a scalar variable. This information
322: allows the compiler to determine something about possible cases
323: of aliasing.
324:
325: In an insn in the delay slot of a branch, 1 means that this insn
326: is from the target of the branch.
327:
328: During instruction scheduling, in an insn, 1 means that this insn
329: must be scheduled as part of a group together with the previous
330: insn.
331:
332: In `reg' expressions, it is 1 if the register has its entire life
333: contained within the test expression of some loopl.
334:
335: In `label_ref' expressions, 1 means that the referenced label is
336: outside the innermost loop containing the insn in which the
337: `label_ref' was found.
338:
339: In `code_label' expressions, it is 1 if the label may never be
340: deleted. This is used for labels which are the target of
341: non-local gotos.
342:
343: In an RTL dump, this flag is represented as `/s'.
344:
345: `unchanging'
346: In `reg' and `mem' expressions, 1 means that the value of the
347: expression never changes.
348:
349: In an insn, 1 means that this is an annulling branch.
350:
351: In a `symbol_ref' expression, 1 means that this symbol addresses
352: something in the per-function constants pool.
353:
354: In a `call_insn', 1 means that this instruction is a call to a
355: const function.
356:
357: In an RTL dump, this flag is represented as `/u'.
358:
359: `integrated'
360: In some kinds of expressions, including insns, this flag means the
361: rtl was produced by procedure integration.
362:
363: In a `reg' expression, this flag indicates the register
364: containing the value to be returned by the current function. On
365: machines that pass parameters in registers, the same register
366: number may be used for parameters as well, but this flag is not
367: set on such uses.
368:
369:
370: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
371:
372: Machine Modes
373: =============
374:
375: A machine mode describes a size of data object and the
376: representation used for it. In the C code, machine modes are
377: represented by an enumeration type, `enum machine_mode', defined in
378: `machmode.def'. Each RTL expression has room for a machine mode and
379: so do certain kinds of tree expressions (declarations and types, to be
380: precise).
381:
382: In debugging dumps and machine descriptions, the machine mode of an
383: RTL expression is written after the expression code with a colon to
384: separate them. The letters `mode' which appear at the end of each
385: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg'
386: expression with machine mode `SImode'. If the mode is `VOIDmode', it
387: is not written at all.
388:
389: Here is a table of machine modes. The term "byte" below refers to
390: an object of `BITS_PER_UNIT' bits (*note Storage Layout::.).
391:
392: `QImode'
393: "Quarter-Integer" mode represents a single byte treated as an
394: integer.
395:
396: `HImode'
397: "Half-Integer" mode represents a two-byte integer.
398:
399: `PSImode'
400: "Partial Single Integer" mode represents an integer which occupies
401: four bytes but which doesn't really use all four. On some
402: machines, this is the right mode to use for pointers.
403:
404: `SImode'
405: "Single Integer" mode represents a four-byte integer.
406:
407: `PDImode'
408: "Partial Double Integer" mode represents an integer which occupies
409: eight bytes but which doesn't really use all eight. On some
410: machines, this is the right mode to use for certain pointers.
411:
412: `DImode'
413: "Double Integer" mode represents an eight-byte integer.
414:
415: `TImode'
416: "Tetra Integer" (?) mode represents a sixteen-byte integer.
417:
418: `SFmode'
419: "Single Floating" mode represents a single-precision (four byte)
420: floating point number.
421:
422: `DFmode'
423: "Double Floating" mode represents a double-precision (eight byte)
424: floating point number.
425:
426: `XFmode'
427: "Extended Floating" mode represents a triple-precision (twelve
428: byte) floating point number. This mode is used for IEEE extended
429: floating point.
430:
431: `TFmode'
432: "Tetra Floating" mode represents a quadruple-precision (sixteen
433: byte) floating point number.
434:
435: `CCmode'
436: "Condition Code" mode represents the value of a condition code,
437: which is a machine-specific set of bits used to represent the
438: result of a comparison operation. Other machine-specific modes
439: may also be used for the condition code. These modes are not
440: used on machines that use `cc0' (see *note Condition Code::.).
441:
442: `BLKmode'
443: "Block" mode represents values that are aggregates to which none
444: of the other modes apply. In RTL, only memory references can
445: have this mode, and only if they appear in string-move or vector
446: instructions. On machines which have no such instructions,
447: `BLKmode' will not appear in RTL.
448:
449: `VOIDmode'
450: Void mode means the absence of a mode or an unspecified mode.
451: For example, RTL expressions of code `const_int' have mode
452: `VOIDmode' because they can be taken to have whatever mode the
453: context requires. In debugging dumps of RTL, `VOIDmode' is
454: expressed by the absence of any mode.
455:
456: `SCmode, DCmode, XCmode, TCmode'
457: These modes stand for a complex number represented as a pair of
458: floating point values. The values are in `SFmode', `DFmode',
459: `XFmode', and `TFmode', respectively. Since C does not support
460: complex numbers, these machine modes are only partially
461: implemented.
462:
463: The machine description defines `Pmode' as a C macro which expands
464: into the machine mode used for addresses. Normally this is the mode
465: whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
466:
467: The only modes which a machine description must support are
468: `QImode', and the modes corresponding to `BITS_PER_WORD',
469: `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt
470: to use `DImode' for 8-byte structures and unions, but this can be
471: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'.
472: Alternatively, you can have the compiler use `TImode' for 16-byte
473: structures and unions. Likewise, you can arrange for the C type
474: `short int' to avoid using `HImode'.
475:
476: Very few explicit references to machine modes remain in the
477: compiler and these few references will soon be removed. Instead, the
478: machine modes are divided into mode classes. These are represented by
479: the enumeration type `enum mode_class' defined in `machmode.h'. The
480: possible mode classes are:
481:
482: `MODE_INT'
483: Integer modes. By default these are `QImode', `HImode',
484: `SImode', `DImode', and `TImode'.
485:
486: `MODE_PARTIAL_INT'
487: The "partial integer" modes, `PSImode' and `PDImode'.
488:
489: `MODE_FLOAT'
490: floating point modes. By default these are `SFmode', `DFmode',
491: `XFmode' and `TFmode'.
492:
493: `MODE_COMPLEX_INT'
494: Complex integer modes. (These are not currently implemented).
495:
496: `MODE_COMPLEX_FLOAT'
497: Complex floating point modes. By default these are `SCmode',
498: `DCmode', `XCmode', and `TCmode'.
499:
500: `MODE_FUNCTION'
501: Algol or Pascal function variables including a static chain.
502: (These are not currently implemented).
503:
504: `MODE_CC'
505: Modes representing condition code values. These are `CCmode' plus
506: any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump
507: Patterns::, also see *Note Condition Code::.
508:
509: `MODE_RANDOM'
510: This is a catchall mode class for modes which don't fit into the
511: above classes. Currently `VOIDmode' and `BLKmode' are in
512: `MODE_RANDOM'.
513:
514: Here are some C macros that relate to machine modes:
515:
516: `GET_MODE (X)'
517: Returns the machine mode of the RTX X.
518:
519: `PUT_MODE (X, NEWMODE)'
520: Alters the machine mode of the RTX X to be NEWMODE.
521:
522: `NUM_MACHINE_MODES'
523: Stands for the number of machine modes available on the target
524: machine. This is one greater than the largest numeric value of
525: any machine mode.
526:
527: `GET_MODE_NAME (M)'
528: Returns the name of mode M as a string.
529:
530: `GET_MODE_CLASS (M)'
531: Returns the mode class of mode M.
532:
533: `GET_MODE_WIDER_MODE (M)'
534: Returns the next wider natural mode. E.g.,
535: `GET_WIDER_MODE(QImode)' returns `HImode'.
536:
537: `GET_MODE_SIZE (M)'
538: Returns the size in bytes of a datum of mode M.
539:
540: `GET_MODE_BITSIZE (M)'
541: Returns the size in bits of a datum of mode M.
542:
543: `GET_MODE_MASK (M)'
544: Returns a bitmask containing 1 for all bits in a word that fit
545: within mode M. This macro can only be used for modes whose
546: bitsize is less than or equal to `HOST_BITS_PER_INT'.
547:
548: `GET_MODE_ALIGNMENT (M))'
549: Return the required alignment, in bits, for an object of mode M.
550:
551: `GET_MODE_UNIT_SIZE (M)'
552: Returns the size in bytes of the subunits of a datum of mode M.
553: This is the same as `GET_MODE_SIZE' except in the case of complex
554: modes. For them, the unit size is the size of the real or
555: imaginary part.
556:
557: `GET_MODE_NUNITS (M)'
558: Returns the number of units contained in a mode, i.e.,
559: `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
560:
561: `GET_CLASS_NARROWEST_MODE (C)'
562: Returns the narrowest mode in mode class C.
563:
564: The global variables `byte_mode' and `word_mode' contain modes
565: whose classes are `MODE_INT' and whose bitsizes are `BITS_PER_UNIT' or
566: `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
567: and `SImode', respectively.
568:
569:
570: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
571:
572: Constant Expression Types
573: =========================
574:
575: The simplest RTL expressions are those that represent constant
576: values.
577:
578: `(const_int I)'
579: This type of expression represents the integer value I. I is
580: customarily accessed with the macro `INTVAL' as in `INTVAL
581: (EXP)', which is equivalent to `XINT (EXP, 0)'.
582:
583: Keep in mind that the result of `INTVAL' is an integer on the host
584: machine. If the host machine has more bits in an `int' than the
585: target machine has in the mode in which the constant will be
586: used, then some of the bits you get from `INTVAL' will be
587: superfluous. In many cases, for proper results, you must
588: carefully disregard the values of those bits.
589:
590: There is only one expression object for the integer value zero;
591: it is the value of the variable `const0_rtx'. Likewise, the only
592: expression for integer value one is found in `const1_rtx', the
593: only expression for integer value two is found in `const2_rtx',
594: and the only expression for integer value negative one is found in
595: `constm1_rtx'. Any attempt to create an expression of code
596: `const_int' and value zero, one, two or negative one will return
597: `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
598: appropriate.
599:
600: Similarly, there is only one object for the integer whose value is
601: `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
602: `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
603: point to the same object. If `STORE_FLAG_VALUE' is -1,
604: `const_true_rtx' and `constm1_rtx' will point to the same object.
605:
606: `(const_double:M ADDR I0 I1 ...)'
607: Represents either a floating-point constant of mode M or an
608: integer constant that is too large to fit into `HOST_BITS_PER_INT'
609: bits but small enough to fit within twice that number of bits
610: (GNU CC does not provide a mechanism to represent even larger
611: constants). In the latter case, M will be `VOIDmode'.
612:
613: ADDR is used to contain the `mem' expression that corresponds to
614: the location in memory that at which the constant can be found.
615: If it has not been allocated a memory location, but is on the
616: chain of all `const_double' expressions in this compilation
617: (maintained using an undisplayed field), ADDR contains
618: `const0_rtx'. If it is not on the chain, ADDR contains
619: `cc0_rtx'. ADDR is customarily accessed with the macro
620: `CONST_DOUBLE_MEM' and the chain field via `CONST_DOUBLE_CHAIN'.
621:
622: If M is `VOIDmode', the bit of the value are stored in I0 and I1.
623: I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
624: I1 with `CONST_DOUBLE_HIGH'.
625:
626: If the constant is floating point (either single or double
627: precision), then the number of integers used to store the value
628: depends on the size of `REAL_VALUE_TYPE' (*note
629: Cross-compilation::.). The integers represent a `double'. To
630: convert them to a `double', do
631:
632: union real_extract u;
633: bcopy (&CONST_DOUBLE_LOW (x), &u, sizeof u);
634:
635: and then refer to `u.d'.
636:
637: The macro `CONST0_RTX (MODE)' refers to an expression with value
638: 0 in mode MODE. If mode MODE is of mode class `MODE_INT', it
639: returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE'
640: expression in mode MODE. Similarly, the macro `CONST1_RTX
641: (MODE)' refers to an expression with value 1 in mode MODE and
642: similarly for `CONST2_RTX'.
643:
644: `(const_string STR)'
645: Represents a constant string with value STR. Currently this is
646: used only for insn attributes (*note Insn Attributes::.) since
647: constant strings in C are placed in memory.
648:
649: `(symbol_ref SYMBOL)'
650: Represents the value of an assembler label for data. SYMBOL is a
651: string that describes the name of the assembler label. If it
652: starts with a `*', the label is the rest of SYMBOL not including
653: the `*'. Otherwise, the label is SYMBOL, usually prefixed with
654: `_'.
655:
656: `(label_ref LABEL)'
657: Represents the value of an assembler label for code. It contains
658: one operand, an expression, which must be a `code_label' that
659: appears in the instruction sequence to identify the place where
660: the label should go.
661:
662: The reason for using a distinct expression type for code label
663: references is so that jump optimization can distinguish them.
664:
665: `(const:M EXP)'
666: Represents a constant that is the result of an assembly-time
667: arithmetic computation. The operand, EXP, is an expression that
668: contains only constants (`const_int', `symbol_ref' and
669: `label_ref' expressions) combined with `plus' and `minus'.
670: However, not all combinations are valid, since the assembler
671: cannot do arbitrary arithmetic on relocatable symbols.
672:
673: M should be `Pmode'.
674:
675: `(high:M EXP)'
676: Represents the high-order bits of EXP, usually a `symbol_ref'.
677: The number of bits is machine-dependent and is normally the
678: number of bits specified in an instruction that initializes the
679: high order bits of a register. It is used with `lo_sum' to
680: represent the typical two-instruction sequence used in RISC
681: machines to reference a global memory location.
682:
683: M should be `Pmode'.
684:
685:
686: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
687:
688: Registers and Memory
689: ====================
690:
691: Here are the RTL expression types for describing access to machine
692: registers and to main memory.
693:
694: `(reg:M N)'
695: For small values of the integer N (less than
696: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
697: register number N: a "hard register". For larger values of N, it
698: stands for a temporary value or "pseudo register". The
699: compiler's strategy is to generate code assuming an unlimited
700: number of such pseudo registers, and later convert them into hard
701: registers or into memory references.
702:
703: M is the machine mode of the reference. It is necessary because
704: machines can generally refer to each register in more than one
705: mode. For example, a register may contain a full word but there
706: may be instructions to refer to it as a half word or as a single
707: byte, as well as instructions to refer to it as a floating point
708: number of various precisions.
709:
710: Even for a register that the machine can access in only one mode,
711: the mode must always be specified.
712:
713: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
714: description, since the number of hard registers on the machine is
715: an invariant characteristic of the machine. Note, however, that
716: not all of the machine registers must be general registers. All
717: the machine registers that can be used for storage of data are
718: given hard register numbers, even those that can be used only in
719: certain instructions or can hold only certain types of data.
720:
721: A hard register may be accessed in various modes throughout one
722: function, but each pseudo register is given a natural mode and is
723: accessed only in that mode. When it is necessary to describe an
724: access to a pseudo register using a nonnatural mode, a `subreg'
725: expression is used.
726:
727: A `reg' expression with a machine mode that specifies more than
728: one word of data may actually stand for several consecutive
729: registers. If in addition the register number specifies a
730: hardware register, then it actually represents several
731: consecutive hardware registers starting with the specified one.
732:
733: Each pseudo register number used in a function's RTL code is
734: represented by a unique `reg' expression.
735:
736: Some pseudo register numbers, those within the range of
737: `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
738: during the RTL generation phase and are eliminated before the
739: optimization phases. These represent locations in the stack
740: frame that cannot be determined until RTL generation for the
741: function has been completed. The following virtual register
742: numbers are defined:
743:
744: `VIRTUAL_INCOMING_ARGS_REGNUM'
745: This points to the first word of the incoming arguments
746: passed on the stack. Normally these arguments are placed
747: there by the caller, but the callee may have pushed some
748: arguments that were previously passed in registers.
749:
750: When RTL generation is complete, this virtual register is
751: replaced by the sum of the register given by
752: `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
753:
754: `VIRTUAL_STACK_VARS_REGNUM'
755: If `FRAME_GROWS_DOWNWARDS' is defined, this points to
756: immediately above the first variable on the stack.
757: Otherwise, it points to the first variable on the stack.
758:
759: It is replaced with the sum of the register given by
760: `FRAME_POINTER_REGNUM' and the value `STARTING_FRAME_OFFSET'.
761:
762: `VIRTUAL_STACK_DYNAMIC_REGNUM'
763: This points to the location of dynamically allocated memory
764: on the stack immediately after the stack pointer has been
765: adjusted by the amount of memory desired.
766:
767: It is replaced by the sum of the register given by
768: `STACK_POINTER_REGNUM' and the value `STACK_DYNAMIC_OFFSET'.
769:
770: `VIRTUAL_OUTGOING_ARGS_REGNUM'
771: This points to the location in the stack at which outgoing
772: arguments should be written when the stack is pre-pushed
773: (arguments pushed using push insns should always use
774: `STACK_POINTER_REGNUM').
775:
776: It is replaced by the sum of the register given by
777: `STACK_POINTER_REGNUM' and the value `STACK_POINTER_OFFSET'.
778:
779: `(subreg:M REG WORDNUM)'
780: `subreg' expressions are used to refer to a register in a machine
781: mode other than its natural one, or to refer to one register of a
782: multi-word `reg' that actually refers to several registers.
783:
784: Each pseudo-register has a natural mode. If it is necessary to
785: operate on it in a different mode--for example, to perform a
786: fullword move instruction on a pseudo-register that contains a
787: single byte--the pseudo-register must be enclosed in a `subreg'.
788: In such a case, WORDNUM is zero.
789:
790: Usually M is at least as narrow as the mode of REG, in which case
791: it is restricting consideration to only the bits of REG that are
792: in M. However, sometimes M is wider than the mode of REG. These
793: `subreg' expressions are often called "paradoxical". They are
794: used in cases where we want to refer to an object in a wider mode
795: but do not care what value the additional bits have. The reload
796: pass ensures that paradoxical references are only made to hard
797: registers.
798:
799: The other use of `subreg' is to extract the individual registers
800: of a multi-register value. Machine modes such as `DImode' and
801: `TImode' can indicate values longer than a word, values which
802: usually require two or more consecutive registers. To access one
803: of the registers, use a `subreg' with mode `SImode' and a WORDNUM
804: that says which register.
805:
806: The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says
807: that word number zero is the most significant part; otherwise, it
808: is the least significant part.
809:
810: Between the combiner pass and the reload pass, it is possible to
811: have a paradoxical `subreg' which contains a `mem' instead of a
812: `reg' as its first operand. After the reload pass, it is also
813: possible to have a non-paradoxical `subreg' which contains a
814: `mem'; this usually occurs when the `mem' is a stack slot which
815: replaced a pseudo register.
816:
817: Note that it is not valid to access a `DFmode' value in `SFmode'
818: using a `subreg'. On some machines the most significant part of a
819: `DFmode' value does not have the same format as a single-precision
820: floating value.
821:
822: It is also not valid to access a single word of a multi-word
823: value in a hard register when less registers can hold the value
824: than would be expected from its size. For example, some 32-bit
825: machines have floating-point registers that can hold an entire
826: `DFmode' value. If register 10 were such a register `(subreg:SI
827: (reg:DF 10) 1)' would be invalid because there is no way to
828: convert that reference to a single machine register. The reload
829: pass prevents `subreg' expressions such as these from being
830: formed.
831:
832: The first operand of a `subreg' expression is customarily accessed
833: with the `SUBREG_REG' macro and the second operand is customarily
834: accessed with the `SUBREG_WORD' macro.
835:
836: `(scratch:M)'
837: This represents a scratch register that will be required for the
838: execution of a single instruction and not used subsequently. It
839: is converted into a `reg' by either the local register allocator
840: or the reload pass.
841:
842: `scratch' is usually present inside a `clobber' operation (*note
843: Side Effects::.).
844:
845: `(cc0)'
846: This refers to the machine's condition code register. It has no
847: operands and may not have a machine mode. There are two ways to
848: use it:
849:
850: * To stand for a complete set of condition code flags. This
851: is best on most machines, where each comparison sets the
852: entire series of flags.
853:
854: With this technique, `(cc0)' may be validly used in only two
855: contexts: as the destination of an assignment (in test and
856: compare instructions) and in comparison operators comparing
857: against zero (`const_int' with value zero; that is to say,
858: `const0_rtx').
859:
860: * To stand for a single flag that is the result of a single
861: condition. This is useful on machines that have only a
862: single flag bit, and in which comparison instructions must
863: specify the condition to test.
864:
865: With this technique, `(cc0)' may be validly used in only two
866: contexts: as the destination of an assignment (in test and
867: compare instructions) where the source is a comparison
868: operator, and as the first operand of `if_then_else' (in a
869: conditional branch).
870:
871: There is only one expression object of code `cc0'; it is the
872: value of the variable `cc0_rtx'. Any attempt to create an
873: expression of code `cc0' will return `cc0_rtx'.
874:
875: Instructions can set the condition code implicitly. On many
876: machines, nearly all instructions set the condition code based on
877: the value that they compute or store. It is not necessary to
878: record these actions explicitly in the RTL because the machine
879: description includes a prescription for recognizing the
880: instructions that do so (by means of the macro
881: `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
882: whose sole purpose is to set the condition code, and instructions
883: that use the condition code, need mention `(cc0)'.
884:
885: On some machines, the condition code register is given a register
886: number and a `reg' is used instead of `(cc0)'. This is usually
887: the preferable approach if only a small subset of instructions
888: modify the condition code. Other machines store condition codes
889: in general registers; in such cases a pseudo register should be
890: used.
891:
892: Some machines, such as the Sparc and RS/6000, have two sets of
893: arithmetic instructions, one that sets and one that does not set
894: the condition code. This is best handled by normally generating
895: the instruction that does not set the condition code, and making
896: a pattern that both performs the arithmetic and sets the
897: condition code register (which would not be `(cc0)' in this
898: case). For examples, search for `addcc' and `andcc' in
899: `sparc.md'.
900:
901: `(pc)'
902: This represents the machine's program counter. It has no
903: operands and may not have a machine mode. `(pc)' may be validly
904: used only in certain specific contexts in jump instructions.
905:
906: There is only one expression object of code `pc'; it is the value
907: of the variable `pc_rtx'. Any attempt to create an expression of
908: code `pc' will return `pc_rtx'.
909:
910: All instructions that do not jump alter the program counter
911: implicitly by incrementing it, but there is no need to mention
912: this in the RTL.
913:
914: `(mem:M ADDR)'
915: This RTX represents a reference to main memory at an address
916: represented by the expression ADDR. M specifies how large a unit
917: of memory is accessed.
918:
919:
920: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
921:
922: RTL Expressions for Arithmetic
923: ==============================
924:
925: Unless otherwise specified, all the operands of arithmetic
926: expressions must be valid for mode M. An operand is valid for mode M
927: if it has mode M, or if it is a `const_int' or `const_double' and M is
928: a mode of class `MODE_INT'.
929:
930: For commutative binary operations, constants should be placed in the
931: second operand.
932:
933: `(plus:M X Y)'
934: Represents the sum of the values represented by X and Y carried
935: out in machine mode M.
936:
937: `(lo_sum:M X Y)'
938: Like `plus', except that it represents that sum of X and the
939: low-order bits of Y. The number of low order bits is
940: machine-dependent but is normally the number of bits in a `Pmode'
941: item minus the number of bits set by the `high' code (*note
942: Constants::.).
943:
944: M should be `Pmode'.
945:
946: `(minus:M X Y)'
947: Like `plus' but represents subtraction.
948:
949: `(compare:M X Y)'
950: Represents the result of subtracting Y from X for purposes of
951: comparison. The result is computed without overflow, as if with
952: infinite precision.
953:
954: Of course, machines can't really subtract with infinite precision.
955: However, they can pretend to do so when only the sign of the
956: result will be used, which is the case when the result is stored
957: in the condition code. And that is the only way this kind of
958: expression may validly be used: as a value to be stored in the
959: condition codes.
960:
961: The mode M is not related to the modes of X and Y, but instead is
962: the mode of the condition code value. If `(cc0)' is used, it is
963: `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
964: `CCmode'. *Note Condition Code::.
965:
966: Normally, X and Y must have the same mode. Otherwise, `compare'
967: is valid only if the mode of X is in class `MODE_INT' and Y is a
968: `const_int' or `const_double' with mode `VOIDmode'. The mode of X
969: determines what mode the comparison is to be done in; thus it
970: must not be `VOIDmode'.
971:
972: If one of the operands is a constant, it should be placed in the
973: second operand and the comparison code adjusted as appropriate.
974:
975: A `compare' specifying two `VOIDmode' constants is not valid
976: since there is no way to know in what mode the comparison is to be
977: performed; the comparison must either be folded during the
978: compilation or the first operand must be loaded into a register
979: while its mode is still known.
980:
981: `(neg:M X)'
982: Represents the negation (subtraction from zero) of the value
983: represented by X, carried out in mode M.
984:
985: `(mult:M X Y)'
986: Represents the signed product of the values represented by X and
987: Y carried out in machine mode M.
988:
989: Some machines support a multiplication that generates a product
990: wider than the operands. Write the pattern for this as
991:
992: (mult:M (sign_extend:M X) (sign_extend:M Y))
993:
994: where M is wider than the modes of X and Y, which need not be the
995: same.
996:
997: Write patterns for unsigned widening multiplication similarly
998: using `zero_extend'.
999:
1000: `(div:M X Y)'
1001: Represents the quotient in signed division of X by Y, carried out
1002: in machine mode M. If M is a floating point mode, it represents
1003: the exact quotient; otherwise, the integerized quotient.
1004:
1005: Some machines have division instructions in which the operands and
1006: quotient widths are not all the same; you should represent such
1007: instructions using `truncate' and `sign_extend' as in,
1008:
1009: (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
1010:
1011: `(udiv:M X Y)'
1012: Like `div' but represents unsigned division.
1013:
1014: `(mod:M X Y)'
1015: `(umod:M X Y)'
1016: Like `div' and `udiv' but represent the remainder instead of the
1017: quotient.
1018:
1019: `(smin:M X Y)'
1020: `(smax:M X Y)'
1021: Represents the smaller (for `smin') or larger (for `smax') of X
1022: and Y, interpreted as signed integers in mode M.
1023:
1024: `(umin:M X Y)'
1025: `(umax:M X Y)'
1026: Like `smin' and `smax', but the values are interpreted as unsigned
1027: integers.
1028:
1029: `(not:M X)'
1030: Represents the bitwise complement of the value represented by X,
1031: carried out in mode M, which must be a fixed-point machine mode.
1032:
1033: `(and:M X Y)'
1034: Represents the bitwise logical-and of the values represented by X
1035: and Y, carried out in machine mode M, which must be a fixed-point
1036: machine mode.
1037:
1038: `(ior:M X Y)'
1039: Represents the bitwise inclusive-or of the values represented by X
1040: and Y, carried out in machine mode M, which must be a fixed-point
1041: mode.
1042:
1043: `(xor:M X Y)'
1044: Represents the bitwise exclusive-or of the values represented by X
1045: and Y, carried out in machine mode M, which must be a fixed-point
1046: mode.
1047:
1048: `(ashift:M X C)'
1049: Represents the result of arithmetically shifting X left by C
1050: places. X have mode M, a fixed-point machine mode. C be a
1051: fixed-point mode or be a constant with mode `VOIDmode'; which
1052: mode is determined by the mode called for in the machine
1053: description entry for the left-shift instruction. For example,
1054: on the Vax, the mode of C is `QImode' regardless of M.
1055:
1056: `(lshift:M X C)'
1057: Like `lshift' but for arithmetic left shift. `ashift' and
1058: `lshift' are identical operations; we customarily use `ashift'
1059: for both.
1060:
1061: `(lshiftrt:M X C)'
1062: `(ashiftrt:M X C)'
1063: Like `lshift' and `ashift' but for right shift. Unlike the case
1064: for left shift, these two operations are distinct.
1065:
1066: `(rotate:M X C)'
1067: `(rotatert:M X C)'
1068: Similar but represent left and right rotate. If C is a constant,
1069: use `rotate'.
1070:
1071: `(abs:M X)'
1072: Represents the absolute value of X, computed in mode M.
1073:
1074: `(sqrt:M X)'
1075: Represents the square root of X, computed in mode M. Most often
1076: M will be a floating point mode.
1077:
1078: `(ffs:M X)'
1079: Represents one plus the index of the least significant 1-bit in
1080: X, represented as an integer of mode M. (The value is zero if X
1081: is zero.) The mode of X need not be M; depending on the target
1082: machine, various mode combinations may be valid.
1083:
1084:
1085: File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL
1086:
1087: Comparison Operations
1088: =====================
1089:
1090: Comparison operators test a relation on two operands and are
1091: considered to represent a machine-dependent nonzero value described
1092: by, but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.)
1093: if the relation holds, or zero if it does not. The mode of the
1094: comparison operation is independent of the mode of the data being
1095: compared. If the comparison operation is being tested (e.g., the first
1096: operand of an `if_then_else'), the mode must be `VOIDmode'. If the
1097: comparison operation is producing data to be stored in some variable,
1098: the mode must be in class `MODE_INT'. All comparison operations
1099: producing data must use the same mode, which is machine-specific.
1100:
1101: There are two ways that comparison operations may be used. The
1102: comparison operators may be used to compare the condition codes
1103: `(cc0)' against zero, as in `(eq (cc0) (const_int 0))'. Such a
1104: construct actually refers to the result of the preceding instruction
1105: in which the condition codes were set. The instructing setting the
1106: condition code must be adjacent to the instruction using the condition
1107: code; only `note' insns may separate them.
1108:
1109: Alternatively, a comparison operation may directly compare two data
1110: objects. The mode of the comparison is determined by the operands;
1111: they must both be valid for a common machine mode. A comparison with
1112: both operands constant would be invalid as the machine mode could not
1113: be deduced from it, but such a comparison should never exist in RTL
1114: due to constant folding.
1115:
1116: In the example above, if `(cc0)' were last set to `(compare X Y)',
1117: the comparison operation is identical to `(eq X Y)'. Usually only one
1118: style of comparisons is supported on a particular machine, but the
1119: combine pass will try to merge the operations to produce the `eq' shown
1120: in case it exists in the context of the particular insn involved.
1121:
1122: Inequality comparisons come in two flavors, signed and unsigned.
1123: Thus, there are distinct expression codes `gt' and `gtu' for signed and
1124: unsigned greater-than. These can produce different results for the
1125: same pair of integer values: for example, 1 is signed greater-than -1
1126: but not unsigned greater-than, because -1 when regarded as unsigned is
1127: actually `0xffffffff' which is greater than 1.
1128:
1129: The signed comparisons are also used for floating point values.
1130: Floating point comparisons are distinguished by the machine modes of
1131: the operands.
1132:
1133: `(eq:M X Y)'
1134: 1 if the values represented by X and Y are equal, otherwise 0.
1135:
1136: `(ne:M X Y)'
1137: 1 if the values represented by X and Y are not equal, otherwise 0.
1138:
1139: `(gt:M X Y)'
1140: 1 if the X is greater than Y. If they are fixed-point, the
1141: comparison is done in a signed sense.
1142:
1143: `(gtu:M X Y)'
1144: Like `gt' but does unsigned comparison, on fixed-point numbers
1145: only.
1146:
1147: `(lt:M X Y)'
1148: `(ltu:M X Y)'
1149: Like `gt' and `gtu' but test for "less than".
1150:
1151: `(ge:M X Y)'
1152: `(geu:M X Y)'
1153: Like `gt' and `gtu' but test for "greater than or equal".
1154:
1155: `(le:M X Y)'
1156: `(leu:M X Y)'
1157: Like `gt' and `gtu' but test for "less than or equal".
1158:
1159: `(if_then_else COND THEN ELSE)'
1160: This is not a comparison operation but is listed here because it
1161: is always used in conjunction with a comparison operation. To be
1162: precise, COND is a comparison expression. This expression
1163: represents a choice, according to COND, between the value
1164: represented by THEN and the one represented by ELSE.
1165:
1166: On most machines, `if_then_else' expressions are valid only to
1167: express conditional jumps.
1168:
1169: `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
1170: Similar to `if_then_else', but more general. Each of TEST1,
1171: TEST2, ... is performed in turn. The result of this expression is
1172: the VALUE corresponding to the first non-zero test, or DEFAULT if
1173: none of the tests are non-zero expressions.
1174:
1175: This is currently not valid for instruction patterns and is
1176: supported only for insn attributes. *Note Insn Attributes::.
1177:
1178:
1179: File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL
1180:
1181: Bit Fields
1182: ==========
1183:
1184: Special expression codes exist to represent bit-field instructions.
1185: These types of expressions are lvalues in RTL; they may appear on the
1186: left side of an assignment, indicating insertion of a value into the
1187: specified bit field.
1188:
1189: `(sign_extract:M LOC SIZE POS)'
1190: This represents a reference to a sign-extended bit field
1191: contained or starting in LOC (a memory or register reference).
1192: The bit field is SIZE bits wide and starts at bit POS. The
1193: compilation option `BITS_BIG_ENDIAN' says which end of the memory
1194: unit POS counts from.
1195:
1196: If LOC is in memory, its mode must be a single-byte integer mode.
1197: If LOC is in a register, the mode to use is specified by the
1198: operand of the `insv' or `extv' pattern (*note Standard Names::.)
1199: and is usually a full-word integer mode.
1200:
1201: The mode of POS is machine-specific and is also specified in the
1202: `insv' or `extv' pattern.
1203:
1204: The mode M is the same as the mode that would be used for LOC if
1205: it were a register.
1206:
1207: `(zero_extract:M LOC SIZE POS)'
1208: Like `sign_extract' but refers to an unsigned or zero-extended
1209: bit field. The same sequence of bits are extracted, but they are
1210: filled to an entire word with zeros instead of by sign-extension.
1211:
1212:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.