![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-12 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-12 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.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue 7: Cambridge, MA 02139 USA 8: 1.1.1.7 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, ! 10: 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.3 root 31: 32: 1.1.1.7 ! root 33: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top 1.1.1.6 root 34: 1.1.1.7 ! root 35: Passes and Files of the Compiler ! 36: ******************************** 1.1.1.6 root 37: 1.1.1.7 ! root 38: The overall control structure of the compiler is in `toplev.c'. This ! 39: file is responsible for initialization, decoding arguments, opening and ! 40: closing files, and sequencing the passes. ! 41: ! 42: The parsing pass is invoked only once, to parse the entire input. ! 43: The RTL intermediate code for a function is generated as the function ! 44: is parsed, a statement at a time. Each statement is read in as a ! 45: syntax tree and then converted to RTL; then the storage for the tree ! 46: for the statement is reclaimed. Storage for types (and the expressions ! 47: for their sizes), declarations, and a representation of the binding ! 48: contours and how they nest, remain until the function is finished being ! 49: compiled; these are all needed to output the debugging information. ! 50: ! 51: Each time the parsing pass reads a complete function definition or ! 52: top-level declaration, it calls either the function ! 53: `rest_of_compilation', or the function `rest_of_decl_compilation' in ! 54: `toplev.c', which are responsible for all further processing necessary, ! 55: ending with output of the assembler language. All other compiler ! 56: passes run, in sequence, within `rest_of_compilation'. When that ! 57: function returns from compiling a function definition, the storage used ! 58: for that function definition's compilation is entirely freed, unless it ! 59: is an inline function (*note An Inline Function is As Fast As a Macro: ! 60: Inline.). ! 61: ! 62: Here is a list of all the passes of the compiler and their source ! 63: files. Also included is a description of where debugging dumps can be ! 64: requested with `-d' options. ! 65: ! 66: * Parsing. This pass reads the entire text of a function definition, ! 67: constructing partial syntax trees. This and RTL generation are no ! 68: longer truly separate passes (formerly they were), but it is ! 69: easier to think of them as separate. ! 70: ! 71: The tree representation does not entirely follow C syntax, because ! 72: it is intended to support other languages as well. ! 73: ! 74: Language-specific data type analysis is also done in this pass, ! 75: and every tree node that represents an expression has a data type ! 76: attached. Variables are represented as declaration nodes. ! 77: ! 78: Constant folding and some arithmetic simplifications are also done ! 79: during this pass. ! 80: ! 81: The language-independent source files for parsing are ! 82: `stor-layout.c', `fold-const.c', and `tree.c'. There are also ! 83: header files `tree.h' and `tree.def' which define the format of ! 84: the tree representation. ! 85: ! 86: The source files to parse C are `c-parse.in', `c-decl.c', ! 87: `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along ! 88: with header files `c-lex.h', and `c-tree.h'. ! 89: ! 90: The source files for parsing C++ are `cp-parse.y', `cp-class.c', ! 91: `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', ! 92: `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', ! 93: `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along ! 94: with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. ! 95: ! 96: The special source files for parsing Objective C are ! 97: `objc-parse.y', `objc-actions.c', `objc-tree.def', and ! 98: `objc-actions.h'. Certain C-specific files are used for this as ! 99: well. ! 100: ! 101: The file `c-common.c' is also used for all of the above languages. ! 102: ! 103: * RTL generation. This is the conversion of syntax tree into RTL ! 104: code. It is actually done statement-by-statement during parsing, ! 105: but for most purposes it can be thought of as a separate pass. ! 106: ! 107: This is where the bulk of target-parameter-dependent code is found, ! 108: since often it is necessary for strategies to apply only when ! 109: certain standard kinds of instructions are available. The purpose ! 110: of named instruction patterns is to provide this information to ! 111: the RTL generation pass. ! 112: ! 113: Optimization is done in this pass for `if'-conditions that are ! 114: comparisons, boolean operations or conditional expressions. Tail ! 115: recursion is detected at this time also. Decisions are made about ! 116: how best to arrange loops and how to output `switch' statements. ! 117: ! 118: The source files for RTL generation include `stmt.c', `calls.c', ! 119: `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and ! 120: `emit-rtl.c'. Also, the file `insn-emit.c', generated from the ! 121: machine description by the program `genemit', is used in this ! 122: pass. The header file `expr.h' is used for communication within ! 123: this pass. ! 124: ! 125: The header files `insn-flags.h' and `insn-codes.h', generated from ! 126: the machine description by the programs `genflags' and `gencodes', ! 127: tell this pass which standard names are available for use and ! 128: which patterns correspond to them. ! 129: ! 130: Aside from debugging information output, none of the following ! 131: passes refers to the tree structure representation of the function ! 132: (only part of which is saved). ! 133: ! 134: The decision of whether the function can and should be expanded ! 135: inline in its subsequent callers is made at the end of rtl ! 136: generation. The function must meet certain criteria, currently ! 137: related to the size of the function and the types and number of ! 138: parameters it has. Note that this function may contain loops, ! 139: recursive calls to itself (tail-recursive functions can be ! 140: inlined!), gotos, in short, all constructs supported by GNU CC. ! 141: The file `integrate.c' contains the code to save a function's rtl ! 142: for later inlining and to inline that rtl when the function is ! 143: called. The header file `integrate.h' is also used for this ! 144: purpose. ! 145: ! 146: The option `-dr' causes a debugging dump of the RTL code after ! 147: this pass. This dump file's name is made by appending `.rtl' to ! 148: the input file name. ! 149: ! 150: * Jump optimization. This pass simplifies jumps to the following ! 151: instruction, jumps across jumps, and jumps to jumps. It deletes ! 152: unreferenced labels and unreachable code, except that unreachable ! 153: code that contains a loop is not recognized as unreachable in this ! 154: pass. (Such loops are deleted later in the basic block analysis.) ! 155: It also converts some code originally written with jumps into ! 156: sequences of instructions that directly set values from the ! 157: results of comparisons, if the machine has such instructions. ! 158: ! 159: Jump optimization is performed two or three times. The first time ! 160: is immediately following RTL generation. The second time is after ! 161: CSE, but only if CSE says repeated jump optimization is needed. ! 162: The last time is right before the final pass. That time, ! 163: cross-jumping and deletion of no-op move instructions are done ! 164: together with the optimizations described above. ! 165: ! 166: The source file of this pass is `jump.c'. ! 167: ! 168: The option `-dj' causes a debugging dump of the RTL code after ! 169: this pass is run for the first time. This dump file's name is ! 170: made by appending `.jump' to the input file name. ! 171: ! 172: * Register scan. This pass finds the first and last use of each ! 173: register, as a guide for common subexpression elimination. Its ! 174: source is in `regclass.c'. ! 175: ! 176: * Jump threading. This pass detects a condition jump that branches ! 177: to an identical or inverse test. Such jumps can be `threaded' ! 178: through the second conditional test. The source code for this ! 179: pass is in `jump.c'. This optimization is only performed if ! 180: `-fthread-jumps' is enabled. ! 181: ! 182: * Common subexpression elimination. This pass also does constant ! 183: propagation. Its source file is `cse.c'. If constant propagation ! 184: causes conditional jumps to become unconditional or to become ! 185: no-ops, jump optimization is run again when CSE is finished. ! 186: ! 187: The option `-ds' causes a debugging dump of the RTL code after ! 188: this pass. This dump file's name is made by appending `.cse' to ! 189: the input file name. ! 190: ! 191: * Loop optimization. This pass moves constant expressions out of ! 192: loops, and optionally does strength-reduction and loop unrolling ! 193: as well. Its source files are `loop.c' and `unroll.c', plus the ! 194: header `loop.h' used for communication between them. Loop ! 195: unrolling uses some functions in `integrate.c' and the header ! 196: `integrate.h'. ! 197: ! 198: The option `-dL' causes a debugging dump of the RTL code after ! 199: this pass. This dump file's name is made by appending `.loop' to ! 200: the input file name. ! 201: ! 202: * If `-frerun-cse-after-loop' was enabled, a second common ! 203: subexpression elimination pass is performed after the loop ! 204: optimization pass. Jump threading is also done again at this time ! 205: if it was specified. ! 206: ! 207: The option `-dt' causes a debugging dump of the RTL code after ! 208: this pass. This dump file's name is made by appending `.cse2' to ! 209: the input file name. ! 210: ! 211: * Stupid register allocation is performed at this point in a ! 212: nonoptimizing compilation. It does a little data flow analysis as ! 213: well. When stupid register allocation is in use, the next pass ! 214: executed is the reloading pass; the others in between are skipped. ! 215: The source file is `stupid.c'. ! 216: ! 217: * Data flow analysis (`flow.c'). This pass divides the program into ! 218: basic blocks (and in the process deletes unreachable loops); then ! 219: it computes which pseudo-registers are live at each point in the ! 220: program, and makes the first instruction that uses a value point at ! 221: the instruction that computed the value. ! 222: ! 223: This pass also deletes computations whose results are never used, ! 224: and combines memory references with add or subtract instructions ! 225: to make autoincrement or autodecrement addressing. ! 226: ! 227: The option `-df' causes a debugging dump of the RTL code after ! 228: this pass. This dump file's name is made by appending `.flow' to ! 229: the input file name. If stupid register allocation is in use, this ! 230: dump file reflects the full results of such allocation. ! 231: ! 232: * Instruction combination (`combine.c'). This pass attempts to ! 233: combine groups of two or three instructions that are related by ! 234: data flow into single instructions. It combines the RTL ! 235: expressions for the instructions by substitution, simplifies the ! 236: result using algebra, and then attempts to match the result ! 237: against the machine description. ! 238: ! 239: The option `-dc' causes a debugging dump of the RTL code after ! 240: this pass. This dump file's name is made by appending `.combine' ! 241: to the input file name. ! 242: ! 243: * Instruction scheduling (`sched.c'). This pass looks for ! 244: instructions whose output will not be available by the time that ! 245: it is used in subsequent instructions. (Memory loads and floating ! 246: point instructions often have this behavior on RISC machines). It ! 247: re-orders instructions within a basic block to try to separate the ! 248: definition and use of items that otherwise would cause pipeline ! 249: stalls. ! 250: ! 251: Instruction scheduling is performed twice. The first time is ! 252: immediately after instruction combination and the second is ! 253: immediately after reload. ! 254: ! 255: The option `-dS' causes a debugging dump of the RTL code after this ! 256: pass is run for the first time. The dump file's name is made by ! 257: appending `.sched' to the input file name. ! 258: ! 259: * Register class preferencing. The RTL code is scanned to find out ! 260: which register class is best for each pseudo register. The source ! 261: file is `regclass.c'. ! 262: ! 263: * Local register allocation (`local-alloc.c'). This pass allocates ! 264: hard registers to pseudo registers that are used only within one ! 265: basic block. Because the basic block is linear, it can use fast ! 266: and powerful techniques to do a very good job. ! 267: ! 268: The option `-dl' causes a debugging dump of the RTL code after ! 269: this pass. This dump file's name is made by appending `.lreg' to ! 270: the input file name. ! 271: ! 272: * Global register allocation (`global.c'). This pass allocates hard ! 273: registers for the remaining pseudo registers (those whose life ! 274: spans are not contained in one basic block). ! 275: ! 276: * Reloading. This pass renumbers pseudo registers with the hardware ! 277: registers numbers they were allocated. Pseudo registers that did ! 278: not get hard registers are replaced with stack slots. Then it ! 279: finds instructions that are invalid because a value has failed to ! 280: end up in a register, or has ended up in a register of the wrong ! 281: kind. It fixes up these instructions by reloading the ! 282: problematical values temporarily into registers. Additional ! 283: instructions are generated to do the copying. ! 284: ! 285: The reload pass also optionally eliminates the frame pointer and ! 286: inserts instructions to save and restore call-clobbered registers ! 287: around calls. ! 288: ! 289: Source files are `reload.c' and `reload1.c', plus the header ! 290: `reload.h' used for communication between them. ! 291: ! 292: The option `-dg' causes a debugging dump of the RTL code after ! 293: this pass. This dump file's name is made by appending `.greg' to ! 294: the input file name. ! 295: ! 296: * Instruction scheduling is repeated here to try to avoid pipeline ! 297: stalls due to memory loads generated for spilled pseudo registers. ! 298: ! 299: The option `-dR' causes a debugging dump of the RTL code after ! 300: this pass. This dump file's name is made by appending `.sched2' ! 301: to the input file name. ! 302: ! 303: * Jump optimization is repeated, this time including cross-jumping ! 304: and deletion of no-op move instructions. ! 305: ! 306: The option `-dJ' causes a debugging dump of the RTL code after ! 307: this pass. This dump file's name is made by appending `.jump2' to ! 308: the input file name. ! 309: ! 310: * Delayed branch scheduling. This optional pass attempts to find ! 311: instructions that can go into the delay slots of other ! 312: instructions, usually jumps and calls. The source file name is ! 313: `reorg.c'. ! 314: ! 315: The option `-dd' causes a debugging dump of the RTL code after ! 316: this pass. This dump file's name is made by appending `.dbr' to ! 317: the input file name. ! 318: ! 319: * Conversion from usage of some hard registers to usage of a register ! 320: stack may be done at this point. Currently, this is supported only ! 321: for the floating-point registers of the Intel 80387 coprocessor. ! 322: The source file name is `reg-stack.c'. ! 323: ! 324: The options `-dk' causes a debugging dump of the RTL code after ! 325: this pass. This dump file's name is made by appending `.stack' to ! 326: the input file name. ! 327: ! 328: * Final. This pass outputs the assembler code for the function. It ! 329: is also responsible for identifying spurious test and compare ! 330: instructions. Machine-specific peephole optimizations are ! 331: performed at the same time. The function entry and exit sequences ! 332: are generated directly as assembler code in this pass; they never ! 333: exist as RTL. ! 334: ! 335: The source files are `final.c' plus `insn-output.c'; the latter is ! 336: generated automatically from the machine description by the tool ! 337: `genoutput'. The header file `conditions.h' is used for ! 338: communication between these files. ! 339: ! 340: * Debugging information output. This is run after final because it ! 341: must output the stack slot offsets for pseudo registers that did ! 342: not get hard registers. Source files are `dbxout.c' for DBX ! 343: symbol table format, `sdbout.c' for SDB symbol table format, and ! 344: `dwarfout.c' for DWARF symbol table format. ! 345: ! 346: Some additional files are used by all or many passes: ! 347: ! 348: * Every pass uses `machmode.def' and `machmode.h' which define the ! 349: machine modes. ! 350: ! 351: * Several passes use `real.h', which defines the default ! 352: representation of floating point constants and how to operate on ! 353: them. ! 354: ! 355: * All the passes that work with RTL use the header files `rtl.h' and ! 356: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also ! 357: use these files to read and work with the machine description RTL. ! 358: ! 359: * Several passes refer to the header file `insn-config.h' which ! 360: contains a few parameters (C macro definitions) generated ! 361: automatically from the machine description RTL by the tool ! 362: `genconfig'. ! 363: ! 364: * Several passes use the instruction recognizer, which consists of ! 365: `recog.c' and `recog.h', plus the files `insn-recog.c' and ! 366: `insn-extract.c' that are generated automatically from the machine ! 367: description by the tools `genrecog' and `genextract'. ! 368: ! 369: * Several passes use the header files `regs.h' which defines the ! 370: information recorded about pseudo register usage, and ! 371: `basic-block.h' which defines the information recorded about basic ! 372: blocks. ! 373: ! 374: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector ! 375: with a bit for each hard register, and some macros to manipulate ! 376: it. This type is just `int' if the machine has few enough hard ! 377: registers; otherwise it is an array of `int' and some of the ! 378: macros expand into loops. ! 379: ! 380: * Several passes use instruction attributes. A definition of the ! 381: attributes defined for a particular machine is in file ! 382: `insn-attr.h', which is generated from the machine description by ! 383: the program `genattr'. The file `insn-attrtab.c' contains ! 384: subroutines to obtain the attribute values for insns. It is ! 385: generated from the machine description by the program `genattrtab'. 1.1.1.6 root 386: 387: 1.1.1.7 ! root 388: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top 1.1.1.6 root 389: 1.1.1.7 ! root 390: RTL Representation ! 391: ****************** 1.1.1.6 root 392: 1.1.1.7 ! root 393: Most of the work of the compiler is done on an intermediate ! 394: representation called register transfer language. In this language, ! 395: the instructions to be output are described, pretty much one by one, in ! 396: an algebraic form that describes what the instruction does. ! 397: ! 398: RTL is inspired by Lisp lists. It has both an internal form, made ! 399: up of structures that point at other structures, and a textual form ! 400: that is used in the machine description and in printed debugging dumps. ! 401: The textual form uses nested parentheses to indicate the pointers in ! 402: the internal form. ! 403: ! 404: * Menu: ! 405: ! 406: * RTL Objects:: Expressions vs vectors vs strings vs integers. ! 407: * Accessors:: Macros to access expression operands or vector elts. ! 408: * Flags:: Other flags in an RTL expression. ! 409: * Machine Modes:: Describing the size and format of a datum. ! 410: * Constants:: Expressions with constant values. ! 411: * Regs and Memory:: Expressions representing register contents or memory. ! 412: * Arithmetic:: Expressions representing arithmetic on other expressions. ! 413: * Comparisons:: Expressions representing comparison of expressions. ! 414: * Bit Fields:: Expressions representing bitfields in memory or reg. ! 415: * Conversions:: Extending, truncating, floating or fixing. ! 416: * RTL Declarations:: Declaring volatility, constancy, etc. ! 417: * Side Effects:: Expressions for storing in registers, etc. ! 418: * Incdec:: Embedded side-effects for autoincrement addressing. ! 419: * Assembler:: Representing `asm' with operands. ! 420: * Insns:: Expression types for entire insns. ! 421: * Calls:: RTL representation of function call insns. ! 422: * Sharing:: Some expressions are unique; others *must* be copied. ! 423: * Reading RTL:: Reading textual RTL from a file. 1.1.1.6 root 424: 425: 1.1.1.7 ! root 426: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL 1.1.1.6 root 427: 1.1.1.7 ! root 428: RTL Object Types ! 429: ================ 1.1.1.6 root 430: 1.1.1.7 ! root 431: RTL uses five kinds of objects: expressions, integers, wide integers, ! 432: strings and vectors. Expressions are the most important ones. An RTL ! 433: expression ("RTX", for short) is a C structure, but it is usually ! 434: referred to with a pointer; a type that is given the typedef name `rtx'. ! 435: ! 436: An integer is simply an `int'; their written form uses decimal ! 437: digits. A wide integer is an integral object whose type is ! 438: `HOST_WIDE_INT' (*note Config::.); their written form uses decimal ! 439: digits. ! 440: ! 441: A string is a sequence of characters. In core it is represented as a ! 442: `char *' in usual C fashion, and it is written in C syntax as well. ! 443: However, strings in RTL may never be null. If you write an empty ! 444: string in a machine description, it is represented in core as a null ! 445: pointer rather than as a pointer to a null character. In certain ! 446: contexts, these null pointers instead of strings are valid. Within RTL ! 447: code, strings are most commonly found inside `symbol_ref' expressions, ! 448: but they appear in other contexts in the RTL expressions that make up ! 449: machine descriptions. ! 450: ! 451: A vector contains an arbitrary number of pointers to expressions. ! 452: The number of elements in the vector is explicitly present in the ! 453: vector. The written form of a vector consists of square brackets ! 454: (`[...]') surrounding the elements, in sequence and with whitespace ! 455: separating them. Vectors of length zero are not created; null pointers ! 456: are used instead. ! 457: ! 458: Expressions are classified by "expression codes" (also called RTX ! 459: codes). The expression code is a name defined in `rtl.def', which is ! 460: also (in upper case) a C enumeration constant. The possible expression ! 461: codes and their meanings are machine-independent. The code of an RTX ! 462: can be extracted with the macro `GET_CODE (X)' and altered with ! 463: `PUT_CODE (X, NEWCODE)'. ! 464: ! 465: The expression code determines how many operands the expression ! 466: contains, and what kinds of objects they are. In RTL, unlike Lisp, you ! 467: cannot tell by looking at an operand what kind of object it is. ! 468: Instead, you must know from its context--from the expression code of ! 469: the containing expression. For example, in an expression of code ! 470: `subreg', the first operand is to be regarded as an expression and the ! 471: second operand as an integer. In an expression of code `plus', there ! 472: are two operands, both of which are to be regarded as expressions. In ! 473: a `symbol_ref' expression, there is one operand, which is to be ! 474: regarded as a string. ! 475: ! 476: Expressions are written as parentheses containing the name of the ! 477: expression type, its flags and machine mode if any, and then the ! 478: operands of the expression (separated by spaces). ! 479: ! 480: Expression code names in the `md' file are written in lower case, ! 481: but when they appear in C code they are written in upper case. In this ! 482: manual, they are shown as follows: `const_int'. 1.1.1.6 root 483: 1.1.1.7 ! root 484: In a few contexts a null pointer is valid where an expression is ! 485: normally wanted. The written form of this is `(nil)'. 1.1.1.6 root 486: 487: 1.1.1.7 ! root 488: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL 1.1.1.6 root 489: 1.1.1.7 ! root 490: Access to Operands ! 491: ================== 1.1.1.6 root 492: 1.1.1.7 ! root 493: For each expression type `rtl.def' specifies the number of contained ! 494: objects and their kinds, with four possibilities: `e' for expression ! 495: (actually a pointer to an expression), `i' for integer, `w' for wide ! 496: integer, `s' for string, and `E' for vector of expressions. The ! 497: sequence of letters for an expression code is called its "format". ! 498: Thus, the format of `subreg' is `ei'. ! 499: ! 500: A few other format characters are used occasionally: ! 501: ! 502: `u' ! 503: `u' is equivalent to `e' except that it is printed differently in ! 504: debugging dumps. It is used for pointers to insns. ! 505: ! 506: `n' ! 507: `n' is equivalent to `i' except that it is printed differently in ! 508: debugging dumps. It is used for the line number or code number of ! 509: a `note' insn. ! 510: ! 511: `S' ! 512: `S' indicates a string which is optional. In the RTL objects in ! 513: core, `S' is equivalent to `s', but when the object is read, from ! 514: an `md' file, the string value of this operand may be omitted. An ! 515: omitted string is taken to be the null string. ! 516: ! 517: `V' ! 518: `V' indicates a vector which is optional. In the RTL objects in ! 519: core, `V' is equivalent to `E', but when the object is read from ! 520: an `md' file, the vector value of this operand may be omitted. An ! 521: omitted vector is effectively the same as a vector of no elements. ! 522: ! 523: `0' ! 524: `0' means a slot whose contents do not fit any normal category. ! 525: `0' slots are not printed at all in dumps, and are often used in ! 526: special ways by small parts of the compiler. ! 527: ! 528: There are macros to get the number of operands, the format, and the ! 529: class of an expression code: ! 530: ! 531: `GET_RTX_LENGTH (CODE)' ! 532: Number of operands of an RTX of code CODE. ! 533: ! 534: `GET_RTX_FORMAT (CODE)' ! 535: The format of an RTX of code CODE, as a C string. ! 536: ! 537: `GET_RTX_CLASS (CODE)' ! 538: A single character representing the type of RTX operation that code ! 539: CODE performs. ! 540: ! 541: The following classes are defined: ! 542: ! 543: `o' ! 544: An RTX code that represents an actual object, such as `reg' or ! 545: `mem'. `subreg' is not in this class. ! 546: ! 547: `<' ! 548: An RTX code for a comparison. The codes in this class are ! 549: `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', ! 550: `GTU'. ! 551: ! 552: `1' ! 553: An RTX code for a unary arithmetic operation, such as `neg'. ! 554: ! 555: `c' ! 556: An RTX code for a commutative binary operation, other than ! 557: `NE' and `EQ' (which have class `<'). ! 558: ! 559: `2' ! 560: An RTX code for a noncommutative binary operation, such as ! 561: `MINUS'. ! 562: ! 563: `b' ! 564: An RTX code for a bitfield operation, either `ZERO_EXTRACT' or ! 565: `SIGN_EXTRACT'. ! 566: ! 567: `3' ! 568: An RTX code for other three input operations, such as ! 569: `IF_THEN_ELSE'. ! 570: ! 571: `i' ! 572: An RTX code for a machine insn (`INSN', `JUMP_INSN', and ! 573: `CALL_INSN'). ! 574: ! 575: `m' ! 576: An RTX code for something that matches in insns, such as ! 577: `MATCH_DUP'. ! 578: ! 579: `x' ! 580: All other RTX codes. ! 581: ! 582: Operands of expressions are accessed using the macros `XEXP', ! 583: `XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments: ! 584: an expression-pointer (RTX) and an operand number (counting from zero). ! 585: Thus, ! 586: ! 587: XEXP (X, 2) ! 588: ! 589: accesses operand 2 of expression X, as an expression. ! 590: ! 591: XINT (X, 2) ! 592: ! 593: accesses the same operand as an integer. `XSTR', used in the same ! 594: fashion, would access it as a string. ! 595: ! 596: Any operand can be accessed as an integer, as an expression or as a ! 597: string. You must choose the correct method of access for the kind of ! 598: value actually stored in the operand. You would do this based on the ! 599: expression code of the containing expression. That is also how you ! 600: would know how many operands there are. ! 601: ! 602: For example, if X is a `subreg' expression, you know that it has two ! 603: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, ! 604: 1)'. If you did `XINT (X, 0)', you would get the address of the ! 605: expression operand but cast as an integer; that might occasionally be ! 606: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP ! 607: (X, 1)' would also compile without error, and would return the second, ! 608: integer operand cast as an expression pointer, which would probably ! 609: result in a crash when accessed. Nothing stops you from writing `XEXP ! 610: (X, 28)' either, but this will access memory past the end of the ! 611: expression with unpredictable results. ! 612: ! 613: Access to operands which are vectors is more complicated. You can ! 614: use the macro `XVEC' to get the vector-pointer itself, or the macros ! 615: `XVECEXP' and `XVECLEN' to access the elements and length of a vector. ! 616: ! 617: `XVEC (EXP, IDX)' ! 618: Access the vector-pointer which is operand number IDX in EXP. ! 619: ! 620: `XVECLEN (EXP, IDX)' ! 621: Access the length (number of elements) in the vector which is in ! 622: operand number IDX in EXP. This value is an `int'. ! 623: ! 624: `XVECEXP (EXP, IDX, ELTNUM)' ! 625: Access element number ELTNUM in the vector which is in operand ! 626: number IDX in EXP. This value is an RTX. ! 627: ! 628: It is up to you to make sure that ELTNUM is not negative and is ! 629: less than `XVECLEN (EXP, IDX)'. ! 630: ! 631: All the macros defined in this section expand into lvalues and ! 632: therefore can be used to assign the operands, lengths and vector ! 633: elements as well as to access them. 1.1.1.6 root 634: 635: 1.1.1.7 ! root 636: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL 1.1.1.6 root 637: 1.1.1.7 ! root 638: Flags in an RTL Expression ! 639: ========================== 1.1.1.6 root 640: 1.1.1.7 ! root 641: RTL expressions contain several flags (one-bit bitfields) that are ! 642: used in certain types of expression. Most often they are accessed with ! 643: the following macros: ! 644: ! 645: `MEM_VOLATILE_P (X)' ! 646: In `mem' expressions, nonzero for volatile memory references. ! 647: Stored in the `volatil' field and printed as `/v'. ! 648: ! 649: `MEM_IN_STRUCT_P (X)' ! 650: In `mem' expressions, nonzero for reference to an entire ! 651: structure, union or array, or to a component of one. Zero for ! 652: references to a scalar variable or through a pointer to a scalar. ! 653: Stored in the `in_struct' field and printed as `/s'. ! 654: ! 655: `REG_LOOP_TEST_P' ! 656: In `reg' expressions, nonzero if this register's entire life is ! 657: contained in the exit test code for some loop. Stored in the ! 658: `in_struct' field and printed as `/s'. ! 659: ! 660: `REG_USERVAR_P (X)' ! 661: In a `reg', nonzero if it corresponds to a variable present in the ! 662: user's source code. Zero for temporaries generated internally by ! 663: the compiler. Stored in the `volatil' field and printed as `/v'. ! 664: ! 665: `REG_FUNCTION_VALUE_P (X)' ! 666: Nonzero in a `reg' if it is the place in which this function's ! 667: value is going to be returned. (This happens only in a hard ! 668: register.) Stored in the `integrated' field and printed as `/i'. ! 669: ! 670: The same hard register may be used also for collecting the values ! 671: of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero ! 672: in this kind of use. ! 673: ! 674: `SUBREG_PROMOTED_VAR_P' ! 675: Nonzero in a `subreg' if it was made when accessing an object that ! 676: was promoted to a wider mode in accord with the `PROMOTED_MODE' ! 677: machine description macro (*note Storage Layout::.). In this ! 678: case, the mode of the `subreg' is the declared mode of the object ! 679: and the mode of `SUBREG_REG' is the mode of the register that ! 680: holds the object. Promoted variables are always either sign- or ! 681: zero-extended to the wider mode on every assignment. Stored in ! 682: the `in_struct' field and printed as `/s'. ! 683: ! 684: `SUBREG_PROMOTED_UNSIGNED_P' ! 685: Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if ! 686: the object being referenced is kept zero-extended and zero if it ! 687: is kept sign-extended. Stored in the `unchanging' field and ! 688: printed as `/u'. ! 689: ! 690: `RTX_UNCHANGING_P (X)' ! 691: Nonzero in a `reg' or `mem' if the value is not changed. (This ! 692: flag is not set for memory references via pointers to constants. ! 693: Such pointers only guarantee that the object will not be changed ! 694: explicitly by the current function. The object might be changed by ! 695: other functions or by aliasing.) Stored in the `unchanging' field ! 696: and printed as `/u'. ! 697: ! 698: `RTX_INTEGRATED_P (INSN)' ! 699: Nonzero in an insn if it resulted from an in-line function call. ! 700: Stored in the `integrated' field and printed as `/i'. This may be ! 701: deleted; nothing currently depends on it. ! 702: ! 703: `SYMBOL_REF_USED (X)' ! 704: In a `symbol_ref', indicates that X has been used. This is ! 705: normally only used to ensure that X is only declared external ! 706: once. Stored in the `used' field. ! 707: ! 708: `SYMBOL_REF_FLAG (X)' ! 709: In a `symbol_ref', this is used as a flag for machine-specific ! 710: purposes. Stored in the `volatil' field and printed as `/v'. ! 711: ! 712: `LABEL_OUTSIDE_LOOP_P' ! 713: In `label_ref' expressions, nonzero if this is a reference to a ! 714: label that is outside the innermost loop containing the reference ! 715: to the label. Stored in the `in_struct' field and printed as `/s'. ! 716: ! 717: `INSN_DELETED_P (INSN)' ! 718: In an insn, nonzero if the insn has been deleted. Stored in the ! 719: `volatil' field and printed as `/v'. ! 720: ! 721: `INSN_ANNULLED_BRANCH_P (INSN)' ! 722: In an `insn' in the delay slot of a branch insn, indicates that an ! 723: annulling branch should be used. See the discussion under ! 724: `sequence' below. Stored in the `unchanging' field and printed as ! 725: `/u'. ! 726: ! 727: `INSN_FROM_TARGET_P (INSN)' ! 728: In an `insn' in a delay slot of a branch, indicates that the insn ! 729: is from the target of the branch. If the branch insn has ! 730: `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if ! 731: the branch is taken. For annulled branches with this bit clear, ! 732: the insn should be executed only if the branch is not taken. ! 733: Stored in the `in_struct' field and printed as `/s'. ! 734: ! 735: `CONSTANT_POOL_ADDRESS_P (X)' ! 736: Nonzero in a `symbol_ref' if it refers to part of the current ! 737: function's "constants pool". These are addresses close to the ! 738: beginning of the function, and GNU CC assumes they can be addressed ! 739: directly (perhaps with the help of base registers). Stored in the ! 740: `unchanging' field and printed as `/u'. ! 741: ! 742: `CONST_CALL_P (X)' ! 743: In a `call_insn', indicates that the insn represents a call to a ! 744: const function. Stored in the `unchanging' field and printed as ! 745: `/u'. ! 746: ! 747: `LABEL_PRESERVE_P (X)' ! 748: In a `code_label', indicates that the label can never be deleted. ! 749: Labels referenced by a non-local goto will have this bit set. ! 750: Stored in the `in_struct' field and printed as `/s'. ! 751: ! 752: `SCHED_GROUP_P (INSN)' ! 753: During instruction scheduling, in an insn, indicates that the ! 754: previous insn must be scheduled together with this insn. This is ! 755: used to ensure that certain groups of instructions will not be ! 756: split up by the instruction scheduling pass, for example, `use' ! 757: insns before a `call_insn' may not be separated from the ! 758: `call_insn'. Stored in the `in_struct' field and printed as `/s'. ! 759: ! 760: These are the fields which the above macros refer to: ! 761: ! 762: `used' ! 763: Normally, this flag is used only momentarily, at the end of RTL ! 764: generation for a function, to count the number of times an ! 765: expression appears in insns. Expressions that appear more than ! 766: once are copied, according to the rules for shared structure ! 767: (*note Sharing::.). ! 768: ! 769: In a `symbol_ref', it indicates that an external declaration for ! 770: the symbol has already been written. ! 771: ! 772: In a `reg', it is used by the leaf register renumbering code to ! 773: ensure that each register is only renumbered once. ! 774: ! 775: `volatil' ! 776: This flag is used in `mem', `symbol_ref' and `reg' expressions and ! 777: in insns. In RTL dump files, it is printed as `/v'. ! 778: ! 779: In a `mem' expression, it is 1 if the memory reference is volatile. ! 780: Volatile memory references may not be deleted, reordered or ! 781: combined. ! 782: ! 783: In a `symbol_ref' expression, it is used for machine-specific ! 784: purposes. ! 785: ! 786: In a `reg' expression, it is 1 if the value is a user-level ! 787: variable. 0 indicates an internal compiler temporary. ! 788: ! 789: In an insn, 1 means the insn has been deleted. ! 790: ! 791: `in_struct' ! 792: In `mem' expressions, it is 1 if the memory datum referred to is ! 793: all or part of a structure or array; 0 if it is (or might be) a ! 794: scalar variable. A reference through a C pointer has 0 because ! 795: the pointer might point to a scalar variable. This information ! 796: allows the compiler to determine something about possible cases of ! 797: aliasing. ! 798: ! 799: In an insn in the delay slot of a branch, 1 means that this insn ! 800: is from the target of the branch. ! 801: ! 802: During instruction scheduling, in an insn, 1 means that this insn ! 803: must be scheduled as part of a group together with the previous ! 804: insn. ! 805: ! 806: In `reg' expressions, it is 1 if the register has its entire life ! 807: contained within the test expression of some loop. ! 808: ! 809: In `subreg' expressions, 1 means that the `subreg' is accessing an ! 810: object that has had its mode promoted from a wider mode. ! 811: ! 812: In `label_ref' expressions, 1 means that the referenced label is ! 813: outside the innermost loop containing the insn in which the ! 814: `label_ref' was found. ! 815: ! 816: In `code_label' expressions, it is 1 if the label may never be ! 817: deleted. This is used for labels which are the target of ! 818: non-local gotos. ! 819: ! 820: In an RTL dump, this flag is represented as `/s'. ! 821: ! 822: `unchanging' ! 823: In `reg' and `mem' expressions, 1 means that the value of the ! 824: expression never changes. ! 825: ! 826: In `subreg' expressions, it is 1 if the `subreg' references an ! 827: unsigned object whose mode has been promoted to a wider mode. ! 828: ! 829: In an insn, 1 means that this is an annulling branch. ! 830: ! 831: In a `symbol_ref' expression, 1 means that this symbol addresses ! 832: something in the per-function constants pool. ! 833: ! 834: In a `call_insn', 1 means that this instruction is a call to a ! 835: const function. ! 836: ! 837: In an RTL dump, this flag is represented as `/u'. ! 838: ! 839: `integrated' ! 840: In some kinds of expressions, including insns, this flag means the ! 841: rtl was produced by procedure integration. ! 842: ! 843: In a `reg' expression, this flag indicates the register containing ! 844: the value to be returned by the current function. On machines ! 845: that pass parameters in registers, the same register number may be ! 846: used for parameters as well, but this flag is not set on such uses. 1.1.1.6 root 847: 848: 1.1.1.7 ! root 849: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 1.1.1.6 root 850: 1.1.1.7 ! root 851: Machine Modes ! 852: ============= 1.1.1.6 root 853: 1.1.1.7 ! root 854: A machine mode describes a size of data object and the ! 855: representation used for it. In the C code, machine modes are ! 856: represented by an enumeration type, `enum machine_mode', defined in ! 857: `machmode.def'. Each RTL expression has room for a machine mode and so ! 858: do certain kinds of tree expressions (declarations and types, to be ! 859: precise). ! 860: ! 861: In debugging dumps and machine descriptions, the machine mode of an ! 862: RTL expression is written after the expression code with a colon to ! 863: separate them. The letters `mode' which appear at the end of each ! 864: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' ! 865: expression with machine mode `SImode'. If the mode is `VOIDmode', it ! 866: is not written at all. ! 867: ! 868: Here is a table of machine modes. The term "byte" below refers to an ! 869: object of `BITS_PER_UNIT' bits (*note Storage Layout::.). ! 870: ! 871: `QImode' ! 872: "Quarter-Integer" mode represents a single byte treated as an ! 873: integer. ! 874: ! 875: `HImode' ! 876: "Half-Integer" mode represents a two-byte integer. ! 877: ! 878: `PSImode' ! 879: "Partial Single Integer" mode represents an integer which occupies ! 880: four bytes but which doesn't really use all four. On some ! 881: machines, this is the right mode to use for pointers. ! 882: ! 883: `SImode' ! 884: "Single Integer" mode represents a four-byte integer. ! 885: ! 886: `PDImode' ! 887: "Partial Double Integer" mode represents an integer which occupies ! 888: eight bytes but which doesn't really use all eight. On some ! 889: machines, this is the right mode to use for certain pointers. ! 890: ! 891: `DImode' ! 892: "Double Integer" mode represents an eight-byte integer. ! 893: ! 894: `TImode' ! 895: "Tetra Integer" (?) mode represents a sixteen-byte integer. ! 896: ! 897: `SFmode' ! 898: "Single Floating" mode represents a single-precision (four byte) ! 899: floating point number. ! 900: ! 901: `DFmode' ! 902: "Double Floating" mode represents a double-precision (eight byte) ! 903: floating point number. ! 904: ! 905: `XFmode' ! 906: "Extended Floating" mode represents a triple-precision (twelve ! 907: byte) floating point number. This mode is used for IEEE extended ! 908: floating point. ! 909: ! 910: `TFmode' ! 911: "Tetra Floating" mode represents a quadruple-precision (sixteen ! 912: byte) floating point number. ! 913: ! 914: `CCmode' ! 915: "Condition Code" mode represents the value of a condition code, ! 916: which is a machine-specific set of bits used to represent the ! 917: result of a comparison operation. Other machine-specific modes ! 918: may also be used for the condition code. These modes are not used ! 919: on machines that use `cc0' (see *note Condition Code::.). ! 920: ! 921: `BLKmode' ! 922: "Block" mode represents values that are aggregates to which none of ! 923: the other modes apply. In RTL, only memory references can have ! 924: this mode, and only if they appear in string-move or vector ! 925: instructions. On machines which have no such instructions, ! 926: `BLKmode' will not appear in RTL. ! 927: ! 928: `VOIDmode' ! 929: Void mode means the absence of a mode or an unspecified mode. For ! 930: example, RTL expressions of code `const_int' have mode `VOIDmode' ! 931: because they can be taken to have whatever mode the context ! 932: requires. In debugging dumps of RTL, `VOIDmode' is expressed by ! 933: the absence of any mode. ! 934: ! 935: `SCmode, DCmode, XCmode, TCmode' ! 936: These modes stand for a complex number represented as a pair of ! 937: floating point values. The floating point values are in `SFmode', ! 938: `DFmode', `XFmode', and `TFmode', respectively. ! 939: ! 940: `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' ! 941: These modes stand for a complex number represented as a pair of ! 942: integer values. The integer values are in `QImode', `HImode', ! 943: `SImode', `DImode', `TImode', and `OImode', respectively. ! 944: ! 945: The machine description defines `Pmode' as a C macro which expands ! 946: into the machine mode used for addresses. Normally this is the mode ! 947: whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. ! 948: ! 949: The only modes which a machine description must support are ! 950: `QImode', and the modes corresponding to `BITS_PER_WORD', ! 951: `FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to ! 952: use `DImode' for 8-byte structures and unions, but this can be ! 953: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. ! 954: Alternatively, you can have the compiler use `TImode' for 16-byte ! 955: structures and unions. Likewise, you can arrange for the C type `short ! 956: int' to avoid using `HImode'. ! 957: ! 958: Very few explicit references to machine modes remain in the compiler ! 959: and these few references will soon be removed. Instead, the machine ! 960: modes are divided into mode classes. These are represented by the ! 961: enumeration type `enum mode_class' defined in `machmode.h'. The ! 962: possible mode classes are: ! 963: ! 964: `MODE_INT' ! 965: Integer modes. By default these are `QImode', `HImode', `SImode', ! 966: `DImode', and `TImode'. ! 967: ! 968: `MODE_PARTIAL_INT' ! 969: The "partial integer" modes, `PSImode' and `PDImode'. ! 970: ! 971: `MODE_FLOAT' ! 972: floating point modes. By default these are `SFmode', `DFmode', ! 973: `XFmode' and `TFmode'. ! 974: ! 975: `MODE_COMPLEX_INT' ! 976: Complex integer modes. (These are not currently implemented). ! 977: ! 978: `MODE_COMPLEX_FLOAT' ! 979: Complex floating point modes. By default these are `SCmode', ! 980: `DCmode', `XCmode', and `TCmode'. ! 981: ! 982: `MODE_FUNCTION' ! 983: Algol or Pascal function variables including a static chain. ! 984: (These are not currently implemented). ! 985: ! 986: `MODE_CC' ! 987: Modes representing condition code values. These are `CCmode' plus ! 988: any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump ! 989: Patterns::, also see *Note Condition Code::. ! 990: ! 991: `MODE_RANDOM' ! 992: This is a catchall mode class for modes which don't fit into the ! 993: above classes. Currently `VOIDmode' and `BLKmode' are in ! 994: `MODE_RANDOM'. ! 995: ! 996: Here are some C macros that relate to machine modes: ! 997: ! 998: `GET_MODE (X)' ! 999: Returns the machine mode of the RTX X. ! 1000: ! 1001: `PUT_MODE (X, NEWMODE)' ! 1002: Alters the machine mode of the RTX X to be NEWMODE. ! 1003: ! 1004: `NUM_MACHINE_MODES' ! 1005: Stands for the number of machine modes available on the target ! 1006: machine. This is one greater than the largest numeric value of any ! 1007: machine mode. 1.1.1.6 root 1008: 1.1.1.7 ! root 1009: `GET_MODE_NAME (M)' ! 1010: Returns the name of mode M as a string. 1.1.1.3 root 1011: 1.1.1.7 ! root 1012: `GET_MODE_CLASS (M)' ! 1013: Returns the mode class of mode M. 1.1.1.3 root 1014: 1.1.1.7 ! root 1015: `GET_MODE_WIDER_MODE (M)' ! 1016: Returns the next wider natural mode. For example, the expression ! 1017: `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. ! 1018: ! 1019: `GET_MODE_SIZE (M)' ! 1020: Returns the size in bytes of a datum of mode M. ! 1021: ! 1022: `GET_MODE_BITSIZE (M)' ! 1023: Returns the size in bits of a datum of mode M. ! 1024: ! 1025: `GET_MODE_MASK (M)' ! 1026: Returns a bitmask containing 1 for all bits in a word that fit ! 1027: within mode M. This macro can only be used for modes whose ! 1028: bitsize is less than or equal to `HOST_BITS_PER_INT'. ! 1029: ! 1030: `GET_MODE_ALIGNMENT (M))' ! 1031: Return the required alignment, in bits, for an object of mode M. ! 1032: ! 1033: `GET_MODE_UNIT_SIZE (M)' ! 1034: Returns the size in bytes of the subunits of a datum of mode M. ! 1035: This is the same as `GET_MODE_SIZE' except in the case of complex ! 1036: modes. For them, the unit size is the size of the real or ! 1037: imaginary part. ! 1038: ! 1039: `GET_MODE_NUNITS (M)' ! 1040: Returns the number of units contained in a mode, i.e., ! 1041: `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. ! 1042: ! 1043: `GET_CLASS_NARROWEST_MODE (C)' ! 1044: Returns the narrowest mode in mode class C. ! 1045: ! 1046: The global variables `byte_mode' and `word_mode' contain modes whose ! 1047: classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or ! 1048: `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' ! 1049: and `SImode', respectively. 1.1.1.3 root 1050: 1051: 1.1.1.7 ! root 1052: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 1.1.1.3 root 1053: 1.1.1.7 ! root 1054: Constant Expression Types ! 1055: ========================= 1.1.1.3 root 1056: 1.1.1.7 ! root 1057: The simplest RTL expressions are those that represent constant ! 1058: values. 1.1.1.5 root 1059: 1.1.1.7 ! root 1060: `(const_int I)' ! 1061: This type of expression represents the integer value I. I is ! 1062: customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', ! 1063: which is equivalent to `XWINT (EXP, 0)'. ! 1064: ! 1065: There is only one expression object for the integer value zero; it ! 1066: is the value of the variable `const0_rtx'. Likewise, the only ! 1067: expression for integer value one is found in `const1_rtx', the only ! 1068: expression for integer value two is found in `const2_rtx', and the ! 1069: only expression for integer value negative one is found in ! 1070: `constm1_rtx'. Any attempt to create an expression of code ! 1071: `const_int' and value zero, one, two or negative one will return ! 1072: `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as ! 1073: appropriate. ! 1074: ! 1075: Similarly, there is only one object for the integer whose value is ! 1076: `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If ! 1077: `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will ! 1078: point to the same object. If `STORE_FLAG_VALUE' is -1, ! 1079: `const_true_rtx' and `constm1_rtx' will point to the same object. ! 1080: ! 1081: `(const_double:M ADDR I0 I1 ...)' ! 1082: Represents either a floating-point constant of mode M or an ! 1083: integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' ! 1084: bits but small enough to fit within twice that number of bits (GNU ! 1085: CC does not provide a mechanism to represent even larger ! 1086: constants). In the latter case, M will be `VOIDmode'. ! 1087: ! 1088: ADDR is used to contain the `mem' expression that corresponds to ! 1089: the location in memory that at which the constant can be found. If ! 1090: it has not been allocated a memory location, but is on the chain ! 1091: of all `const_double' expressions in this compilation (maintained ! 1092: using an undisplayed field), ADDR contains `const0_rtx'. If it is ! 1093: not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily ! 1094: accessed with the macro `CONST_DOUBLE_MEM' and the chain field via ! 1095: `CONST_DOUBLE_CHAIN'. ! 1096: ! 1097: If M is `VOIDmode', the bits of the value are stored in I0 and I1. ! 1098: I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and ! 1099: I1 with `CONST_DOUBLE_HIGH'. ! 1100: ! 1101: If the constant is floating point (regardless of its precision), ! 1102: then the number of integers used to store the value depends on the ! 1103: size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The ! 1104: integers represent a floating point number, but not precisely in ! 1105: the target machine's or host machine's floating point format. To ! 1106: convert them to the precise bit pattern used by the target ! 1107: machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends ! 1108: (*note Data Output::.). ! 1109: ! 1110: The macro `CONST0_RTX (MODE)' refers to an expression with value 0 ! 1111: in mode MODE. If mode MODE is of mode class `MODE_INT', it ! 1112: returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' ! 1113: expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)' ! 1114: refers to an expression with value 1 in mode MODE and similarly ! 1115: for `CONST2_RTX'. ! 1116: ! 1117: `(const_string STR)' ! 1118: Represents a constant string with value STR. Currently this is ! 1119: used only for insn attributes (*note Insn Attributes::.) since ! 1120: constant strings in C are placed in memory. ! 1121: ! 1122: `(symbol_ref:MODE SYMBOL)' ! 1123: Represents the value of an assembler label for data. SYMBOL is a ! 1124: string that describes the name of the assembler label. If it ! 1125: starts with a `*', the label is the rest of SYMBOL not including ! 1126: the `*'. Otherwise, the label is SYMBOL, usually prefixed with ! 1127: `_'. ! 1128: ! 1129: The `symbol_ref' contains a mode, which is usually `Pmode'. ! 1130: Usually that is the only mode for which a symbol is directly valid. ! 1131: ! 1132: `(label_ref LABEL)' ! 1133: Represents the value of an assembler label for code. It contains ! 1134: one operand, an expression, which must be a `code_label' that ! 1135: appears in the instruction sequence to identify the place where ! 1136: the label should go. ! 1137: ! 1138: The reason for using a distinct expression type for code label ! 1139: references is so that jump optimization can distinguish them. ! 1140: ! 1141: `(const:M EXP)' ! 1142: Represents a constant that is the result of an assembly-time ! 1143: arithmetic computation. The operand, EXP, is an expression that ! 1144: contains only constants (`const_int', `symbol_ref' and `label_ref' ! 1145: expressions) combined with `plus' and `minus'. However, not all ! 1146: combinations are valid, since the assembler cannot do arbitrary ! 1147: arithmetic on relocatable symbols. 1.1.1.3 root 1148: 1.1.1.7 ! root 1149: M should be `Pmode'. 1.1.1.3 root 1150: 1.1.1.7 ! root 1151: `(high:M EXP)' ! 1152: Represents the high-order bits of EXP, usually a `symbol_ref'. ! 1153: The number of bits is machine-dependent and is normally the number ! 1154: of bits specified in an instruction that initializes the high ! 1155: order bits of a register. It is used with `lo_sum' to represent ! 1156: the typical two-instruction sequence used in RISC machines to ! 1157: reference a global memory location. 1.1.1.3 root 1158: 1.1.1.7 ! root 1159: M should be `Pmode'. 1.1.1.3 root 1160:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.