![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-11 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-11 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: Passes, Next: RTL, Prev: Interface, Up: Top
32:
33: Passes and Files of the Compiler
34: ********************************
35:
36: The overall control structure of the compiler is in `toplev.c'. This
37: file is responsible for initialization, decoding arguments, opening and
38: closing files, and sequencing the passes.
39:
40: The parsing pass is invoked only once, to parse the entire input.
41: The RTL intermediate code for a function is generated as the function
42: is parsed, a statement at a time. Each statement is read in as a
43: syntax tree and then converted to RTL; then the storage for the tree
44: for the statement is reclaimed. Storage for types (and the expressions
45: for their sizes), declarations, and a representation of the binding
46: contours and how they nest, remain until the function is finished being
47: compiled; these are all needed to output the debugging information.
48:
49: Each time the parsing pass reads a complete function definition or
50: top-level declaration, it calls either the function
51: `rest_of_compilation', or the function `rest_of_decl_compilation' in
52: `toplev.c', which are responsible for all further processing necessary,
53: ending with output of the assembler language. All other compiler
54: passes run, in sequence, within `rest_of_compilation'. When that
55: function returns from compiling a function definition, the storage used
56: for that function definition's compilation is entirely freed, unless it
57: is an inline function (*note An Inline Function is As Fast As a Macro:
58: Inline.).
59:
60: Here is a list of all the passes of the compiler and their source
61: files. Also included is a description of where debugging dumps can be
62: requested with `-d' options.
63:
64: * Parsing. This pass reads the entire text of a function definition,
65: constructing partial syntax trees. This and RTL generation are no
66: longer truly separate passes (formerly they were), but it is
67: easier to think of them as separate.
68:
69: The tree representation does not entirely follow C syntax, because
70: it is intended to support other languages as well.
71:
72: Language-specific data type analysis is also done in this pass,
73: and every tree node that represents an expression has a data type
74: attached. Variables are represented as declaration nodes.
75:
76: Constant folding and some arithmetic simplifications are also done
77: during this pass.
78:
79: The language-independent source files for parsing are
80: `stor-layout.c', `fold-const.c', and `tree.c'. There are also
81: header files `tree.h' and `tree.def' which define the format of
82: the tree representation.
83:
84: The source files to parse C are `c-parse.in', `c-decl.c',
85: `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along
86: with header files `c-lex.h', and `c-tree.h'.
87:
88: The source files for parsing C++ are `cp-parse.y', `cp-class.c',
89: `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c',
90: `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c',
91: `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along
92: with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'.
93:
94: The special source files for parsing Objective C are
95: `objc-parse.y', `objc-actions.c', `objc-tree.def', and
96: `objc-actions.h'. Certain C-specific files are used for this as
97: well.
98:
99: The file `c-common.c' is also used for all of the above languages.
100:
101: * RTL generation. This is the conversion of syntax tree into RTL
102: code. It is actually done statement-by-statement during parsing,
103: but for most purposes it can be thought of as a separate pass.
104:
105: This is where the bulk of target-parameter-dependent code is found,
106: since often it is necessary for strategies to apply only when
107: certain standard kinds of instructions are available. The purpose
108: of named instruction patterns is to provide this information to
109: the RTL generation pass.
110:
111: Optimization is done in this pass for `if'-conditions that are
112: comparisons, boolean operations or conditional expressions. Tail
113: recursion is detected at this time also. Decisions are made about
114: how best to arrange loops and how to output `switch' statements.
115:
116: The source files for RTL generation include `stmt.c', `calls.c',
117: `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
118: `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
119: machine description by the program `genemit', is used in this
120: pass. The header file `expr.h' is used for communication within
121: this pass.
122:
123: The header files `insn-flags.h' and `insn-codes.h', generated from
124: the machine description by the programs `genflags' and `gencodes',
125: tell this pass which standard names are available for use and
126: which patterns correspond to them.
127:
128: Aside from debugging information output, none of the following
129: passes refers to the tree structure representation of the function
130: (only part of which is saved).
131:
132: The decision of whether the function can and should be expanded
133: inline in its subsequent callers is made at the end of rtl
134: generation. The function must meet certain criteria, currently
135: related to the size of the function and the types and number of
136: parameters it has. Note that this function may contain loops,
137: recursive calls to itself (tail-recursive functions can be
138: inlined!), gotos, in short, all constructs supported by GNU CC.
139: The file `integrate.c' contains the code to save a function's rtl
140: for later inlining and to inline that rtl when the function is
141: called. The header file `integrate.h' is also used for this
142: purpose.
143:
144: The option `-dr' causes a debugging dump of the RTL code after
145: this pass. This dump file's name is made by appending `.rtl' to
146: the input file name.
147:
148: * Jump optimization. This pass simplifies jumps to the following
149: instruction, jumps across jumps, and jumps to jumps. It deletes
150: unreferenced labels and unreachable code, except that unreachable
151: code that contains a loop is not recognized as unreachable in this
152: pass. (Such loops are deleted later in the basic block analysis.)
153: It also converts some code originally written with jumps into
154: sequences of instructions that directly set values from the
155: results of comparisons, if the machine has such instructions.
156:
157: Jump optimization is performed two or three times. The first time
158: is immediately following RTL generation. The second time is after
159: CSE, but only if CSE says repeated jump optimization is needed.
160: The last time is right before the final pass. That time,
161: cross-jumping and deletion of no-op move instructions are done
162: together with the optimizations described above.
163:
164: The source file of this pass is `jump.c'.
165:
166: The option `-dj' causes a debugging dump of the RTL code after
167: this pass is run for the first time. This dump file's name is
168: made by appending `.jump' to the input file name.
169:
170: * Register scan. This pass finds the first and last use of each
171: register, as a guide for common subexpression elimination. Its
172: source is in `regclass.c'.
173:
174: * Jump threading. This pass detects a condition jump that branches
175: to an identical or inverse test. Such jumps can be `threaded'
176: through the second conditional test. The source code for this
177: pass is in `jump.c'. This optimization is only performed if
178: `-fthread-jumps' is enabled.
179:
180: * Common subexpression elimination. This pass also does constant
181: propagation. Its source file is `cse.c'. If constant propagation
182: causes conditional jumps to become unconditional or to become
183: no-ops, jump optimization is run again when CSE is finished.
184:
185: The option `-ds' causes a debugging dump of the RTL code after
186: this pass. This dump file's name is made by appending `.cse' to
187: the input file name.
188:
189: * Loop optimization. This pass moves constant expressions out of
190: loops, and optionally does strength-reduction and loop unrolling
191: as well. Its source files are `loop.c' and `unroll.c', plus the
192: header `loop.h' used for communication between them. Loop
193: unrolling uses some functions in `integrate.c' and the header
194: `integrate.h'.
195:
196: The option `-dL' causes a debugging dump of the RTL code after
197: this pass. This dump file's name is made by appending `.loop' to
198: the input file name.
199:
200: * If `-frerun-cse-after-loop' was enabled, a second common
201: subexpression elimination pass is performed after the loop
202: optimization pass. Jump threading is also done again at this time
203: if it was specified.
204:
205: The option `-dt' causes a debugging dump of the RTL code after
206: this pass. This dump file's name is made by appending `.cse2' to
207: the input file name.
208:
209: * Stupid register allocation is performed at this point in a
210: nonoptimizing compilation. It does a little data flow analysis as
211: well. When stupid register allocation is in use, the next pass
212: executed is the reloading pass; the others in between are skipped.
213: The source file is `stupid.c'.
214:
215: * Data flow analysis (`flow.c'). This pass divides the program into
216: basic blocks (and in the process deletes unreachable loops); then
217: it computes which pseudo-registers are live at each point in the
218: program, and makes the first instruction that uses a value point at
219: the instruction that computed the value.
220:
221: This pass also deletes computations whose results are never used,
222: and combines memory references with add or subtract instructions
223: to make autoincrement or autodecrement addressing.
224:
225: The option `-df' causes a debugging dump of the RTL code after
226: this pass. This dump file's name is made by appending `.flow' to
227: the input file name. If stupid register allocation is in use, this
228: dump file reflects the full results of such allocation.
229:
230: * Instruction combination (`combine.c'). This pass attempts to
231: combine groups of two or three instructions that are related by
232: data flow into single instructions. It combines the RTL
233: expressions for the instructions by substitution, simplifies the
234: result using algebra, and then attempts to match the result
235: against the machine description.
236:
237: The option `-dc' causes a debugging dump of the RTL code after
238: this pass. This dump file's name is made by appending `.combine'
239: to the input file name.
240:
241: * Instruction scheduling (`sched.c'). This pass looks for
242: instructions whose output will not be available by the time that
243: it is used in subsequent instructions. (Memory loads and floating
244: point instructions often have this behavior on RISC machines). It
245: re-orders instructions within a basic block to try to separate the
246: definition and use of items that otherwise would cause pipeline
247: stalls.
248:
249: Instruction scheduling is performed twice. The first time is
250: immediately after instruction combination and the second is
251: immediately after reload.
252:
253: The option `-dS' causes a debugging dump of the RTL code after this
254: pass is run for the first time. The dump file's name is made by
255: appending `.sched' to the input file name.
256:
257: * Register class preferencing. The RTL code is scanned to find out
258: which register class is best for each pseudo register. The source
259: file is `regclass.c'.
260:
261: * Local register allocation (`local-alloc.c'). This pass allocates
262: hard registers to pseudo registers that are used only within one
263: basic block. Because the basic block is linear, it can use fast
264: and powerful techniques to do a very good job.
265:
266: The option `-dl' causes a debugging dump of the RTL code after
267: this pass. This dump file's name is made by appending `.lreg' to
268: the input file name.
269:
270: * Global register allocation (`global.c'). This pass allocates hard
271: registers for the remaining pseudo registers (those whose life
272: spans are not contained in one basic block).
273:
274: * Reloading. This pass renumbers pseudo registers with the hardware
275: registers numbers they were allocated. Pseudo registers that did
276: not get hard registers are replaced with stack slots. Then it
277: finds instructions that are invalid because a value has failed to
278: end up in a register, or has ended up in a register of the wrong
279: kind. It fixes up these instructions by reloading the
280: problematical values temporarily into registers. Additional
281: instructions are generated to do the copying.
282:
283: The reload pass also optionally eliminates the frame pointer and
284: inserts instructions to save and restore call-clobbered registers
285: around calls.
286:
287: Source files are `reload.c' and `reload1.c', plus the header
288: `reload.h' used for communication between them.
289:
290: The option `-dg' causes a debugging dump of the RTL code after
291: this pass. This dump file's name is made by appending `.greg' to
292: the input file name.
293:
294: * Instruction scheduling is repeated here to try to avoid pipeline
295: stalls due to memory loads generated for spilled pseudo registers.
296:
297: The option `-dR' causes a debugging dump of the RTL code after
298: this pass. This dump file's name is made by appending `.sched2'
299: to the input file name.
300:
301: * Jump optimization is repeated, this time including cross-jumping
302: and deletion of no-op move instructions.
303:
304: The option `-dJ' causes a debugging dump of the RTL code after
305: this pass. This dump file's name is made by appending `.jump2' to
306: the input file name.
307:
308: * Delayed branch scheduling. This optional pass attempts to find
309: instructions that can go into the delay slots of other
310: instructions, usually jumps and calls. The source file name is
311: `reorg.c'.
312:
313: The option `-dd' causes a debugging dump of the RTL code after
314: this pass. This dump file's name is made by appending `.dbr' to
315: the input file name.
316:
317: * Conversion from usage of some hard registers to usage of a register
318: stack may be done at this point. Currently, this is supported only
319: for the floating-point registers of the Intel 80387 coprocessor.
320: The source file name is `reg-stack.c'.
321:
322: The options `-dk' causes a debugging dump of the RTL code after
323: this pass. This dump file's name is made by appending `.stack' to
324: the input file name.
325:
326: * Final. This pass outputs the assembler code for the function. It
327: is also responsible for identifying spurious test and compare
328: instructions. Machine-specific peephole optimizations are
329: performed at the same time. The function entry and exit sequences
330: are generated directly as assembler code in this pass; they never
331: exist as RTL.
332:
333: The source files are `final.c' plus `insn-output.c'; the latter is
334: generated automatically from the machine description by the tool
335: `genoutput'. The header file `conditions.h' is used for
336: communication between these files.
337:
338: * Debugging information output. This is run after final because it
339: must output the stack slot offsets for pseudo registers that did
340: not get hard registers. Source files are `dbxout.c' for DBX
341: symbol table format, `sdbout.c' for SDB symbol table format, and
342: `dwarfout.c' for DWARF symbol table format.
343:
344: Some additional files are used by all or many passes:
345:
346: * Every pass uses `machmode.def' and `machmode.h' which define the
347: machine modes.
348:
349: * Several passes use `real.h', which defines the default
350: representation of floating point constants and how to operate on
351: them.
352:
353: * All the passes that work with RTL use the header files `rtl.h' and
354: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also
355: use these files to read and work with the machine description RTL.
356:
357: * Several passes refer to the header file `insn-config.h' which
358: contains a few parameters (C macro definitions) generated
359: automatically from the machine description RTL by the tool
360: `genconfig'.
361:
362: * Several passes use the instruction recognizer, which consists of
363: `recog.c' and `recog.h', plus the files `insn-recog.c' and
364: `insn-extract.c' that are generated automatically from the machine
365: description by the tools `genrecog' and `genextract'.
366:
367: * Several passes use the header files `regs.h' which defines the
368: information recorded about pseudo register usage, and
369: `basic-block.h' which defines the information recorded about basic
370: blocks.
371:
372: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
373: with a bit for each hard register, and some macros to manipulate
374: it. This type is just `int' if the machine has few enough hard
375: registers; otherwise it is an array of `int' and some of the
376: macros expand into loops.
377:
378: * Several passes use instruction attributes. A definition of the
379: attributes defined for a particular machine is in file
380: `insn-attr.h', which is generated from the machine description by
381: the program `genattr'. The file `insn-attrtab.c' contains
382: subroutines to obtain the attribute values for insns. It is
383: generated from the machine description by the program `genattrtab'.
384:
385:
386: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top
387:
388: RTL Representation
389: ******************
390:
391: Most of the work of the compiler is done on an intermediate
392: representation called register transfer language. In this language,
393: the instructions to be output are described, pretty much one by one, in
394: an algebraic form that describes what the instruction does.
395:
396: RTL is inspired by Lisp lists. It has both an internal form, made
397: up of structures that point at other structures, and a textual form
398: that is used in the machine description and in printed debugging dumps.
399: The textual form uses nested parentheses to indicate the pointers in
400: the internal form.
401:
402: * Menu:
403:
404: * RTL Objects:: Expressions vs vectors vs strings vs integers.
405: * Accessors:: Macros to access expression operands or vector elts.
406: * Flags:: Other flags in an RTL expression.
407: * Machine Modes:: Describing the size and format of a datum.
408: * Constants:: Expressions with constant values.
409: * Regs and Memory:: Expressions representing register contents or memory.
410: * Arithmetic:: Expressions representing arithmetic on other expressions.
411: * Comparisons:: Expressions representing comparison of expressions.
412: * Bit Fields:: Expressions representing bitfields in memory or reg.
413: * Conversions:: Extending, truncating, floating or fixing.
414: * RTL Declarations:: Declaring volatility, constancy, etc.
415: * Side Effects:: Expressions for storing in registers, etc.
416: * Incdec:: Embedded side-effects for autoincrement addressing.
417: * Assembler:: Representing `asm' with operands.
418: * Insns:: Expression types for entire insns.
419: * Calls:: RTL representation of function call insns.
420: * Sharing:: Some expressions are unique; others *must* be copied.
421: * Reading RTL:: Reading textual RTL from a file.
422:
423:
424: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL
425:
426: RTL Object Types
427: ================
428:
429: RTL uses five kinds of objects: expressions, integers, wide integers,
430: strings and vectors. Expressions are the most important ones. An RTL
431: expression ("RTX", for short) is a C structure, but it is usually
432: referred to with a pointer; a type that is given the typedef name `rtx'.
433:
434: An integer is simply an `int'; their written form uses decimal
435: digits. A wide integer is an integral object whose type is
436: `HOST_WIDE_INT' (*note Config::.); their written form uses decimal
437: digits.
438:
439: A string is a sequence of characters. In core it is represented as a
440: `char *' in usual C fashion, and it is written in C syntax as well.
441: However, strings in RTL may never be null. If you write an empty
442: string in a machine description, it is represented in core as a null
443: pointer rather than as a pointer to a null character. In certain
444: contexts, these null pointers instead of strings are valid. Within RTL
445: code, strings are most commonly found inside `symbol_ref' expressions,
446: but they appear in other contexts in the RTL expressions that make up
447: machine descriptions.
448:
449: A vector contains an arbitrary number of pointers to expressions.
450: The number of elements in the vector is explicitly present in the
451: vector. The written form of a vector consists of square brackets
452: (`[...]') surrounding the elements, in sequence and with whitespace
453: separating them. Vectors of length zero are not created; null pointers
454: are used instead.
455:
456: Expressions are classified by "expression codes" (also called RTX
457: codes). The expression code is a name defined in `rtl.def', which is
458: also (in upper case) a C enumeration constant. The possible expression
459: codes and their meanings are machine-independent. The code of an RTX
460: can be extracted with the macro `GET_CODE (X)' and altered with
461: `PUT_CODE (X, NEWCODE)'.
462:
463: The expression code determines how many operands the expression
464: contains, and what kinds of objects they are. In RTL, unlike Lisp, you
465: cannot tell by looking at an operand what kind of object it is.
466: Instead, you must know from its context--from the expression code of
467: the containing expression. For example, in an expression of code
468: `subreg', the first operand is to be regarded as an expression and the
469: second operand as an integer. In an expression of code `plus', there
470: are two operands, both of which are to be regarded as expressions. In
471: a `symbol_ref' expression, there is one operand, which is to be
472: regarded as a string.
473:
474: Expressions are written as parentheses containing the name of the
475: expression type, its flags and machine mode if any, and then the
476: operands of the expression (separated by spaces).
477:
478: Expression code names in the `md' file are written in lower case,
479: but when they appear in C code they are written in upper case. In this
480: manual, they are shown as follows: `const_int'.
481:
482: In a few contexts a null pointer is valid where an expression is
483: normally wanted. The written form of this is `(nil)'.
484:
485:
486: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL
487:
488: Access to Operands
489: ==================
490:
491: For each expression type `rtl.def' specifies the number of contained
492: objects and their kinds, with four possibilities: `e' for expression
493: (actually a pointer to an expression), `i' for integer, `w' for wide
494: integer, `s' for string, and `E' for vector of expressions. The
495: sequence of letters for an expression code is called its "format".
496: Thus, the format of `subreg' is `ei'.
497:
498: A few other format characters are used occasionally:
499:
500: `u'
501: `u' is equivalent to `e' except that it is printed differently in
502: debugging dumps. It is used for pointers to insns.
503:
504: `n'
505: `n' is equivalent to `i' except that it is printed differently in
506: debugging dumps. It is used for the line number or code number of
507: a `note' insn.
508:
509: `S'
510: `S' indicates a string which is optional. In the RTL objects in
511: core, `S' is equivalent to `s', but when the object is read, from
512: an `md' file, the string value of this operand may be omitted. An
513: omitted string is taken to be the null string.
514:
515: `V'
516: `V' indicates a vector which is optional. In the RTL objects in
517: core, `V' is equivalent to `E', but when the object is read from
518: an `md' file, the vector value of this operand may be omitted. An
519: omitted vector is effectively the same as a vector of no elements.
520:
521: `0'
522: `0' means a slot whose contents do not fit any normal category.
523: `0' slots are not printed at all in dumps, and are often used in
524: special ways by small parts of the compiler.
525:
526: There are macros to get the number of operands, the format, and the
527: class of an expression code:
528:
529: `GET_RTX_LENGTH (CODE)'
530: Number of operands of an RTX of code CODE.
531:
532: `GET_RTX_FORMAT (CODE)'
533: The format of an RTX of code CODE, as a C string.
534:
535: `GET_RTX_CLASS (CODE)'
536: A single character representing the type of RTX operation that code
537: CODE performs.
538:
539: The following classes are defined:
540:
541: `o'
542: An RTX code that represents an actual object, such as `reg' or
543: `mem'. `subreg' is not in this class.
544:
545: `<'
546: An RTX code for a comparison. The codes in this class are
547: `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU',
548: `GTU'.
549:
550: `1'
551: An RTX code for a unary arithmetic operation, such as `neg'.
552:
553: `c'
554: An RTX code for a commutative binary operation, other than
555: `NE' and `EQ' (which have class `<').
556:
557: `2'
558: An RTX code for a noncommutative binary operation, such as
559: `MINUS'.
560:
561: `b'
562: An RTX code for a bitfield operation, either `ZERO_EXTRACT' or
563: `SIGN_EXTRACT'.
564:
565: `3'
566: An RTX code for other three input operations, such as
567: `IF_THEN_ELSE'.
568:
569: `i'
570: An RTX code for a machine insn (`INSN', `JUMP_INSN', and
571: `CALL_INSN').
572:
573: `m'
574: An RTX code for something that matches in insns, such as
575: `MATCH_DUP'.
576:
577: `x'
578: All other RTX codes.
579:
580: Operands of expressions are accessed using the macros `XEXP',
581: `XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments:
582: an expression-pointer (RTX) and an operand number (counting from zero).
583: Thus,
584:
585: XEXP (X, 2)
586:
587: accesses operand 2 of expression X, as an expression.
588:
589: XINT (X, 2)
590:
591: accesses the same operand as an integer. `XSTR', used in the same
592: fashion, would access it as a string.
593:
594: Any operand can be accessed as an integer, as an expression or as a
595: string. You must choose the correct method of access for the kind of
596: value actually stored in the operand. You would do this based on the
597: expression code of the containing expression. That is also how you
598: would know how many operands there are.
599:
600: For example, if X is a `subreg' expression, you know that it has two
601: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
602: 1)'. If you did `XINT (X, 0)', you would get the address of the
603: expression operand but cast as an integer; that might occasionally be
604: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
605: (X, 1)' would also compile without error, and would return the second,
606: integer operand cast as an expression pointer, which would probably
607: result in a crash when accessed. Nothing stops you from writing `XEXP
608: (X, 28)' either, but this will access memory past the end of the
609: expression with unpredictable results.
610:
611: Access to operands which are vectors is more complicated. You can
612: use the macro `XVEC' to get the vector-pointer itself, or the macros
613: `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
614:
615: `XVEC (EXP, IDX)'
616: Access the vector-pointer which is operand number IDX in EXP.
617:
618: `XVECLEN (EXP, IDX)'
619: Access the length (number of elements) in the vector which is in
620: operand number IDX in EXP. This value is an `int'.
621:
622: `XVECEXP (EXP, IDX, ELTNUM)'
623: Access element number ELTNUM in the vector which is in operand
624: number IDX in EXP. This value is an RTX.
625:
626: It is up to you to make sure that ELTNUM is not negative and is
627: less than `XVECLEN (EXP, IDX)'.
628:
629: All the macros defined in this section expand into lvalues and
630: therefore can be used to assign the operands, lengths and vector
631: elements as well as to access them.
632:
633:
634: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL
635:
636: Flags in an RTL Expression
637: ==========================
638:
639: RTL expressions contain several flags (one-bit bitfields) that are
640: used in certain types of expression. Most often they are accessed with
641: the following macros:
642:
643: `MEM_VOLATILE_P (X)'
644: In `mem' expressions, nonzero for volatile memory references.
645: Stored in the `volatil' field and printed as `/v'.
646:
647: `MEM_IN_STRUCT_P (X)'
648: In `mem' expressions, nonzero for reference to an entire
649: structure, union or array, or to a component of one. Zero for
650: references to a scalar variable or through a pointer to a scalar.
651: Stored in the `in_struct' field and printed as `/s'.
652:
653: `REG_LOOP_TEST_P'
654: In `reg' expressions, nonzero if this register's entire life is
655: contained in the exit test code for some loop. Stored in the
656: `in_struct' field and printed as `/s'.
657:
658: `REG_USERVAR_P (X)'
659: In a `reg', nonzero if it corresponds to a variable present in the
660: user's source code. Zero for temporaries generated internally by
661: the compiler. Stored in the `volatil' field and printed as `/v'.
662:
663: `REG_FUNCTION_VALUE_P (X)'
664: Nonzero in a `reg' if it is the place in which this function's
665: value is going to be returned. (This happens only in a hard
666: register.) Stored in the `integrated' field and printed as `/i'.
667:
668: The same hard register may be used also for collecting the values
669: of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
670: in this kind of use.
671:
672: `SUBREG_PROMOTED_VAR_P'
673: Nonzero in a `subreg' if it was made when accessing an object that
674: was promoted to a wider mode in accord with the `PROMOTED_MODE'
675: machine description macro (*note Storage Layout::.). In this
676: case, the mode of the `subreg' is the declared mode of the object
677: and the mode of `SUBREG_REG' is the mode of the register that
678: holds the object. Promoted variables are always either sign- or
679: zero-extended to the wider mode on every assignment. Stored in
680: the `in_struct' field and printed as `/s'.
681:
682: `SUBREG_PROMOTED_UNSIGNED_P'
683: Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if
684: the object being referenced is kept zero-extended and zero if it
685: is kept sign-extended. Stored in the `unchanging' field and
686: printed as `/u'.
687:
688: `RTX_UNCHANGING_P (X)'
689: Nonzero in a `reg' or `mem' if the value is not changed. (This
690: flag is not set for memory references via pointers to constants.
691: Such pointers only guarantee that the object will not be changed
692: explicitly by the current function. The object might be changed by
693: other functions or by aliasing.) Stored in the `unchanging' field
694: and printed as `/u'.
695:
696: `RTX_INTEGRATED_P (INSN)'
697: Nonzero in an insn if it resulted from an in-line function call.
698: Stored in the `integrated' field and printed as `/i'. This may be
699: deleted; nothing currently depends on it.
700:
701: `SYMBOL_REF_USED (X)'
702: In a `symbol_ref', indicates that X has been used. This is
703: normally only used to ensure that X is only declared external
704: once. Stored in the `used' field.
705:
706: `SYMBOL_REF_FLAG (X)'
707: In a `symbol_ref', this is used as a flag for machine-specific
708: purposes. Stored in the `volatil' field and printed as `/v'.
709:
710: `LABEL_OUTSIDE_LOOP_P'
711: In `label_ref' expressions, nonzero if this is a reference to a
712: label that is outside the innermost loop containing the reference
713: to the label. Stored in the `in_struct' field and printed as `/s'.
714:
715: `INSN_DELETED_P (INSN)'
716: In an insn, nonzero if the insn has been deleted. Stored in the
717: `volatil' field and printed as `/v'.
718:
719: `INSN_ANNULLED_BRANCH_P (INSN)'
720: In an `insn' in the delay slot of a branch insn, indicates that an
721: annulling branch should be used. See the discussion under
722: `sequence' below. Stored in the `unchanging' field and printed as
723: `/u'.
724:
725: `INSN_FROM_TARGET_P (INSN)'
726: In an `insn' in a delay slot of a branch, indicates that the insn
727: is from the target of the branch. If the branch insn has
728: `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if
729: the branch is taken. For annulled branches with this bit clear,
730: the insn should be executed only if the branch is not taken.
731: Stored in the `in_struct' field and printed as `/s'.
732:
733: `CONSTANT_POOL_ADDRESS_P (X)'
734: Nonzero in a `symbol_ref' if it refers to part of the current
735: function's "constants pool". These are addresses close to the
736: beginning of the function, and GNU CC assumes they can be addressed
737: directly (perhaps with the help of base registers). Stored in the
738: `unchanging' field and printed as `/u'.
739:
740: `CONST_CALL_P (X)'
741: In a `call_insn', indicates that the insn represents a call to a
742: const function. Stored in the `unchanging' field and printed as
743: `/u'.
744:
745: `LABEL_PRESERVE_P (X)'
746: In a `code_label', indicates that the label can never be deleted.
747: Labels referenced by a non-local goto will have this bit set.
748: Stored in the `in_struct' field and printed as `/s'.
749:
750: `SCHED_GROUP_P (INSN)'
751: During instruction scheduling, in an insn, indicates that the
752: previous insn must be scheduled together with this insn. This is
753: used to ensure that certain groups of instructions will not be
754: split up by the instruction scheduling pass, for example, `use'
755: insns before a `call_insn' may not be separated from the
756: `call_insn'. Stored in the `in_struct' field and printed as `/s'.
757:
758: These are the fields which the above macros refer to:
759:
760: `used'
761: Normally, this flag is used only momentarily, at the end of RTL
762: generation for a function, to count the number of times an
763: expression appears in insns. Expressions that appear more than
764: once are copied, according to the rules for shared structure
765: (*note Sharing::.).
766:
767: In a `symbol_ref', it indicates that an external declaration for
768: the symbol has already been written.
769:
770: In a `reg', it is used by the leaf register renumbering code to
771: ensure that each register is only renumbered once.
772:
773: `volatil'
774: This flag is used in `mem', `symbol_ref' and `reg' expressions and
775: in insns. In RTL dump files, it is printed as `/v'.
776:
777: In a `mem' expression, it is 1 if the memory reference is volatile.
778: Volatile memory references may not be deleted, reordered or
779: combined.
780:
781: In a `symbol_ref' expression, it is used for machine-specific
782: purposes.
783:
784: In a `reg' expression, it is 1 if the value is a user-level
785: variable. 0 indicates an internal compiler temporary.
786:
787: In an insn, 1 means the insn has been deleted.
788:
789: `in_struct'
790: In `mem' expressions, it is 1 if the memory datum referred to is
791: all or part of a structure or array; 0 if it is (or might be) a
792: scalar variable. A reference through a C pointer has 0 because
793: the pointer might point to a scalar variable. This information
794: allows the compiler to determine something about possible cases of
795: aliasing.
796:
797: In an insn in the delay slot of a branch, 1 means that this insn
798: is from the target of the branch.
799:
800: During instruction scheduling, in an insn, 1 means that this insn
801: must be scheduled as part of a group together with the previous
802: insn.
803:
804: In `reg' expressions, it is 1 if the register has its entire life
805: contained within the test expression of some loop.
806:
807: In `subreg' expressions, 1 means that the `subreg' is accessing an
808: object that has had its mode promoted from a wider mode.
809:
810: In `label_ref' expressions, 1 means that the referenced label is
811: outside the innermost loop containing the insn in which the
812: `label_ref' was found.
813:
814: In `code_label' expressions, it is 1 if the label may never be
815: deleted. This is used for labels which are the target of
816: non-local gotos.
817:
818: In an RTL dump, this flag is represented as `/s'.
819:
820: `unchanging'
821: In `reg' and `mem' expressions, 1 means that the value of the
822: expression never changes.
823:
824: In `subreg' expressions, it is 1 if the `subreg' references an
825: unsigned object whose mode has been promoted to a wider mode.
826:
827: In an insn, 1 means that this is an annulling branch.
828:
829: In a `symbol_ref' expression, 1 means that this symbol addresses
830: something in the per-function constants pool.
831:
832: In a `call_insn', 1 means that this instruction is a call to a
833: const function.
834:
835: In an RTL dump, this flag is represented as `/u'.
836:
837: `integrated'
838: In some kinds of expressions, including insns, this flag means the
839: rtl was produced by procedure integration.
840:
841: In a `reg' expression, this flag indicates the register containing
842: the value to be returned by the current function. On machines
843: that pass parameters in registers, the same register number may be
844: used for parameters as well, but this flag is not set on such uses.
845:
846:
847: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
848:
849: Machine Modes
850: =============
851:
852: A machine mode describes a size of data object and the
853: representation used for it. In the C code, machine modes are
854: represented by an enumeration type, `enum machine_mode', defined in
855: `machmode.def'. Each RTL expression has room for a machine mode and so
856: do certain kinds of tree expressions (declarations and types, to be
857: precise).
858:
859: In debugging dumps and machine descriptions, the machine mode of an
860: RTL expression is written after the expression code with a colon to
861: separate them. The letters `mode' which appear at the end of each
862: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg'
863: expression with machine mode `SImode'. If the mode is `VOIDmode', it
864: is not written at all.
865:
866: Here is a table of machine modes. The term "byte" below refers to an
867: object of `BITS_PER_UNIT' bits (*note Storage Layout::.).
868:
869: `QImode'
870: "Quarter-Integer" mode represents a single byte treated as an
871: integer.
872:
873: `HImode'
874: "Half-Integer" mode represents a two-byte integer.
875:
876: `PSImode'
877: "Partial Single Integer" mode represents an integer which occupies
878: four bytes but which doesn't really use all four. On some
879: machines, this is the right mode to use for pointers.
880:
881: `SImode'
882: "Single Integer" mode represents a four-byte integer.
883:
884: `PDImode'
885: "Partial Double Integer" mode represents an integer which occupies
886: eight bytes but which doesn't really use all eight. On some
887: machines, this is the right mode to use for certain pointers.
888:
889: `DImode'
890: "Double Integer" mode represents an eight-byte integer.
891:
892: `TImode'
893: "Tetra Integer" (?) mode represents a sixteen-byte integer.
894:
895: `SFmode'
896: "Single Floating" mode represents a single-precision (four byte)
897: floating point number.
898:
899: `DFmode'
900: "Double Floating" mode represents a double-precision (eight byte)
901: floating point number.
902:
903: `XFmode'
904: "Extended Floating" mode represents a triple-precision (twelve
905: byte) floating point number. This mode is used for IEEE extended
906: floating point.
907:
908: `TFmode'
909: "Tetra Floating" mode represents a quadruple-precision (sixteen
910: byte) floating point number.
911:
912: `CCmode'
913: "Condition Code" mode represents the value of a condition code,
914: which is a machine-specific set of bits used to represent the
915: result of a comparison operation. Other machine-specific modes
916: may also be used for the condition code. These modes are not used
917: on machines that use `cc0' (see *note Condition Code::.).
918:
919: `BLKmode'
920: "Block" mode represents values that are aggregates to which none of
921: the other modes apply. In RTL, only memory references can have
922: this mode, and only if they appear in string-move or vector
923: instructions. On machines which have no such instructions,
924: `BLKmode' will not appear in RTL.
925:
926: `VOIDmode'
927: Void mode means the absence of a mode or an unspecified mode. For
928: example, RTL expressions of code `const_int' have mode `VOIDmode'
929: because they can be taken to have whatever mode the context
930: requires. In debugging dumps of RTL, `VOIDmode' is expressed by
931: the absence of any mode.
932:
933: `SCmode, DCmode, XCmode, TCmode'
934: These modes stand for a complex number represented as a pair of
935: floating point values. The floating point values are in `SFmode',
936: `DFmode', `XFmode', and `TFmode', respectively.
937:
938: `CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
939: These modes stand for a complex number represented as a pair of
940: integer values. The integer values are in `QImode', `HImode',
941: `SImode', `DImode', `TImode', and `OImode', respectively.
942:
943: The machine description defines `Pmode' as a C macro which expands
944: into the machine mode used for addresses. Normally this is the mode
945: whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
946:
947: The only modes which a machine description must support are
948: `QImode', and the modes corresponding to `BITS_PER_WORD',
949: `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to
950: use `DImode' for 8-byte structures and unions, but this can be
951: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'.
952: Alternatively, you can have the compiler use `TImode' for 16-byte
953: structures and unions. Likewise, you can arrange for the C type `short
954: int' to avoid using `HImode'.
955:
956: Very few explicit references to machine modes remain in the compiler
957: and these few references will soon be removed. Instead, the machine
958: modes are divided into mode classes. These are represented by the
959: enumeration type `enum mode_class' defined in `machmode.h'. The
960: possible mode classes are:
961:
962: `MODE_INT'
963: Integer modes. By default these are `QImode', `HImode', `SImode',
964: `DImode', and `TImode'.
965:
966: `MODE_PARTIAL_INT'
967: The "partial integer" modes, `PSImode' and `PDImode'.
968:
969: `MODE_FLOAT'
970: floating point modes. By default these are `SFmode', `DFmode',
971: `XFmode' and `TFmode'.
972:
973: `MODE_COMPLEX_INT'
974: Complex integer modes. (These are not currently implemented).
975:
976: `MODE_COMPLEX_FLOAT'
977: Complex floating point modes. By default these are `SCmode',
978: `DCmode', `XCmode', and `TCmode'.
979:
980: `MODE_FUNCTION'
981: Algol or Pascal function variables including a static chain.
982: (These are not currently implemented).
983:
984: `MODE_CC'
985: Modes representing condition code values. These are `CCmode' plus
986: any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump
987: Patterns::, also see *Note Condition Code::.
988:
989: `MODE_RANDOM'
990: This is a catchall mode class for modes which don't fit into the
991: above classes. Currently `VOIDmode' and `BLKmode' are in
992: `MODE_RANDOM'.
993:
994: Here are some C macros that relate to machine modes:
995:
996: `GET_MODE (X)'
997: Returns the machine mode of the RTX X.
998:
999: `PUT_MODE (X, NEWMODE)'
1000: Alters the machine mode of the RTX X to be NEWMODE.
1001:
1002: `NUM_MACHINE_MODES'
1003: Stands for the number of machine modes available on the target
1004: machine. This is one greater than the largest numeric value of any
1005: machine mode.
1006:
1007: `GET_MODE_NAME (M)'
1008: Returns the name of mode M as a string.
1009:
1010: `GET_MODE_CLASS (M)'
1011: Returns the mode class of mode M.
1012:
1013: `GET_MODE_WIDER_MODE (M)'
1014: Returns the next wider natural mode. For example, the expression
1015: `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
1016:
1017: `GET_MODE_SIZE (M)'
1018: Returns the size in bytes of a datum of mode M.
1019:
1020: `GET_MODE_BITSIZE (M)'
1021: Returns the size in bits of a datum of mode M.
1022:
1023: `GET_MODE_MASK (M)'
1024: Returns a bitmask containing 1 for all bits in a word that fit
1025: within mode M. This macro can only be used for modes whose
1026: bitsize is less than or equal to `HOST_BITS_PER_INT'.
1027:
1028: `GET_MODE_ALIGNMENT (M))'
1029: Return the required alignment, in bits, for an object of mode M.
1030:
1031: `GET_MODE_UNIT_SIZE (M)'
1032: Returns the size in bytes of the subunits of a datum of mode M.
1033: This is the same as `GET_MODE_SIZE' except in the case of complex
1034: modes. For them, the unit size is the size of the real or
1035: imaginary part.
1036:
1037: `GET_MODE_NUNITS (M)'
1038: Returns the number of units contained in a mode, i.e.,
1039: `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
1040:
1041: `GET_CLASS_NARROWEST_MODE (C)'
1042: Returns the narrowest mode in mode class C.
1043:
1044: The global variables `byte_mode' and `word_mode' contain modes whose
1045: classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
1046: `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
1047: and `SImode', respectively.
1048:
1049:
1050: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
1051:
1052: Constant Expression Types
1053: =========================
1054:
1055: The simplest RTL expressions are those that represent constant
1056: values.
1057:
1058: `(const_int I)'
1059: This type of expression represents the integer value I. I is
1060: customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
1061: which is equivalent to `XWINT (EXP, 0)'.
1062:
1063: There is only one expression object for the integer value zero; it
1064: is the value of the variable `const0_rtx'. Likewise, the only
1065: expression for integer value one is found in `const1_rtx', the only
1066: expression for integer value two is found in `const2_rtx', and the
1067: only expression for integer value negative one is found in
1068: `constm1_rtx'. Any attempt to create an expression of code
1069: `const_int' and value zero, one, two or negative one will return
1070: `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
1071: appropriate.
1072:
1073: Similarly, there is only one object for the integer whose value is
1074: `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
1075: `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
1076: point to the same object. If `STORE_FLAG_VALUE' is -1,
1077: `const_true_rtx' and `constm1_rtx' will point to the same object.
1078:
1079: `(const_double:M ADDR I0 I1 ...)'
1080: Represents either a floating-point constant of mode M or an
1081: integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
1082: bits but small enough to fit within twice that number of bits (GNU
1083: CC does not provide a mechanism to represent even larger
1084: constants). In the latter case, M will be `VOIDmode'.
1085:
1086: ADDR is used to contain the `mem' expression that corresponds to
1087: the location in memory that at which the constant can be found. If
1088: it has not been allocated a memory location, but is on the chain
1089: of all `const_double' expressions in this compilation (maintained
1090: using an undisplayed field), ADDR contains `const0_rtx'. If it is
1091: not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily
1092: accessed with the macro `CONST_DOUBLE_MEM' and the chain field via
1093: `CONST_DOUBLE_CHAIN'.
1094:
1095: If M is `VOIDmode', the bits of the value are stored in I0 and I1.
1096: I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
1097: I1 with `CONST_DOUBLE_HIGH'.
1098:
1099: If the constant is floating point (regardless of its precision),
1100: then the number of integers used to store the value depends on the
1101: size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The
1102: integers represent a floating point number, but not precisely in
1103: the target machine's or host machine's floating point format. To
1104: convert them to the precise bit pattern used by the target
1105: machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends
1106: (*note Data Output::.).
1107:
1108: The macro `CONST0_RTX (MODE)' refers to an expression with value 0
1109: in mode MODE. If mode MODE is of mode class `MODE_INT', it
1110: returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE'
1111: expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)'
1112: refers to an expression with value 1 in mode MODE and similarly
1113: for `CONST2_RTX'.
1114:
1115: `(const_string STR)'
1116: Represents a constant string with value STR. Currently this is
1117: used only for insn attributes (*note Insn Attributes::.) since
1118: constant strings in C are placed in memory.
1119:
1120: `(symbol_ref:MODE SYMBOL)'
1121: Represents the value of an assembler label for data. SYMBOL is a
1122: string that describes the name of the assembler label. If it
1123: starts with a `*', the label is the rest of SYMBOL not including
1124: the `*'. Otherwise, the label is SYMBOL, usually prefixed with
1125: `_'.
1126:
1127: The `symbol_ref' contains a mode, which is usually `Pmode'.
1128: Usually that is the only mode for which a symbol is directly valid.
1129:
1130: `(label_ref LABEL)'
1131: Represents the value of an assembler label for code. It contains
1132: one operand, an expression, which must be a `code_label' that
1133: appears in the instruction sequence to identify the place where
1134: the label should go.
1135:
1136: The reason for using a distinct expression type for code label
1137: references is so that jump optimization can distinguish them.
1138:
1139: `(const:M EXP)'
1140: Represents a constant that is the result of an assembly-time
1141: arithmetic computation. The operand, EXP, is an expression that
1142: contains only constants (`const_int', `symbol_ref' and `label_ref'
1143: expressions) combined with `plus' and `minus'. However, not all
1144: combinations are valid, since the assembler cannot do arbitrary
1145: arithmetic on relocatable symbols.
1146:
1147: M should be `Pmode'.
1148:
1149: `(high:M EXP)'
1150: Represents the high-order bits of EXP, usually a `symbol_ref'.
1151: The number of bits is machine-dependent and is normally the number
1152: of bits specified in an instruction that initializes the high
1153: order bits of a register. It is used with `lo_sum' to represent
1154: the typical two-instruction sequence used in RISC machines to
1155: reference a global memory location.
1156:
1157: M should be `Pmode'.
1158:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.