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