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