![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-5 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.4 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect
! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
! 16: original, and provided that the entire resulting derived work is
! 17: distributed under the terms of a permission notice identical to this
! 18: one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.4 ! root 22: versions, except that the sections entitled "GNU General Public
! 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
! 24: permission notice may be included in translations approved by the
! 25: Free Software Foundation instead of in the original English.
1.1 root 26:
1.1.1.2 root 27:
28:
1.1.1.3 root 29: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top
1.1.1.2 root 30:
1.1.1.3 root 31: Passes and Files of the Compiler
32: ********************************
1.1.1.2 root 33:
1.1.1.3 root 34: The overall control structure of the compiler is in `toplev.c'. This
35: file is responsible for initialization, decoding arguments, opening
36: and closing files, and sequencing the passes.
37:
38: The parsing pass is invoked only once, to parse the entire input.
39: The RTL intermediate code for a function is generated as the function
40: is parsed, a statement at a time. Each statement is read in as a
41: syntax tree and then converted to RTL; then the storage for the tree
42: for the statement is reclaimed. Storage for types (and the
43: expressions for their sizes), declarations, and a representation of
44: the binding contours and how they nest, remains until the function is
45: finished being compiled; these are all needed to output the debugging
46: information.
47:
48: Each time the parsing pass reads a complete function definition or
49: top-level declaration, it calls the function `rest_of_compilation' or
50: `rest_of_decl_compilation' in `toplev.c', which are responsible for
51: all further processing necessary, ending with output of the assembler
52: language. All other compiler passes run, in sequence, within
53: `rest_of_compilation'. When that function returns from compiling a
54: function definition, the storage used for that function definition's
55: compilation is entirely freed, unless it is an inline function (*note
56: Inline::.).
57:
58: Here is a list of all the passes of the compiler and their source
59: files. Also included is a description of where debugging dumps can
60: be requested with `-d' options.
61:
62: * Parsing. This pass reads the entire text of a function
63: definition, constructing partial syntax trees. This and RTL
64: generation are no longer truly separate passes (formerly they
65: were), but it is easier to think of them as separate.
66:
67: The tree representation does not entirely follow C syntax,
68: because it is intended to support other languages as well.
69:
70: C data type analysis is also done in this pass, and every tree
71: node that represents an expression has a data type attached.
72: Variables are represented as declaration nodes.
73:
74: Constant folding and associative-law simplifications are also
75: done during this pass.
76:
77: The source files for parsing are `c-parse.y', `c-decl.c',
78: `c-typeck.c', `c-convert.c', `stor-layout.c', `fold-const.c',
79: and `tree.c'. The last three files are intended to be
80: language-independent. There are also header files `c-parse.h',
81: `c-tree.h', `tree.h' and `tree.def'. The last two define the
82: format of the tree representation.
83:
84: * RTL generation. This is the conversion of syntax tree into RTL
85: code. It is actually done statement-by-statement during
86: parsing, but for most purposes it can be thought of as a
87: separate pass.
88:
89: This is where the bulk of target-parameter-dependent code is
90: found, since often it is necessary for strategies to apply only
91: when certain standard kinds of instructions are available. The
92: purpose of named instruction patterns is to provide this
93: information to the RTL generation pass.
94:
95: Optimization is done in this pass for `if'-conditions that are
96: comparisons, boolean operations or conditional expressions.
97: Tail recursion is detected at this time also. Decisions are
98: made about how best to arrange loops and how to output `switch'
99: statements.
100:
101: The source files for RTL generation are `stmt.c', `expr.c',
102: `explow.c', `expmed.c', `optabs.c' and `emit-rtl.c'. Also, the
103: file `insn-emit.c', generated from the machine description by
104: the program `genemit', is used in this pass. The header files
105: `expr.h' is used for communication within this pass.
106:
107: The header files `insn-flags.h' and `insn-codes.h', generated
108: from the machine description by the programs `genflags' and
109: `gencodes', tell this pass which standard names are available
110: for use and which patterns correspond to them.
111:
112: Aside from debugging information output, none of the following
113: passes refers to the tree structure representation of the
114: function (only part of which is saved).
115:
116: The decision of whether the function can and should be expanded
117: inline in its subsequent callers is made at the end of rtl
118: generation. The function must meet certain criteria, currently
119: related to the size of the function and the types and number of
120: parameters it has. Note that this function may contain loops,
121: recursive calls to itself (tail-recursive functions can be
122: inlined!), gotos, in short, all constructs supported by GNU CC.
123:
124: The option `-dr' causes a debugging dump of the RTL code after
125: this pass. This dump file's name is made by appending `.rtl' to
126: the input file name.
127:
128: * Jump optimization. This pass simplifies jumps to the following
129: instruction, jumps across jumps, and jumps to jumps. It deletes
130: unreferenced labels and unreachable code, except that
131: unreachable code that contains a loop is not recognized as
132: unreachable in this pass. (Such loops are deleted later in the
133: basic block analysis.)
134:
135: Jump optimization is performed two or three times. The first
136: time is immediately following RTL generation. The second time
137: is after CSE, but only if CSE says repeated jump optimization is
138: needed. The last time is right before the final pass. That
139: time, cross-jumping and deletion of no-op move instructions are
140: done together with the optimizations described above.
141:
142: The source file of this pass is `jump.c'.
143:
144: The option `-dj' causes a debugging dump of the RTL code after
145: this pass is run for the first time. This dump file's name is
146: made by appending `.jump' to the input file name.
147:
148: * Register scan. This pass finds the first and last use of each
149: register, as a guide for common subexpression elimination. Its
150: source is in `regclass.c'.
151:
152: * Common subexpression elimination. This pass also does constant
153: propagation. Its source file is `cse.c'. If constant
154: propagation causes conditional jumps to become unconditional or
155: to become no-ops, jump optimization is run again when CSE is
156: finished.
157:
158: The option `-ds' causes a debugging dump of the RTL code after
159: this pass. This dump file's name is made by appending `.cse' to
160: the input file name.
161:
162: * Loop optimization. This pass moves constant expressions out of
163: loops, and optionally does strength-reduction as well. Its
164: source file is `loop.c'.
165:
166: The option `-dL' causes a debugging dump of the RTL code after
167: this pass. This dump file's name is made by appending `.loop'
168: to the input file name.
169:
170: * Stupid register allocation is performed at this point in a
171: nonoptimizing compilation. It does a little data flow analysis
172: as well. When stupid register allocation is in use, the next
173: pass executed is the reloading pass; the others in between are
174: skipped. The source file is `stupid.c'.
175:
176: * Data flow analysis (`flow.c'). This pass divides the program
177: into basic blocks (and in the process deletes unreachable
178: loops); then it computes which pseudo-registers are live at each
179: point in the program, and makes the first instruction that uses
180: a value point at the instruction that computed the value.
181:
182: This pass also deletes computations whose results are never
183: used, and combines memory references with add or subtract
184: instructions to make autoincrement or autodecrement addressing.
185:
186: The option `-df' causes a debugging dump of the RTL code after
187: this pass. This dump file's name is made by appending `.flow'
188: to the input file name. If stupid register allocation is in
189: use, this dump file reflects the full results of such allocation.
190:
191: * Instruction combination (`combine.c'). This pass attempts to
192: combine groups of two or three instructions that are related by
193: data flow into single instructions. It combines the RTL
194: expressions for the instructions by substitution, simplifies the
195: result using algebra, and then attempts to match the result
196: against the machine description.
197:
198: The option `-dc' causes a debugging dump of the RTL code after
199: this pass. This dump file's name is made by appending
200: `.combine' to the input file name.
201:
202: * Register class preferencing. The RTL code is scanned to find
203: out which register class is best for each pseudo register. The
204: source file is `regclass.c'.
205:
206: * Local register allocation (`local-alloc.c'). This pass
207: allocates hard registers to pseudo registers that are used only
208: within one basic block. Because the basic block is linear, it
209: can use fast and powerful techniques to do a very good job.
210:
211: The option `-dl' causes a debugging dump of the RTL code after
212: this pass. This dump file's name is made by appending `.lreg'
213: to the input file name.
214:
215: * Global register allocation (`global-alloc.c'). This pass
216: allocates hard registers for the remaining pseudo registers
217: (those whose life spans are not contained in one basic block).
218:
219: * Reloading. This pass renumbers pseudo registers with the
220: hardware registers numbers they were allocated. Pseudo
221: registers that did not get hard registers are replaced with
222: stack slots. Then it finds instructions that are invalid
223: because a value has failed to end up in a register, or has ended
224: up in a register of the wrong kind. It fixes up these
225: instructions by reloading the problematical values temporarily
226: into registers. Additional instructions are generated to do the
227: copying.
228:
229: Source files are `reload.c' and `reload1.c', plus the header
230: `reload.h' used for communication between them.
231:
232: The option `-dg' causes a debugging dump of the RTL code after
233: this pass. This dump file's name is made by appending `.greg'
234: to the input file name.
235:
236: * Jump optimization is repeated, this time including cross-jumping
237: and deletion of no-op move instructions.
238:
239: The option `-dJ' causes a debugging dump of the RTL code after
240: this pass. This dump file's name is made by appending `.jump2'
241: to the input file name.
242:
243: * Delayed branch scheduling may be done at this point. The source
244: file name is `dbranch.c'.
245:
246: The option `-dd' causes a debugging dump of the RTL code after
247: this pass. This dump file's name is made by appending `.dbr' to
248: the input file name.
249:
250: * Final. This pass outputs the assembler code for the function.
251: It is also responsible for identifying spurious test and compare
252: instructions. Machine-specific peephole optimizations are
253: performed at the same time. The function entry and exit
254: sequences are generated directly as assembler code in this pass;
255: they never exist as RTL.
256:
257: The source files are `final.c' plus `insn-output.c'; the latter
258: is generated automatically from the machine description by the
259: tool `genoutput'. The header file `conditions.h' is used for
260: communication between these files.
261:
262: * Debugging information output. This is run after final because
263: it must output the stack slot offsets for pseudo registers that
264: did not get hard registers. Source files are `dbxout.c' for DBX
265: symbol table format and `symout.c' for GDB's own symbol table
266: format.
267:
268: Some additional files are used by all or many passes:
269:
270: * Every pass uses `machmode.def', which defines the machine modes.
271:
272: * All the passes that work with RTL use the header files `rtl.h'
273: and `rtl.def', and subroutines in file `rtl.c'. The tools
274: `gen*' also use these files to read and work with the machine
275: description RTL.
276:
277: * Several passes refer to the header file `insn-config.h' which
278: contains a few parameters (C macro definitions) generated
279: automatically from the machine description RTL by the tool
280: `genconfig'.
281:
282: * Several passes use the instruction recognizer, which consists of
283: `recog.c' and `recog.h', plus the files `insn-recog.c' and
284: `insn-extract.c' that are generated automatically from the
285: machine description by the tools `genrecog' and `genextract'.
286:
287: * Several passes use the header files `regs.h' which defines the
288: information recorded about pseudo register usage, and
289: `basic-block.h' which defines the information recorded about
290: basic blocks.
291:
292: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
293: with a bit for each hard register, and some macros to manipulate
294: it. This type is just `int' if the machine has few enough hard
295: registers; otherwise it is an array of `int' and some of the
296: macros expand into loops.
1.1.1.2 root 297:
298:
299:
1.1.1.3 root 300: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top
1.1.1.2 root 301:
1.1.1.3 root 302: RTL Representation
303: ******************
1.1.1.2 root 304:
1.1.1.3 root 305: Most of the work of the compiler is done on an intermediate
306: representation called register transfer language. In this language,
307: the instructions to be output are described, pretty much one by one,
308: in an algebraic form that describes what the instruction does.
309:
310: RTL is inspired by Lisp lists. It has both an internal form, made up
311: of structures that point at other structures, and a textual form that
312: is used in the machine description and in printed debugging dumps.
313: The textual form uses nested parentheses to indicate the pointers in
314: the internal form.
1.1.1.2 root 315:
1.1.1.3 root 316: * Menu:
1.1.1.2 root 317:
1.1.1.3 root 318: * RTL Objects:: Expressions vs vectors vs strings vs integers.
319: * Accessors:: Macros to access expression operands or vector elts.
320: * Flags:: Other flags in an RTL expression.
321: * Machine Modes:: Describing the size and format of a datum.
322: * Constants:: Expressions with constant values.
323: * Regs and Memory:: Expressions representing register contents or memory.
324: * Arithmetic:: Expressions representing arithmetic on other expressions.
325: * Comparisons:: Expressions representing comparison of expressions.
326: * Bit Fields:: Expressions representing bit-fields in memory or reg.
327: * Conversions:: Extending, truncating, floating or fixing.
328: * RTL Declarations:: Declaring volatility, constancy, etc.
329: * Side Effects:: Expressions for storing in registers, etc.
330: * Incdec:: Embedded side-effects for autoincrement addressing.
331: * Assembler:: Representing `asm' with operands.
332: * Insns:: Expression types for entire insns.
333: * Calls:: RTL representation of function call insns.
334: * Sharing:: Some expressions are unique; others *must* be copied.
1.1.1.2 root 335:
1.1.1.3 root 336:
337:
338: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL
1.1.1.2 root 339:
1.1.1.3 root 340: RTL Object Types
341: ================
1.1.1.2 root 342:
1.1.1.3 root 343: RTL uses four kinds of objects: expressions, integers, strings and
344: vectors. Expressions are the most important ones. An RTL expression
1.1.1.4 ! root 345: ("RTX", for short) is a C structure, but it is usually referred to
1.1.1.3 root 346: with a pointer; a type that is given the typedef name `rtx'.
347:
348: An integer is simply an `int', and a string is a `char *'. Within
349: RTL code, strings appear only inside `symbol_ref' expressions, but
350: they appear in other contexts in the RTL expressions that make up
351: machine descriptions. Their written form uses decimal digits.
352:
353: A string is a sequence of characters. In core it is represented as a
354: `char *' in usual C fashion, and it is written in C syntax as well.
355: However, strings in RTL may never be null. If you write an empty
356: string in a machine description, it is represented in core as a null
357: pointer rather than as a pointer to a null character. In certain
358: contexts, these null pointers instead of strings are valid.
359:
360: A vector contains an arbitrary, specified number of pointers to
361: expressions. The number of elements in the vector is explicitly
362: present in the vector. The written form of a vector consists of
363: square brackets (`[...]') surrounding the elements, in sequence and
364: with whitespace separating them. Vectors of length zero are not
365: created; null pointers are used instead.
366:
367: Expressions are classified by "expression codes" (also called RTX
368: codes). The expression code is a name defined in `rtl.def', which is
369: also (in upper case) a C enumeration constant. The possible
370: expression codes and their meanings are machine-independent. The
371: code of an RTX can be extracted with the macro `GET_CODE (X)' and
372: altered with `PUT_CODE (X, NEWCODE)'.
373:
374: The expression code determines how many operands the expression
375: contains, and what kinds of objects they are. In RTL, unlike Lisp,
376: you cannot tell by looking at an operand what kind of object it is.
377: Instead, you must know from its context--from the expression code of
378: the containing expression. For example, in an expression of code
379: `subreg', the first operand is to be regarded as an expression and
380: the second operand as an integer. In an expression of code `plus',
381: there are two operands, both of which are to be regarded as
382: expressions. In a `symbol_ref' expression, there is one operand,
383: which is to be regarded as a string.
384:
385: Expressions are written as parentheses containing the name of the
386: expression type, its flags and machine mode if any, and then the
387: operands of the expression (separated by spaces).
388:
389: Expression code names in the `md' file are written in lower case, but
390: when they appear in C code they are written in upper case. In this
391: manual, they are shown as follows: `const_int'.
1.1.1.2 root 392:
1.1.1.3 root 393: In a few contexts a null pointer is valid where an expression is
394: normally wanted. The written form of this is `(nil)'.
1.1.1.2 root 395:
396:
397:
1.1.1.3 root 398: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL
1.1.1.2 root 399:
1.1.1.3 root 400: Access to Operands
401: ==================
1.1.1.2 root 402:
1.1.1.3 root 403: For each expression type `rtl.def' specifies the number of contained
404: objects and their kinds, with four possibilities: `e' for expression
405: (actually a pointer to an expression), `i' for integer, `s' for
406: string, and `E' for vector of expressions. The sequence of letters
407: for an expression code is called its "format". Thus, the format of
408: `subreg' is `ei'.
409:
410: Two other format characters are used occasionally: `u' and `0'. `u'
411: is equivalent to `e' except that it is printed differently in
412: debugging dumps, and `0' means a slot whose contents do not fit any
413: normal category. `0' slots are not printed at all in dumps, and are
414: often used in special ways by small parts of the compiler.
415:
416: There are macros to get the number of operands and the format of an
417: expression code:
418:
419: `GET_RTX_LENGTH (CODE)'
420: Number of operands of an RTX of code CODE.
421:
422: `GET_RTX_FORMAT (CODE)'
423: The format of an RTX of code CODE, as a C string.
424:
425: Operands of expressions are accessed using the macros `XEXP', `XINT'
426: and `XSTR'. Each of these macros takes two arguments: an
427: expression-pointer (RTX) and an operand number (counting from zero).
428: Thus,
429:
430: XEXP (X, 2)
431:
432: accesses operand 2 of expression X, as an expression.
433:
434: XINT (X, 2)
435:
436: accesses the same operand as an integer. `XSTR', used in the same
437: fashion, would access it as a string.
438:
439: Any operand can be accessed as an integer, as an expression or as a
440: string. You must choose the correct method of access for the kind of
441: value actually stored in the operand. You would do this based on the
442: expression code of the containing expression. That is also how you
443: would know how many operands there are.
444:
445: For example, if X is a `subreg' expression, you know that it has two
446: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT
447: (X, 1)'. If you did `XINT (X, 0)', you would get the address of the
448: expression operand but cast as an integer; that might occasionally be
449: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
450: (X, 1)' would also compile without error, and would return the
451: second, integer operand cast as an expression pointer, which would
452: probably result in a crash when accessed. Nothing stops you from
453: writing `XEXP (X, 28)' either, but this will access memory past the
454: end of the expression with unpredictable results.
455:
456: Access to operands which are vectors is more complicated. You can
457: use the macro `XVEC' to get the vector-pointer itself, or the macros
458: `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
459:
460: `XVEC (EXP, IDX)'
461: Access the vector-pointer which is operand number IDX in EXP.
462:
463: `XVECLEN (EXP, IDX)'
464: Access the length (number of elements) in the vector which is in
465: operand number IDX in EXP. This value is an `int'.
466:
467: `XVECEXP (EXP, IDX, ELTNUM)'
468: Access element number ELTNUM in the vector which is in operand
469: number IDX in EXP. This value is an RTX.
470:
471: It is up to you to make sure that ELTNUM is not negative and is
472: less than `XVECLEN (EXP, IDX)'.
473:
474: All the macros defined in this section expand into lvalues and
475: therefore can be used to assign the operands, lengths and vector
476: elements as well as to access them.
1.1.1.2 root 477:
478:
479:
1.1.1.3 root 480: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL
1.1.1.2 root 481:
1.1.1.3 root 482: Flags in an RTL Expression
483: ==========================
1.1.1.2 root 484:
1.1.1.3 root 485: RTL expressions contain several flags (one-bit bit-fields) that are
486: used in certain types of expression. Most often they are accessed
487: with the following macros:
488:
1.1.1.4 ! root 489: `EXTERNAL_SYMBOL_P (X)'
! 490: In a `symbol_ref' expression, nonzero if it corresponds to a
! 491: variable declared extern in the users code. Zero for all other
! 492: variables. Stored in the `volatil' field and printed as `/v'.
! 493:
1.1.1.3 root 494: `MEM_VOLATILE_P (X)'
495: In `mem' expressions, nonzero for volatile memory references.
496: Stored in the `volatil' field and printed as `/v'.
497:
498: `MEM_IN_STRUCT_P (X)'
499: In `mem' expressions, nonzero for reference to an entire
500: structure, union or array, or to a component of one. Zero for
501: references to a scalar variable or through a pointer to a scalar.
502: Stored in the `in_struct' field and printed as `/s'.
503:
504: `REG_USER_VAR_P (X)'
505: In a `reg', nonzero if it corresponds to a variable present in
506: the user's source code. Zero for temporaries generated
507: internally by the compiler. Stored in the `volatil' field and
508: printed as `/v'.
509:
510: `REG_FUNCTION_VALUE_P (X)'
511: Nonzero in a `reg' if it is the place in which this function's
512: value is going to be returned. (This happens only in a hard
513: register.) Stored in the `integrated' field and printed as `/i'.
514:
515: The same hard register may be used also for collecting the
516: values of functions called by this one, but
517: `REG_FUNCTION_VALUE_P' is zero in this kind of use.
518:
519: `RTX_UNCHANGING_P (X)'
520: Nonzero in a `reg' or `mem' if the value is not changed
521: explicitly by the current function. (If it is a memory
522: reference then it may be changed by other functions or by
523: aliasing.) Stored in the `unchanging' field and printed as `/u'.
524:
525: `RTX_INTEGRATED_P (INSN)'
526: Nonzero in an insn if it resulted from an in-line function call.
527: Stored in the `integrated' field and printed as `/i'. This may
528: be deleted; nothing currently depends on it.
529:
530: `INSN_DELETED_P (INSN)'
531: In an insn, nonzero if the insn has been deleted. Stored in the
532: `volatil' field and printed as `/v'.
533:
534: `CONSTANT_POOL_ADDRESS_P (X)'
535: Nonzero in a `symbol_ref' if it refers to part of the current
1.1.1.4 ! root 536: function's "constants pool". These are addresses close to the
1.1.1.3 root 537: beginning of the function, and GNU CC assumes they can be
538: addressed directly (perhaps with the help of base registers).
539: Stored in the `unchanging' field and printed as `/u'.
540:
541: These are the fields which the above macros refer to:
542:
543: `used'
544: This flag is used only momentarily, at the end of RTL generation
545: for a function, to count the number of times an expression
546: appears in insns. Expressions that appear more than once are
547: copied, according to the rules for shared structure (*note
548: Sharing::.).
549:
550: `volatil'
1.1.1.4 ! root 551: This flag is used in `mem',`symbol_ref' and `reg' expressions
! 552: and in insns. In RTL dump files, it is printed as `/v'.
1.1.1.3 root 553:
554: In a `mem' expression, it is 1 if the memory reference is
555: volatile. Volatile memory references may not be deleted,
556: reordered or combined.
557:
558: In a `reg' expression, it is 1 if the value is a user-level
559: variable. 0 indicates an internal compiler temporary.
560:
1.1.1.4 ! root 561: In a `symbol_ref' expression, it is 1 if the symbol is declared
! 562: `extern'.
! 563:
1.1.1.3 root 564: In an insn, 1 means the insn has been deleted.
565:
566: `in_struct'
567: This flag is used in `mem' expressions. It is 1 if the memory
568: datum referred to is all or part of a structure or array; 0 if
569: it is (or might be) a scalar variable. A reference through a C
570: pointer has 0 because the pointer might point to a scalar
571: variable.
572:
573: This information allows the compiler to determine something
574: about possible cases of aliasing.
575:
576: In an RTL dump, this flag is represented as `/s'.
577:
578: `unchanging'
579: This flag is used in `reg' and `mem' expressions. 1 means that
580: the value of the expression never changes (at least within the
581: current function).
582:
583: In an RTL dump, this flag is represented as `/u'.
584:
585: `integrated'
586: In some kinds of expressions, including insns, this flag means
587: the rtl was produced by procedure integration.
588:
589: In a `reg' expression, this flag indicates the register
590: containing the value to be returned by the current function. On
591: machines that pass parameters in registers, the same register
592: number may be used for parameters as well, but this flag is not
593: set on such uses.
1.1.1.2 root 594:
595:
596:
1.1.1.3 root 597: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
1.1.1.2 root 598:
1.1.1.3 root 599: Machine Modes
600: =============
1.1.1.2 root 601:
1.1.1.3 root 602: A machine mode describes a size of data object and the representation
603: used for it. In the C code, machine modes are represented by an
604: enumeration type, `enum machine_mode', defined in `machmode.def'.
605: Each RTL expression has room for a machine mode and so do certain
606: kinds of tree expressions (declarations and types, to be precise).
607:
608: In debugging dumps and machine descriptions, the machine mode of an
609: RTL expression is written after the expression code with a colon to
610: separate them. The letters `mode' which appear at the end of each
611: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg'
612: expression with machine mode `SImode'. If the mode is `VOIDmode', it
613: is not written at all.
614:
615: Here is a table of machine modes.
616:
617: `QImode'
1.1.1.4 ! root 618: "Quarter-Integer" mode represents a single byte treated as an
1.1.1.3 root 619: integer.
620:
621: `HImode'
1.1.1.4 ! root 622: "Half-Integer" mode represents a two-byte integer.
1.1.1.3 root 623:
624: `PSImode'
1.1.1.4 ! root 625: "Partial Single Integer" mode represents an integer which
1.1.1.3 root 626: occupies four bytes but which doesn't really use all four. On
627: some machines, this is the right mode to use for pointers.
628:
629: `SImode'
1.1.1.4 ! root 630: "Single Integer" mode represents a four-byte integer.
1.1.1.3 root 631:
632: `PDImode'
1.1.1.4 ! root 633: "Partial Double Integer" mode represents an integer which
1.1.1.3 root 634: occupies eight bytes but which doesn't really use all eight. On
635: some machines, this is the right mode to use for certain pointers.
636:
637: `DImode'
1.1.1.4 ! root 638: "Double Integer" mode represents an eight-byte integer.
1.1.1.3 root 639:
640: `TImode'
1.1.1.4 ! root 641: "Tetra Integer" (?) mode represents a sixteen-byte integer.
1.1.1.3 root 642:
643: `SFmode'
1.1.1.4 ! root 644: "Single Floating" mode represents a single-precision (four byte)
! 645: floating point number.
1.1.1.3 root 646:
647: `DFmode'
1.1.1.4 ! root 648: "Double Floating" mode represents a double-precision (eight
1.1.1.3 root 649: byte) floating point number.
650:
651: `XFmode'
1.1.1.4 ! root 652: "Extended Floating" mode represents a triple-precision (twelve
1.1.1.3 root 653: byte) floating point number. This mode is used for IEEE
654: extended floating point.
655:
656: `TFmode'
1.1.1.4 ! root 657: "Tetra Floating" mode represents a quadruple-precision (sixteen
! 658: byte) floating point number.
1.1.1.3 root 659:
660: `BLKmode'
1.1.1.4 ! root 661: "Block" mode represents values that are aggregates to which none
! 662: of the other modes apply. In RTL, only memory references can
! 663: have this mode, and only if they appear in string-move or vector
! 664: instructions. On machines which have no such instructions,
! 665: `BLKmode' will not appear in RTL.
1.1.1.3 root 666:
667: `VOIDmode'
668: Void mode means the absence of a mode or an unspecified mode.
669: For example, RTL expressions of code `const_int' have mode
670: `VOIDmode' because they can be taken to have whatever mode the
671: context requires. In debugging dumps of RTL, `VOIDmode' is
672: expressed by the absence of any mode.
673:
674: `EPmode'
1.1.1.4 ! root 675: "Entry Pointer" mode is intended to be used for function
1.1.1.3 root 676: variables in Pascal and other block structured languages. Such
677: values contain both a function address and a static chain
678: pointer for access to automatic variables of outer levels. This
679: mode is only partially implemented since C does not use it.
680:
681: `CSImode, ...'
1.1.1.4 ! root 682: "Complex Single Integer" mode stands for a complex number
1.1.1.3 root 683: represented as a pair of `SImode' integers. Any of the integer
684: and floating modes may have `C' prefixed to its name to obtain a
685: complex number mode. For example, there are `CQImode',
686: `CSFmode', and `CDFmode'. Since C does not support complex
687: numbers, these machine modes are only partially implemented.
688:
689: `BImode'
690: This is the machine mode of a bit-field in a structure. It is
691: used only in the syntax tree, never in RTL, and in the syntax
692: tree it appears only in declaration nodes. In C, it appears
693: only in `FIELD_DECL' nodes for structure fields defined with a
694: bit size.
695:
696: The machine description defines `Pmode' as a C macro which expands
697: into the machine mode used for addresses. Normally this is `SImode'.
698:
699: The only modes which a machine description must support are `QImode',
700: `SImode', `SFmode' and `DFmode'. The compiler will attempt to use
701: `DImode' for two-word structures and unions, but this can be
702: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'.
703: Likewise, you can arrange for the C type `short int' to avoid using
704: `HImode'. In the long term it might be desirable to make the set of
705: available machine modes machine-dependent and eliminate all
706: assumptions about specific machine modes or their uses from the
707: machine-independent code of the compiler.
708:
709: To help begin this process, the machine modes are divided into mode
710: classes. These are represented by the enumeration type `enum
711: mode_class' defined in `rtl.h'. The possible mode classes are:
712:
713: `MODE_INT'
714: Integer modes. By default these are `QImode', `HImode',
715: `SImode', `DImode', `TImode', and also `BImode'.
716:
717: `MODE_FLOAT'
718: Floating-point modes. By default these are `QFmode', `HFmode',
719: `SFmode', `DFmode' and `TFmode', but the MC68881 also defines
720: `XFmode' to be an 80-bit extended-precision floating-point mode.
721:
722: `MODE_COMPLEX_INT'
723: Complex integer modes. By default these are `CQImode',
724: `CHImode', `CSImode', `CDImode' and `CTImode'.
725:
726: `MODE_COMPLEX_FLOAT'
727: Complex floating-point modes. By default these are `CQFmode',
728: `CHFmode', `CSFmode', `CDFmode' and `CTFmode',
729:
730: `MODE_FUNCTION'
731: Algol or Pascal function variables including a static chain.
732: (These are not currently implemented).
733:
734: `MODE_RANDOM'
735: This is a catchall mode class for modes which don't fit into the
736: above classes. Currently `VOIDmode', `BLKmode' and `EPmode' are
737: in `MODE_RANDOM'.
738:
739: Here are some C macros that relate to machine modes:
740:
741: `GET_MODE (X)'
742: Returns the machine mode of the RTX X.
743:
744: `PUT_MODE (X, NEWMODE)'
745: Alters the machine mode of the RTX X to be NEWMODE.
746:
747: `NUM_MACHINE_MODES'
748: Stands for the number of machine modes available on the target
749: machine. This is one greater than the largest numeric value of
750: any machine mode.
751:
752: `GET_MODE_NAME (M)'
753: Returns the name of mode M as a string.
754:
755: `GET_MODE_CLASS (M)'
756: Returns the mode class of mode M.
757:
758: `GET_MODE_SIZE (M)'
759: Returns the size in bytes of a datum of mode M.
760:
761: `GET_MODE_BITSIZE (M)'
762: Returns the size in bits of a datum of mode M.
763:
764: `GET_MODE_UNIT_SIZE (M)'
765: Returns the size in bits of the subunits of a datum of mode M.
766: This is the same as `GET_MODE_SIZE' except in the case of
767: complex modes and `EPmode'. For them, the unit size is the size
768: of the real or imaginary part, or the size of the function
769: pointer or the context pointer.
1.1.1.2 root 770:
771:
772:
1.1.1.3 root 773: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
1.1.1.2 root 774:
1.1.1.3 root 775: Constant Expression Types
776: =========================
1.1.1.2 root 777:
1.1.1.3 root 778: The simplest RTL expressions are those that represent constant values.
1.1.1.2 root 779:
1.1.1.3 root 780: `(const_int I)'
781: This type of expression represents the integer value I. I is
782: customarily accessed with the macro `INTVAL' as in `INTVAL
783: (EXP)', which is equivalent to `XINT (EXP, 0)'.
784:
785: There is only one expression object for the integer value zero;
786: it is the value of the variable `const0_rtx'. Likewise, the
787: only expression for integer value one is found in `const1_rtx'.
788: Any attempt to create an expression of code `const_int' and
789: value zero or one will return `const0_rtx' or `const1_rtx' as
790: appropriate.
791:
792: `(const_double:M I0 I1)'
793: Represents a 64-bit constant of mode M. All floating point
794: constants are represented in this way, and so are 64-bit
795: `DImode' integer constants.
796:
797: The two integers I0 and I1 together contain the bits of the
798: value. If the constant is floating point (either single or
799: double precision), then they represent a `double'. To convert
800: them to a `double', do
801:
802: union { double d; int i[2];} u;
803: u.i[0] = CONST_DOUBLE_LOW(x);
804: u.i[1] = CONST_DOUBLE_HIGH(x);
805:
806: and then refer to `u.d'.
807:
808: The global variables `dconst0_rtx' and `fconst0_rtx' hold
809: `const_double' expressions with value 0, in modes `DFmode' and
810: `SFmode', respectively. The macro `CONST0_RTX (MODE)' refers to
811: a `const_double' expression with value 0 in mode MODE. The mode
812: MODE must be of mode class `MODE_FLOAT'.
813:
814: `(symbol_ref SYMBOL)'
815: Represents the value of an assembler label for data. SYMBOL is
816: a string that describes the name of the assembler label. If it
817: starts with a `*', the label is the rest of SYMBOL not including
818: the `*'. Otherwise, the label is SYMBOL, prefixed with `_'.
819:
820: `(label_ref LABEL)'
821: Represents the value of an assembler label for code. It
822: contains one operand, an expression, which must be a
823: `code_label' that appears in the instruction sequence to
824: identify the place where the label should go.
825:
826: The reason for using a distinct expression type for code label
827: references is so that jump optimization can distinguish them.
828:
829: `(const EXP)'
830: Represents a constant that is the result of an assembly-time
831: arithmetic computation. The operand, EXP, is an expression that
832: contains only constants (`const_int', `symbol_ref' and
833: `label_ref' expressions) combined with `plus' and `minus'.
834: However, not all combinations are valid, since the assembler
835: cannot do arbitrary arithmetic on relocatable symbols.
1.1.1.2 root 836:
837:
838:
1.1.1.3 root 839: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
1.1.1.2 root 840:
1.1.1.3 root 841: Registers and Memory
842: ====================
1.1.1.2 root 843:
1.1.1.3 root 844: Here are the RTL expression types for describing access to machine
845: registers and to main memory.
1.1.1.2 root 846:
1.1.1.3 root 847: `(reg:M N)'
848: For small values of the integer N (less than
849: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
850: register number N: a "hard register". For larger values of N,
851: it stands for a temporary value or "pseudo register". The
852: compiler's strategy is to generate code assuming an unlimited
853: number of such pseudo registers, and later convert them into
854: hard registers or into memory references.
855:
856: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
857: description, since the number of hard registers on the machine
858: is an invariant characteristic of the machine. Note, however,
859: that not all of the machine registers must be general registers.
860: All the machine registers that can be used for storage of data
861: are given hard register numbers, even those that can be used
862: only in certain instructions or can hold only certain types of
863: data.
864:
865: Each pseudo register number used in a function's RTL code is
866: represented by a unique `reg' expression.
867:
868: M is the machine mode of the reference. It is necessary because
869: machines can generally refer to each register in more than one
870: mode. For example, a register may contain a full word but there
871: may be instructions to refer to it as a half word or as a single
872: byte, as well as instructions to refer to it as a floating point
873: number of various precisions.
874:
875: Even for a register that the machine can access in only one
876: mode, the mode must always be specified.
877:
878: A hard register may be accessed in various modes throughout one
879: function, but each pseudo register is given a natural mode and
880: is accessed only in that mode. When it is necessary to describe
881: an access to a pseudo register using a nonnatural mode, a
882: `subreg' expression is used.
883:
884: A `reg' expression with a machine mode that specifies more than
885: one word of data may actually stand for several consecutive
886: registers. If in addition the register number specifies a
887: hardware register, then it actually represents several
888: consecutive hardware registers starting with the specified one.
889:
890: Such multi-word hardware register `reg' expressions must not be
891: live across the boundary of a basic block. The lifetime
892: analysis pass does not know how to record properly that several
893: consecutive registers are actually live there, and therefore
894: register allocation would be confused. The CSE pass must go out
895: of its way to make sure the situation does not arise.
896:
897: `(subreg:M REG WORDNUM)'
898: `subreg' expressions are used to refer to a register in a
899: machine mode other than its natural one, or to refer to one
900: register of a multi-word `reg' that actually refers to several
901: registers.
902:
903: Each pseudo-register has a natural mode. If it is necessary to
904: operate on it in a different mode--for example, to perform a
905: fullword move instruction on a pseudo-register that contains a
906: single byte--the pseudo-register must be enclosed in a `subreg'.
907: In such a case, WORDNUM is zero.
908:
909: The other use of `subreg' is to extract the individual registers
910: of a multi-register value. Machine modes such as `DImode' and
911: `EPmode' indicate values longer than a word, values which
912: usually require two consecutive registers. To access one of the
913: registers, use a `subreg' with mode `SImode' and a WORDNUM that
914: says which register.
915:
916: The compilation parameter `WORDS_BIG_ENDIAN', if defined, says
917: that word number zero is the most significant part; otherwise,
918: it is the least significant part.
919:
920: Between the combiner pass and the reload pass, it is possible to
921: have a `subreg' which contains a `mem' instead of a `reg' as its
922: first operand. The reload pass eliminates these cases by
923: reloading the `mem' into a suitable register.
924:
925: Note that it is not valid to access a `DFmode' value in `SFmode'
926: using a `subreg'. On some machines the most significant part of
927: a `DFmode' value does not have the same format as a
928: single-precision floating value.
929:
930: `(cc0)'
931: This refers to the machine's condition code register. It has no
1.1.1.4 ! root 932: operands and may not have a machine mode. There are two ways to
! 933: use it:
! 934:
! 935: * To stand for a complete set of condition code flags. This
! 936: is best on most machines, where each comparison sets the
! 937: entire series of flags.
! 938:
! 939: With this technique, `(cc0)' may be validly used in only
! 940: two contexts: as the destination of an assignment (in test
! 941: and compare instructions) and in comparison operators
! 942: comparing against zero (`const_int' with value zero; that
! 943: is to say, `const0_rtx').
! 944:
! 945: * To stand for a single flag that is the result of a single
! 946: condition. This is useful on machines that have only a
! 947: single flag bit, and in which comparison instructions must
! 948: specify the condition to test.
! 949:
! 950: With this technique, `(cc0)' may be validly used in only
! 951: two contexts: as the destination of an assignment (in test
! 952: and compare instructions) where the source is a comparison
! 953: operator, and as the first operand of `if_then_else' (in a
! 954: conditional branch).
1.1.1.3 root 955:
956: There is only one expression object of code `cc0'; it is the
957: value of the variable `cc0_rtx'. Any attempt to create an
958: expression of code `cc0' will return `cc0_rtx'.
959:
960: One special thing about the condition code register is that
961: instructions can set it implicitly. On many machines, nearly
962: all instructions set the condition code based on the value that
963: they compute or store. It is not necessary to record these
964: actions explicitly in the RTL because the machine description
965: includes a prescription for recognizing the instructions that do
966: so (by means of the macro `NOTICE_UPDATE_CC'). Only
967: instructions whose sole purpose is to set the condition code,
968: and instructions that use the condition code, need mention
969: `(cc0)'.
970:
1.1.1.4 ! root 971: In some cases, better code may result from recognizing
! 972: combinations or peepholes that include instructions that set the
! 973: condition codes, even in cases where some reloading is
! 974: inevitable. For examples, search for `addcc' and `andcc' in
! 975: `sparc.md'.
! 976:
1.1.1.3 root 977: `(pc)'
978: This represents the machine's program counter. It has no
979: operands and may not have a machine mode. `(pc)' may be validly
980: used only in certain specific contexts in jump instructions.
981:
982: There is only one expression object of code `pc'; it is the
983: value of the variable `pc_rtx'. Any attempt to create an
984: expression of code `pc' will return `pc_rtx'.
985:
986: All instructions that do not jump alter the program counter
987: implicitly by incrementing it, but there is no need to mention
988: this in the RTL.
989:
990: `(mem:M ADDR)'
991: This RTX represents a reference to main memory at an address
992: represented by the expression ADDR. M specifies how large a
993: unit of memory is accessed.
1.1.1.2 root 994:
995:
996:
1.1.1.3 root 997: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
1.1.1.2 root 998:
1.1.1.3 root 999: RTL Expressions for Arithmetic
1000: ==============================
1.1.1.2 root 1001:
1.1.1.3 root 1002: `(plus:M X Y)'
1003: Represents the sum of the values represented by X and Y carried
1004: out in machine mode M. This is valid only if X and Y both are
1005: valid for mode M.
1006:
1007: `(minus:M X Y)'
1008: Like `plus' but represents subtraction.
1009:
1010: `(compare X Y)'
1011: Represents the result of subtracting Y from X for purposes of
1012: comparison. The absence of a machine mode in the `compare'
1013: expression indicates that the result is computed without
1014: overflow, as if with infinite precision.
1015:
1016: Of course, machines can't really subtract with infinite precision.
1017: However, they can pretend to do so when only the sign of the
1018: result will be used, which is the case when the result is stored
1019: in `(cc0)'. And that is the only way this kind of expression
1020: may validly be used: as a value to be stored in the condition
1021: codes.
1022:
1023: `(neg:M X)'
1024: Represents the negation (subtraction from zero) of the value
1025: represented by X, carried out in mode M. X must be valid for
1026: mode M.
1027:
1028: `(mult:M X Y)'
1029: Represents the signed product of the values represented by X and
1030: Y carried out in machine mode M. If X and Y are both valid for
1031: mode M, this is ordinary size-preserving multiplication.
1032: Alternatively, both X and Y may be valid for a different,
1033: narrower mode. This represents the kind of multiplication that
1034: generates a product wider than the operands. Widening
1035: multiplication and same-size multiplication are completely
1036: distinct and supported by different machine instructions;
1037: machines may support one but not the other.
1038:
1039: `mult' may be used for floating point multiplication as well.
1040: Then M is a floating point machine mode.
1041:
1042: `(umult:M X Y)'
1043: Like `mult' but represents unsigned multiplication. It may be
1044: used in both same-size and widening forms, like `mult'. `umult'
1045: is used only for fixed-point multiplication.
1046:
1047: `(div:M X Y)'
1048: Represents the quotient in signed division of X by Y, carried
1049: out in machine mode M. If M is a floating-point mode, it
1050: represents the exact quotient; otherwise, the integerized
1051: quotient. If X and Y are both valid for mode M, this is
1052: ordinary size-preserving division. Some machines have division
1053: instructions in which the operands and quotient widths are not
1054: all the same; such instructions are represented by `div'
1055: expressions in which the machine modes are not all the same.
1056:
1057: `(udiv:M X Y)'
1058: Like `div' but represents unsigned division.
1059:
1060: `(mod:M X Y)'
1061: `(umod:M X Y)'
1062: Like `div' and `udiv' but represent the remainder instead of the
1063: quotient.
1064:
1065: `(not:M X)'
1066: Represents the bitwise complement of the value represented by X,
1067: carried out in mode M, which must be a fixed-point machine mode.
1068: x must be valid for mode M, which must be a fixed-point mode.
1069:
1070: `(and:M X Y)'
1071: Represents the bitwise logical-and of the values represented by
1072: X and Y, carried out in machine mode M. This is valid only if X
1073: and Y both are valid for mode M, which must be a fixed-point mode.
1074:
1075: `(ior:M X Y)'
1076: Represents the bitwise inclusive-or of the values represented by
1077: X and Y, carried out in machine mode M. This is valid only if X
1078: and Y both are valid for mode M, which must be a fixed-point mode.
1079:
1080: `(xor:M X Y)'
1081: Represents the bitwise exclusive-or of the values represented by
1082: X and Y, carried out in machine mode M. This is valid only if X
1083: and Y both are valid for mode M, which must be a fixed-point mode.
1084:
1085: `(lshift:M X C)'
1086: Represents the result of logically shifting X left by C places.
1087: X must be valid for the mode M, a fixed-point machine mode. C
1088: must be valid for a fixed-point mode; which mode is determined
1089: by the mode called for in the machine description entry for the
1090: left-shift instruction. For example, on the Vax, the mode of C
1091: is `QImode' regardless of M.
1092:
1093: On some machines, negative values of C may be meaningful; this
1094: is why logical left shift and arithmetic left shift are
1095: distinguished. For example, Vaxes have no right-shift
1096: instructions, and right shifts are represented as left-shift
1097: instructions whose counts happen to be negative constants or
1098: else computed (in a previous instruction) by negation.
1099:
1100: `(ashift:M X C)'
1101: Like `lshift' but for arithmetic left shift.
1102:
1103: `(lshiftrt:M X C)'
1104: `(ashiftrt:M X C)'
1105: Like `lshift' and `ashift' but for right shift.
1106:
1107: `(rotate:M X C)'
1108: `(rotatert:M X C)'
1109: Similar but represent left and right rotate.
1110:
1111: `(abs:M X)'
1112: Represents the absolute value of X, computed in mode M. X must
1113: be valid for M.
1114:
1115: `(sqrt:M X)'
1116: Represents the square root of X, computed in mode M. X must be
1117: valid for M. Most often M will be a floating point mode.
1118:
1119: `(ffs:M X)'
1.1.1.4 ! root 1120: Represents one plus the index of the least significant 1-bit in
! 1121: X, represented as an integer of mode M. (The value is zero if X
! 1122: is zero.) The mode of X need not be M; depending on the target
! 1123: machine, various mode combinations may be valid.
1.1 root 1124:
1125:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.