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