![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-1 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to internals-1 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file internals, produced by texinfo-format-buffer -*-Text-*-
2: from file internals.texinfo
3:
4:
5: This file documents the internals of the GNU compiler.
6:
7: Copyright (C) 1987 Richard M. Stallman.
8:
9: Permission is granted to make and distribute verbatim copies of
10: this manual provided the copyright notice and this permission notice
11: are preserved on all copies.
12:
13: Permission is granted to copy and distribute modified versions of this
14: manual under the conditions for verbatim copying, provided also that the
15: section entitled "GNU CC General Public License" is included exactly as
16: in the original, and provided that the entire resulting derived work is
17: distributed under the terms of a permission notice identical to this one.
18:
19: Permission is granted to copy and distribute translations of this manual
20: into another language, under the above conditions for modified versions,
21: except that the section entitled "GNU CC General Public License" may be
22: included in a translation approved by the author instead of in the original
23: English.
24:
25:
26:
27:
28:
29: File: internals Node: Top, Up: (DIR), Next: Switches
30:
31: Introduction
32: ************
33:
34: This manual documents how to install and port the GNU C compiler.
35:
36: * Menu:
37:
38: * Copying:: GNU CC General Public License says
39: how you can copy and share GNU CC.
40: * Switches:: Command switches supported by `gcc'.
41: * Installation:: How to configure, compile and install GNU CC.
42: * Portability:: Goals of GNU CC's portability features.
43: * Passes:: Order of passes, what they do, and what each file is for.
44: * RTL:: The intermediate representation that most passes work on.
45: * Machine Desc:: How to write machine description instruction patterns.
46: * Machine Macros:: How to write the machine description C macros.
47:
48:
49: File: internals Node: Copying, Prev: Top, Up: Top, Next: Switches
50:
51: GNU CC GENERAL PUBLIC LICENSE
52: *****************************
53:
54: The license agreements of most software companies keep you at the
55: mercy of those companies. By contrast, our general public license is
56: intended to give everyone the right to share GNU CC. To make sure that
57: you get the rights we want you to have, we need to make restrictions
58: that forbid anyone to deny you these rights or to ask you to surrender
59: the rights. Hence this license agreement.
60:
61: Specifically, we want to make sure that you have the right to give
62: away copies of GNU CC, that you receive source code or else can get it
63: if you want it, that you can change GNU CC or use pieces of it in new
64: free programs, and that you know you can do these things.
65:
66: To make sure that everyone has such rights, we have to forbid you to
67: deprive anyone else of these rights. For example, if you distribute
68: copies of GNU CC, you must give the recipients all the rights that you
69: have. You must make sure that they, too, receive or can get the
70: source code. And you must tell them their rights.
71:
72: Also, for our own protection, we must make certain that everyone
73: finds out that there is no warranty for GNU CC. If GNU CC is modified by
74: someone else and passed on, we want its recipients to know that what
75: they have is not what we distributed, so that any problems introduced
76: by others will not reflect on our reputation.
77:
78: Therefore we (Richard Stallman and the Free Software Fundation,
79: Inc.) make the following terms which say what you must do to be
80: allowed to distribute or change GNU CC.
81:
82:
83: COPYING POLICIES
84: ================
85:
86: 1. You may copy and distribute verbatim copies of GNU CC source code as
87: you receive it, in any medium, provided that you conspicuously and
88: appropriately publish on each copy a valid copyright notice
89: "Copyright (C) 1987 Free Software Foundation, Inc." (or
90: with the year updated if that is appropriate); keep intact the notices
91: on all files that refer to this License Agreement and to the absence
92: of any warranty; and give any other recipients of the GNU CC program a
93: copy of this License Agreement along with the program. You may charge
94: a distribution fee for the physical act of transferring a copy.
95:
96: 2. You may modify your copy or copies of GNU CC or any portion of it,
97: and copy and distribute such modifications under the terms of
98: Paragraph 1 above, provided that you also do the following:
99:
100: * cause the modified files to carry prominent notices stating
101: that you changed the files and the date of any change; and
102:
103: * cause the whole of any work that you distribute or publish,
104: that in whole or in part contains or is a derivative of GNU CC or
105: any part thereof, to be licensed at no charge to all third
106: parties on terms identical to those contained in this License
107: Agreement (except that you may choose to grant more extensive
108: warranty protection to some or all third parties, at your
109: option).
110:
111: * You may charge a distribution fee for the physical act of
112: transferring a copy, and you may at your option offer warranty
113: protection in exchange for a fee.
114:
115: 3. You may copy and distribute GNU CC or any portion of it in
116: compiled, executable or object code form under the terms of Paragraphs
117: 1 and 2 above provided that you do the following:
118:
119: * cause each such copy to be accompanied by the
120: corresponding machine-readable source code, which must
121: be distributed under the terms of Paragraphs 1 and 2 above; or,
122:
123: * cause each such copy to be accompanied by a
124: written offer, with no time limit, to give any third party
125: free (except for a nominal shipping charge) a machine readable
126: copy of the corresponding source code, to be distributed
127: under the terms of Paragraphs 1 and 2 above; or,
128:
129: * in the case of a recipient of GNU CC in compiled, executable
130: or object code form (without the corresponding source code) you
131: shall cause copies you distribute to be accompanied by a copy
132: of the written offer of source code which you received along
133: with the copy you received.
134:
135: 4. You may not copy, sublicense, distribute or transfer GNU CC
136: except as expressly provided under this License Agreement. Any attempt
137: otherwise to copy, sublicense, distribute or transfer GNU CC is void and
138: your rights to use the program under this License agreement shall be
139: automatically terminated. However, parties who have received computer
140: software programs from you with this License Agreement will not have
141: their licenses terminated so long as such parties remain in full compliance.
142:
143: 5. If you wish to incorporate parts of GNU CC into other free programs
144: whose distribution conditions are different, write to the Free Software
145: Foundation at 1000 Mass Ave, Cambridge, MA 02138. We have not yet worked
146: out a simple rule that can be stated here, but we will often permit this.
147: We will be guided by the two goals of preserving the free status of all
148: derivatives our free software and of promoting the sharing and reuse of
149: software.
150:
151: Your comments and suggestions about our licensing policies and our
152: software are welcome! Please contact the Free Software Foundation, Inc.,
153: 1000 Mass Ave, Cambridge, MA 02138, or call (617) 876-3296.
154:
155:
156: NO WARRANTY
157: ===========
158:
159: BECAUSE GNU CC IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO
160: WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT
161: WHEN OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC,
162: RICHARD M. STALLMAN AND/OR OTHER PARTIES PROVIDE GNU CC "AS IS" WITHOUT
163: WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
164: LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
165: A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
166: PERFORMANCE OF GNU CC IS WITH YOU. SHOULD GNU CC PROVE DEFECTIVE, YOU
167: ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
168:
169: IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL RICHARD M.
170: STALLMAN, THE FREE SOFTWARE FOUNDATION, INC., AND/OR ANY OTHER PARTY
171: WHO MAY MODIFY AND REDISTRIBUTE GNU CC AS PERMITTED ABOVE, BE LIABLE TO
172: YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER
173: SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
174: INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
175: BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A
176: FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS) GNU CC, EVEN
177: IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR
178: ANY CLAIM BY ANY OTHER PARTY.
179:
180:
181: File: internals Node: Switches, Prev: Copying, Up: Top, Next: Installation
182:
183: GNU CC Switches
184: ***************
185:
186: `-O'
187: Do optimize.
188:
189: `-g'
190: Produce debugging information in DBX format.
191:
192: `-c'
193: Compile but do not link the object files.
194:
195: `-o FILE'
196: Place linker output in file FILE.
197:
198: `-S'
199: Compile into assembler code but do not assemble.
200:
201: `-mMACHINESPEC'
202: Machine-dependent switch specifying something about the type
203: of target machine. For example, using the 68000 machine description,
204: `-m68000' specifies do not use the 68020 instructions,
205: and `-msoft-float' specifies do not use the 68881 floating point
206: instructions.
207:
208: `-dLETTERS'
209: Says to make debugging dumps at times specified by LETTERS.
210: Here are the possible letters:
211:
212: `t'
213: Dump syntax-tree.
214: `r'
215: Dump after RTL generation.
216: `j'
217: Dump after first jump optimization.
218: `s'
219: Dump after CSE.
220: `L'
221: Dump after loop optimization.
222: `f'
223: Dump after flow analysis.
224: `c'
225: Dump after instruction combination.
226: `l'
227: Dump after local register allocation.
228: `g'
229: Dump after global register allocation.
230:
231: `-pedantic'
232: Attempt to support strict ANSI standard C. Valid ANSI standard C
233: programs should compile properly with or without this switch.
234: However, without this switch, certain useful or traditional constructs
235: banned by the standard are supported. With this switch, they are
236: rejected. There is no reason to use this switch; it exists only
237: to satisfy pedants.
238:
239: `E'
240: Preprocess the input files and output the results to standard output.
241:
242: `C'
243: Tell the preprocessor not to discard comments. Used with the `-E'
244: switch.
245:
246: `IDIR'
247: Search directory DIR for include files.
248:
249: `DMACRO'
250: Define macro MACRO with the empty string as its definition.
251:
252: `DMACRO=DEFN'
253: Define macro MACRO as DEFN.
254:
255: `UMACRO'
256: Undefine macro MACRO.
257:
258: `w'
259: Inhibit warning messages.
260:
261: `v'
262: Compiler driver program prints the commands it executes as it runs
263: the preprocessor, compiler proper, assembler and linker.
264:
265: `BPREFIX'
266: Compiler driver program tries PREFIX as a prefix for each program
267: it tries to run. These programs are `cpp', `cc1',
268: `as' and `ld'.
269:
270: For each subprogram to be run, the compiler driver first tries the
271: `-B' prefix, if any. If that name is not found, or if `-B'
272: was not specified, the driver tries two standard prefixes, which are
273: `/usr/lib/gcc-' and `/usr/local/lib/gcc-'. If neither of
274: those results in a file name that is found, the unmodified program
275: name is searched for using the `PATH' environment variable.
276:
277:
278: File: internals Node: Installation, Prev: Switches, Up: Top, Next: Portability
279:
280: Installing GNU CC
281: *****************
282:
283: 1. Choose configuration files.
284:
285: * Make a symbolic link from file `config.h' to the top-level
286: config file for the machine you are using. Its name should be
287: `config-MACHINE.h'. This file is responsible for
288: defining information about the host machine. It includes
289: `tm.h'.
290:
291: * Make a symbolic link from `tm.h' to the machine-description
292: macro file for your machine (its name should be
293: `tm-MACHINE.h').
294:
295: * Make a symbolic link from `md' to the
296: machine description pattern file (its name should be
297: `MACHINE.md').
298:
299: * Make a symbolic link from
300: `aux-output.c' to the output-subroutine file for your machine
301: (its name should be `MACHINE-output.c').
302:
303: 2. Make sure the Bison parser generator is installed.
304:
305: 3. Build the compiler. Just type `make' in the compiler directory.
306:
307: 4. Delete `*.o' in the compiler directory. The executables from
308: the previous step remain for the next step.
309:
310: 5. Remake the compiler with
311:
312: make CC=./gcc CFLAGS="-g -O -I."
313:
314: 6. Install the compiler's passes. Copy the file `cc1' just made
315: to `/usr/local/lib/gcc-cc1'.
316:
317: Make the file `/usr/local/lib/gcc-cpp' either a link to `/lib/cpp'
318: or a copy of the file `cpp' generated by `make'.
319:
320: *Warning: the GNU CPP may not work for @file{ioctl.h}.* This
321: cannot be fixed in the GNU CPP because the bug is in `ioctl.h':
322: at least on some machines, it relies on behavior that is incompatible
323: with ANSI C. This behavior consists of substituting for macro
324: argument names when they appear inside of character constants.
325:
326: 7. Install the compiler driver. This is the file `gcc' generated
327: by `make'.
328:
329:
330: File: internals Node: Portability, Prev: Installation, Up: Top, Next: Passes
331:
332: GNU CC and Portability
333: **********************
334:
335: The main goal of GNU CC was to make a good, fast compiler for machines in
336: the class that the GNU system aims to run on: 32-bit machines that address
337: 8-bit bytes and have several general registers. Elegance, theoretical
338: power and simplicity are only secondary.
339:
340: GNU CC gets most of the information about the target machine from a machine
341: description which gives an algebraic formula for each of the machine's
342: instructions. This is a very clean way to describe the target. But when
343: the compiler needs information that is difficult to express in this
344: fashion, I have not hesitated to define an ad-hoc parameter to the machine
345: description. The purpose of portability is to reduce the total work needed
346: on the compiler; it was not of interest for its own sake.
347:
348: GNU CC does not contain machine dependent code, but it does contain code
349: that depends on machine parameters such as endianness (whether the most
350: significant byte has the highest or lowest address of the bytes in a word)
351: and the availability of autoincrement addressing. In the RTL-generation
352: pass, it is often necessary to have multiple strategies for generating code
353: for a particular kind of syntax tree, strategies that are usable for different
354: combinations of parameters. Often I have not tried to address all possible
355: cases, but only the common ones or only the ones that I have encountered.
356: As a result, a new target may require additional strategies. You will know
357: if this happens because the compiler will call `abort'. Fortunately,
358: the new strategies can be added to all versions of the compiler, and will
359: be relevant only for target machines that need them.
360:
361:
362: File: internals Node: Passes, Prev: Portability, Up: Top, Next: RTL
363:
364: Passes and Files of the Compiler
365: ********************************
366:
367: The overall control structure of the compiler is in `toplev.c'. This
368: file is responsible for initialization, decoding arguments, opening and
369: closing files, and sequencing the passes.
370:
371: The parsing pass is invoked only once, to parse the entire input. Each
372: time a complete function definition or top-level data definition is read,
373: the parsing pass calls the function `rest_of_compilation' in
374: `toplev.c', which is responsible for all further processing necessary,
375: ending with output of the assembler language. All other compiler passes
376: run, in sequence, within `rest_of_compilation'. After
377: `rest_of_compilation' returns from compiling a function definition,
378: the storage used for its compilation is entirely freed.
379:
380: Here is a list of all the passes of the compiler and their source files.
381: Also included is a description of where debugging dumps can be requested
382: with `-d' switches.
383:
384: * Parsing. This pass reads the entire text of a function definition,
385: constructing a syntax tree. The tree representation does not entirely
386: follow C syntax, because it is intended to support other languages as well.
387:
388: C data type analysis is also done in this pass, and every tree node that
389: represents an expression has a data type attached. Variables are represented
390: as declaration nodes.
391:
392: Constant folding and associative-law simplifications are also done during
393: this pass.
394:
395: The source files of the parsing pass are `parse.y', `decl.c',
396: `typecheck.c', `stor-layout.c', `fold-const.c', and
397: `tree.c'. The last three are intended to be language-independent.
398: There are also header files `parse.h', `c-tree.h',
399: `tree.h' and `tree.def'. The last two define the format of
400: the tree representation.
401:
402: * RTL generation. This pass converts the tree structure for one
403: function into RTL code.
404:
405: This is where the bulk of target-parameter-dependent code is found,
406: since often it is necessary for strategies to apply only when certain
407: standard kinds of instructions are available. The purpose of named
408: instruction patterns is to provide this information to the RTL
409: generation pass.
410:
411: Optimization is done in this pass for `if'-conditions that are
412: comparisons, boolean operations or conditional expressions. Tail
413: recursion is detected at this time also. Decisions are made about how
414: best to arrange loops and how to output `switch' statements.
415:
416: The files of the RTL generation pass are `stmt.c', `expr.c',
417: `explow.c', `expmed.c', `optabs.c' and `emit-rtl.c'.
418: Also, the file `insn-emit.c', generated from the machine description
419: by the program `genemit', is used in this pass. The header files
420: `expr.h' is used for communication within this pass.
421:
422: The header files `insn-flags.h' and `insn-codes.h', generated from
423: the machine description by the programs `genflags' and `gencodes',
424: tell this pass which standard names are available for use and which patterns
425: correspond to them.
426:
427: Aside from debugging information output, none of the following passes
428: refers to the tree structure representation of the function.
429:
430: The switch `-dr' causes a debugging dump of the RTL code after this
431: pass. This dump file's name is made by appending `.rtl' to the
432: input file name.
433:
434: * Jump optimization. This pass simplifies jumps to the following instruction,
435: jumps across jumps, and jumps to jumps. It deletes unreferenced labels
436: and unreachable code, except that unreachable code that contains a loop
437: is not recognized as unreachable in this pass. (Such loops are deleted
438: later in the basic block analysis.)
439:
440: Jump optimization is performed two or three times. The first time is
441: immediately following RTL generation.
442:
443: The source file of this pass is `jump.c'.
444:
445: The switch `-dj' causes a debugging dump of the RTL code after this
446: pass is run for the first time. This dump file's name is made by appending
447: `.jump' to the input file name.
448:
449: * Register scan. This pass finds the first and last use of each
450: register, as a guide for common subexpression elimination. Its source
451: is in `regclass.c'.
452:
453: * Common subexpression elimination. This pass also does constant
454: propagation. Its source file is `cse.c'. If constant
455: propagation causes conditional jumps to become unconditional or to
456: become no-ops, jump optimization is run again when cse is finished.
457:
458: The switch `-ds' causes a debugging dump of the RTL code after
459: this pass. This dump file's name is made by appending `.cse' to
460: the input file name.
461:
462: * Loop optimization. This pass moves constant expressions out of loops.
463: Its source file is `loop.c'.
464:
465: The switch `-dL' causes a debugging dump of the RTL code after
466: this pass. This dump file's name is made by appending `.loop' to
467: the input file name.
468:
469: * Stupid register allocation is performed at this point in a
470: nonoptimizing compilation. It does a little data flow analysis as
471: well. When stupid register allocation is in use, the next pass
472: executed is the reloading pass; the others in between are skipped.
473: The source file is `stupid.c', with header file `stupid.h'
474: used for communication with the RTL generation pass.
475:
476: * Data flow analysis (`flow.c'). This pass divides the program
477: into basic blocks (and in the process deletes unreachable loops); then
478: it computes which pseudo-registers are live at each point in the
479: program, and makes the first instruction that uses a value point at
480: the instruction that computed the value.
481:
482: This pass also deletes computations whose results are never used, and
483: combines memory references with add or subtract instructions to make
484: autoincrement or autodecrement addressing.
485:
486: The switch `-df' causes a debugging dump of the RTL code after
487: this pass. This dump file's name is made by appending `.flow' to
488: the input file name. If stupid register allocation is in use, this
489: dump file reflects the full results of such allocation.
490:
491: * Instruction combination (`combine.c'). This pass attempts to
492: combine groups of two or three instructions that are related by data
493: flow into single instructions. It combines the RTL expressions for
494: the instructions by substitution, simplifies the result using algebra,
495: and then attempts to match the result against the machine description.
496:
497: The switch `-dc' causes a debugging dump of the RTL code after
498: this pass. This dump file's name is made by appending `.combine'
499: to the input file name.
500:
501: * Register class preferencing. The RTL code is scanned to find out
502: which register class is best for each pseudo register. The source file
503: is `regclass.c'.
504:
505: * Local register allocation (`local-alloc.c'). This pass allocates
506: hard registers to pseudo registers that are used only within one basic
507: block. Because the basic block is linear, it can use fast and powerful
508: techniques to do a very good job.
509:
510: The switch `-dl' causes a debugging dump of the RTL code after
511: this pass. This dump file's name is made by appending `.lreg' to
512: the input file name.
513:
514: * Global register allocation (`global-alloc.c'). This pass
515: allocates hard registers for the remaining pseudo registers (those
516: whose life spans are not contained in one basic block).
517:
518: * Reloading. This pass finds instructions that are invalid because a
519: value has failed to end up in a register, or has ended up in a
520: register of the wrong kind. It fixes up these instructions by
521: reloading the problematical values into registers temporarily.
522: Additional instructions are generated to do the copying.
523:
524: Source files are `reload.c' and `reload1.c', plus the header
525: `reload.h' used for communication between them.
526:
527: The switch `-dg' causes a debugging dump of the RTL code after
528: this pass. This dump file's name is made by appending `.greg' to
529: the input file name.
530:
531: * Jump optimization is repeated, this time including cross-jumping.
532:
533: * Final. This pass outputs the assembler code for the function. It is
534: also responsible for identifying no-op move instructions and spurious
535: test and compare instructions. The function entry and exit sequences
536: are generated directly as assembler code in this pass; they never
537: exist as RTL. Pseudo registers that did not get hard registers are
538: given stack slots in this pass.
539:
540: The source files are `final.c' plus `insn-output.c'; the
541: latter is generated automatically from the machine description by the
542: tool `genoutput'. The header file `conditions.h' is used
543: for communication between these files.
544:
545: * Debugging information output. This is run after final because it must
546: output the stack slot offsets for pseudo registers that did not get
547: hard registers. Source files are `dbxout.c' for DBX symbol table
548: format and `symout.c' for GDB's own symbol table format.
549:
550: Some additional files are used by all or many passes:
551:
552: * Every pass uses `machmode.def', which defines the machine modes.
553:
554: * All the passes that work with RTL use the header files `rtl.h'
555: and `rtl.def', and subroutines in file `rtl.c'. The
556: tools `gen*' also use these files to read and work with the
557: machine description RTL.
558:
559: * Several passes refer to the header file `insn-config.h' which
560: contains a few parameters (C macro definitions) generated
561: automatically from the machine description RTL by the tool
562: `genconfig'.
563:
564: * Several passes use the instruction recognizer, which consists of
565: `recog.c' and `recog.h', plus the files `insn-recog.c'
566: and `insn-extract.c' that are generated automatically from the
567: machine description by the tools `genrecog' and `genextract'.
568:
569: * Several passes use the header file `regs.h' which defines the
570: information recorded about pseudo register usage, `basic-block.h'
571: which defines the information recorded about basic blocks.
572:
573: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector
574: with a bit for each hard register, and some macros to manipulate it.
575: This type is just `int' if the machine has few enough hard registers;
576: otherwise it is an array of `int' and some of the macros expand
577: into loops.
578:
579:
580: File: internals Node: RTL, Prev: Passes, Up: Top, Next: Machine Desc
581:
582: RTL Representation
583: ******************
584:
585: Most of the work of the compiler is done on an intermediate representation
586: called register tranfer language. In this language, the instructions to be
587: output are described, pretty much one by one, in an algebraic form that
588: describes what the instruction does.
589:
590: RTL is inspired by Lisp lists. It has both an internal form, made up of
591: structures that point at other structures, and a textual form that is used
592: in the machine description and in printed debugging dumps. The textual
593: form uses nested parentheses to indicate the pointers in the internal form.
594:
595: * Menu:
596:
597: * RTL Objects:: Expressions vs vectors vs strings vs integers.
598: * Accessors:: Macros to access expression operands or vector elts.
599: * Machine Modes:: Describing the size and format of a datum.
600: * Constants:: Expressions with constant values.
601: * Regs and Memory:: Expressions representing register contents or memory.
602: * Arithmetic:: Expressions representing arithmetic on other expressions.
603: * Comparisons:: Expressions representing comparison of expressions.
604: * Bit Fields:: Expressions representing bit-fields in memory or reg.
605: * Conversions:: Extending, truncating, floating or fixing.
606: * RTL Declarations:: Declaring volatility, constancy, etc.
607: * Side Effects:: Expressions for storing in registers, etc.
608: * Incdec:: Embedded side-effects for autoincrement addressing.
609: * Insns:: Expression types for entire insns.
610: * Sharing:: Some expressions are unique; others *must* be copied.
611:
612:
613: File: internals Node: RTL Objects, Prev: RTL, Up: RTL, Next: Accessors
614:
615: RTL Object Types
616: ================
617:
618: RTL uses four kinds of objects: expressions, integers, strings and vectors.
619: Expressions are the most important ones. An RTL expression is a C
620: structure, but it is usually referred to with a pointer; a type that is
621: given the typedef name `rtx'.
622:
623: An integer is simply an `int', and a string is a `char *'.
624: Within rtl code, strings appear only inside `symbol_ref' expressions,
625: but they appear in other contexts in the rtl expressions that make up
626: machine descriptions. Their written form uses decimal digits.
627:
628: A string is a sequence of characters. In core it is represented as a
629: `char *' in usual C fashion, and they are written in C syntax as well.
630: However, strings in RTL may never be null. If you write an empty string in
631: a machine description, it is represented in core as a null pointer rather
632: than as a pointer to a null character. In certain contexts, these null
633: pointers instead of strings are valid.
634:
635: A vector contains an arbitrary, specified number of pointers to
636: expressions. The number of elements in the vector is explicitly present in
637: the vector. The written form of a vector consists of square brackets
638: (`[...]') surrounding the elements, in sequence and with
639: whitespace separating them. Vectors of length zero are not created; null
640: pointers are used instead.
641:
642: Expressions are classified by "expression code". The expression code
643: is a name defined in `rtl.def', which is also (in upper case) a C
644: enumeration constant. The possible expression codes and their meanings are
645: machine-independent. The code of an rtx can be extracted with the macro
646: `GET_CODE (X)' and altered with `PUT_CODE (X,
647: NEWCODE)'.
648:
649: The expression code determines how many operands the expression contains,
650: and what kinds of objects they are. In RTL, unlike Lisp, you cannot tell
651: by looking at an operand what kind of object it is. Instead, you must know
652: from its context---from the expression code of the containing expression.
653: For example, in an expression of code `subreg', the first operand is
654: to be regarded as an expression and the second operand as an integer. In
655: an expression of code `plus', there are two operands, both of which
656: are to be regarded as expressions. In a `symbol_ref' expression,
657: there is one operand, which is to be regarded as a string.
658:
659: Expressions are written as parentheses containing the name of the
660: expression type, its flags and machine mode if any, and then the operands
661: of the expression (separated by spaces).
662:
663: In a few contexts a null pointer is valid where an expression is normally
664: wanted. The written form of this is `(nil)'.
665:
666:
667: File: internals Node: Accessors, Prev: RTL Objects, Up: RTL, Next: Machine Modes
668:
669: Access to Operands
670: ==================
671:
672: For each expression type `rtl.def' specifies the number of contained
673: objects and their kinds, with four possibilities: `e' for expression
674: (actually a pointer to an expression), `i' for integer, `s' for
675: string, and `E' for vector of expressions. The sequence of letters
676: for an expression code is called its "format". Thus, the format of
677: `subreg' is `ei'.
678:
679: Two other format characters are used occasionally: `u' and `0'.
680: `u' is equivalent to `e' except that it is printed differently in
681: debugging dumps, and `0' means a slot whose contents do not fit any
682: normal category. `0' slots are not printed at all in dumps, and are
683: often used in special ways by small parts of the compiler.
684:
685: There are macros to get the number of operands and the format of an
686: expression code:
687:
688: `GET_RTX_LENGTH (CODE)'
689: Number of operands of an rtx of code CODE.
690:
691: `GET_RTX_FORMAT (CODE)'
692: The format of an rtx of code CODE, as a C string.
693:
694: Operands of expressions are accessed using the macros `XEXP',
695: `XINT' and `XSTR'. Each of these macros takes two arguments: an
696: expression-pointer (rtx) and an operand number (counting from zero). Thus,
697:
698: XEXP (x, 2)
699:
700: accesses operand 2 of expression X, as an expression.
701:
702: XINT (x, 2)
703:
704: accesses the same operand as an integer. `XSTR', used in the same
705: fashion, would access it as a string.
706:
707: Any operand can be accessed as an integer, as an expression or as a string.
708: You must choose the correct method of access for the kind of value actually
709: stored in the operand. You would do this based on the expression code of
710: the containing expression. That is also how you would know how many
711: operands there are.
712:
713: For example, if X is a `subreg' expression, you know that it has
714: two operands which can be correctly accessed as `XEXP (x, 0)' and
715: `XINT (x, 1)'. If you did `XINT (x, 0)', you would get the
716: address of the expression operand but cast as an integer; that might
717: occasionally be useful, but it would be cleaner to write `(int) XEXP
718: (x, 0)'. `XEXP (x, 1)' would also compile without error, and would
719: return the second, integer operand cast as an expression pointer, which
720: would probably result in a crash when accessed. Nothing stops you from
721: writing `XEXP (x, 28)' either, but this will access memory past the
722: end of the expression with unpredictable results.
723:
724: Access to operands which are vectors is more complicated. You can use the
725: macro `XVEC' to get the vector-pointer itself, or the macros
726: `XVECEXP' and `XVECLEN' to access the elements and length of a
727: vector.
728:
729: `XVEC (EXP, IDX)'
730: Access the vector-pointer which is operand number IDX in EXP.
731:
732: `XVECLEN (EXP, IDX)'
733: Access the length (number of elements) in the vector which is
734: in operand number IDX in EXP. This value is an `int'.
735:
736: `XVECLEN (EXP, IDX, ELTNUM)'
737: Access element number ELTNUM in the vector which is
738: in operand number IDX in EXP. This value is an `rtx'.
739:
740: It is up to you to make sure that ELTNUM is not negative
741: and is less than `XVECLEN (EXP, IDX)'.
742:
743: All the macros defined in this section expand into lvalues and therefore
744: can be used to assign the operands, lengths and vector elements as well as
745: to access them.
746:
747:
748: File: internals Node: Machine Modes, Prev: Accessors, Up: RTL, Next: Constants
749:
750: Machine Modes
751: =============
752:
753: A machine mode describes a size of data object and the representation used
754: for it. In the C code, machine modes are represented by an enumeration
755: type, `enum machine_mode'. Each rtl expression has room for a machine
756: mode and so do certain kinds of tree expressions (declarations and types,
757: to be precise).
758:
759: In debugging dumps and machine descriptions, the machine mode of an RTL
760: expression is written after the expression code with a colon to separate
761: them. The letters `mode' which appear at the end of each machine mode
762: name are omitted. For example, `(reg:SI 38)' is a `reg'
763: expression with machine mode `SImode'. If the mode is
764: `VOIDmode', it is not written at all.
765:
766: Here is a table of machine modes.
767:
768: `QImode'
769: "Quarter-Integer" mode represents a single byte treated as an integer.
770:
771: `HImode'
772: "Half-Integer" mode represents a two-byte integer.
773:
774: `SImode'
775: "Single Integer" mode represents a four-byte integer.
776:
777: `DImode'
778: "Double Integer" mode represents an eight-byte integer.
779:
780: `TImode'
781: "Tetra Integer" (?) mode represents a sixteen-byte integer.
782:
783: `SFmode'
784: "Single Floating" mode represents a single-precision (four byte) floating
785: point number.
786:
787: `DFmode'
788: "Double Floating" mode represents a double-precision (eight byte) floating
789: point number.
790:
791: `TFmode'
792: "Tetra Floating" mode represents a quadruple-precision (sixteen byte)
793: floating point number.
794:
795: `BLKmode'
796: "Block" mode represents values that are aggregates to which none of
797: the other modes apply. In rtl, only memory references can have this mode,
798: and only if they appear in string-move or vector instructions. On machines
799: which have no such instructions, `BLKmode' will not appear in RTL.
800:
801: `VOIDmode'
802: Void mode means the absence of a mode or an unspecified mode.
803: For example, RTL expresslons of code `const_int' have mode
804: `VOIDmode' because they can be taken to have whatever mode the context
805: requires. In debugging dumps of RTL, `VOIDmode' is expressed by
806: the absence of any mode.
807:
808: `EPmode'
809: "Entry Pointer" mode is intended to be used for function variables in
810: Pascal and other block structured languages. Such values contain
811: both a function address and a static chain pointer for access to
812: automatic variables of outer levels. This mode is only partially
813: implemented since C does not use it.
814:
815: `CSImode, ...'
816: "Complex Single Integer" mode stands for a complex number represented
817: as a pair of `SImode' integers. Any of the integer and floating modes
818: may have `C' prefixed to its name to obtain a complex number mode.
819: For example, there are `CQImode', `CSFmode', and `CDFmode'.
820: Since C does not support complex numbers, these machine modes are only
821: partially implemented.
822:
823: `BImode'
824: This is the machine mode of a bit-field in a structure. It is used
825: only in the syntax tree, never in RTL, and in the syntax tree it appears
826: only in declaration nodes. In C, it appears only in `FIELD_DECL'
827: nodes for structure fields defined with a bit size.
828:
829: The machine description defines `Pmode' as a C macro which expands
830: into the machine mode used for addresses. Normally this is `SImode'.
831:
832: The only modes which a machine description must support are
833: `QImode', `SImode', `SFmode' and `DFmode'. The
834: compiler will attempt to use `DImode' for two-word structures and
835: unions, but it would not be hard to program it to avoid this. Likewise,
836: you can arrange for the C type `short int' to avoid using
837: `HImode'. In the long term it would be desirable to make the set of
838: available machine modes machine-dependent and eliminate all assumptions
839: about specific machine modes or their uses from the machine-independent
840: code of the compiler.
841:
842: Here are some C macros that relate to machine modes:
843:
844: `GET_MODE (X)'
845: Returns the machine mode of the rtx X.
846:
847: `PUT_MODE (X, NEWMODE)'
848: Alters the machine mode of the rtx X to be NEWMODE.
849:
850: `GET_MODE_SIZE (M)'
851: Returns the size in bytes of a datum of mode M.
852:
853: `GET_MODE_BITSIZE (M)'
854: Returns the size in bits of a datum of mode M.
855:
856: `GET_MODE_UNIT_SIZE (M)'
857: Returns the size in bits of the subunits of a datum of mode M.
858: This is the same as `GET_MODE_SIZE' except in the case of
859: complex modes and `EPmode'. For them, the unit size ithe
860: size of the real or imaginary part, or the size of the function
861: pointer or the context pointer.
862:
863:
864: File: internals Node: Constants, Prev: Machine Modes, Up: RTL, Next: Regs and Memory
865:
866: Constant Expression Types
867: =========================
868:
869: The simplest RTL expressions are those that represent constant values.
870:
871: `(const_int I)'
872: This type of expression represents the integer value I. I
873: is customarily accessed with the macro `INTVAL' as in
874: `INTVAL (exp)', which is equivalent to `XINT (exp, 0)'.
875:
876: There is only one expression object for the integer value zero;
877: it is the value of the variable `const0_rtx'. Likewise, the
878: only expression for integer value one is found in `const1_rtx'.
879: Any attempt to create an expression of code `const_int' and
880: value zero or one will return `const0_rtx' or `const1_rtx'
881: as appropriate.
882:
883: `(const_double:M I0 I1)'
884: Represents a floating point constant value of mode M. The two
885: integers I0 and I1 together contain the bits of a
886: `double' value. To convert them to a `double', do
887:
888: union { double d; int i[2];} u;
889: u.i[0] = XINT (x, 0);
890: u.i[1] = XINT (x, 1);
891:
892: and then refer to `u.d'. The value of the constant is
893: represented as a double in this fashion even if the value represented
894: is single-precision.
895:
896: `dconst0_rtx' and `fconst0_rtx' are `CONST_DOUBLE'
897: expressions with value 0 and modes `DFmode' and `SFmode'.
898:
899: `(symbol_ref SYMBOL)'
900: Represents the value of an assembler label for data. SYMBOL is
901: a string that describes the name of the assembler label. If it starts
902: with a `*', the label is the rest of SYMBOL not including
903: the `*'. Otherwise, the label is SYMBOL, prefixed with
904: `_'.
905:
906: `(label_ref LABEL)'
907: Represents the value of an assembler label for code. It contains one
908: operand, an expression, which must be a `code_label' that appears
909: in the instruction sequence to identify the place where the label
910: should go.
911:
912: The reason for using a distinct expression type for code label
913: references is so that jump optimization can distinguish them.
914:
915: `(const EXP)'
916: Represents a constant that is the result of an assembly-time
917: arithmetic computation. The operand, EXP, is an expression that
918: contains only constants (`const_int', `symbol_ref' and
919: `label_ref' expressions) combined with `plus' and
920: `minus'. However, not all combinations are valid, since the
921: assembler cannot do arbitrary arithmetic on relocatable symbols.
922:
923:
924: File: internals Node: Regs and Memory, Prev: Constants, Up: RTL, Next: Arithmetic
925:
926: Registers and Memory
927: ====================
928:
929: Here are the RTL expression types for describing access to machine
930: registers and to main memory.
931:
932: `(reg:M N)'
933: For small values of the integer N (less than
934: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
935: register number N: a "hard register". For larger values of
936: N, it stands for a temporary value or "pseudo register".
937: The compiler's strategy is to generate code assuming an unlimited
938: number of such pseudo registers, and later convert them into hard
939: registers or into memory references.
940:
941: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
942: description, since the number of hard registers on the machine is an
943: invariant characteristic of the machine. Note, however, that not
944: all of the machine registers must be general registers. All the
945: machine registers that can be used for storage of data are given
946: hard register numbers, even those that can be used only in certain
947: instructions or can hold only certain types of data.
948:
949: Each pseudo register number used in a function's rtl code is
950: represented by a unique `reg' expression.
951:
952: M is the machine mode of the reference. It is necessary because
953: machines can generally refer to each register in more than one mode.
954: For example, a register may contain a full word but there may be
955: instructions to refer to it as a half word or as a single byte, as
956: well as instructions to refer to it as a floating point number of
957: various precisions.
958:
959: Even for a register that the machine can access in only one mode,
960: the mode must always be specified.
961:
962: A hard register may be accessed in various modes throughout one
963: function, but each pseudo register is given a natural mode
964: and is accessed only in that mode. When it is necessary to describe
965: an access to a pseudo register using a nonnatural mode, a `subreg'
966: expression is used.
967:
968: A `reg' expression with a machine mode that specifies more than
969: one word of data may actually stand for several consecutive registers.
970: If in addition the register number specifies a hardware register, then
971: it actually represents several consecutive hardware registers starting
972: with the specified one.
973:
974: Such multi-word hardware register `reg' expressions may not be live
975: across the boundary of a basic block. The lifetime analysis pass does not
976: know how to record properly that several consecutive registers are
977: actually live there, and therefore register allocation would be confused.
978: The CSE pass must go out of its way to make sure the situation does
979: not arise.
980:
981: `(subreg:M REG WORDNUM)'
982: `subreg' expressions are used to refer to a register in a machine
983: mode other than its natural one, or to refer to one register of
984: a multi-word `reg' that actually refers to several registers.
985:
986: Each pseudo-register has a natural mode. If it is necessary to
987: operate on it in a different mode---for example, to perform a fullword
988: move instruction on a pseudo-register that contains a single byte---
989: the pseudo-register must be enclosed in a `subreg'. In such
990: a case, WORDNUM is zero.
991:
992: The other use of `subreg' is to extract the individual registers
993: of a multi-register value. Machine modes such as `DImode' and
994: `EPmode' indicate values longer than a word, values which usually
995: require two consecutive registers. To access one of the registers,
996: use a `subreg' with mode `SImode' and a WORDNUM that
997: says which register.
998:
999: The compilation parameter `WORDS_BIG_ENDIAN', if defined, says
1000: that word number zero is the most significant part; otherwise, it is
1001: the least significant part.
1002:
1003: Note that it is not valid to access a `DFmode' value in `SFmode'
1004: using a `subreg'. On some machines the most significant part of a
1005: `DFmode' value does not have the same format as a single-precision
1006: floating value.
1007:
1008: `(cc0)'
1009: This refers to the machine's condition code register. It has no
1010: operands and may not have a machine mode. It may be validly used in
1011: only two contexts: as the destination of an assignment (in test and
1012: compare instructions) and in comparison operators comparing against
1013: zero (`const_int' with value zero; that is to say,
1014: `const0_rtx'.
1015:
1016: There is only one expression object of code `cc0'; it is the
1017: value of the variable `cc0_rtx'. Any attempt to create an
1018: expression of code `cc0' will return `cc0_rtx'.
1019:
1020: One special thing about the condition code register is that instructions
1021: can set it implicitly. On many machines, nearly all instructions set
1022: the condition code based on the value that they compute or store.
1023: It is not necessary to record these actions explicitly in the RTL
1024: because the machine description includes a prescription for recognizing
1025: the instructions that do so (by means of the macro `NOTICE_UPDATE_CC').
1026: Only instructions whose sole purpose is to set the condition code,
1027: and instructions that use the condition code, need mention `(cc0)'.
1028:
1029: `(pc)'
1030: This represents the machine's program counter. It has no operands and
1031: may not have a machine mode. `(pc)' may be validly used only in
1032: certain specific contexts in jump instructions.
1033:
1034: There is only one expression object of code `pc'; it is the value of
1035: the variable `pc_rtx'. Any attempt to create an expression of code
1036: `pc' will return `pc_rtx'.
1037:
1038: All instructions that do not jump alter the program counter implicitly,
1039: but there is no need to mention this in the RTL.
1040:
1041: `(mem:M ADDR)'
1042: This rtx represents a reference to main memory at an address
1043: represented by the expression ADDR. M specifies how
1044: large a unit of memory is accessed.
1045:
1046:
1047: File: internals Node: Arithmetic, Prev: Regs and Memory, Up: RTL, Next: Comparisons
1048:
1049: RTL Expressions for Arithmetic
1050: ==============================
1051:
1052: `(plus:M X Y)'
1053: Represents the sum of the values represented by X and Y
1054: carried out in machine mode M. This is valid only if
1055: X and Y both are valid for mode M.
1056:
1057: `(minus:M X Y)'
1058: Like `plus' but represents subtraction.
1059:
1060: `(minus X Y)'
1061: Represents the result of subtracting Y from X
1062: for purposes of comparison. The absence of a machine mode
1063: in the `minus' expression indicates that the result is
1064: computed without overflow, as if with infinite precision.
1065:
1066: Of course, machines can't really subtract with infinite precision.
1067: However, they can pretend to do so when only the sign of the
1068: result will be used, which is the case when the result is stored
1069: in `(cc0)'. And that is the only was this kind of expression
1070: may validly be used: as a value to be stored in the condition codes.
1071:
1072: `(neg:M X)'
1073: Represents the negation (subtraction from zero) of the value
1074: represented by X, carried out in mode M. X must be
1075: valid for mode M.
1076:
1077: `(mult:M X Y)'
1078: Represents the signed product of the values represented by X and
1079: Y carried out in machine mode M. If
1080: X and Y are both valid for mode M, this is ordinary
1081: size-preserving multiplication. Alteratively, both X and Y
1082: may be valid for a different, narrower mode. This represents the
1083: kind of multiplication that generates a product wider than the operands.
1084: Widening multiplication and same-size multiplication are completely
1085: distinct and supported by different machine instructions; machines may
1086: support one but not the other.
1087:
1088: `mult' may be used for floating point division as well.
1089: Then M is a floating point machine mode.
1090:
1091: `(umult:M X Y)'
1092: Like `mult' but represents unsigned multiplication. It may be
1093: used in both same-size and widening forms, like `mult'.
1094: `umult' is used only for fixed-point division.
1095:
1096: `(div:M X Y)'
1097: Represents the quotient in signed division of X by Y,
1098: carried out in machine mode M. If M is a floating-point
1099: mode, it represents the exact quotient; otherwise, the integerized
1100: quotient. If X and Y are both valid for mode M,
1101: this is ordinary size-preserving division. Some machines have
1102: division instructions in which the operands and quotient widths are
1103: not all the same; such instructions are represented by `div'
1104: expressions in which the machine modes are not all the same.
1105:
1106: `(udiv:M X Y)'
1107: Like `div' but represents unsigned division.
1108:
1109: `(mod:M X Y)'
1110: `(umod:M X Y)'
1111: Like `div' and `udiv' but represent the remainder instead of
1112: the quotient.
1113:
1114: `(not:M X)'
1115: Represents the bitwise complement of the value represented by X,
1116: carried out in mode M, which must be a fixed-point machine mode.
1117: X must be valid for mode M, which must be a fixed-point mode.
1118:
1119: `(and:M X Y)'
1120: Represents the bitwise logical-and of the values represented by
1121: X and Y, carried out in machine mode M. This is
1122: valid only if X and Y both are valid for mode M,
1123: which must be a fixed-point mode.
1124:
1125: `(ior:M X Y)'
1126: Represents the bitwise inclusive-or of the values represented by
1127: X and Y, carried out in machine mode M. This is
1128: valid only if X and Y both are valid for mode M,
1129: which must be a fixed-point mode.
1130:
1131: `(xor:M X Y)'
1132: Represents the bitwise exclusive-or of the values represented by
1133: X and Y, carried out in machine mode M. This is
1134: valid only if X and Y both are valid for mode M,
1135: which must be a fixed-point mode.
1136:
1137: `(lshift:M X C)'
1138: Represents the result of logically shifting X left by C
1139: places. X must be valid for the mode M, a fixed-point
1140: machine mode. C must be valid for a fixed-point mode;
1141: which mode is determined by the mode called for in the machine
1142: description entry for the left-shift instruction. For example,
1143: on the Vax, the mode of C is `QImode' regardless of M.
1144:
1145: On some machines, negative values of C may be meaningful; this
1146: is why logical left shift an arithmetic left shift are distinguished.
1147: For example, Vaxes have no right-shift instructions, and right shifts
1148: are represented as left-shift instructions whose counts happen
1149: to be negative constants or else computed (in a previous instruction)
1150: by negation.
1151:
1152: `(ashift:M X C)'
1153: Like `lshift' but for arithmetic left shift.
1154:
1155: `(lshiftrt:M X C)'
1156: `(ashiftrt:M X C)'
1157: Like `lshift' and `ashift' but for right shift.
1158:
1159: `(rotate:M X C)'
1160: `(rotatert:M X C)'
1161: Similar but represent left and right rotate.
1162:
1163: `(abs:M X)'
1164: Represents the absolute value of X, computed in mode M.
1165: X must be valid for M.
1166:
1167: `(sqrt:M X)'
1168: Represents the square root of X, computed in mode M.
1169: X must be valid for M. Most often M will be
1170: a floating point mode.
1171:
1172:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.