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