![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.3 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.47 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 1.1.1.3 ! root 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. 1.1 root 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.3 ! root 14: that the sections entitled "GNU General Public License" and "Boycott" ! 15: are included exactly as in the original, and provided that the entire ! 16: resulting derived work is distributed under the terms of a permission ! 17: notice identical to this one. 1.1 root 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 1.1.1.3 ! root 21: versions, except that the sections entitled "GNU General Public ! 22: License" and "Boycott", and this permission notice, may be included in ! 23: translations approved by the Free Software Foundation instead of in the ! 24: original English. ! 25: ! 26: ! 27: File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS ! 28: ! 29: Other VMS Issues ! 30: ================ ! 31: ! 32: GNU CC automatically arranges for `main' to return 1 by default if ! 33: you fail to specify an explicit return value. This will be interpreted ! 34: by VMS as a status code indicating a normal successful completion. ! 35: Version 1 of GNU CC did not provide this default. ! 36: ! 37: GNU CC on VMS works only with the GNU assembler, GAS. You need ! 38: version 1.37 or later of GAS in order to produce value debugging ! 39: information for the VMS debugger. Use the ordinary VMS linker with the ! 40: object files produced by GAS. ! 41: ! 42: Under previous versions of GNU CC, the generated code would ! 43: occasionally give strange results when linked to the sharable `VAXCRTL' ! 44: library. Now this should work. ! 45: ! 46: A caveat for use of `const' global variables: the `const' modifier ! 47: must be specified in every external declaration of the variable in all ! 48: of the source files that use that variable. Otherwise the linker will ! 49: issue warnings about conflicting attributes for the variable. Your ! 50: program will still work despite the warnings, but the variable will be ! 51: placed in writable storage. ! 52: ! 53: The VMS linker does not distinguish between upper and lower case ! 54: letters in function and variable names. However, usual practice in C ! 55: is to distinguish case. Normally GNU CC (by means of the assembler GAS) ! 56: implements usual C behavior by augmenting each name that is not all ! 57: lower-case. A name is augmented by truncating it to at most 23 ! 58: characters and then adding more characters at the end which encode the ! 59: case pattern the rest. ! 60: ! 61: Name augmentation yields bad results for programs that use ! 62: precompiled libraries (such as Xlib) which were generated by another ! 63: compiler. You can use the compiler option `/NOCASE_HACK' to inhibit ! 64: augmentation; it makes external C functions and variables ! 65: case-independent as is usual on VMS. Alternatively, you could write ! 66: all references to the functions and variables in such libraries using ! 67: lower case; this will work on VMS, but is not portable to other systems. ! 68: ! 69: Function and variable names are handled somewhat differently with GNU ! 70: C++. The GNU C++ compiler performs "name mangling" on function names, ! 71: which means that it adds information to the function name to describe ! 72: the data types of the arguments that the function takes. One result of ! 73: this is that the name of a function can become very long. Since the VMS ! 74: linker only recognizes the first 31 characters in a name, special ! 75: action is taken to ensure that each function and variable has a unique ! 76: name that can be represented in 31 characters. ! 77: ! 78: If the name (plus a name augmentation, if required) is less than 32 ! 79: characters in length, then no special action is performed. If the name ! 80: is longer than 31 characters, the assembler (GAS) will generate a hash ! 81: string based upon the function name, truncate the function name to 23 ! 82: characters, and append the hash string to the truncated name. If the ! 83: `/VERBOSE' compiler option is used, the assembler will print both the ! 84: full and truncated names of each symbol that is truncated. ! 85: ! 86: The `/NOCASE_HACK' compiler option should not be used when you are ! 87: compiling programs that use libg++. libg++ has several instances of ! 88: objects (i.e. `Filebuf' and `filebuf') which become indistinguishable ! 89: in a case-insensitive environment. This leads to cases where you need ! 90: to inhibit augmentation selectively (if you were using libg++ and Xlib ! 91: in the same program, for example). There is no special feature for ! 92: doing this, but you can get the result by defining a macro for each ! 93: mixed case symbol for which you wish to inhibit augmentation. The ! 94: macro should expand into the lower case equivalent of itself. For ! 95: example: ! 96: ! 97: #define StuDlyCapS studlycaps ! 98: ! 99: These macro definitions can be placed in a header file to minimize ! 100: the number of changes to your source code. ! 101: ! 102: ! 103: File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top ! 104: ! 105: GNU CC and Portability ! 106: ********************** ! 107: ! 108: The main goal of GNU CC was to make a good, fast compiler for ! 109: machines in the class that the GNU system aims to run on: 32-bit ! 110: machines that address 8-bit bytes and have several general registers. ! 111: Elegance, theoretical power and simplicity are only secondary. ! 112: ! 113: GNU CC gets most of the information about the target machine from a ! 114: machine description which gives an algebraic formula for each of the ! 115: machine's instructions. This is a very clean way to describe the ! 116: target. But when the compiler needs information that is difficult to ! 117: express in this fashion, I have not hesitated to define an ad-hoc ! 118: parameter to the machine description. The purpose of portability is to ! 119: reduce the total work needed on the compiler; it was not of interest ! 120: for its own sake. ! 121: ! 122: GNU CC does not contain machine dependent code, but it does contain ! 123: code that depends on machine parameters such as endianness (whether the ! 124: most significant byte has the highest or lowest address of the bytes in ! 125: a word) and the availability of autoincrement addressing. In the ! 126: RTL-generation pass, it is often necessary to have multiple strategies ! 127: for generating code for a particular kind of syntax tree, strategies ! 128: that are usable for different combinations of parameters. Often I have ! 129: not tried to address all possible cases, but only the common ones or ! 130: only the ones that I have encountered. As a result, a new target may ! 131: require additional strategies. You will know if this happens because ! 132: the compiler will call `abort'. Fortunately, the new strategies can be ! 133: added in a machine-independent fashion, and will affect only the target ! 134: machines that need them. ! 135: ! 136: ! 137: File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top ! 138: ! 139: Interfacing to GNU CC Output ! 140: **************************** ! 141: ! 142: GNU CC is normally configured to use the same function calling ! 143: convention normally in use on the target system. This is done with the ! 144: machine-description macros described (*note Target Macros::.). ! 145: ! 146: However, returning of structure and union values is done differently ! 147: on some target machines. As a result, functions compiled with PCC ! 148: returning such types cannot be called from code compiled with GNU CC, ! 149: and vice versa. This does not cause trouble often because few Unix ! 150: library routines return structures or unions. ! 151: ! 152: GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes ! 153: long in the same registers used for `int' or `double' return values. ! 154: (GNU CC typically allocates variables of such types in registers also.) ! 155: Structures and unions of other sizes are returned by storing them into ! 156: an address passed by the caller (usually in a register). The ! 157: machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE' ! 158: tell GNU CC where to pass this address. ! 159: ! 160: By contrast, PCC on most target machines returns structures and ! 161: unions of any size by copying the data into an area of static storage, ! 162: and then returning the address of that storage as if it were a pointer ! 163: value. The caller must copy the data from that memory area to the place ! 164: where the value is wanted. This is slower than the method used by GNU ! 165: CC, and fails to be reentrant. ! 166: ! 167: On some target machines, such as RISC machines and the 80386, the ! 168: standard system convention is to pass to the subroutine the address of ! 169: where to return the value. On these machines, GNU CC has been ! 170: configured to be compatible with the standard compiler, when this method ! 171: is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. ! 172: ! 173: GNU CC uses the system's standard convention for passing arguments. ! 174: On some machines, the first few arguments are passed in registers; in ! 175: others, all are passed on the stack. It would be possible to use ! 176: registers for argument passing on any machine, and this would probably ! 177: result in a significant speedup. But the result would be complete ! 178: incompatibility with code that follows the standard convention. So this ! 179: change is practical only if you are switching to GNU CC as the sole C ! 180: compiler for the system. We may implement register argument passing on ! 181: certain machines once we have a complete GNU system so that we can ! 182: compile the libraries with GNU CC. ! 183: ! 184: On some machines (particularly the Sparc), certain types of arguments ! 185: are passed "by invisible reference". This means that the value is ! 186: stored in memory, and the address of the memory location is passed to ! 187: the subroutine. ! 188: ! 189: If you use `longjmp', beware of automatic variables. ANSI C says ! 190: that automatic variables that are not declared `volatile' have undefined ! 191: values after a `longjmp'. And this is all GNU CC promises to do, ! 192: because it is very difficult to restore register variables correctly, ! 193: and one of GNU CC's features is that it can put variables in registers ! 194: without your asking it to. ! 195: ! 196: If you want a variable to be unaltered by `longjmp', and you don't ! 197: want to write `volatile' because old C compilers don't accept it, just ! 198: take the address of the variable. If a variable's address is ever ! 199: taken, even if just to compute it and ignore it, then the variable ! 200: cannot go in a register: ! 201: ! 202: { ! 203: int careful; ! 204: &careful; ! 205: ... ! 206: } ! 207: ! 208: Code compiled with GNU CC may call certain library routines. Most of ! 209: them handle arithmetic for which there are no instructions. This ! 210: includes multiply and divide on some machines, and floating point ! 211: operations on any machine for which floating point support is disabled ! 212: with `-msoft-float'. Some standard parts of the C library, such as ! 213: `bcopy' or `memcpy', are also called automatically. The usual function ! 214: call interface is used for calling the library routines. ! 215: ! 216: These library routines should be defined in the library `libgcc.a', ! 217: which GNU CC automatically searches whenever it links a program. On ! 218: machines that have multiply and divide instructions, if hardware ! 219: floating point is in use, normally `libgcc.a' is not needed, but it is ! 220: searched just in case. ! 221: ! 222: Each arithmetic function is defined in `libgcc1.c' to use the ! 223: corresponding C arithmetic operator. As long as the file is compiled ! 224: with another C compiler, which supports all the C arithmetic operators, ! 225: this file will work portably. However, `libgcc1.c' does not work if ! 226: compiled with GNU CC, because each arithmetic function would compile ! 227: into a call to itself! 1.1 root 228: 229: 1.1.1.2 root 230: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top 231: 232: Passes and Files of the Compiler 233: ******************************** 234: 1.1.1.3 ! root 235: The overall control structure of the compiler is in `toplev.c'. This ! 236: file is responsible for initialization, decoding arguments, opening and ! 237: closing files, and sequencing the passes. 1.1.1.2 root 238: 239: The parsing pass is invoked only once, to parse the entire input. 240: The RTL intermediate code for a function is generated as the function 241: is parsed, a statement at a time. Each statement is read in as a 242: syntax tree and then converted to RTL; then the storage for the tree 1.1.1.3 ! root 243: for the statement is reclaimed. Storage for types (and the expressions ! 244: for their sizes), declarations, and a representation of the binding ! 245: contours and how they nest, remain until the function is finished being ! 246: compiled; these are all needed to output the debugging information. 1.1.1.2 root 247: 248: Each time the parsing pass reads a complete function definition or 249: top-level declaration, it calls the function `rest_of_compilation' or 1.1.1.3 ! root 250: `rest_of_decl_compilation' in `toplev.c', which are responsible for all ! 251: further processing necessary, ending with output of the assembler 1.1.1.2 root 252: language. All other compiler passes run, in sequence, within 1.1.1.3 ! root 253: `rest_of_compilation'. When that function returns from compiling a 1.1.1.2 root 254: function definition, the storage used for that function definition's 255: compilation is entirely freed, unless it is an inline function (*note 256: Inline::.). 257: 258: Here is a list of all the passes of the compiler and their source 1.1.1.3 ! root 259: files. Also included is a description of where debugging dumps can be 1.1.1.2 root 260: requested with `-d' options. 261: 1.1.1.3 ! root 262: * Parsing. This pass reads the entire text of a function definition, ! 263: constructing partial syntax trees. This and RTL generation are no ! 264: longer truly separate passes (formerly they were), but it is ! 265: easier to think of them as separate. 1.1.1.2 root 266: 1.1.1.3 ! root 267: The tree representation does not entirely follow C syntax, because ! 268: it is intended to support other languages as well. 1.1.1.2 root 269: 270: Language-specific data type analysis is also done in this pass, 271: and every tree node that represents an expression has a data type 1.1.1.3 ! root 272: attached. Variables are represented as declaration nodes. 1.1.1.2 root 273: 274: Constant folding and some arithmetic simplifications are also done 275: during this pass. 276: 277: The language-independent source files for parsing are 1.1.1.3 ! root 278: `stor-layout.c', `fold-const.c', and `tree.c'. There are also 1.1.1.2 root 279: header files `tree.h' and `tree.def' which define the format of 280: the tree representation. 281: 282: The source files for parsing C are `c-parse.y', `c-decl.c', 283: `c-typeck.c', `c-convert.c', `c-lang.c', and `c-aux-info.c' along 284: with header files `c-lex.h', and `c-tree.h'. 285: 286: The source files for parsing C++ are `cp-parse.y', `cp-class.c', 287: `cp-cvt.c', 288: `cp-decl.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', 289: `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', 1.1.1.3 ! root 290: `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along ! 291: with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. 1.1.1.2 root 292: 293: The special source files for parsing Objective C are 294: `objc-parse.y', `objc-actions.c', `objc-tree.def', and 295: `objc-actions.h'. Certain C-specific files are used for this as 296: well. 297: 298: The file `c-common.c' is also used for all of the above languages. 299: 300: * RTL generation. This is the conversion of syntax tree into RTL 1.1.1.3 ! root 301: code. It is actually done statement-by-statement during parsing, 1.1.1.2 root 302: but for most purposes it can be thought of as a separate pass. 303: 1.1.1.3 ! root 304: This is where the bulk of target-parameter-dependent code is found, ! 305: since often it is necessary for strategies to apply only when ! 306: certain standard kinds of instructions are available. The purpose ! 307: of named instruction patterns is to provide this information to ! 308: the RTL generation pass. 1.1.1.2 root 309: 310: Optimization is done in this pass for `if'-conditions that are 311: comparisons, boolean operations or conditional expressions. Tail 1.1.1.3 ! root 312: recursion is detected at this time also. Decisions are made about ! 313: how best to arrange loops and how to output `switch' statements. 1.1.1.2 root 314: 315: The source files for RTL generation include `stmt.c', 316: `function.c', `expr.c', `calls.c', `explow.c', `expmed.c', 317: `optabs.c' and `emit-rtl.c'. Also, the file `insn-emit.c', 318: generated from the machine description by the program `genemit', 319: is used in this pass. The header file `expr.h' is used for 320: communication within this pass. 321: 1.1.1.3 ! root 322: The header files `insn-flags.h' and `insn-codes.h', generated from ! 323: the machine description by the programs `genflags' and `gencodes', ! 324: tell this pass which standard names are available for use and ! 325: which patterns correspond to them. 1.1.1.2 root 326: 327: Aside from debugging information output, none of the following 1.1.1.3 ! root 328: passes refers to the tree structure representation of the function ! 329: (only part of which is saved). 1.1.1.2 root 330: 331: The decision of whether the function can and should be expanded 332: inline in its subsequent callers is made at the end of rtl 333: generation. The function must meet certain criteria, currently 334: related to the size of the function and the types and number of 335: parameters it has. Note that this function may contain loops, 336: recursive calls to itself (tail-recursive functions can be 337: inlined!), gotos, in short, all constructs supported by GNU CC. 338: The file `integrate.c' contains the code to save a function's rtl 339: for later inlining and to inline that rtl when the function is 340: called. The header file `integrate.h' is also used for this 341: purpose. 342: 343: The option `-dr' causes a debugging dump of the RTL code after 344: this pass. This dump file's name is made by appending `.rtl' to 345: the input file name. 346: 347: * Jump optimization. This pass simplifies jumps to the following 348: instruction, jumps across jumps, and jumps to jumps. It deletes 349: unreferenced labels and unreachable code, except that unreachable 1.1.1.3 ! root 350: code that contains a loop is not recognized as unreachable in this ! 351: pass. (Such loops are deleted later in the basic block analysis.) ! 352: It also converts some code originally written with jumps into ! 353: sequences of instructions that directly set values from the ! 354: results of comparisons, if the machine has such instructions. ! 355: ! 356: Jump optimization is performed two or three times. The first time ! 357: is immediately following RTL generation. The second time is after ! 358: CSE, but only if CSE says repeated jump optimization is needed. ! 359: The last time is right before the final pass. That time, ! 360: cross-jumping and deletion of no-op move instructions are done ! 361: together with the optimizations described above. 1.1.1.2 root 362: 363: The source file of this pass is `jump.c'. 364: 365: The option `-dj' causes a debugging dump of the RTL code after 366: this pass is run for the first time. This dump file's name is 367: made by appending `.jump' to the input file name. 368: 369: * Register scan. This pass finds the first and last use of each 370: register, as a guide for common subexpression elimination. Its 371: source is in `regclass.c'. 372: 373: * Jump threading. This pass detects a condition jump that branches 374: to an identical or inverse test. Such jumps can be `threaded' 375: through the second conditional test. The source code for this 376: pass is in `jump.c'. This optimization is only performed if 377: `-fthread-jumps' is enabled. 378: 379: * Common subexpression elimination. This pass also does constant 1.1.1.3 ! root 380: propagation. Its source file is `cse.c'. If constant propagation ! 381: causes conditional jumps to become unconditional or to become ! 382: no-ops, jump optimization is run again when CSE is finished. 1.1.1.2 root 383: 384: The option `-ds' causes a debugging dump of the RTL code after 385: this pass. This dump file's name is made by appending `.cse' to 386: the input file name. 387: 388: * Loop optimization. This pass moves constant expressions out of 389: loops, and optionally does strength-reduction and loop unrolling 1.1.1.3 ! root 390: as well. Its source files are `loop.c' and `unroll.c', plus the 1.1.1.2 root 391: header `loop.h' used for communication between them. Loop 392: unrolling uses some functions in `integrate.c' and the header 393: `integrate.h'. 394: 395: The option `-dL' causes a debugging dump of the RTL code after 396: this pass. This dump file's name is made by appending `.loop' to 397: the input file name. 398: 399: * If `-frerun-cse-after-loop' was enabled, a second common 400: subexpression elimination pass is performed after the loop 1.1.1.3 ! root 401: optimization pass. Jump threading is also done again at this time ! 402: if it was specified. 1.1.1.2 root 403: 404: The option `-dt' causes a debugging dump of the RTL code after 405: this pass. This dump file's name is made by appending `.cse2' to 406: the input file name. 407: 408: * Stupid register allocation is performed at this point in a 409: nonoptimizing compilation. It does a little data flow analysis as 410: well. When stupid register allocation is in use, the next pass 1.1.1.3 ! root 411: executed is the reloading pass; the others in between are skipped. 1.1.1.2 root 412: The source file is `stupid.c'. 413: 1.1.1.3 ! root 414: * Data flow analysis (`flow.c'). This pass divides the program into ! 415: basic blocks (and in the process deletes unreachable loops); then ! 416: it computes which pseudo-registers are live at each point in the ! 417: program, and makes the first instruction that uses a value point at ! 418: the instruction that computed the value. 1.1.1.2 root 419: 420: This pass also deletes computations whose results are never used, 421: and combines memory references with add or subtract instructions 422: to make autoincrement or autodecrement addressing. 423: 424: The option `-df' causes a debugging dump of the RTL code after 425: this pass. This dump file's name is made by appending `.flow' to 1.1.1.3 ! root 426: the input file name. If stupid register allocation is in use, this ! 427: dump file reflects the full results of such allocation. 1.1.1.2 root 428: 429: * Instruction combination (`combine.c'). This pass attempts to 430: combine groups of two or three instructions that are related by 431: data flow into single instructions. It combines the RTL 432: expressions for the instructions by substitution, simplifies the 433: result using algebra, and then attempts to match the result 434: against the machine description. 435: 436: The option `-dc' causes a debugging dump of the RTL code after 437: this pass. This dump file's name is made by appending `.combine' 438: to the input file name. 439: 440: * Instruction scheduling (`sched.c'). This pass looks for 441: instructions whose output will not be available by the time that 1.1.1.3 ! root 442: it is used in subsequent instructions. (Memory loads and floating ! 443: point instructions often have this behavior on RISC machines). It ! 444: re-orders instructions within a basic block to try to separate the ! 445: definition and use of items that otherwise would cause pipeline ! 446: stalls. 1.1.1.2 root 447: 448: Instruction scheduling is performed twice. The first time is 449: immediately after instruction combination and the second is 450: immediately after reload. 451: 1.1.1.3 ! root 452: The option `-dS' causes a debugging dump of the RTL code after this ! 453: pass is run for the first time. The dump file's name is made by ! 454: appending `.sched' to the input file name. 1.1.1.2 root 455: 456: * Register class preferencing. The RTL code is scanned to find out 457: which register class is best for each pseudo register. The source 458: file is `regclass.c'. 459: 460: * Local register allocation (`local-alloc.c'). This pass allocates 461: hard registers to pseudo registers that are used only within one 462: basic block. Because the basic block is linear, it can use fast 463: and powerful techniques to do a very good job. 464: 465: The option `-dl' causes a debugging dump of the RTL code after 466: this pass. This dump file's name is made by appending `.lreg' to 467: the input file name. 468: 469: * Global register allocation (`global-alloc.c'). This pass 470: allocates hard registers for the remaining pseudo registers (those 471: whose life spans are not contained in one basic block). 472: 473: * Reloading. This pass renumbers pseudo registers with the hardware 474: registers numbers they were allocated. Pseudo registers that did 475: not get hard registers are replaced with stack slots. Then it 476: finds instructions that are invalid because a value has failed to 477: end up in a register, or has ended up in a register of the wrong 478: kind. It fixes up these instructions by reloading the 479: problematical values temporarily into registers. Additional 480: instructions are generated to do the copying. 481: 482: The reload pass also optionally eliminates the frame pointer and 483: inserts instructions to save and restore call-clobbered registers 484: around calls. 485: 486: Source files are `reload.c' and `reload1.c', plus the header 487: `reload.h' used for communication between them. 488: 489: The option `-dg' causes a debugging dump of the RTL code after 490: this pass. This dump file's name is made by appending `.greg' to 491: the input file name. 492: 493: * Instruction scheduling is repeated here to try to avoid pipeline 494: stalls due to memory loads generated for spilled pseudo registers. 495: 496: The option `-dR' causes a debugging dump of the RTL code after 497: this pass. This dump file's name is made by appending `.sched2' 498: to the input file name. 499: 500: * Jump optimization is repeated, this time including cross-jumping 501: and deletion of no-op move instructions. 502: 503: The option `-dJ' causes a debugging dump of the RTL code after 1.1.1.3 ! root 504: this pass. This dump file's name is made by appending `.jump2' to ! 505: the input file name. 1.1.1.2 root 506: 507: * Delayed branch scheduling. This optional pass attempts to find 508: instructions that can go into the delay slots of other 509: instructions, usually jumps and calls. The source file name is 510: `reorg.c'. 511: 512: The option `-dd' causes a debugging dump of the RTL code after 513: this pass. This dump file's name is made by appending `.dbr' to 514: the input file name. 515: 1.1.1.3 ! root 516: * Conversion from usage of some hard registers to usage of a register ! 517: stack may be done at this point. Currently, this is supported only ! 518: for the floating-point registers of the Intel 80387 coprocessor. ! 519: The source file name is `reg-stack.c'. 1.1.1.2 root 520: 521: The options `-dk' causes a debugging dump of the RTL code after 1.1.1.3 ! root 522: this pass. This dump file's name is made by appending `.stack' to ! 523: the input file name. 1.1.1.2 root 524: 1.1.1.3 ! root 525: * Final. This pass outputs the assembler code for the function. It ! 526: is also responsible for identifying spurious test and compare 1.1.1.2 root 527: instructions. Machine-specific peephole optimizations are 1.1.1.3 ! root 528: performed at the same time. The function entry and exit sequences ! 529: are generated directly as assembler code in this pass; they never ! 530: exist as RTL. ! 531: ! 532: The source files are `final.c' plus `insn-output.c'; the latter is ! 533: generated automatically from the machine description by the tool ! 534: `genoutput'. The header file `conditions.h' is used for 1.1.1.2 root 535: communication between these files. 536: 537: * Debugging information output. This is run after final because it 538: must output the stack slot offsets for pseudo registers that did 539: not get hard registers. Source files are `dbxout.c' for DBX 540: symbol table format, `sdbout.c' for SDB symbol table format, and 541: `dwarfout.c' for DWARF symbol table format. 542: 543: Some additional files are used by all or many passes: 544: 545: * Every pass uses `machmode.def' and `machmode.h' which define the 546: machine modes. 547: 548: * Several passes use `real.h', which defines the default 549: representation of floating point constants and how to operate on 550: them. 551: 1.1.1.3 ! root 552: * All the passes that work with RTL use the header files `rtl.h' and ! 553: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also ! 554: use these files to read and work with the machine description RTL. 1.1.1.2 root 555: 556: * Several passes refer to the header file `insn-config.h' which 557: contains a few parameters (C macro definitions) generated 558: automatically from the machine description RTL by the tool 559: `genconfig'. 560: 561: * Several passes use the instruction recognizer, which consists of 562: `recog.c' and `recog.h', plus the files `insn-recog.c' and 1.1.1.3 ! root 563: `insn-extract.c' that are generated automatically from the machine ! 564: description by the tools `genrecog' and `genextract'. 1.1.1.2 root 565: 566: * Several passes use the header files `regs.h' which defines the 567: information recorded about pseudo register usage, and 1.1.1.3 ! root 568: `basic-block.h' which defines the information recorded about basic ! 569: blocks. 1.1.1.2 root 570: 571: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector 572: with a bit for each hard register, and some macros to manipulate 1.1.1.3 ! root 573: it. This type is just `int' if the machine has few enough hard 1.1.1.2 root 574: registers; otherwise it is an array of `int' and some of the 575: macros expand into loops. 576: 577: * Several passes use instruction attributes. A definition of the 578: attributes defined for a particular machine is in file 579: `insn-attr.h', which is generated from the machine description by 580: the program `genattr'. The file `insn-attrtab.c' contains 581: subroutines to obtain the attribute values for insns. It is 1.1.1.3 ! root 582: generated from the machine description by the program `genattrtab'. 1.1.1.2 root 583: 584: 585: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top 586: 587: RTL Representation 588: ****************** 589: 590: Most of the work of the compiler is done on an intermediate 591: representation called register transfer language. In this language, 1.1.1.3 ! root 592: the instructions to be output are described, pretty much one by one, in ! 593: an algebraic form that describes what the instruction does. 1.1.1.2 root 594: 595: RTL is inspired by Lisp lists. It has both an internal form, made 596: up of structures that point at other structures, and a textual form 1.1.1.3 ! root 597: that is used in the machine description and in printed debugging dumps. ! 598: The textual form uses nested parentheses to indicate the pointers in ! 599: the internal form. 1.1.1.2 root 600: 601: * Menu: 602: 603: * RTL Objects:: Expressions vs vectors vs strings vs integers. 604: * Accessors:: Macros to access expression operands or vector elts. 605: * Flags:: Other flags in an RTL expression. 606: * Machine Modes:: Describing the size and format of a datum. 607: * Constants:: Expressions with constant values. 608: * Regs and Memory:: Expressions representing register contents or memory. 609: * Arithmetic:: Expressions representing arithmetic on other expressions. 610: * Comparisons:: Expressions representing comparison of expressions. 611: * Bit Fields:: Expressions representing bit-fields in memory or reg. 612: * Conversions:: Extending, truncating, floating or fixing. 613: * RTL Declarations:: Declaring volatility, constancy, etc. 614: * Side Effects:: Expressions for storing in registers, etc. 615: * Incdec:: Embedded side-effects for autoincrement addressing. 616: * Assembler:: Representing `asm' with operands. 617: * Insns:: Expression types for entire insns. 618: * Calls:: RTL representation of function call insns. 619: * Sharing:: Some expressions are unique; others *must* be copied. 620: 621: 622: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL 623: 624: RTL Object Types 625: ================ 626: 627: RTL uses four kinds of objects: expressions, integers, strings and 1.1.1.3 ! root 628: vectors. Expressions are the most important ones. An RTL expression ! 629: ("RTX", for short) is a C structure, but it is usually referred to with ! 630: a pointer; a type that is given the typedef name `rtx'. 1.1.1.2 root 631: 632: An integer is simply an `int'; their written form uses decimal 633: digits. 634: 1.1.1.3 ! root 635: A string is a sequence of characters. In core it is represented as a ! 636: `char *' in usual C fashion, and it is written in C syntax as well. 1.1.1.2 root 637: However, strings in RTL may never be null. If you write an empty 638: string in a machine description, it is represented in core as a null 639: pointer rather than as a pointer to a null character. In certain 1.1.1.3 ! root 640: contexts, these null pointers instead of strings are valid. Within RTL ! 641: code, strings are most commonly found inside `symbol_ref' expressions, ! 642: but they appear in other contexts in the RTL expressions that make up ! 643: machine descriptions. 1.1.1.2 root 644: 645: A vector contains an arbitrary number of pointers to expressions. 646: The number of elements in the vector is explicitly present in the 1.1.1.3 ! root 647: vector. The written form of a vector consists of square brackets 1.1.1.2 root 648: (`[...]') surrounding the elements, in sequence and with whitespace 1.1.1.3 ! root 649: separating them. Vectors of length zero are not created; null pointers ! 650: are used instead. 1.1.1.2 root 651: 652: Expressions are classified by "expression codes" (also called RTX 653: codes). The expression code is a name defined in `rtl.def', which is 654: also (in upper case) a C enumeration constant. The possible expression 655: codes and their meanings are machine-independent. The code of an RTX 656: can be extracted with the macro `GET_CODE (X)' and altered with 657: `PUT_CODE (X, NEWCODE)'. 658: 659: The expression code determines how many operands the expression 1.1.1.3 ! root 660: contains, and what kinds of objects they are. In RTL, unlike Lisp, you ! 661: cannot tell by looking at an operand what kind of object it is. 1.1.1.2 root 662: Instead, you must know from its context--from the expression code of 1.1.1.3 ! root 663: the containing expression. For example, in an expression of code 1.1.1.2 root 664: `subreg', the first operand is to be regarded as an expression and the 665: second operand as an integer. In an expression of code `plus', there 666: are two operands, both of which are to be regarded as expressions. In 667: a `symbol_ref' expression, there is one operand, which is to be 668: regarded as a string. 669: 670: Expressions are written as parentheses containing the name of the 671: expression type, its flags and machine mode if any, and then the 672: operands of the expression (separated by spaces). 673: 674: Expression code names in the `md' file are written in lower case, 675: but when they appear in C code they are written in upper case. In this 676: manual, they are shown as follows: `const_int'. 677: 678: In a few contexts a null pointer is valid where an expression is 679: normally wanted. The written form of this is `(nil)'. 680: 681: 1.1 root 682: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL 683: 684: Access to Operands 685: ================== 686: 687: For each expression type `rtl.def' specifies the number of contained 688: objects and their kinds, with four possibilities: `e' for expression 1.1.1.3 ! root 689: (actually a pointer to an expression), `i' for integer, `s' for string, ! 690: and `E' for vector of expressions. The sequence of letters for an ! 691: expression code is called its "format". Thus, the format of `subreg' ! 692: is `ei'. 1.1 root 693: 694: A few other format characters are used occasionally: 695: 696: `u' 697: `u' is equivalent to `e' except that it is printed differently in 698: debugging dumps. It is used for pointers to insns. 699: 700: `n' 701: `n' is equivalent to `i' except that it is printed differently in 1.1.1.3 ! root 702: debugging dumps. It is used for the line number or code number of ! 703: a `note' insn. 1.1 root 704: 705: `S' 706: `S' indicates a string which is optional. In the RTL objects in 707: core, `S' is equivalent to `s', but when the object is read, from 1.1.1.3 ! root 708: an `md' file, the string value of this operand may be omitted. An ! 709: omitted string is taken to be the null string. 1.1 root 710: 711: `V' 712: `V' indicates a vector which is optional. In the RTL objects in 713: core, `V' is equivalent to `E', but when the object is read from 1.1.1.3 ! root 714: an `md' file, the vector value of this operand may be omitted. An ! 715: omitted vector is effectively the same as a vector of no elements. 1.1 root 716: 717: `0' 1.1.1.3 ! root 718: `0' means a slot whose contents do not fit any normal category. 1.1 root 719: `0' slots are not printed at all in dumps, and are often used in 720: special ways by small parts of the compiler. 721: 722: There are macros to get the number of operands, the format, and the 723: class of an expression code: 724: 725: `GET_RTX_LENGTH (CODE)' 726: Number of operands of an RTX of code CODE. 727: 728: `GET_RTX_FORMAT (CODE)' 729: The format of an RTX of code CODE, as a C string. 730: 731: `GET_RTX_CLASS (CODE)' 1.1.1.3 ! root 732: A single character representing the type of RTX operation that code ! 733: CODE performs. 1.1 root 734: 735: The following classes are defined: 736: 737: `o' 1.1.1.3 ! root 738: An RTX code that represents an actual object, such as `reg' or ! 739: `mem'. `subreg' is not in this class. 1.1 root 740: 741: `<' 742: An RTX code for a comparison. The codes in this class are 743: `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', 744: `GTU'. 745: 746: `1' 747: An RTX code for a unary arithmetic operation, such as `neg'. 748: 749: `c' 750: An RTX code for a commutative binary operation, other than 751: `NE' and `EQ' (which have class `<'). 752: 753: `2' 754: An RTX code for a noncommutative binary operation, such as 755: `MINUS'. 756: 757: `b' 758: An RTX code for a bitfield operation (`ZERO_EXTRACT' and 759: `SIGN_EXTRACT'). 760: 761: `3' 762: An RTX code for other three input operations, such as 763: `IF_THEN_ELSE'. 764: 765: `i' 766: An RTX code for a machine insn (`INSN', `JUMP_INSN', and 767: `CALL_INSN'). 768: 769: `m' 770: An RTX code for something that matches in insns, such as 771: `MATCH_DUP'. 772: 773: `x' 774: All other RTX codes. 775: 1.1.1.3 ! root 776: Operands of expressions are accessed using the macros `XEXP', `XINT' ! 777: and `XSTR'. Each of these macros takes two arguments: an ! 778: expression-pointer (RTX) and an operand number (counting from zero). 1.1 root 779: Thus, 780: 781: XEXP (X, 2) 782: 783: accesses operand 2 of expression X, as an expression. 784: 785: XINT (X, 2) 786: 787: accesses the same operand as an integer. `XSTR', used in the same 788: fashion, would access it as a string. 789: 790: Any operand can be accessed as an integer, as an expression or as a 1.1.1.3 ! root 791: string. You must choose the correct method of access for the kind of 1.1 root 792: value actually stored in the operand. You would do this based on the 793: expression code of the containing expression. That is also how you 794: would know how many operands there are. 795: 1.1.1.3 ! root 796: For example, if X is a `subreg' expression, you know that it has two ! 797: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, ! 798: 1)'. If you did `XINT (X, 0)', you would get the address of the ! 799: expression operand but cast as an integer; that might occasionally be ! 800: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP ! 801: (X, 1)' would also compile without error, and would return the second, ! 802: integer operand cast as an expression pointer, which would probably ! 803: result in a crash when accessed. Nothing stops you from writing `XEXP ! 804: (X, 28)' either, but this will access memory past the end of the ! 805: expression with unpredictable results. 1.1 root 806: 807: Access to operands which are vectors is more complicated. You can 808: use the macro `XVEC' to get the vector-pointer itself, or the macros 809: `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 810: 811: `XVEC (EXP, IDX)' 812: Access the vector-pointer which is operand number IDX in EXP. 813: 814: `XVECLEN (EXP, IDX)' 815: Access the length (number of elements) in the vector which is in 816: operand number IDX in EXP. This value is an `int'. 817: 818: `XVECEXP (EXP, IDX, ELTNUM)' 819: Access element number ELTNUM in the vector which is in operand 820: number IDX in EXP. This value is an RTX. 821: 822: It is up to you to make sure that ELTNUM is not negative and is 823: less than `XVECLEN (EXP, IDX)'. 824: 825: All the macros defined in this section expand into lvalues and 826: therefore can be used to assign the operands, lengths and vector 827: elements as well as to access them. 828: 829: 830: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL 831: 832: Flags in an RTL Expression 833: ========================== 834: 835: RTL expressions contain several flags (one-bit bit-fields) that are 1.1.1.3 ! root 836: used in certain types of expression. Most often they are accessed with ! 837: the following macros: 1.1 root 838: 839: `MEM_VOLATILE_P (X)' 1.1.1.3 ! root 840: In `mem' expressions, nonzero for volatile memory references. 1.1 root 841: Stored in the `volatil' field and printed as `/v'. 842: 843: `MEM_IN_STRUCT_P (X)' 844: In `mem' expressions, nonzero for reference to an entire 845: structure, union or array, or to a component of one. Zero for 1.1.1.3 ! root 846: references to a scalar variable or through a pointer to a scalar. 1.1 root 847: Stored in the `in_struct' field and printed as `/s'. 848: 849: `REG_LOOP_TEST_P' 850: In `reg' expressions, nonzero if this register's entire life is 851: contained in the exit test code for some loop. Stored in the 852: `in_struct' field and printed as `/s'. 853: 854: `REG_USERVAR_P (X)' 1.1.1.3 ! root 855: In a `reg', nonzero if it corresponds to a variable present in the ! 856: user's source code. Zero for temporaries generated internally by ! 857: the compiler. Stored in the `volatil' field and printed as `/v'. 1.1 root 858: 859: `REG_FUNCTION_VALUE_P (X)' 860: Nonzero in a `reg' if it is the place in which this function's 861: value is going to be returned. (This happens only in a hard 862: register.) Stored in the `integrated' field and printed as `/i'. 863: 864: The same hard register may be used also for collecting the values 1.1.1.3 ! root 865: of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero ! 866: in this kind of use. 1.1 root 867: 868: `RTX_UNCHANGING_P (X)' 1.1.1.3 ! root 869: Nonzero in a `reg' or `mem' if the value is not changed. (This ! 870: flag is not set for memory references via pointers to constants. 1.1 root 871: Such pointers only guarantee that the object will not be changed 1.1.1.3 ! root 872: explicitly by the current function. The object might be changed by ! 873: other functions or by aliasing.) Stored in the `unchanging' field ! 874: and printed as `/u'. 1.1 root 875: 876: `RTX_INTEGRATED_P (INSN)' 1.1.1.3 ! root 877: Nonzero in an insn if it resulted from an in-line function call. ! 878: Stored in the `integrated' field and printed as `/i'. This may be ! 879: deleted; nothing currently depends on it. 1.1 root 880: 881: `SYMBOL_REF_USED (X)' 882: In a `symbol_ref', indicates that X has been used. This is 883: normally only used to ensure that X is only declared external 884: once. Stored in the `used' field. 885: 886: `SYMBOL_REF_FLAG (X)' 887: In a `symbol_ref', this is used as a flag for machine-specific 1.1.1.3 ! root 888: purposes. Stored in the `volatil' field and printed as `/v'. 1.1 root 889: 890: `LABEL_OUTSIDE_LOOP_P' 891: In `label_ref' expressions, nonzero if this is a reference to a 892: label that is outside the innermost loop containing the reference 1.1.1.3 ! root 893: to the label. Stored in the `in_struct' field and printed as `/s'. 1.1 root 894: 895: `INSN_DELETED_P (INSN)' 896: In an insn, nonzero if the insn has been deleted. Stored in the 897: `volatil' field and printed as `/v'. 898: 899: `INSN_ANNULLED_BRANCH_P (INSN)' 900: In an `insn' in the delay slot of a branch insn, indicates that an 901: annulling branch should be used. See the discussion under 1.1.1.3 ! root 902: `sequence' below. Stored in the `unchanging' field and printed as ! 903: `/u'. 1.1 root 904: 905: `INSN_FROM_TARGET_P (INSN)' 906: In an `insn' in a delay slot of a branch, indicates that the insn 907: is from the target of the branch. If the branch insn has 908: `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if 909: the branch is taken. For annulled branches with this bit clear, 910: the insn should be executed only if the branch is not taken. 911: Stored in the `in_struct' field and printed as `/s'. 912: 913: `CONSTANT_POOL_ADDRESS_P (X)' 914: Nonzero in a `symbol_ref' if it refers to part of the current 915: function's "constants pool". These are addresses close to the 1.1.1.3 ! root 916: beginning of the function, and GNU CC assumes they can be addressed ! 917: directly (perhaps with the help of base registers). Stored in the ! 918: `unchanging' field and printed as `/u'. 1.1 root 919: 920: `CONST_CALL_P (X)' 921: In a `call_insn', indicates that the insn represents a call to a 922: const function. Stored in the `unchanging' field and printed as 923: `/u'. 924: 925: `LABEL_PRESERVE_P (X)' 1.1.1.3 ! root 926: In a `code_label', indicates that the label can never be deleted. 1.1 root 927: Labels referenced by a a non-local goto will have this bit set. 928: Stored in the `in_struct' field and printed as `/s'. 929: 930: `SCHED_GROUP_P (INSN)' 931: During instruction scheduling, in an insn, indicates that the 932: previous insn must be scheduled together with this insn. This is 933: used to ensure that certain groups of instructions will not be 934: split up by the instruction scheduling pass, for example, `use' 935: insns before a `call_insn' may not be separated from the 936: `call_insn'. Stored in the `in_struct' field and printed as `/s'. 937: 938: These are the fields which the above macros refer to: 939: 940: `used' 941: Normally, this flag is used only momentarily, at the end of RTL 942: generation for a function, to count the number of times an 943: expression appears in insns. Expressions that appear more than 944: once are copied, according to the rules for shared structure 945: (*note Sharing::.). 946: 947: In a `symbol_ref', it indicates that an external declaration for 948: the symbol has already been written. 949: 950: In a `reg', it is used by the leaf register renumbering code to 951: ensure that each register is only renumbered once. 952: 953: `volatil' 954: This flag is used in `mem',`symbol_ref' and `reg' expressions and 955: in insns. In RTL dump files, it is printed as `/v'. 956: 1.1.1.3 ! root 957: In a `mem' expression, it is 1 if the memory reference is volatile. ! 958: Volatile memory references may not be deleted, reordered or ! 959: combined. 1.1 root 960: 961: In a `symbol_ref' expression, it is used for machine-specific 962: purposes. 963: 964: In a `reg' expression, it is 1 if the value is a user-level 1.1.1.3 ! root 965: variable. 0 indicates an internal compiler temporary. 1.1 root 966: 967: In an insn, 1 means the insn has been deleted. 968: 969: `in_struct' 970: In `mem' expressions, it is 1 if the memory datum referred to is 971: all or part of a structure or array; 0 if it is (or might be) a 972: scalar variable. A reference through a C pointer has 0 because 973: the pointer might point to a scalar variable. This information 1.1.1.3 ! root 974: allows the compiler to determine something about possible cases of ! 975: aliasing. 1.1 root 976: 977: In an insn in the delay slot of a branch, 1 means that this insn 978: is from the target of the branch. 979: 980: During instruction scheduling, in an insn, 1 means that this insn 981: must be scheduled as part of a group together with the previous 982: insn. 983: 984: In `reg' expressions, it is 1 if the register has its entire life 985: contained within the test expression of some loopl. 986: 987: In `label_ref' expressions, 1 means that the referenced label is 988: outside the innermost loop containing the insn in which the 989: `label_ref' was found. 990: 991: In `code_label' expressions, it is 1 if the label may never be 1.1.1.3 ! root 992: deleted. This is used for labels which are the target of non-local ! 993: gotos. 1.1 root 994: 995: In an RTL dump, this flag is represented as `/s'. 996: 997: `unchanging' 998: In `reg' and `mem' expressions, 1 means that the value of the 999: expression never changes. 1000: 1001: In an insn, 1 means that this is an annulling branch. 1002: 1003: In a `symbol_ref' expression, 1 means that this symbol addresses 1004: something in the per-function constants pool. 1005: 1006: In a `call_insn', 1 means that this instruction is a call to a 1007: const function. 1008: 1009: In an RTL dump, this flag is represented as `/u'. 1010: 1011: `integrated' 1012: In some kinds of expressions, including insns, this flag means the 1013: rtl was produced by procedure integration. 1014: 1.1.1.3 ! root 1015: In a `reg' expression, this flag indicates the register containing ! 1016: the value to be returned by the current function. On machines ! 1017: that pass parameters in registers, the same register number may be ! 1018: used for parameters as well, but this flag is not set on such uses. 1.1 root 1019: 1020:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.