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