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