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