![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rtl.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to rtl.texi CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 ! root 1: @c Copyright (C) 1988, 1989, 1992, 1994 Free Software Foundation, Inc. 1.1 root 2: @c This is part of the GCC manual. 3: @c For copying conditions, see the file gcc.texi. 4: 1.1.1.3 root 5: @node RTL 1.1 root 6: @chapter RTL Representation 7: @cindex RTL representation 8: @cindex representation of RTL 9: @cindex Register Transfer Language (RTL) 10: 11: Most of the work of the compiler is done on an intermediate representation 12: called register transfer language. In this language, the instructions to be 13: output are described, pretty much one by one, in an algebraic form that 14: describes what the instruction does. 15: 16: RTL is inspired by Lisp lists. It has both an internal form, made up of 17: structures that point at other structures, and a textual form that is used 18: in the machine description and in printed debugging dumps. The textual 19: form uses nested parentheses to indicate the pointers in the internal form. 20: 21: @menu 22: * RTL Objects:: Expressions vs vectors vs strings vs integers. 23: * Accessors:: Macros to access expression operands or vector elts. 24: * Flags:: Other flags in an RTL expression. 25: * Machine Modes:: Describing the size and format of a datum. 26: * Constants:: Expressions with constant values. 27: * Regs and Memory:: Expressions representing register contents or memory. 28: * Arithmetic:: Expressions representing arithmetic on other expressions. 29: * Comparisons:: Expressions representing comparison of expressions. 1.1.1.5 root 30: * Bit Fields:: Expressions representing bitfields in memory or reg. 1.1 root 31: * Conversions:: Extending, truncating, floating or fixing. 32: * RTL Declarations:: Declaring volatility, constancy, etc. 33: * Side Effects:: Expressions for storing in registers, etc. 34: * Incdec:: Embedded side-effects for autoincrement addressing. 35: * Assembler:: Representing @code{asm} with operands. 36: * Insns:: Expression types for entire insns. 37: * Calls:: RTL representation of function call insns. 38: * Sharing:: Some expressions are unique; others *must* be copied. 1.1.1.5 root 39: * Reading RTL:: Reading textual RTL from a file. 1.1 root 40: @end menu 41: 42: @node RTL Objects, Accessors, RTL, RTL 43: @section RTL Object Types 44: @cindex RTL object types 45: 46: @cindex RTL integers 47: @cindex RTL strings 48: @cindex RTL vectors 49: @cindex RTL expression 50: @cindex RTX (See RTL) 1.1.1.4 root 51: RTL uses five kinds of objects: expressions, integers, wide integers, 52: strings and vectors. Expressions are the most important ones. An RTL 53: expression (``RTX'', for short) is a C structure, but it is usually 54: referred to with a pointer; a type that is given the typedef name 55: @code{rtx}. 1.1 root 56: 57: An integer is simply an @code{int}; their written form uses decimal digits. 1.1.1.4 root 58: A wide integer is an integral object whose type is @code{HOST_WIDE_INT} 1.1.1.5 root 59: (@pxref{Config}); their written form uses decimal digits. 1.1 root 60: 61: A string is a sequence of characters. In core it is represented as a 62: @code{char *} in usual C fashion, and it is written in C syntax as well. 63: However, strings in RTL may never be null. If you write an empty string in 64: a machine description, it is represented in core as a null pointer rather 65: than as a pointer to a null character. In certain contexts, these null 66: pointers instead of strings are valid. Within RTL code, strings are most 67: commonly found inside @code{symbol_ref} expressions, but they appear in 68: other contexts in the RTL expressions that make up machine descriptions. 69: 70: A vector contains an arbitrary number of pointers to expressions. The 71: number of elements in the vector is explicitly present in the vector. 72: The written form of a vector consists of square brackets 73: (@samp{[@dots{}]}) surrounding the elements, in sequence and with 74: whitespace separating them. Vectors of length zero are not created; 75: null pointers are used instead. 76: 77: @cindex expression codes 78: @cindex codes, RTL expression 79: @findex GET_CODE 80: @findex PUT_CODE 81: Expressions are classified by @dfn{expression codes} (also called RTX 82: codes). The expression code is a name defined in @file{rtl.def}, which is 83: also (in upper case) a C enumeration constant. The possible expression 84: codes and their meanings are machine-independent. The code of an RTX can 85: be extracted with the macro @code{GET_CODE (@var{x})} and altered with 86: @code{PUT_CODE (@var{x}, @var{newcode})}. 87: 88: The expression code determines how many operands the expression contains, 89: and what kinds of objects they are. In RTL, unlike Lisp, you cannot tell 90: by looking at an operand what kind of object it is. Instead, you must know 91: from its context---from the expression code of the containing expression. 92: For example, in an expression of code @code{subreg}, the first operand is 93: to be regarded as an expression and the second operand as an integer. In 94: an expression of code @code{plus}, there are two operands, both of which 95: are to be regarded as expressions. In a @code{symbol_ref} expression, 96: there is one operand, which is to be regarded as a string. 97: 98: Expressions are written as parentheses containing the name of the 99: expression type, its flags and machine mode if any, and then the operands 100: of the expression (separated by spaces). 101: 102: Expression code names in the @samp{md} file are written in lower case, 103: but when they appear in C code they are written in upper case. In this 104: manual, they are shown as follows: @code{const_int}. 105: 106: @cindex (nil) 107: @cindex nil 108: In a few contexts a null pointer is valid where an expression is normally 109: wanted. The written form of this is @code{(nil)}. 110: 111: @node Accessors, Flags, RTL Objects, RTL 112: @section Access to Operands 113: @cindex accessors 114: @cindex access to operands 115: @cindex operand access 116: 117: @cindex RTL format 1.1.1.4 root 118: For each expression type @file{rtl.def} specifies the number of 119: contained objects and their kinds, with four possibilities: @samp{e} for 120: expression (actually a pointer to an expression), @samp{i} for integer, 121: @samp{w} for wide integer, @samp{s} for string, and @samp{E} for vector 122: of expressions. The sequence of letters for an expression code is 123: called its @dfn{format}. Thus, the format of @code{subreg} is 124: @samp{ei}.@refill 1.1 root 125: 126: @cindex RTL format characters 127: A few other format characters are used occasionally: 128: 129: @table @code 130: @item u 131: @samp{u} is equivalent to @samp{e} except that it is printed differently 132: in debugging dumps. It is used for pointers to insns. 133: 134: @item n 135: @samp{n} is equivalent to @samp{i} except that it is printed differently 136: in debugging dumps. It is used for the line number or code number of a 137: @code{note} insn. 138: 139: @item S 140: @samp{S} indicates a string which is optional. In the RTL objects in 141: core, @samp{S} is equivalent to @samp{s}, but when the object is read, 142: from an @samp{md} file, the string value of this operand may be omitted. 143: An omitted string is taken to be the null string. 144: 145: @item V 146: @samp{V} indicates a vector which is optional. In the RTL objects in 147: core, @samp{V} is equivalent to @samp{E}, but when the object is read 148: from an @samp{md} file, the vector value of this operand may be omitted. 149: An omitted vector is effectively the same as a vector of no elements. 150: 151: @item 0 152: @samp{0} means a slot whose contents do not fit any normal category. 153: @samp{0} slots are not printed at all in dumps, and are often used in 154: special ways by small parts of the compiler. 155: @end table 156: 157: There are macros to get the number of operands, the format, and the 158: class of an expression code: 159: 160: @table @code 161: @findex GET_RTX_LENGTH 162: @item GET_RTX_LENGTH (@var{code}) 163: Number of operands of an RTX of code @var{code}. 164: 165: @findex GET_RTX_FORMAT 166: @item GET_RTX_FORMAT (@var{code}) 167: The format of an RTX of code @var{code}, as a C string. 168: 169: @findex GET_RTX_CLASS 170: @cindex classes of RTX codes 171: @item GET_RTX_CLASS (@var{code}) 172: A single character representing the type of RTX operation that code 173: @var{code} performs. 174: 175: The following classes are defined: 176: 177: @table @code 178: @item o 179: An RTX code that represents an actual object, such as @code{reg} or 180: @code{mem}. @code{subreg} is not in this class. 181: 182: @item < 183: An RTX code for a comparison. The codes in this class are 184: @code{NE}, @code{EQ}, @code{LE}, @code{LT}, @code{GE}, @code{GT}, 185: @code{LEU}, @code{LTU}, @code{GEU}, @code{GTU}.@refill 186: 187: @item 1 188: An RTX code for a unary arithmetic operation, such as @code{neg}. 189: 190: @item c 191: An RTX code for a commutative binary operation, other than @code{NE} 192: and @code{EQ} (which have class @samp{<}). 193: 194: @item 2 195: An RTX code for a noncommutative binary operation, such as @code{MINUS}. 196: 197: @item b 1.1.1.5 root 198: An RTX code for a bitfield operation, either @code{ZERO_EXTRACT} or 199: @code{SIGN_EXTRACT}. 1.1 root 200: 201: @item 3 202: An RTX code for other three input operations, such as @code{IF_THEN_ELSE}. 203: 204: @item i 205: An RTX code for a machine insn (@code{INSN}, @code{JUMP_INSN}, and 206: @code{CALL_INSN}).@refill 207: 208: @item m 209: An RTX code for something that matches in insns, such as @code{MATCH_DUP}. 210: 211: @item x 212: All other RTX codes. 213: @end table 214: @end table 215: 216: @findex XEXP 217: @findex XINT 1.1.1.4 root 218: @findex XWINT 1.1 root 219: @findex XSTR 220: Operands of expressions are accessed using the macros @code{XEXP}, 1.1.1.4 root 221: @code{XINT}, @code{XWINT} and @code{XSTR}. Each of these macros takes 222: two arguments: an expression-pointer (RTX) and an operand number 223: (counting from zero). Thus,@refill 1.1 root 224: 225: @example 226: XEXP (@var{x}, 2) 227: @end example 228: 229: @noindent 230: accesses operand 2 of expression @var{x}, as an expression. 231: 232: @example 233: XINT (@var{x}, 2) 234: @end example 235: 236: @noindent 237: accesses the same operand as an integer. @code{XSTR}, used in the same 238: fashion, would access it as a string. 239: 240: Any operand can be accessed as an integer, as an expression or as a string. 241: You must choose the correct method of access for the kind of value actually 242: stored in the operand. You would do this based on the expression code of 243: the containing expression. That is also how you would know how many 244: operands there are. 245: 246: For example, if @var{x} is a @code{subreg} expression, you know that it has 247: two operands which can be correctly accessed as @code{XEXP (@var{x}, 0)} 248: and @code{XINT (@var{x}, 1)}. If you did @code{XINT (@var{x}, 0)}, you 249: would get the address of the expression operand but cast as an integer; 250: that might occasionally be useful, but it would be cleaner to write 251: @code{(int) XEXP (@var{x}, 0)}. @code{XEXP (@var{x}, 1)} would also 252: compile without error, and would return the second, integer operand cast as 253: an expression pointer, which would probably result in a crash when 254: accessed. Nothing stops you from writing @code{XEXP (@var{x}, 28)} either, 255: but this will access memory past the end of the expression with 256: unpredictable results.@refill 257: 258: Access to operands which are vectors is more complicated. You can use the 259: macro @code{XVEC} to get the vector-pointer itself, or the macros 260: @code{XVECEXP} and @code{XVECLEN} to access the elements and length of a 261: vector. 262: 263: @table @code 264: @findex XVEC 265: @item XVEC (@var{exp}, @var{idx}) 266: Access the vector-pointer which is operand number @var{idx} in @var{exp}. 267: 268: @findex XVECLEN 269: @item XVECLEN (@var{exp}, @var{idx}) 270: Access the length (number of elements) in the vector which is 271: in operand number @var{idx} in @var{exp}. This value is an @code{int}. 272: 273: @findex XVECEXP 274: @item XVECEXP (@var{exp}, @var{idx}, @var{eltnum}) 275: Access element number @var{eltnum} in the vector which is 276: in operand number @var{idx} in @var{exp}. This value is an RTX. 277: 278: It is up to you to make sure that @var{eltnum} is not negative 279: and is less than @code{XVECLEN (@var{exp}, @var{idx})}. 280: @end table 281: 282: All the macros defined in this section expand into lvalues and therefore 283: can be used to assign the operands, lengths and vector elements as well as 284: to access them. 285: 286: @node Flags, Machine Modes, Accessors, RTL 287: @section Flags in an RTL Expression 288: @cindex flags in RTL expression 289: 1.1.1.5 root 290: RTL expressions contain several flags (one-bit bitfields) that are used 1.1 root 291: in certain types of expression. Most often they are accessed with the 292: following macros: 293: 294: @table @code 295: @findex MEM_VOLATILE_P 296: @cindex @code{mem} and @samp{/v} 297: @cindex @code{volatil}, in @code{mem} 298: @cindex @samp{/v} in RTL dump 299: @item MEM_VOLATILE_P (@var{x}) 300: In @code{mem} expressions, nonzero for volatile memory references. 301: Stored in the @code{volatil} field and printed as @samp{/v}. 302: 303: @findex MEM_IN_STRUCT_P 304: @cindex @code{mem} and @samp{/s} 305: @cindex @code{in_struct}, in @code{mem} 306: @cindex @samp{/s} in RTL dump 307: @item MEM_IN_STRUCT_P (@var{x}) 308: In @code{mem} expressions, nonzero for reference to an entire 309: structure, union or array, or to a component of one. Zero for 310: references to a scalar variable or through a pointer to a scalar. 311: Stored in the @code{in_struct} field and printed as @samp{/s}. 312: 313: @findex REG_LOOP_TEST_P 314: @cindex @code{reg} and @samp{/s} 315: @cindex @code{in_struct}, in @code{reg} 316: @item REG_LOOP_TEST_P 317: In @code{reg} expressions, nonzero if this register's entire life is 318: contained in the exit test code for some loop. Stored in the 319: @code{in_struct} field and printed as @samp{/s}. 320: 321: @findex REG_USERVAR_P 322: @cindex @code{reg} and @samp{/v} 323: @cindex @code{volatil}, in @code{reg} 324: @item REG_USERVAR_P (@var{x}) 325: In a @code{reg}, nonzero if it corresponds to a variable present in 326: the user's source code. Zero for temporaries generated internally by 327: the compiler. Stored in the @code{volatil} field and printed as 328: @samp{/v}. 329: 330: @cindex @samp{/i} in RTL dump 331: @findex REG_FUNCTION_VALUE_P 332: @cindex @code{reg} and @samp{/i} 333: @cindex @code{integrated}, in @code{reg} 334: @item REG_FUNCTION_VALUE_P (@var{x}) 335: Nonzero in a @code{reg} if it is the place in which this function's 336: value is going to be returned. (This happens only in a hard 337: register.) Stored in the @code{integrated} field and printed as 338: @samp{/i}. 339: 340: The same hard register may be used also for collecting the values of 341: functions called by this one, but @code{REG_FUNCTION_VALUE_P} is zero 342: in this kind of use. 343: 1.1.1.4 root 344: @findex SUBREG_PROMOTED_VAR_P 345: @cindex @code{subreg} and @samp{/s} 346: @cindex @code{in_struct}, in @code{subreg} 347: @item SUBREG_PROMOTED_VAR_P 348: Nonzero in a @code{subreg} if it was made when accessing an object that 349: was promoted to a wider mode in accord with the @code{PROMOTED_MODE} machine 350: description macro (@pxref{Storage Layout}). In this case, the mode of 351: the @code{subreg} is the declared mode of the object and the mode of 352: @code{SUBREG_REG} is the mode of the register that holds the object. 353: Promoted variables are always either sign- or zero-extended to the wider 354: mode on every assignment. Stored in the @code{in_struct} field and 355: printed as @samp{/s}. 356: 357: @findex SUBREG_PROMOTED_UNSIGNED_P 358: @cindex @code{subreg} and @samp{/u} 359: @cindex @code{unchanging}, in @code{subreg} 360: @item SUBREG_PROMOTED_UNSIGNED_P 361: Nonzero in a @code{subreg} that has @code{SUBREG_PROMOTED_VAR_P} nonzero 362: if the object being referenced is kept zero-extended and zero if it 363: is kept sign-extended. Stored in the @code{unchanging} field and 364: printed as @samp{/u}. 365: 1.1 root 366: @findex RTX_UNCHANGING_P 367: @cindex @code{reg} and @samp{/u} 368: @cindex @code{mem} and @samp{/u} 369: @cindex @code{unchanging}, in @code{reg} and @code{mem} 370: @cindex @samp{/u} in RTL dump 371: @item RTX_UNCHANGING_P (@var{x}) 372: Nonzero in a @code{reg} or @code{mem} if the value is not changed. 373: (This flag is not set for memory references via pointers to constants. 374: Such pointers only guarantee that the object will not be changed 375: explicitly by the current function. The object might be changed by 376: other functions or by aliasing.) Stored in the 377: @code{unchanging} field and printed as @samp{/u}. 378: 379: @findex RTX_INTEGRATED_P 380: @cindex @code{integrated}, in @code{insn} 381: @item RTX_INTEGRATED_P (@var{insn}) 382: Nonzero in an insn if it resulted from an in-line function call. 383: Stored in the @code{integrated} field and printed as @samp{/i}. This 384: may be deleted; nothing currently depends on it. 385: 386: @findex SYMBOL_REF_USED 387: @cindex @code{used}, in @code{symbol_ref} 388: @item SYMBOL_REF_USED (@var{x}) 389: In a @code{symbol_ref}, indicates that @var{x} has been used. This is 390: normally only used to ensure that @var{x} is only declared external 391: once. Stored in the @code{used} field. 392: 393: @findex SYMBOL_REF_FLAG 394: @cindex @code{symbol_ref} and @samp{/v} 395: @cindex @code{volatil}, in @code{symbol_ref} 396: @item SYMBOL_REF_FLAG (@var{x}) 397: In a @code{symbol_ref}, this is used as a flag for machine-specific purposes. 398: Stored in the @code{volatil} field and printed as @samp{/v}. 399: 400: @findex LABEL_OUTSIDE_LOOP_P 401: @cindex @code{label_ref} and @samp{/s} 402: @cindex @code{in_struct}, in @code{label_ref} 403: @item LABEL_OUTSIDE_LOOP_P 404: In @code{label_ref} expressions, nonzero if this is a reference to a 405: label that is outside the innermost loop containing the reference to the 406: label. Stored in the @code{in_struct} field and printed as @samp{/s}. 407: 408: @findex INSN_DELETED_P 409: @cindex @code{volatil}, in @code{insn} 410: @item INSN_DELETED_P (@var{insn}) 411: In an insn, nonzero if the insn has been deleted. Stored in the 412: @code{volatil} field and printed as @samp{/v}. 413: 414: @findex INSN_ANNULLED_BRANCH_P 415: @cindex @code{insn} and @samp{/u} 416: @cindex @code{unchanging}, in @code{insn} 417: @item INSN_ANNULLED_BRANCH_P (@var{insn}) 418: In an @code{insn} in the delay slot of a branch insn, indicates that an 419: annulling branch should be used. See the discussion under 420: @code{sequence} below. Stored in the @code{unchanging} field and printed 421: as @samp{/u}. 422: 423: @findex INSN_FROM_TARGET_P 424: @cindex @code{insn} and @samp{/s} 425: @cindex @code{in_struct}, in @code{insn} 426: @cindex @samp{/s} in RTL dump 427: @item INSN_FROM_TARGET_P (@var{insn}) 428: In an @code{insn} in a delay slot of a branch, indicates that the insn 429: is from the target of the branch. If the branch insn has 430: @code{INSN_ANNULLED_BRANCH_P} set, this insn should only be executed if 431: the branch is taken. For annulled branches with this bit clear, the 432: insn should be executed only if the branch is not taken. Stored in the 433: @code{in_struct} field and printed as @samp{/s}. 434: 435: @findex CONSTANT_POOL_ADDRESS_P 436: @cindex @code{symbol_ref} and @samp{/u} 437: @cindex @code{unchanging}, in @code{symbol_ref} 438: @item CONSTANT_POOL_ADDRESS_P (@var{x}) 439: Nonzero in a @code{symbol_ref} if it refers to part of the current 440: function's ``constants pool''. These are addresses close to the 441: beginning of the function, and GNU CC assumes they can be addressed 442: directly (perhaps with the help of base registers). Stored in the 443: @code{unchanging} field and printed as @samp{/u}. 444: 445: @findex CONST_CALL_P 446: @cindex @code{call_insn} and @samp{/u} 447: @cindex @code{unchanging}, in @code{call_insn} 448: @item CONST_CALL_P (@var{x}) 449: In a @code{call_insn}, indicates that the insn represents a call to a const 450: function. Stored in the @code{unchanging} field and printed as @samp{/u}. 451: 452: @findex LABEL_PRESERVE_P 453: @cindex @code{code_label} and @samp{/i} 454: @cindex @code{in_struct}, in @code{code_label} 455: @item LABEL_PRESERVE_P (@var{x}) 456: In a @code{code_label}, indicates that the label can never be deleted. 1.1.1.4 root 457: Labels referenced by a non-local goto will have this bit set. Stored 1.1 root 458: in the @code{in_struct} field and printed as @samp{/s}. 459: 460: @findex SCHED_GROUP_P 461: @cindex @code{insn} and @samp{/i} 462: @cindex @code{in_struct}, in @code{insn} 463: @item SCHED_GROUP_P (@var{insn}) 464: During instruction scheduling, in an insn, indicates that the previous insn 465: must be scheduled together with this insn. This is used to ensure that 466: certain groups of instructions will not be split up by the instruction 467: scheduling pass, for example, @code{use} insns before a @code{call_insn} may 468: not be separated from the @code{call_insn}. Stored in the @code{in_struct} 469: field and printed as @samp{/s}. 470: @end table 471: 472: These are the fields which the above macros refer to: 473: 474: @table @code 475: @findex used 476: @item used 477: Normally, this flag is used only momentarily, at the end of RTL 478: generation for a function, to count the number of times an expression 479: appears in insns. Expressions that appear more than once are copied, 480: according to the rules for shared structure (@pxref{Sharing}). 481: 482: In a @code{symbol_ref}, it indicates that an external declaration for 483: the symbol has already been written. 484: 485: In a @code{reg}, it is used by the leaf register renumbering code to ensure 486: that each register is only renumbered once. 487: 488: @findex volatil 489: @item volatil 1.1.1.4 root 490: This flag is used in @code{mem}, @code{symbol_ref} and @code{reg} 1.1 root 491: expressions and in insns. In RTL dump files, it is printed as 492: @samp{/v}. 493: 494: @cindex volatile memory references 495: In a @code{mem} expression, it is 1 if the memory reference is volatile. 496: Volatile memory references may not be deleted, reordered or combined. 497: 498: In a @code{symbol_ref} expression, it is used for machine-specific 499: purposes. 500: 501: In a @code{reg} expression, it is 1 if the value is a user-level variable. 502: 0 indicates an internal compiler temporary. 503: 504: In an insn, 1 means the insn has been deleted. 505: 506: @findex in_struct 507: @item in_struct 508: In @code{mem} expressions, it is 1 if the memory datum referred to is 509: all or part of a structure or array; 0 if it is (or might be) a scalar 510: variable. A reference through a C pointer has 0 because the pointer 511: might point to a scalar variable. This information allows the compiler 512: to determine something about possible cases of aliasing. 513: 514: In an insn in the delay slot of a branch, 1 means that this insn is from 515: the target of the branch. 516: 517: During instruction scheduling, in an insn, 1 means that this insn must be 518: scheduled as part of a group together with the previous insn. 519: 520: In @code{reg} expressions, it is 1 if the register has its entire life 1.1.1.5 root 521: contained within the test expression of some loop. 1.1 root 522: 1.1.1.4 root 523: In @code{subreg} expressions, 1 means that the @code{subreg} is accessing 524: an object that has had its mode promoted from a wider mode. 525: 1.1 root 526: In @code{label_ref} expressions, 1 means that the referenced label is 527: outside the innermost loop containing the insn in which the @code{label_ref} 528: was found. 529: 530: In @code{code_label} expressions, it is 1 if the label may never be deleted. 531: This is used for labels which are the target of non-local gotos. 532: 533: In an RTL dump, this flag is represented as @samp{/s}. 534: 535: @findex unchanging 536: @item unchanging 537: In @code{reg} and @code{mem} expressions, 1 means 538: that the value of the expression never changes. 539: 1.1.1.4 root 540: In @code{subreg} expressions, it is 1 if the @code{subreg} references an 541: unsigned object whose mode has been promoted to a wider mode. 542: 1.1 root 543: In an insn, 1 means that this is an annulling branch. 544: 545: In a @code{symbol_ref} expression, 1 means that this symbol addresses 546: something in the per-function constants pool. 547: 548: In a @code{call_insn}, 1 means that this instruction is a call to a 549: const function. 550: 551: In an RTL dump, this flag is represented as @samp{/u}. 552: 553: @findex integrated 554: @item integrated 555: In some kinds of expressions, including insns, this flag means the 556: rtl was produced by procedure integration. 557: 558: In a @code{reg} expression, this flag indicates the register 559: containing the value to be returned by the current function. On 560: machines that pass parameters in registers, the same register number 561: may be used for parameters as well, but this flag is not set on such 562: uses. 563: @end table 564: 565: @node Machine Modes, Constants, Flags, RTL 566: @section Machine Modes 567: @cindex machine modes 568: 569: @findex enum machine_mode 570: A machine mode describes a size of data object and the representation used 571: for it. In the C code, machine modes are represented by an enumeration 572: type, @code{enum machine_mode}, defined in @file{machmode.def}. Each RTL 573: expression has room for a machine mode and so do certain kinds of tree 574: expressions (declarations and types, to be precise). 575: 576: In debugging dumps and machine descriptions, the machine mode of an RTL 577: expression is written after the expression code with a colon to separate 578: them. The letters @samp{mode} which appear at the end of each machine mode 579: name are omitted. For example, @code{(reg:SI 38)} is a @code{reg} 580: expression with machine mode @code{SImode}. If the mode is 581: @code{VOIDmode}, it is not written at all. 582: 583: Here is a table of machine modes. The term ``byte'' below refers to an 584: object of @code{BITS_PER_UNIT} bits (@pxref{Storage Layout}). 585: 586: @table @code 587: @findex QImode 588: @item QImode 589: ``Quarter-Integer'' mode represents a single byte treated as an integer. 590: 591: @findex HImode 592: @item HImode 593: ``Half-Integer'' mode represents a two-byte integer. 594: 595: @findex PSImode 596: @item PSImode 597: ``Partial Single Integer'' mode represents an integer which occupies 598: four bytes but which doesn't really use all four. On some machines, 599: this is the right mode to use for pointers. 600: 601: @findex SImode 602: @item SImode 603: ``Single Integer'' mode represents a four-byte integer. 604: 605: @findex PDImode 606: @item PDImode 607: ``Partial Double Integer'' mode represents an integer which occupies 608: eight bytes but which doesn't really use all eight. On some machines, 609: this is the right mode to use for certain pointers. 610: 611: @findex DImode 612: @item DImode 613: ``Double Integer'' mode represents an eight-byte integer. 614: 615: @findex TImode 616: @item TImode 617: ``Tetra Integer'' (?) mode represents a sixteen-byte integer. 618: 619: @findex SFmode 620: @item SFmode 621: ``Single Floating'' mode represents a single-precision (four byte) floating 622: point number. 623: 624: @findex DFmode 625: @item DFmode 626: ``Double Floating'' mode represents a double-precision (eight byte) floating 627: point number. 628: 629: @findex XFmode 630: @item XFmode 631: ``Extended Floating'' mode represents a triple-precision (twelve byte) 632: floating point number. This mode is used for IEEE extended floating 633: point. 634: 635: @findex TFmode 636: @item TFmode 637: ``Tetra Floating'' mode represents a quadruple-precision (sixteen byte) 638: floating point number. 639: 640: @findex CCmode 641: @item CCmode 642: ``Condition Code'' mode represents the value of a condition code, which 643: is a machine-specific set of bits used to represent the result of a 644: comparison operation. Other machine-specific modes may also be used for 645: the condition code. These modes are not used on machines that use 646: @code{cc0} (see @pxref{Condition Code}). 647: 648: @findex BLKmode 649: @item BLKmode 650: ``Block'' mode represents values that are aggregates to which none of 651: the other modes apply. In RTL, only memory references can have this mode, 652: and only if they appear in string-move or vector instructions. On machines 653: which have no such instructions, @code{BLKmode} will not appear in RTL. 654: 655: @findex VOIDmode 656: @item VOIDmode 657: Void mode means the absence of a mode or an unspecified mode. 658: For example, RTL expressions of code @code{const_int} have mode 659: @code{VOIDmode} because they can be taken to have whatever mode the context 660: requires. In debugging dumps of RTL, @code{VOIDmode} is expressed by 661: the absence of any mode. 662: 663: @findex SCmode 664: @findex DCmode 665: @findex XCmode 666: @findex TCmode 667: @item SCmode, DCmode, XCmode, TCmode 1.1.1.6 root 668: These modes stand for a complex number represented as a pair of floating 669: point values. The floating point values are in @code{SFmode}, 670: @code{DFmode}, @code{XFmode}, and @code{TFmode}, respectively. 671: 672: @findex CQImode 673: @findex CHImode 674: @findex CSImode 675: @findex CDImode 676: @findex CTImode 677: @findex COImode 678: @item CQImode, CHImode, CSImode, CDImode, CTImode, COImode 679: These modes stand for a complex number represented as a pair of integer 680: values. The integer values are in @code{QImode}, @code{HImode}, 681: @code{SImode}, @code{DImode}, @code{TImode}, and @code{OImode}, 682: respectively. 1.1 root 683: @end table 684: 685: The machine description defines @code{Pmode} as a C macro which expands 686: into the machine mode used for addresses. Normally this is the mode 687: whose size is @code{BITS_PER_WORD}, @code{SImode} on 32-bit machines. 688: 689: The only modes which a machine description @i{must} support are 690: @code{QImode}, and the modes corresponding to @code{BITS_PER_WORD}, 691: @code{FLOAT_TYPE_SIZE} and @code{DOUBLE_TYPE_SIZE}. 692: The compiler will attempt to use @code{DImode} for 8-byte structures and 693: unions, but this can be prevented by overriding the definition of 694: @code{MAX_FIXED_MODE_SIZE}. Alternatively, you can have the compiler 695: use @code{TImode} for 16-byte structures and unions. Likewise, you can 696: arrange for the C type @code{short int} to avoid using @code{HImode}. 697: 698: @cindex mode classes 699: Very few explicit references to machine modes remain in the compiler and 700: these few references will soon be removed. Instead, the machine modes 701: are divided into mode classes. These are represented by the enumeration 702: type @code{enum mode_class} defined in @file{machmode.h}. The possible 703: mode classes are: 704: 705: @table @code 706: @findex MODE_INT 707: @item MODE_INT 708: Integer modes. By default these are @code{QImode}, @code{HImode}, 709: @code{SImode}, @code{DImode}, and @code{TImode}. 710: 711: @findex MODE_PARTIAL_INT 712: @item MODE_PARTIAL_INT 713: The ``partial integer'' modes, @code{PSImode} and @code{PDImode}. 714: 715: @findex MODE_FLOAT 716: @item MODE_FLOAT 717: floating point modes. By default these are @code{SFmode}, @code{DFmode}, 718: @code{XFmode} and @code{TFmode}. 719: 720: @findex MODE_COMPLEX_INT 721: @item MODE_COMPLEX_INT 722: Complex integer modes. (These are not currently implemented). 723: 724: @findex MODE_COMPLEX_FLOAT 725: @item MODE_COMPLEX_FLOAT 726: Complex floating point modes. By default these are @code{SCmode}, 727: @code{DCmode}, @code{XCmode}, and @code{TCmode}. 728: 729: @findex MODE_FUNCTION 730: @item MODE_FUNCTION 731: Algol or Pascal function variables including a static chain. 732: (These are not currently implemented). 733: 734: @findex MODE_CC 735: @item MODE_CC 736: Modes representing condition code values. These are @code{CCmode} plus 737: any modes listed in the @code{EXTRA_CC_MODES} macro. @xref{Jump Patterns}, 738: also see @ref{Condition Code}. 739: 740: @findex MODE_RANDOM 741: @item MODE_RANDOM 742: This is a catchall mode class for modes which don't fit into the above 743: classes. Currently @code{VOIDmode} and @code{BLKmode} are in 744: @code{MODE_RANDOM}. 745: @end table 746: 747: Here are some C macros that relate to machine modes: 748: 749: @table @code 750: @findex GET_MODE 751: @item GET_MODE (@var{x}) 752: Returns the machine mode of the RTX @var{x}. 753: 754: @findex PUT_MODE 755: @item PUT_MODE (@var{x}, @var{newmode}) 756: Alters the machine mode of the RTX @var{x} to be @var{newmode}. 757: 758: @findex NUM_MACHINE_MODES 759: @item NUM_MACHINE_MODES 760: Stands for the number of machine modes available on the target 761: machine. This is one greater than the largest numeric value of any 762: machine mode. 763: 764: @findex GET_MODE_NAME 765: @item GET_MODE_NAME (@var{m}) 766: Returns the name of mode @var{m} as a string. 767: 768: @findex GET_MODE_CLASS 769: @item GET_MODE_CLASS (@var{m}) 770: Returns the mode class of mode @var{m}. 771: 772: @findex GET_MODE_WIDER_MODE 773: @item GET_MODE_WIDER_MODE (@var{m}) 1.1.1.5 root 774: Returns the next wider natural mode. For example, the expression 775: @code{GET_MODE_WIDER_MODE (QImode)} returns @code{HImode}. 1.1 root 776: 777: @findex GET_MODE_SIZE 778: @item GET_MODE_SIZE (@var{m}) 779: Returns the size in bytes of a datum of mode @var{m}. 780: 781: @findex GET_MODE_BITSIZE 782: @item GET_MODE_BITSIZE (@var{m}) 783: Returns the size in bits of a datum of mode @var{m}. 784: 785: @findex GET_MODE_MASK 786: @item GET_MODE_MASK (@var{m}) 787: Returns a bitmask containing 1 for all bits in a word that fit within 788: mode @var{m}. This macro can only be used for modes whose bitsize is 789: less than or equal to @code{HOST_BITS_PER_INT}. 790: 791: @findex GET_MODE_ALIGNMENT 792: @item GET_MODE_ALIGNMENT (@var{m)}) 793: Return the required alignment, in bits, for an object of mode @var{m}. 794: 795: @findex GET_MODE_UNIT_SIZE 796: @item GET_MODE_UNIT_SIZE (@var{m}) 797: Returns the size in bytes of the subunits of a datum of mode @var{m}. 798: This is the same as @code{GET_MODE_SIZE} except in the case of complex 799: modes. For them, the unit size is the size of the real or imaginary 800: part. 801: 802: @findex GET_MODE_NUNITS 803: @item GET_MODE_NUNITS (@var{m}) 804: Returns the number of units contained in a mode, i.e., 805: @code{GET_MODE_SIZE} divided by @code{GET_MODE_UNIT_SIZE}. 806: 807: @findex GET_CLASS_NARROWEST_MODE 808: @item GET_CLASS_NARROWEST_MODE (@var{c}) 809: Returns the narrowest mode in mode class @var{c}. 810: @end table 811: 812: @findex byte_mode 813: @findex word_mode 1.1.1.5 root 814: The global variables @code{byte_mode} and @code{word_mode} contain modes 815: whose classes are @code{MODE_INT} and whose bitsizes are either 1.1 root 816: @code{BITS_PER_UNIT} or @code{BITS_PER_WORD}, respectively. On 32-bit 817: machines, these are @code{QImode} and @code{SImode}, respectively. 818: 819: @node Constants, Regs and Memory, Machine Modes, RTL 820: @section Constant Expression Types 821: @cindex RTL constants 822: @cindex RTL constant expression types 823: 824: The simplest RTL expressions are those that represent constant values. 825: 826: @table @code 827: @findex const_int 828: @item (const_int @var{i}) 829: This type of expression represents the integer value @var{i}. @var{i} 830: is customarily accessed with the macro @code{INTVAL} as in 1.1.1.4 root 831: @code{INTVAL (@var{exp})}, which is equivalent to @code{XWINT (@var{exp}, 0)}. 1.1 root 832: 833: @findex const0_rtx 834: @findex const1_rtx 835: @findex const2_rtx 836: @findex constm1_rtx 837: There is only one expression object for the integer value zero; it is 838: the value of the variable @code{const0_rtx}. Likewise, the only 839: expression for integer value one is found in @code{const1_rtx}, the only 840: expression for integer value two is found in @code{const2_rtx}, and the 841: only expression for integer value negative one is found in 842: @code{constm1_rtx}. Any attempt to create an expression of code 843: @code{const_int} and value zero, one, two or negative one will return 844: @code{const0_rtx}, @code{const1_rtx}, @code{const2_rtx} or 845: @code{constm1_rtx} as appropriate.@refill 846: 847: @findex const_true_rtx 848: Similarly, there is only one object for the integer whose value is 849: @code{STORE_FLAG_VALUE}. It is found in @code{const_true_rtx}. If 850: @code{STORE_FLAG_VALUE} is one, @code{const_true_rtx} and 851: @code{const1_rtx} will point to the same object. If 852: @code{STORE_FLAG_VALUE} is -1, @code{const_true_rtx} and 853: @code{constm1_rtx} will point to the same object.@refill 854: 855: @findex const_double 856: @item (const_double:@var{m} @var{addr} @var{i0} @var{i1} @dots{}) 857: Represents either a floating-point constant of mode @var{m} or an 1.1.1.5 root 858: integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT} 1.1 root 859: bits but small enough to fit within twice that number of bits (GNU CC 860: does not provide a mechanism to represent even larger constants). In 861: the latter case, @var{m} will be @code{VOIDmode}. 862: 863: @findex CONST_DOUBLE_MEM 864: @findex CONST_DOUBLE_CHAIN 865: @var{addr} is used to contain the @code{mem} expression that corresponds 866: to the location in memory that at which the constant can be found. If 867: it has not been allocated a memory location, but is on the chain of all 868: @code{const_double} expressions in this compilation (maintained using an 869: undisplayed field), @var{addr} contains @code{const0_rtx}. If it is not 870: on the chain, @var{addr} contains @code{cc0_rtx}. @var{addr} is 871: customarily accessed with the macro @code{CONST_DOUBLE_MEM} and the 872: chain field via @code{CONST_DOUBLE_CHAIN}.@refill 873: 874: @findex CONST_DOUBLE_LOW 1.1.1.2 root 875: If @var{m} is @code{VOIDmode}, the bits of the value are stored in 1.1 root 876: @var{i0} and @var{i1}. @var{i0} is customarily accessed with the macro 877: @code{CONST_DOUBLE_LOW} and @var{i1} with @code{CONST_DOUBLE_HIGH}. 878: 1.1.1.5 root 879: If the constant is floating point (regardless of its precision), then 880: the number of integers used to store the value depends on the size of 881: @code{REAL_VALUE_TYPE} (@pxref{Cross-compilation}). The integers 882: represent a floating point number, but not precisely in the target 883: machine's or host machine's floating point format. To convert them to 884: the precise bit pattern used by the target machine, use the macro 885: @code{REAL_VALUE_TO_TARGET_DOUBLE} and friends (@pxref{Data Output}). 1.1 root 886: 887: @findex CONST0_RTX 888: @findex CONST1_RTX 889: @findex CONST2_RTX 890: The macro @code{CONST0_RTX (@var{mode})} refers to an expression with 1.1.1.5 root 891: value 0 in mode @var{mode}. If mode @var{mode} is of mode class 1.1 root 892: @code{MODE_INT}, it returns @code{const0_rtx}. Otherwise, it returns a 893: @code{CONST_DOUBLE} expression in mode @var{mode}. Similarly, the macro 894: @code{CONST1_RTX (@var{mode})} refers to an expression with value 1 in 895: mode @var{mode} and similarly for @code{CONST2_RTX}. 896: 897: @findex const_string 898: @item (const_string @var{str}) 899: Represents a constant string with value @var{str}. Currently this is 900: used only for insn attributes (@pxref{Insn Attributes}) since constant 901: strings in C are placed in memory. 902: 903: @findex symbol_ref 1.1.1.2 root 904: @item (symbol_ref:@var{mode} @var{symbol}) 1.1 root 905: Represents the value of an assembler label for data. @var{symbol} is 906: a string that describes the name of the assembler label. If it starts 907: with a @samp{*}, the label is the rest of @var{symbol} not including 908: the @samp{*}. Otherwise, the label is @var{symbol}, usually prefixed 909: with @samp{_}. 910: 1.1.1.2 root 911: The @code{symbol_ref} contains a mode, which is usually @code{Pmode}. 912: Usually that is the only mode for which a symbol is directly valid. 913: 1.1 root 914: @findex label_ref 915: @item (label_ref @var{label}) 916: Represents the value of an assembler label for code. It contains one 917: operand, an expression, which must be a @code{code_label} that appears 918: in the instruction sequence to identify the place where the label 919: should go. 920: 921: The reason for using a distinct expression type for code label 922: references is so that jump optimization can distinguish them. 923: 924: @item (const:@var{m} @var{exp}) 925: Represents a constant that is the result of an assembly-time 926: arithmetic computation. The operand, @var{exp}, is an expression that 927: contains only constants (@code{const_int}, @code{symbol_ref} and 928: @code{label_ref} expressions) combined with @code{plus} and 929: @code{minus}. However, not all combinations are valid, since the 930: assembler cannot do arbitrary arithmetic on relocatable symbols. 931: 932: @var{m} should be @code{Pmode}. 933: 934: @findex high 935: @item (high:@var{m} @var{exp}) 936: Represents the high-order bits of @var{exp}, usually a 937: @code{symbol_ref}. The number of bits is machine-dependent and is 938: normally the number of bits specified in an instruction that initializes 939: the high order bits of a register. It is used with @code{lo_sum} to 940: represent the typical two-instruction sequence used in RISC machines to 941: reference a global memory location. 942: 943: @var{m} should be @code{Pmode}. 944: @end table 945: 946: @node Regs and Memory, Arithmetic, Constants, RTL 947: @section Registers and Memory 948: @cindex RTL register expressions 949: @cindex RTL memory expressions 950: 951: Here are the RTL expression types for describing access to machine 952: registers and to main memory. 953: 954: @table @code 955: @findex reg 956: @cindex hard registers 957: @cindex pseudo registers 958: @item (reg:@var{m} @var{n}) 1.1.1.5 root 959: For small values of the integer @var{n} (those that are less than 1.1 root 960: @code{FIRST_PSEUDO_REGISTER}), this stands for a reference to machine 961: register number @var{n}: a @dfn{hard register}. For larger values of 962: @var{n}, it stands for a temporary value or @dfn{pseudo register}. 963: The compiler's strategy is to generate code assuming an unlimited 964: number of such pseudo registers, and later convert them into hard 965: registers or into memory references. 966: 967: @var{m} is the machine mode of the reference. It is necessary because 968: machines can generally refer to each register in more than one mode. 969: For example, a register may contain a full word but there may be 970: instructions to refer to it as a half word or as a single byte, as 971: well as instructions to refer to it as a floating point number of 972: various precisions. 973: 974: Even for a register that the machine can access in only one mode, 975: the mode must always be specified. 976: 977: The symbol @code{FIRST_PSEUDO_REGISTER} is defined by the machine 978: description, since the number of hard registers on the machine is an 979: invariant characteristic of the machine. Note, however, that not 980: all of the machine registers must be general registers. All the 981: machine registers that can be used for storage of data are given 982: hard register numbers, even those that can be used only in certain 983: instructions or can hold only certain types of data. 984: 985: A hard register may be accessed in various modes throughout one 986: function, but each pseudo register is given a natural mode 987: and is accessed only in that mode. When it is necessary to describe 988: an access to a pseudo register using a nonnatural mode, a @code{subreg} 989: expression is used. 990: 991: A @code{reg} expression with a machine mode that specifies more than 992: one word of data may actually stand for several consecutive registers. 993: If in addition the register number specifies a hardware register, then 994: it actually represents several consecutive hardware registers starting 995: with the specified one. 996: 997: Each pseudo register number used in a function's RTL code is 998: represented by a unique @code{reg} expression. 999: 1000: @findex FIRST_VIRTUAL_REGISTER 1001: @findex LAST_VIRTUAL_REGISTER 1002: Some pseudo register numbers, those within the range of 1003: @code{FIRST_VIRTUAL_REGISTER} to @code{LAST_VIRTUAL_REGISTER} only 1004: appear during the RTL generation phase and are eliminated before the 1005: optimization phases. These represent locations in the stack frame that 1006: cannot be determined until RTL generation for the function has been 1007: completed. The following virtual register numbers are defined: 1008: 1009: @table @code 1010: @findex VIRTUAL_INCOMING_ARGS_REGNUM 1011: @item VIRTUAL_INCOMING_ARGS_REGNUM 1012: This points to the first word of the incoming arguments passed on the 1013: stack. Normally these arguments are placed there by the caller, but the 1014: callee may have pushed some arguments that were previously passed in 1015: registers. 1016: 1017: @cindex @code{FIRST_PARM_OFFSET} and virtual registers 1018: @cindex @code{ARG_POINTER_REGNUM} and virtual registers 1019: When RTL generation is complete, this virtual register is replaced 1020: by the sum of the register given by @code{ARG_POINTER_REGNUM} and the 1021: value of @code{FIRST_PARM_OFFSET}. 1022: 1023: @findex VIRTUAL_STACK_VARS_REGNUM 1024: @cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers 1025: @item VIRTUAL_STACK_VARS_REGNUM 1.1.1.6 root 1026: If @code{FRAME_GROWS_DOWNWARD} is defined, this points to immediately 1.1 root 1027: above the first variable on the stack. Otherwise, it points to the 1028: first variable on the stack. 1029: 1030: @cindex @code{STARTING_FRAME_OFFSET} and virtual registers 1031: @cindex @code{FRAME_POINTER_REGNUM} and virtual registers 1.1.1.5 root 1032: @code{VIRTUAL_STACK_VARS_REGNUM} is replaced with the sum of the 1033: register given by @code{FRAME_POINTER_REGNUM} and the value 1034: @code{STARTING_FRAME_OFFSET}. 1.1 root 1035: 1036: @findex VIRTUAL_STACK_DYNAMIC_REGNUM 1037: @item VIRTUAL_STACK_DYNAMIC_REGNUM 1038: This points to the location of dynamically allocated memory on the stack 1039: immediately after the stack pointer has been adjusted by the amount of 1040: memory desired. 1041: 1042: @cindex @code{STACK_DYNAMIC_OFFSET} and virtual registers 1043: @cindex @code{STACK_POINTER_REGNUM} and virtual registers 1.1.1.5 root 1044: This virtual register is replaced by the sum of the register given by 1.1 root 1045: @code{STACK_POINTER_REGNUM} and the value @code{STACK_DYNAMIC_OFFSET}. 1046: 1047: @findex VIRTUAL_OUTGOING_ARGS_REGNUM 1048: @item VIRTUAL_OUTGOING_ARGS_REGNUM 1049: This points to the location in the stack at which outgoing arguments 1050: should be written when the stack is pre-pushed (arguments pushed using 1051: push insns should always use @code{STACK_POINTER_REGNUM}). 1052: 1053: @cindex @code{STACK_POINTER_OFFSET} and virtual registers 1.1.1.5 root 1054: This virtual register is replaced by the sum of the register given by 1.1 root 1055: @code{STACK_POINTER_REGNUM} and the value @code{STACK_POINTER_OFFSET}. 1056: @end table 1057: 1058: @findex subreg 1059: @item (subreg:@var{m} @var{reg} @var{wordnum}) 1060: @code{subreg} expressions are used to refer to a register in a machine 1061: mode other than its natural one, or to refer to one register of 1062: a multi-word @code{reg} that actually refers to several registers. 1063: 1064: Each pseudo-register has a natural mode. If it is necessary to 1065: operate on it in a different mode---for example, to perform a fullword 1066: move instruction on a pseudo-register that contains a single 1067: byte---the pseudo-register must be enclosed in a @code{subreg}. In 1068: such a case, @var{wordnum} is zero. 1069: 1070: Usually @var{m} is at least as narrow as the mode of @var{reg}, in which 1071: case it is restricting consideration to only the bits of @var{reg} that 1.1.1.6 root 1072: are in @var{m}. 1073: 1074: Sometimes @var{m} is wider than the mode of @var{reg}. These 1075: @code{subreg} expressions are often called @dfn{paradoxical}. They are 1076: used in cases where we want to refer to an object in a wider mode but do 1077: not care what value the additional bits have. The reload pass ensures 1078: that paradoxical references are only made to hard registers. 1.1 root 1079: 1080: The other use of @code{subreg} is to extract the individual registers of 1081: a multi-register value. Machine modes such as @code{DImode} and 1082: @code{TImode} can indicate values longer than a word, values which 1083: usually require two or more consecutive registers. To access one of the 1084: registers, use a @code{subreg} with mode @code{SImode} and a 1085: @var{wordnum} that says which register. 1086: 1.1.1.6 root 1087: Storing in a non-paradoxical @code{subreg} has undefined results for 1088: bits belonging to the same word as the @code{subreg}. This laxity makes 1089: it easier to generate efficient code for such instructions. To 1090: represent an instruction that preserves all the bits outside of those in 1091: the @code{subreg}, use @code{strict_low_part} around the @code{subreg}. 1092: 1.1 root 1093: @cindex @code{WORDS_BIG_ENDIAN}, effect on @code{subreg} 1094: The compilation parameter @code{WORDS_BIG_ENDIAN}, if set to 1, says 1095: that word number zero is the most significant part; otherwise, it is 1096: the least significant part. 1097: 1098: @cindex combiner pass 1099: @cindex reload pass 1100: @cindex @code{subreg}, special reload handling 1101: Between the combiner pass and the reload pass, it is possible to have a 1102: paradoxical @code{subreg} which contains a @code{mem} instead of a 1103: @code{reg} as its first operand. After the reload pass, it is also 1104: possible to have a non-paradoxical @code{subreg} which contains a 1105: @code{mem}; this usually occurs when the @code{mem} is a stack slot 1106: which replaced a pseudo register. 1107: 1108: Note that it is not valid to access a @code{DFmode} value in @code{SFmode} 1109: using a @code{subreg}. On some machines the most significant part of a 1110: @code{DFmode} value does not have the same format as a single-precision 1111: floating value. 1112: 1113: It is also not valid to access a single word of a multi-word value in a 1114: hard register when less registers can hold the value than would be 1115: expected from its size. For example, some 32-bit machines have 1116: floating-point registers that can hold an entire @code{DFmode} value. 1117: If register 10 were such a register @code{(subreg:SI (reg:DF 10) 1)} 1118: would be invalid because there is no way to convert that reference to 1119: a single machine register. The reload pass prevents @code{subreg} 1120: expressions such as these from being formed. 1121: 1122: @findex SUBREG_REG 1123: @findex SUBREG_WORD 1124: The first operand of a @code{subreg} expression is customarily accessed 1125: with the @code{SUBREG_REG} macro and the second operand is customarily 1126: accessed with the @code{SUBREG_WORD} macro. 1127: 1128: @findex scratch 1129: @cindex scratch operands 1130: @item (scratch:@var{m}) 1131: This represents a scratch register that will be required for the 1132: execution of a single instruction and not used subsequently. It is 1133: converted into a @code{reg} by either the local register allocator or 1134: the reload pass. 1135: 1136: @code{scratch} is usually present inside a @code{clobber} operation 1137: (@pxref{Side Effects}). 1138: 1139: @findex cc0 1140: @cindex condition code register 1141: @item (cc0) 1142: This refers to the machine's condition code register. It has no 1143: operands and may not have a machine mode. There are two ways to use it: 1144: 1145: @itemize @bullet 1146: @item 1147: To stand for a complete set of condition code flags. This is best on 1148: most machines, where each comparison sets the entire series of flags. 1149: 1150: With this technique, @code{(cc0)} may be validly used in only two 1151: contexts: as the destination of an assignment (in test and compare 1152: instructions) and in comparison operators comparing against zero 1153: (@code{const_int} with value zero; that is to say, @code{const0_rtx}). 1154: 1155: @item 1156: To stand for a single flag that is the result of a single condition. 1157: This is useful on machines that have only a single flag bit, and in 1158: which comparison instructions must specify the condition to test. 1159: 1160: With this technique, @code{(cc0)} may be validly used in only two 1161: contexts: as the destination of an assignment (in test and compare 1162: instructions) where the source is a comparison operator, and as the 1163: first operand of @code{if_then_else} (in a conditional branch). 1164: @end itemize 1165: 1166: @findex cc0_rtx 1167: There is only one expression object of code @code{cc0}; it is the 1168: value of the variable @code{cc0_rtx}. Any attempt to create an 1169: expression of code @code{cc0} will return @code{cc0_rtx}. 1170: 1171: Instructions can set the condition code implicitly. On many machines, 1172: nearly all instructions set the condition code based on the value that 1173: they compute or store. It is not necessary to record these actions 1174: explicitly in the RTL because the machine description includes a 1175: prescription for recognizing the instructions that do so (by means of 1176: the macro @code{NOTICE_UPDATE_CC}). @xref{Condition Code}. Only 1177: instructions whose sole purpose is to set the condition code, and 1178: instructions that use the condition code, need mention @code{(cc0)}. 1179: 1180: On some machines, the condition code register is given a register number 1181: and a @code{reg} is used instead of @code{(cc0)}. This is usually the 1182: preferable approach if only a small subset of instructions modify the 1183: condition code. Other machines store condition codes in general 1184: registers; in such cases a pseudo register should be used. 1185: 1186: Some machines, such as the Sparc and RS/6000, have two sets of 1187: arithmetic instructions, one that sets and one that does not set the 1188: condition code. This is best handled by normally generating the 1189: instruction that does not set the condition code, and making a pattern 1190: that both performs the arithmetic and sets the condition code register 1191: (which would not be @code{(cc0)} in this case). For examples, search 1192: for @samp{addcc} and @samp{andcc} in @file{sparc.md}. 1193: 1194: @findex pc 1195: @item (pc) 1196: @cindex program counter 1197: This represents the machine's program counter. It has no operands and 1198: may not have a machine mode. @code{(pc)} may be validly used only in 1199: certain specific contexts in jump instructions. 1200: 1201: @findex pc_rtx 1202: There is only one expression object of code @code{pc}; it is the value 1203: of the variable @code{pc_rtx}. Any attempt to create an expression of 1204: code @code{pc} will return @code{pc_rtx}. 1205: 1206: All instructions that do not jump alter the program counter implicitly 1207: by incrementing it, but there is no need to mention this in the RTL. 1208: 1209: @findex mem 1210: @item (mem:@var{m} @var{addr}) 1211: This RTX represents a reference to main memory at an address 1212: represented by the expression @var{addr}. @var{m} specifies how large 1213: a unit of memory is accessed. 1214: @end table 1215: 1216: @node Arithmetic, Comparisons, Regs and Memory, RTL 1217: @section RTL Expressions for Arithmetic 1218: @cindex arithmetic, in RTL 1219: @cindex math, in RTL 1220: @cindex RTL expressions for arithmetic 1221: 1222: Unless otherwise specified, all the operands of arithmetic expressions 1223: must be valid for mode @var{m}. An operand is valid for mode @var{m} 1224: if it has mode @var{m}, or if it is a @code{const_int} or 1225: @code{const_double} and @var{m} is a mode of class @code{MODE_INT}. 1226: 1227: For commutative binary operations, constants should be placed in the 1228: second operand. 1229: 1230: @table @code 1231: @findex plus 1232: @cindex RTL addition 1233: @cindex RTL sum 1234: @item (plus:@var{m} @var{x} @var{y}) 1235: Represents the sum of the values represented by @var{x} and @var{y} 1236: carried out in machine mode @var{m}. 1237: 1238: @findex lo_sum 1239: @item (lo_sum:@var{m} @var{x} @var{y}) 1240: Like @code{plus}, except that it represents that sum of @var{x} and the 1241: low-order bits of @var{y}. The number of low order bits is 1242: machine-dependent but is normally the number of bits in a @code{Pmode} 1243: item minus the number of bits set by the @code{high} code 1244: (@pxref{Constants}). 1245: 1246: @var{m} should be @code{Pmode}. 1247: 1248: @findex minus 1249: @cindex RTL subtraction 1250: @cindex RTL difference 1251: @item (minus:@var{m} @var{x} @var{y}) 1252: Like @code{plus} but represents subtraction. 1253: 1254: @findex compare 1255: @cindex RTL comparison 1256: @item (compare:@var{m} @var{x} @var{y}) 1257: Represents the result of subtracting @var{y} from @var{x} for purposes 1258: of comparison. The result is computed without overflow, as if with 1259: infinite precision. 1260: 1261: Of course, machines can't really subtract with infinite precision. 1262: However, they can pretend to do so when only the sign of the 1263: result will be used, which is the case when the result is stored 1264: in the condition code. And that is the only way this kind of expression 1265: may validly be used: as a value to be stored in the condition codes. 1266: 1267: The mode @var{m} is not related to the modes of @var{x} and @var{y}, 1268: but instead is the mode of the condition code value. If @code{(cc0)} 1269: is used, it is @code{VOIDmode}. Otherwise it is some mode in class 1270: @code{MODE_CC}, often @code{CCmode}. @xref{Condition Code}. 1271: 1272: Normally, @var{x} and @var{y} must have the same mode. Otherwise, 1273: @code{compare} is valid only if the mode of @var{x} is in class 1274: @code{MODE_INT} and @var{y} is a @code{const_int} or 1275: @code{const_double} with mode @code{VOIDmode}. The mode of @var{x} 1276: determines what mode the comparison is to be done in; thus it must not 1277: be @code{VOIDmode}. 1278: 1279: If one of the operands is a constant, it should be placed in the 1280: second operand and the comparison code adjusted as appropriate. 1281: 1282: A @code{compare} specifying two @code{VOIDmode} constants is not valid 1283: since there is no way to know in what mode the comparison is to be 1284: performed; the comparison must either be folded during the compilation 1285: or the first operand must be loaded into a register while its mode is 1286: still known. 1287: 1288: @findex neg 1289: @item (neg:@var{m} @var{x}) 1290: Represents the negation (subtraction from zero) of the value represented 1291: by @var{x}, carried out in mode @var{m}. 1292: 1293: @findex mult 1294: @cindex multiplication 1295: @cindex product 1296: @item (mult:@var{m} @var{x} @var{y}) 1297: Represents the signed product of the values represented by @var{x} and 1298: @var{y} carried out in machine mode @var{m}. 1299: 1300: Some machines support a multiplication that generates a product wider 1301: than the operands. Write the pattern for this as 1302: 1303: @example 1304: (mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y})) 1305: @end example 1306: 1307: where @var{m} is wider than the modes of @var{x} and @var{y}, which need 1308: not be the same. 1309: 1310: Write patterns for unsigned widening multiplication similarly using 1311: @code{zero_extend}. 1312: 1313: @findex div 1314: @cindex division 1315: @cindex signed division 1316: @cindex quotient 1317: @item (div:@var{m} @var{x} @var{y}) 1318: Represents the quotient in signed division of @var{x} by @var{y}, 1319: carried out in machine mode @var{m}. If @var{m} is a floating point 1320: mode, it represents the exact quotient; otherwise, the integerized 1321: quotient. 1322: 1323: Some machines have division instructions in which the operands and 1324: quotient widths are not all the same; you should represent 1325: such instructions using @code{truncate} and @code{sign_extend} as in, 1326: 1327: @example 1328: (truncate:@var{m1} (div:@var{m2} @var{x} (sign_extend:@var{m2} @var{y}))) 1329: @end example 1330: 1331: @findex udiv 1332: @cindex unsigned division 1333: @cindex division 1334: @item (udiv:@var{m} @var{x} @var{y}) 1335: Like @code{div} but represents unsigned division. 1336: 1337: @findex mod 1338: @findex umod 1339: @cindex remainder 1340: @cindex division 1341: @item (mod:@var{m} @var{x} @var{y}) 1342: @itemx (umod:@var{m} @var{x} @var{y}) 1343: Like @code{div} and @code{udiv} but represent the remainder instead of 1344: the quotient. 1345: 1346: @findex smin 1347: @findex smax 1348: @cindex signed minimum 1349: @cindex signed maximum 1350: @item (smin:@var{m} @var{x} @var{y}) 1351: @itemx (smax:@var{m} @var{x} @var{y}) 1352: Represents the smaller (for @code{smin}) or larger (for @code{smax}) of 1353: @var{x} and @var{y}, interpreted as signed integers in mode @var{m}. 1354: 1355: @findex umin 1356: @findex umax 1357: @cindex unsigned minimum and maximum 1358: @item (umin:@var{m} @var{x} @var{y}) 1359: @itemx (umax:@var{m} @var{x} @var{y}) 1360: Like @code{smin} and @code{smax}, but the values are interpreted as unsigned 1361: integers. 1362: 1363: @findex not 1364: @cindex complement, bitwise 1365: @cindex bitwise complement 1366: @item (not:@var{m} @var{x}) 1367: Represents the bitwise complement of the value represented by @var{x}, 1368: carried out in mode @var{m}, which must be a fixed-point machine mode. 1369: 1370: @findex and 1371: @cindex logical-and, bitwise 1372: @cindex bitwise logical-and 1373: @item (and:@var{m} @var{x} @var{y}) 1374: Represents the bitwise logical-and of the values represented by 1375: @var{x} and @var{y}, carried out in machine mode @var{m}, which must be 1376: a fixed-point machine mode. 1377: 1378: @findex ior 1379: @cindex inclusive-or, bitwise 1380: @cindex bitwise inclusive-or 1381: @item (ior:@var{m} @var{x} @var{y}) 1382: Represents the bitwise inclusive-or of the values represented by @var{x} 1383: and @var{y}, carried out in machine mode @var{m}, which must be a 1384: fixed-point mode. 1385: 1386: @findex xor 1387: @cindex exclusive-or, bitwise 1388: @cindex bitwise exclusive-or 1389: @item (xor:@var{m} @var{x} @var{y}) 1390: Represents the bitwise exclusive-or of the values represented by @var{x} 1391: and @var{y}, carried out in machine mode @var{m}, which must be a 1392: fixed-point mode. 1393: 1394: @findex ashift 1395: @cindex left shift 1396: @cindex shift 1397: @cindex arithmetic shift 1398: @item (ashift:@var{m} @var{x} @var{c}) 1399: Represents the result of arithmetically shifting @var{x} left by @var{c} 1400: places. @var{x} have mode @var{m}, a fixed-point machine mode. @var{c} 1401: be a fixed-point mode or be a constant with mode @code{VOIDmode}; which 1402: mode is determined by the mode called for in the machine description 1403: entry for the left-shift instruction. For example, on the Vax, the mode 1404: of @var{c} is @code{QImode} regardless of @var{m}. 1405: 1406: @findex lshiftrt 1407: @cindex right shift 1408: @findex ashiftrt 1409: @item (lshiftrt:@var{m} @var{x} @var{c}) 1410: @itemx (ashiftrt:@var{m} @var{x} @var{c}) 1.1.1.7 ! root 1411: Like @code{ashift} but for right shift. Unlike the case for left shift, ! 1412: these two operations are distinct. 1.1 root 1413: 1414: @findex rotate 1415: @cindex rotate 1416: @cindex left rotate 1417: @findex rotatert 1418: @cindex right rotate 1419: @item (rotate:@var{m} @var{x} @var{c}) 1420: @itemx (rotatert:@var{m} @var{x} @var{c}) 1421: Similar but represent left and right rotate. If @var{c} is a constant, 1422: use @code{rotate}. 1423: 1424: @findex abs 1425: @cindex absolute value 1426: @item (abs:@var{m} @var{x}) 1427: Represents the absolute value of @var{x}, computed in mode @var{m}. 1428: 1429: @findex sqrt 1430: @cindex square root 1431: @item (sqrt:@var{m} @var{x}) 1432: Represents the square root of @var{x}, computed in mode @var{m}. 1433: Most often @var{m} will be a floating point mode. 1434: 1435: @findex ffs 1436: @item (ffs:@var{m} @var{x}) 1437: Represents one plus the index of the least significant 1-bit in 1438: @var{x}, represented as an integer of mode @var{m}. (The value is 1439: zero if @var{x} is zero.) The mode of @var{x} need not be @var{m}; 1440: depending on the target machine, various mode combinations may be 1441: valid. 1442: @end table 1443: 1444: @node Comparisons, Bit Fields, Arithmetic, RTL 1445: @section Comparison Operations 1446: @cindex RTL comparison operations 1447: 1448: Comparison operators test a relation on two operands and are considered 1449: to represent a machine-dependent nonzero value described by, but not 1450: necessarily equal to, @code{STORE_FLAG_VALUE} (@pxref{Misc}) 1451: if the relation holds, or zero if it does not. The mode of the 1452: comparison operation is independent of the mode of the data being 1453: compared. If the comparison operation is being tested (e.g., the first 1454: operand of an @code{if_then_else}), the mode must be @code{VOIDmode}. 1455: If the comparison operation is producing data to be stored in some 1456: variable, the mode must be in class @code{MODE_INT}. All comparison 1457: operations producing data must use the same mode, which is 1458: machine-specific. 1459: 1460: @cindex condition codes 1461: There are two ways that comparison operations may be used. The 1462: comparison operators may be used to compare the condition codes 1463: @code{(cc0)} against zero, as in @code{(eq (cc0) (const_int 0))}. Such 1464: a construct actually refers to the result of the preceding instruction 1465: in which the condition codes were set. The instructing setting the 1466: condition code must be adjacent to the instruction using the condition 1467: code; only @code{note} insns may separate them. 1468: 1469: Alternatively, a comparison operation may directly compare two data 1470: objects. The mode of the comparison is determined by the operands; they 1471: must both be valid for a common machine mode. A comparison with both 1472: operands constant would be invalid as the machine mode could not be 1473: deduced from it, but such a comparison should never exist in RTL due to 1474: constant folding. 1475: 1476: In the example above, if @code{(cc0)} were last set to 1477: @code{(compare @var{x} @var{y})}, the comparison operation is 1478: identical to @code{(eq @var{x} @var{y})}. Usually only one style 1479: of comparisons is supported on a particular machine, but the combine 1480: pass will try to merge the operations to produce the @code{eq} shown 1481: in case it exists in the context of the particular insn involved. 1482: 1483: Inequality comparisons come in two flavors, signed and unsigned. Thus, 1484: there are distinct expression codes @code{gt} and @code{gtu} for signed and 1485: unsigned greater-than. These can produce different results for the same 1486: pair of integer values: for example, 1 is signed greater-than -1 but not 1487: unsigned greater-than, because -1 when regarded as unsigned is actually 1488: @code{0xffffffff} which is greater than 1. 1489: 1490: The signed comparisons are also used for floating point values. Floating 1491: point comparisons are distinguished by the machine modes of the operands. 1492: 1493: @table @code 1494: @findex eq 1495: @cindex equal 1496: @item (eq:@var{m} @var{x} @var{y}) 1497: 1 if the values represented by @var{x} and @var{y} are equal, 1498: otherwise 0. 1499: 1500: @findex ne 1501: @cindex not equal 1502: @item (ne:@var{m} @var{x} @var{y}) 1503: 1 if the values represented by @var{x} and @var{y} are not equal, 1504: otherwise 0. 1505: 1506: @findex gt 1507: @cindex greater than 1508: @item (gt:@var{m} @var{x} @var{y}) 1509: 1 if the @var{x} is greater than @var{y}. If they are fixed-point, 1510: the comparison is done in a signed sense. 1511: 1512: @findex gtu 1513: @cindex greater than 1514: @cindex unsigned greater than 1515: @item (gtu:@var{m} @var{x} @var{y}) 1516: Like @code{gt} but does unsigned comparison, on fixed-point numbers only. 1517: 1518: @findex lt 1519: @cindex less than 1520: @findex ltu 1521: @cindex unsigned less than 1522: @item (lt:@var{m} @var{x} @var{y}) 1523: @itemx (ltu:@var{m} @var{x} @var{y}) 1524: Like @code{gt} and @code{gtu} but test for ``less than''. 1525: 1526: @findex ge 1527: @cindex greater than 1528: @findex geu 1529: @cindex unsigned greater than 1530: @item (ge:@var{m} @var{x} @var{y}) 1531: @itemx (geu:@var{m} @var{x} @var{y}) 1532: Like @code{gt} and @code{gtu} but test for ``greater than or equal''. 1533: 1534: @findex le 1535: @cindex less than or equal 1536: @findex leu 1537: @cindex unsigned less than 1538: @item (le:@var{m} @var{x} @var{y}) 1539: @itemx (leu:@var{m} @var{x} @var{y}) 1540: Like @code{gt} and @code{gtu} but test for ``less than or equal''. 1541: 1542: @findex if_then_else 1543: @item (if_then_else @var{cond} @var{then} @var{else}) 1544: This is not a comparison operation but is listed here because it is 1545: always used in conjunction with a comparison operation. To be 1546: precise, @var{cond} is a comparison expression. This expression 1547: represents a choice, according to @var{cond}, between the value 1548: represented by @var{then} and the one represented by @var{else}. 1549: 1550: On most machines, @code{if_then_else} expressions are valid only 1551: to express conditional jumps. 1552: 1553: @findex cond 1554: @item (cond [@var{test1} @var{value1} @var{test2} @var{value2} @dots{}] @var{default}) 1555: Similar to @code{if_then_else}, but more general. Each of @var{test1}, 1556: @var{test2}, @dots{} is performed in turn. The result of this expression is 1557: the @var{value} corresponding to the first non-zero test, or @var{default} if 1558: none of the tests are non-zero expressions. 1559: 1560: This is currently not valid for instruction patterns and is supported only 1561: for insn attributes. @xref{Insn Attributes}. 1562: @end table 1563: 1564: @node Bit Fields, Conversions, Comparisons, RTL 1565: @section Bit Fields 1566: @cindex bit fields 1567: 1.1.1.5 root 1568: Special expression codes exist to represent bitfield instructions. 1.1 root 1569: These types of expressions are lvalues in RTL; they may appear 1570: on the left side of an assignment, indicating insertion of a value 1571: into the specified bit field. 1572: 1573: @table @code 1574: @findex sign_extract 1575: @cindex @code{BITS_BIG_ENDIAN}, effect on @code{sign_extract} 1576: @item (sign_extract:@var{m} @var{loc} @var{size} @var{pos}) 1577: This represents a reference to a sign-extended bit field contained or 1578: starting in @var{loc} (a memory or register reference). The bit field 1579: is @var{size} bits wide and starts at bit @var{pos}. The compilation 1580: option @code{BITS_BIG_ENDIAN} says which end of the memory unit 1581: @var{pos} counts from. 1582: 1583: If @var{loc} is in memory, its mode must be a single-byte integer mode. 1584: If @var{loc} is in a register, the mode to use is specified by the 1585: operand of the @code{insv} or @code{extv} pattern 1586: (@pxref{Standard Names}) and is usually a full-word integer mode. 1587: 1588: The mode of @var{pos} is machine-specific and is also specified 1589: in the @code{insv} or @code{extv} pattern. 1590: 1591: The mode @var{m} is the same as the mode that would be used for 1592: @var{loc} if it were a register. 1593: 1594: @findex zero_extract 1595: @item (zero_extract:@var{m} @var{loc} @var{size} @var{pos}) 1596: Like @code{sign_extract} but refers to an unsigned or zero-extended 1597: bit field. The same sequence of bits are extracted, but they 1598: are filled to an entire word with zeros instead of by sign-extension. 1599: @end table 1600: 1601: @node Conversions, RTL Declarations, Bit Fields, RTL 1602: @section Conversions 1603: @cindex conversions 1604: @cindex machine mode conversions 1605: 1606: All conversions between machine modes must be represented by 1607: explicit conversion operations. For example, an expression 1608: which is the sum of a byte and a full word cannot be written as 1609: @code{(plus:SI (reg:QI 34) (reg:SI 80))} because the @code{plus} 1610: operation requires two operands of the same machine mode. 1611: Therefore, the byte-sized operand is enclosed in a conversion 1612: operation, as in 1613: 1614: @example 1615: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 1616: @end example 1617: 1618: The conversion operation is not a mere placeholder, because there 1619: may be more than one way of converting from a given starting mode 1620: to the desired final mode. The conversion operation code says how 1621: to do it. 1622: 1623: For all conversion operations, @var{x} must not be @code{VOIDmode} 1624: because the mode in which to do the conversion would not be known. 1625: The conversion must either be done at compile-time or @var{x} 1626: must be placed into a register. 1627: 1628: @table @code 1629: @findex sign_extend 1630: @item (sign_extend:@var{m} @var{x}) 1631: Represents the result of sign-extending the value @var{x} 1632: to machine mode @var{m}. @var{m} must be a fixed-point mode 1633: and @var{x} a fixed-point value of a mode narrower than @var{m}. 1634: 1635: @findex zero_extend 1636: @item (zero_extend:@var{m} @var{x}) 1637: Represents the result of zero-extending the value @var{x} 1638: to machine mode @var{m}. @var{m} must be a fixed-point mode 1639: and @var{x} a fixed-point value of a mode narrower than @var{m}. 1640: 1641: @findex float_extend 1642: @item (float_extend:@var{m} @var{x}) 1643: Represents the result of extending the value @var{x} 1644: to machine mode @var{m}. @var{m} must be a floating point mode 1645: and @var{x} a floating point value of a mode narrower than @var{m}. 1646: 1647: @findex truncate 1648: @item (truncate:@var{m} @var{x}) 1649: Represents the result of truncating the value @var{x} 1650: to machine mode @var{m}. @var{m} must be a fixed-point mode 1651: and @var{x} a fixed-point value of a mode wider than @var{m}. 1652: 1653: @findex float_truncate 1654: @item (float_truncate:@var{m} @var{x}) 1655: Represents the result of truncating the value @var{x} 1656: to machine mode @var{m}. @var{m} must be a floating point mode 1657: and @var{x} a floating point value of a mode wider than @var{m}. 1658: 1659: @findex float 1660: @item (float:@var{m} @var{x}) 1661: Represents the result of converting fixed point value @var{x}, 1662: regarded as signed, to floating point mode @var{m}. 1663: 1664: @findex unsigned_float 1665: @item (unsigned_float:@var{m} @var{x}) 1666: Represents the result of converting fixed point value @var{x}, 1667: regarded as unsigned, to floating point mode @var{m}. 1668: 1669: @findex fix 1670: @item (fix:@var{m} @var{x}) 1671: When @var{m} is a fixed point mode, represents the result of 1672: converting floating point value @var{x} to mode @var{m}, regarded as 1673: signed. How rounding is done is not specified, so this operation may 1674: be used validly in compiling C code only for integer-valued operands. 1675: 1676: @findex unsigned_fix 1677: @item (unsigned_fix:@var{m} @var{x}) 1678: Represents the result of converting floating point value @var{x} to 1679: fixed point mode @var{m}, regarded as unsigned. How rounding is done 1680: is not specified. 1681: 1682: @findex fix 1683: @item (fix:@var{m} @var{x}) 1684: When @var{m} is a floating point mode, represents the result of 1685: converting floating point value @var{x} (valid for mode @var{m}) to an 1686: integer, still represented in floating point mode @var{m}, by rounding 1687: towards zero. 1688: @end table 1689: 1690: @node RTL Declarations, Side Effects, Conversions, RTL 1691: @section Declarations 1692: @cindex RTL declarations 1693: @cindex declarations, RTL 1694: 1695: Declaration expression codes do not represent arithmetic operations 1696: but rather state assertions about their operands. 1697: 1698: @table @code 1699: @findex strict_low_part 1700: @cindex @code{subreg}, in @code{strict_low_part} 1701: @item (strict_low_part (subreg:@var{m} (reg:@var{n} @var{r}) 0)) 1.1.1.4 root 1702: This expression code is used in only one context: as the destination operand of a 1.1 root 1703: @code{set} expression. In addition, the operand of this expression 1704: must be a non-paradoxical @code{subreg} expression. 1705: 1706: The presence of @code{strict_low_part} says that the part of the 1707: register which is meaningful in mode @var{n}, but is not part of 1708: mode @var{m}, is not to be altered. Normally, an assignment to such 1709: a subreg is allowed to have undefined effects on the rest of the 1710: register when @var{m} is less than a word. 1711: @end table 1712: 1713: @node Side Effects, Incdec, RTL Declarations, RTL 1714: @section Side Effect Expressions 1715: @cindex RTL side effect expressions 1716: 1717: The expression codes described so far represent values, not actions. 1718: But machine instructions never produce values; they are meaningful 1719: only for their side effects on the state of the machine. Special 1720: expression codes are used to represent side effects. 1721: 1722: The body of an instruction is always one of these side effect codes; 1723: the codes described above, which represent values, appear only as 1724: the operands of these. 1725: 1726: @table @code 1727: @findex set 1728: @item (set @var{lval} @var{x}) 1729: Represents the action of storing the value of @var{x} into the place 1730: represented by @var{lval}. @var{lval} must be an expression 1731: representing a place that can be stored in: @code{reg} (or 1732: @code{subreg} or @code{strict_low_part}), @code{mem}, @code{pc} or 1733: @code{cc0}.@refill 1734: 1735: If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a 1736: machine mode; then @var{x} must be valid for that mode.@refill 1737: 1738: If @var{lval} is a @code{reg} whose machine mode is less than the full 1739: width of the register, then it means that the part of the register 1740: specified by the machine mode is given the specified value and the 1741: rest of the register receives an undefined value. Likewise, if 1742: @var{lval} is a @code{subreg} whose machine mode is narrower than 1743: the mode of the register, the rest of the register can be changed in 1744: an undefined way. 1745: 1746: If @var{lval} is a @code{strict_low_part} of a @code{subreg}, then the 1747: part of the register specified by the machine mode of the 1748: @code{subreg} is given the value @var{x} and the rest of the register 1749: is not changed.@refill 1750: 1751: If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may 1752: be either a @code{compare} expression or a value that may have any mode. 1753: The latter case represents a ``test'' instruction. The expression 1754: @code{(set (cc0) (reg:@var{m} @var{n}))} is equivalent to 1755: @code{(set (cc0) (compare (reg:@var{m} @var{n}) (const_int 0)))}. 1756: Use the former expression to save space during the compilation. 1757: 1758: @cindex jump instructions and @code{set} 1759: @cindex @code{if_then_else} usage 1760: If @var{lval} is @code{(pc)}, we have a jump instruction, and the 1761: possibilities for @var{x} are very limited. It may be a 1762: @code{label_ref} expression (unconditional jump). It may be an 1763: @code{if_then_else} (conditional jump), in which case either the 1764: second or the third operand must be @code{(pc)} (for the case which 1765: does not jump) and the other of the two must be a @code{label_ref} 1766: (for the case which does jump). @var{x} may also be a @code{mem} or 1767: @code{(plus:SI (pc) @var{y})}, where @var{y} may be a @code{reg} or a 1768: @code{mem}; these unusual patterns are used to represent jumps through 1769: branch tables.@refill 1770: 1771: If @var{lval} is neither @code{(cc0)} nor @code{(pc)}, the mode of 1772: @var{lval} must not be @code{VOIDmode} and the mode of @var{x} must be 1773: valid for the mode of @var{lval}. 1774: 1775: @findex SET_DEST 1776: @findex SET_SRC 1777: @var{lval} is customarily accessed with the @code{SET_DEST} macro and 1778: @var{x} with the @code{SET_SRC} macro. 1779: 1780: @findex return 1781: @item (return) 1782: As the sole expression in a pattern, represents a return from the 1783: current function, on machines where this can be done with one 1784: instruction, such as Vaxes. On machines where a multi-instruction 1785: ``epilogue'' must be executed in order to return from the function, 1786: returning is done by jumping to a label which precedes the epilogue, and 1787: the @code{return} expression code is never used. 1788: 1789: Inside an @code{if_then_else} expression, represents the value to be 1790: placed in @code{pc} to return to the caller. 1791: 1792: Note that an insn pattern of @code{(return)} is logically equivalent to 1793: @code{(set (pc) (return))}, but the latter form is never used. 1794: 1795: @findex call 1796: @item (call @var{function} @var{nargs}) 1797: Represents a function call. @var{function} is a @code{mem} expression 1798: whose address is the address of the function to be called. 1799: @var{nargs} is an expression which can be used for two purposes: on 1800: some machines it represents the number of bytes of stack argument; on 1801: others, it represents the number of argument registers. 1802: 1803: Each machine has a standard machine mode which @var{function} must 1804: have. The machine description defines macro @code{FUNCTION_MODE} to 1805: expand into the requisite mode name. The purpose of this mode is to 1806: specify what kind of addressing is allowed, on machines where the 1807: allowed kinds of addressing depend on the machine mode being 1808: addressed. 1809: 1810: @findex clobber 1811: @item (clobber @var{x}) 1812: Represents the storing or possible storing of an unpredictable, 1813: undescribed value into @var{x}, which must be a @code{reg}, 1814: @code{scratch} or @code{mem} expression. 1815: 1816: One place this is used is in string instructions that store standard 1817: values into particular hard registers. It may not be worth the 1818: trouble to describe the values that are stored, but it is essential to 1819: inform the compiler that the registers will be altered, lest it 1820: attempt to keep data in them across the string instruction. 1821: 1822: If @var{x} is @code{(mem:BLK (const_int 0))}, it means that all memory 1823: locations must be presumed clobbered. 1824: 1825: Note that the machine description classifies certain hard registers as 1826: ``call-clobbered''. All function call instructions are assumed by 1827: default to clobber these registers, so there is no need to use 1828: @code{clobber} expressions to indicate this fact. Also, each function 1829: call is assumed to have the potential to alter any memory location, 1830: unless the function is declared @code{const}. 1831: 1832: If the last group of expressions in a @code{parallel} are each a 1833: @code{clobber} expression whose arguments are @code{reg} or 1834: @code{match_scratch} (@pxref{RTL Template}) expressions, the combiner 1835: phase can add the appropriate @code{clobber} expressions to an insn it 1836: has constructed when doing so will cause a pattern to be matched. 1837: 1838: This feature can be used, for example, on a machine that whose multiply 1839: and add instructions don't use an MQ register but which has an 1840: add-accumulate instruction that does clobber the MQ register. Similarly, 1841: a combined instruction might require a temporary register while the 1842: constituent instructions might not. 1843: 1844: When a @code{clobber} expression for a register appears inside a 1845: @code{parallel} with other side effects, the register allocator 1846: guarantees that the register is unoccupied both before and after that 1847: insn. However, the reload phase may allocate a register used for one of 1848: the inputs unless the @samp{&} constraint is specified for the selected 1849: alternative (@pxref{Modifiers}). You can clobber either a specific hard 1850: register, a pseudo register, or a @code{scratch} expression; in the 1851: latter two cases, GNU CC will allocate a hard register that is available 1852: there for use as a temporary. 1853: 1854: For instructions that require a temporary register, you should use 1855: @code{scratch} instead of a pseudo-register because this will allow the 1856: combiner phase to add the @code{clobber} when required. You do this by 1857: coding (@code{clobber} (@code{match_scratch} @dots{})). If you do 1858: clobber a pseudo register, use one which appears nowhere else---generate 1859: a new one each time. Otherwise, you may confuse CSE. 1860: 1861: There is one other known use for clobbering a pseudo register in a 1862: @code{parallel}: when one of the input operands of the insn is also 1863: clobbered by the insn. In this case, using the same pseudo register in 1864: the clobber and elsewhere in the insn produces the expected results. 1865: 1866: @findex use 1867: @item (use @var{x}) 1868: Represents the use of the value of @var{x}. It indicates that the 1869: value in @var{x} at this point in the program is needed, even though 1870: it may not be apparent why this is so. Therefore, the compiler will 1871: not attempt to delete previous instructions whose only effect is to 1872: store a value in @var{x}. @var{x} must be a @code{reg} expression. 1873: 1874: During the delayed branch scheduling phase, @var{x} may be an insn. 1875: This indicates that @var{x} previously was located at this place in the 1876: code and its data dependencies need to be taken into account. These 1877: @code{use} insns will be deleted before the delayed branch scheduling 1878: phase exits. 1879: 1880: @findex parallel 1881: @item (parallel [@var{x0} @var{x1} @dots{}]) 1882: Represents several side effects performed in parallel. The square 1883: brackets stand for a vector; the operand of @code{parallel} is a 1884: vector of expressions. @var{x0}, @var{x1} and so on are individual 1885: side effect expressions---expressions of code @code{set}, @code{call}, 1886: @code{return}, @code{clobber} or @code{use}.@refill 1887: 1888: ``In parallel'' means that first all the values used in the individual 1889: side-effects are computed, and second all the actual side-effects are 1890: performed. For example, 1891: 1892: @example 1893: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 1894: (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 1895: @end example 1896: 1897: @noindent 1898: says unambiguously that the values of hard register 1 and the memory 1899: location addressed by it are interchanged. In both places where 1900: @code{(reg:SI 1)} appears as a memory address it refers to the value 1901: in register 1 @emph{before} the execution of the insn. 1902: 1903: It follows that it is @emph{incorrect} to use @code{parallel} and 1904: expect the result of one @code{set} to be available for the next one. 1905: For example, people sometimes attempt to represent a jump-if-zero 1906: instruction this way: 1907: 1908: @example 1909: (parallel [(set (cc0) (reg:SI 34)) 1910: (set (pc) (if_then_else 1911: (eq (cc0) (const_int 0)) 1912: (label_ref @dots{}) 1913: (pc)))]) 1914: @end example 1915: 1916: @noindent 1917: But this is incorrect, because it says that the jump condition depends 1918: on the condition code value @emph{before} this instruction, not on the 1919: new value that is set by this instruction. 1920: 1921: @cindex peephole optimization, RTL representation 1922: Peephole optimization, which takes place together with final assembly 1923: code output, can produce insns whose patterns consist of a @code{parallel} 1924: whose elements are the operands needed to output the resulting 1925: assembler code---often @code{reg}, @code{mem} or constant expressions. 1926: This would not be well-formed RTL at any other stage in compilation, 1927: but it is ok then because no further optimization remains to be done. 1928: However, the definition of the macro @code{NOTICE_UPDATE_CC}, if 1929: any, must deal with such insns if you define any peephole optimizations. 1930: 1931: @findex sequence 1932: @item (sequence [@var{insns} @dots{}]) 1933: Represents a sequence of insns. Each of the @var{insns} that appears 1934: in the vector is suitable for appearing in the chain of insns, so it 1935: must be an @code{insn}, @code{jump_insn}, @code{call_insn}, 1936: @code{code_label}, @code{barrier} or @code{note}. 1937: 1938: A @code{sequence} RTX is never placed in an actual insn during RTL 1939: generation. It represents the sequence of insns that result from a 1940: @code{define_expand} @emph{before} those insns are passed to 1941: @code{emit_insn} to insert them in the chain of insns. When actually 1942: inserted, the individual sub-insns are separated out and the 1943: @code{sequence} is forgotten. 1944: 1945: After delay-slot scheduling is completed, an insn and all the insns that 1946: reside in its delay slots are grouped together into a @code{sequence}. 1947: The insn requiring the delay slot is the first insn in the vector; 1948: subsequent insns are to be placed in the delay slot. 1949: 1950: @code{INSN_ANNULLED_BRANCH_P} is set on an insn in a delay slot to 1951: indicate that a branch insn should be used that will conditionally annul 1952: the effect of the insns in the delay slots. In such a case, 1953: @code{INSN_FROM_TARGET_P} indicates that the insn is from the target of 1954: the branch and should be executed only if the branch is taken; otherwise 1955: the insn should be executed only if the branch is not taken. 1956: @xref{Delay Slots}. 1957: @end table 1958: 1959: These expression codes appear in place of a side effect, as the body of 1960: an insn, though strictly speaking they do not always describe side 1961: effects as such: 1962: 1963: @table @code 1964: @findex asm_input 1965: @item (asm_input @var{s}) 1966: Represents literal assembler code as described by the string @var{s}. 1967: 1968: @findex unspec 1969: @findex unspec_volatile 1970: @item (unspec [@var{operands} @dots{}] @var{index}) 1.1.1.2 root 1971: @itemx (unspec_volatile [@var{operands} @dots{}] @var{index}) 1.1 root 1972: Represents a machine-specific operation on @var{operands}. @var{index} 1.1.1.2 root 1973: selects between multiple machine-specific operations. 1.1 root 1974: @code{unspec_volatile} is used for volatile operations and operations 1975: that may trap; @code{unspec} is used for other operations. 1976: 1.1.1.2 root 1977: These codes may appear inside a @code{pattern} of an 1.1 root 1978: insn, inside a @code{parallel}, or inside an expression. 1979: 1980: @findex addr_vec 1981: @item (addr_vec:@var{m} [@var{lr0} @var{lr1} @dots{}]) 1982: Represents a table of jump addresses. The vector elements @var{lr0}, 1983: etc., are @code{label_ref} expressions. The mode @var{m} specifies 1984: how much space is given to each address; normally @var{m} would be 1985: @code{Pmode}. 1986: 1987: @findex addr_diff_vec 1988: @item (addr_diff_vec:@var{m} @var{base} [@var{lr0} @var{lr1} @dots{}]) 1989: Represents a table of jump addresses expressed as offsets from 1990: @var{base}. The vector elements @var{lr0}, etc., are @code{label_ref} 1991: expressions and so is @var{base}. The mode @var{m} specifies how much 1992: space is given to each address-difference.@refill 1993: @end table 1994: 1995: @node Incdec, Assembler, Side Effects, RTL 1996: @section Embedded Side-Effects on Addresses 1997: @cindex RTL preincrement 1998: @cindex RTL postincrement 1999: @cindex RTL predecrement 2000: @cindex RTL postdecrement 2001: 2002: Four special side-effect expression codes appear as memory addresses. 2003: 2004: @table @code 2005: @findex pre_dec 2006: @item (pre_dec:@var{m} @var{x}) 2007: Represents the side effect of decrementing @var{x} by a standard 2008: amount and represents also the value that @var{x} has after being 2009: decremented. @var{x} must be a @code{reg} or @code{mem}, but most 2010: machines allow only a @code{reg}. @var{m} must be the machine mode 2011: for pointers on the machine in use. The amount @var{x} is decremented 2012: by is the length in bytes of the machine mode of the containing memory 2013: reference of which this expression serves as the address. Here is an 2014: example of its use:@refill 2015: 2016: @example 2017: (mem:DF (pre_dec:SI (reg:SI 39))) 2018: @end example 2019: 2020: @noindent 2021: This says to decrement pseudo register 39 by the length of a @code{DFmode} 2022: value and use the result to address a @code{DFmode} value. 2023: 2024: @findex pre_inc 2025: @item (pre_inc:@var{m} @var{x}) 2026: Similar, but specifies incrementing @var{x} instead of decrementing it. 2027: 2028: @findex post_dec 2029: @item (post_dec:@var{m} @var{x}) 2030: Represents the same side effect as @code{pre_dec} but a different 2031: value. The value represented here is the value @var{x} has @i{before} 2032: being decremented. 2033: 2034: @findex post_inc 2035: @item (post_inc:@var{m} @var{x}) 2036: Similar, but specifies incrementing @var{x} instead of decrementing it. 2037: @end table 2038: 2039: These embedded side effect expressions must be used with care. Instruction 2040: patterns may not use them. Until the @samp{flow} pass of the compiler, 2041: they may occur only to represent pushes onto the stack. The @samp{flow} 2042: pass finds cases where registers are incremented or decremented in one 2043: instruction and used as an address shortly before or after; these cases are 2044: then transformed to use pre- or post-increment or -decrement. 2045: 2046: If a register used as the operand of these expressions is used in 2047: another address in an insn, the original value of the register is used. 2048: Uses of the register outside of an address are not permitted within the 2049: same insn as a use in an embedded side effect expression because such 2050: insns behave differently on different machines and hence must be treated 2051: as ambiguous and disallowed. 2052: 2053: An instruction that can be represented with an embedded side effect 2054: could also be represented using @code{parallel} containing an additional 2055: @code{set} to describe how the address register is altered. This is not 2056: done because machines that allow these operations at all typically 2057: allow them wherever a memory address is called for. Describing them as 2058: additional parallel stores would require doubling the number of entries 2059: in the machine description. 2060: 1.1.1.5 root 2061: @node Assembler, Insns, Incdec, RTL 1.1 root 2062: @section Assembler Instructions as Expressions 2063: @cindex assembler instructions in RTL 2064: 2065: @cindex @code{asm_operands}, usage 2066: The RTX code @code{asm_operands} represents a value produced by a 2067: user-specified assembler instruction. It is used to represent 2068: an @code{asm} statement with arguments. An @code{asm} statement with 2069: a single output operand, like this: 2070: 1.1.1.5 root 2071: @smallexample 1.1 root 2072: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 1.1.1.5 root 2073: @end smallexample 1.1 root 2074: 2075: @noindent 2076: is represented using a single @code{asm_operands} RTX which represents 2077: the value that is stored in @code{outputvar}: 2078: 1.1.1.5 root 2079: @smallexample 1.1 root 2080: (set @var{rtx-for-outputvar} 2081: (asm_operands "foo %1,%2,%0" "a" 0 2082: [@var{rtx-for-addition-result} @var{rtx-for-*z}] 2083: [(asm_input:@var{m1} "g") 2084: (asm_input:@var{m2} "di")])) 1.1.1.5 root 2085: @end smallexample 1.1 root 2086: 2087: @noindent 2088: Here the operands of the @code{asm_operands} RTX are the assembler 2089: template string, the output-operand's constraint, the index-number of the 2090: output operand among the output operands specified, a vector of input 2091: operand RTX's, and a vector of input-operand modes and constraints. The 2092: mode @var{m1} is the mode of the sum @code{x+y}; @var{m2} is that of 2093: @code{*z}. 2094: 2095: When an @code{asm} statement has multiple output values, its insn has 2096: several such @code{set} RTX's inside of a @code{parallel}. Each @code{set} 2097: contains a @code{asm_operands}; all of these share the same assembler 2098: template and vectors, but each contains the constraint for the respective 2099: output operand. They are also distinguished by the output-operand index 2100: number, which is 0, 1, @dots{} for successive output operands. 2101: 2102: @node Insns, Calls, Assembler, RTL 2103: @section Insns 2104: @cindex insns 2105: 2106: The RTL representation of the code for a function is a doubly-linked 2107: chain of objects called @dfn{insns}. Insns are expressions with 2108: special codes that are used for no other purpose. Some insns are 2109: actual instructions; others represent dispatch tables for @code{switch} 2110: statements; others represent labels to jump to or various sorts of 2111: declarative information. 2112: 2113: In addition to its own specific data, each insn must have a unique 2114: id-number that distinguishes it from all other insns in the current 2115: function (after delayed branch scheduling, copies of an insn with the 2116: same id-number may be present in multiple places in a function, but 2117: these copies will always be identical and will only appear inside a 2118: @code{sequence}), and chain pointers to the preceding and following 2119: insns. These three fields occupy the same position in every insn, 2120: independent of the expression code of the insn. They could be accessed 2121: with @code{XEXP} and @code{XINT}, but instead three special macros are 2122: always used: 2123: 2124: @table @code 2125: @findex INSN_UID 2126: @item INSN_UID (@var{i}) 2127: Accesses the unique id of insn @var{i}. 2128: 2129: @findex PREV_INSN 2130: @item PREV_INSN (@var{i}) 2131: Accesses the chain pointer to the insn preceding @var{i}. 2132: If @var{i} is the first insn, this is a null pointer. 2133: 2134: @findex NEXT_INSN 2135: @item NEXT_INSN (@var{i}) 2136: Accesses the chain pointer to the insn following @var{i}. 2137: If @var{i} is the last insn, this is a null pointer. 2138: @end table 2139: 2140: @findex get_insns 2141: @findex get_last_insn 2142: The first insn in the chain is obtained by calling @code{get_insns}; the 2143: last insn is the result of calling @code{get_last_insn}. Within the 2144: chain delimited by these insns, the @code{NEXT_INSN} and 2145: @code{PREV_INSN} pointers must always correspond: if @var{insn} is not 2146: the first insn, 2147: 2148: @example 2149: NEXT_INSN (PREV_INSN (@var{insn})) == @var{insn} 2150: @end example 2151: 2152: @noindent 2153: is always true and if @var{insn} is not the last insn, 2154: 2155: @example 2156: PREV_INSN (NEXT_INSN (@var{insn})) == @var{insn} 2157: @end example 2158: 2159: @noindent 2160: is always true. 2161: 2162: After delay slot scheduling, some of the insns in the chain might be 2163: @code{sequence} expressions, which contain a vector of insns. The value 2164: of @code{NEXT_INSN} in all but the last of these insns is the next insn 2165: in the vector; the value of @code{NEXT_INSN} of the last insn in the vector 2166: is the same as the value of @code{NEXT_INSN} for the @code{sequence} in 2167: which it is contained. Similar rules apply for @code{PREV_INSN}. 2168: 2169: This means that the above invariants are not necessarily true for insns 2170: inside @code{sequence} expressions. Specifically, if @var{insn} is the 2171: first insn in a @code{sequence}, @code{NEXT_INSN (PREV_INSN (@var{insn}))} 2172: is the insn containing the @code{sequence} expression, as is the value 2173: of @code{PREV_INSN (NEXT_INSN (@var{insn}))} is @var{insn} is the last 2174: insn in the @code{sequence} expression. You can use these expressions 2175: to find the containing @code{sequence} expression.@refill 2176: 2177: Every insn has one of the following six expression codes: 2178: 2179: @table @code 2180: @findex insn 2181: @item insn 2182: The expression code @code{insn} is used for instructions that do not jump 2183: and do not do function calls. @code{sequence} expressions are always 2184: contained in insns with code @code{insn} even if one of those insns 2185: should jump or do function calls. 2186: 2187: Insns with code @code{insn} have four additional fields beyond the three 2188: mandatory ones listed above. These four are described in a table below. 2189: 2190: @findex jump_insn 2191: @item jump_insn 2192: The expression code @code{jump_insn} is used for instructions that may 2193: jump (or, more generally, may contain @code{label_ref} expressions). If 2194: there is an instruction to return from the current function, it is 2195: recorded as a @code{jump_insn}. 2196: 2197: @findex JUMP_LABEL 2198: @code{jump_insn} insns have the same extra fields as @code{insn} insns, 1.1.1.7 ! root 2199: accessed in the same way and in addition contain a field 1.1 root 2200: @code{JUMP_LABEL} which is defined once jump optimization has completed. 2201: 2202: For simple conditional and unconditional jumps, this field contains the 2203: @code{code_label} to which this insn will (possibly conditionally) 2204: branch. In a more complex jump, @code{JUMP_LABEL} records one of the 2205: labels that the insn refers to; the only way to find the others 2206: is to scan the entire body of the insn. 2207: 2208: Return insns count as jumps, but since they do not refer to any labels, 2209: they have zero in the @code{JUMP_LABEL} field. 2210: 2211: @findex call_insn 2212: @item call_insn 2213: The expression code @code{call_insn} is used for instructions that may do 2214: function calls. It is important to distinguish these instructions because 2215: they imply that certain registers and memory locations may be altered 2216: unpredictably. 2217: 1.1.1.7 ! root 2218: @findex CALL_INSN_FUNCTION_USAGE 1.1 root 2219: @code{call_insn} insns have the same extra fields as @code{insn} insns, 1.1.1.7 ! root 2220: accessed in the same way and in addition contain a field ! 2221: @code{CALL_INSN_FUNCTION_USAGE}, which contains a list (chain of ! 2222: @code{expr_list} expressions) containing @code{use} and @code{clobber} ! 2223: expressions that denote hard registers used or clobbered by the called ! 2224: function. A register specified in a @code{clobber} in this list is ! 2225: modified @emph{after} the execution of the @code{call_insn}, while a ! 2226: register in a @code{clobber} in the body of the @code{call_insn} is ! 2227: clobbered before the insn completes execution. @code{clobber} ! 2228: expressions in this list augment registers specified in ! 2229: @code{CALL_USED_REGISTERS} (@pxref{Register Basics}). 1.1 root 2230: 2231: @findex code_label 2232: @findex CODE_LABEL_NUMBER 2233: @item code_label 2234: A @code{code_label} insn represents a label that a jump insn can jump 2235: to. It contains two special fields of data in addition to the three 2236: standard ones. @code{CODE_LABEL_NUMBER} is used to hold the @dfn{label 2237: number}, a number that identifies this label uniquely among all the 2238: labels in the compilation (not just in the current function). 2239: Ultimately, the label is represented in the assembler output as an 2240: assembler label, usually of the form @samp{L@var{n}} where @var{n} is 2241: the label number. 2242: 2243: When a @code{code_label} appears in an RTL expression, it normally 2244: appears within a @code{label_ref} which represents the address of 2245: the label, as a number. 2246: 2247: @findex LABEL_NUSES 2248: The field @code{LABEL_NUSES} is only defined once the jump optimization 2249: phase is completed and contains the number of times this label is 2250: referenced in the current function. 2251: 2252: @findex barrier 2253: @item barrier 2254: Barriers are placed in the instruction stream when control cannot flow 2255: past them. They are placed after unconditional jump instructions to 2256: indicate that the jumps are unconditional and after calls to 2257: @code{volatile} functions, which do not return (e.g., @code{exit}). 2258: They contain no information beyond the three standard fields. 2259: 2260: @findex note 2261: @findex NOTE_LINE_NUMBER 2262: @findex NOTE_SOURCE_FILE 2263: @item note 2264: @code{note} insns are used to represent additional debugging and 2265: declarative information. They contain two nonstandard fields, an 2266: integer which is accessed with the macro @code{NOTE_LINE_NUMBER} and a 2267: string accessed with @code{NOTE_SOURCE_FILE}. 2268: 2269: If @code{NOTE_LINE_NUMBER} is positive, the note represents the 2270: position of a source line and @code{NOTE_SOURCE_FILE} is the source file name 2271: that the line came from. These notes control generation of line 2272: number data in the assembler output. 2273: 2274: Otherwise, @code{NOTE_LINE_NUMBER} is not really a line number but a 2275: code with one of the following values (and @code{NOTE_SOURCE_FILE} 2276: must contain a null pointer): 2277: 2278: @table @code 2279: @findex NOTE_INSN_DELETED 2280: @item NOTE_INSN_DELETED 2281: Such a note is completely ignorable. Some passes of the compiler 2282: delete insns by altering them into notes of this kind. 2283: 2284: @findex NOTE_INSN_BLOCK_BEG 2285: @findex NOTE_INSN_BLOCK_END 2286: @item NOTE_INSN_BLOCK_BEG 2287: @itemx NOTE_INSN_BLOCK_END 2288: These types of notes indicate the position of the beginning and end 2289: of a level of scoping of variable names. They control the output 2290: of debugging information. 2291: 2292: @findex NOTE_INSN_LOOP_BEG 2293: @findex NOTE_INSN_LOOP_END 2294: @item NOTE_INSN_LOOP_BEG 2295: @itemx NOTE_INSN_LOOP_END 2296: These types of notes indicate the position of the beginning and end 2297: of a @code{while} or @code{for} loop. They enable the loop optimizer 2298: to find loops quickly. 2299: 2300: @findex NOTE_INSN_LOOP_CONT 2301: @item NOTE_INSN_LOOP_CONT 2302: Appears at the place in a loop that @code{continue} statements jump to. 2303: 2304: @findex NOTE_INSN_LOOP_VTOP 2305: @item NOTE_INSN_LOOP_VTOP 2306: This note indicates the place in a loop where the exit test begins for 2307: those loops in which the exit test has been duplicated. This position 2308: becomes another virtual start of the loop when considering loop 2309: invariants. 2310: 2311: @findex NOTE_INSN_FUNCTION_END 2312: @item NOTE_INSN_FUNCTION_END 2313: Appears near the end of the function body, just before the label that 2314: @code{return} statements jump to (on machine where a single instruction 2315: does not suffice for returning). This note may be deleted by jump 2316: optimization. 2317: 2318: @findex NOTE_INSN_SETJMP 2319: @item NOTE_INSN_SETJMP 2320: Appears following each call to @code{setjmp} or a related function. 2321: @end table 2322: 2323: These codes are printed symbolically when they appear in debugging dumps. 2324: @end table 2325: 2326: @cindex @code{HImode}, in @code{insn} 2327: @cindex @code{QImode}, in @code{insn} 2328: The machine mode of an insn is normally @code{VOIDmode}, but some 2329: phases use the mode for various purposes; for example, the reload pass 2330: sets it to @code{HImode} if the insn needs reloading but not register 2331: elimination and @code{QImode} if both are required. The common 2332: subexpression elimination pass sets the mode of an insn to @code{QImode} 2333: when it is the first insn in a block that has already been processed. 2334: 2335: Here is a table of the extra fields of @code{insn}, @code{jump_insn} 2336: and @code{call_insn} insns: 2337: 2338: @table @code 2339: @findex PATTERN 2340: @item PATTERN (@var{i}) 2341: An expression for the side effect performed by this insn. This must be 2342: one of the following codes: @code{set}, @code{call}, @code{use}, 2343: @code{clobber}, @code{return}, @code{asm_input}, @code{asm_output}, 2344: @code{addr_vec}, @code{addr_diff_vec}, @code{trap_if}, @code{unspec}, 1.1.1.4 root 2345: @code{unspec_volatile}, @code{parallel}, or @code{sequence}. If it is a @code{parallel}, 1.1 root 2346: each element of the @code{parallel} must be one these codes, except that 2347: @code{parallel} expressions cannot be nested and @code{addr_vec} and 2348: @code{addr_diff_vec} are not permitted inside a @code{parallel} expression. 2349: 2350: @findex INSN_CODE 2351: @item INSN_CODE (@var{i}) 2352: An integer that says which pattern in the machine description matches 2353: this insn, or -1 if the matching has not yet been attempted. 2354: 2355: Such matching is never attempted and this field remains -1 on an insn 2356: whose pattern consists of a single @code{use}, @code{clobber}, 2357: @code{asm_input}, @code{addr_vec} or @code{addr_diff_vec} expression. 2358: 2359: @findex asm_noperands 2360: Matching is also never attempted on insns that result from an @code{asm} 2361: statement. These contain at least one @code{asm_operands} expression. 2362: The function @code{asm_noperands} returns a non-negative value for 2363: such insns. 2364: 2365: In the debugging output, this field is printed as a number followed by 2366: a symbolic representation that locates the pattern in the @file{md} 2367: file as some small positive or negative offset from a named pattern. 2368: 2369: @findex LOG_LINKS 2370: @item LOG_LINKS (@var{i}) 2371: A list (chain of @code{insn_list} expressions) giving information about 2372: dependencies between instructions within a basic block. Neither a jump 2373: nor a label may come between the related insns. 2374: 2375: @findex REG_NOTES 2376: @item REG_NOTES (@var{i}) 2377: A list (chain of @code{expr_list} and @code{insn_list} expressions) 2378: giving miscellaneous information about the insn. It is often information 2379: pertaining to the registers used in this insn. 2380: @end table 2381: 2382: The @code{LOG_LINKS} field of an insn is a chain of @code{insn_list} 2383: expressions. Each of these has two operands: the first is an insn, 2384: and the second is another @code{insn_list} expression (the next one in 2385: the chain). The last @code{insn_list} in the chain has a null pointer 2386: as second operand. The significant thing about the chain is which 2387: insns appear in it (as first operands of @code{insn_list} 2388: expressions). Their order is not significant. 2389: 2390: This list is originally set up by the flow analysis pass; it is a null 2391: pointer until then. Flow only adds links for those data dependencies 2392: which can be used for instruction combination. For each insn, the flow 2393: analysis pass adds a link to insns which store into registers values 2394: that are used for the first time in this insn. The instruction 2395: scheduling pass adds extra links so that every dependence will be 2396: represented. Links represent data dependencies, antidependencies and 2397: output dependencies; the machine mode of the link distinguishes these 2398: three types: antidependencies have mode @code{REG_DEP_ANTI}, output 2399: dependencies have mode @code{REG_DEP_OUTPUT}, and data dependencies have 2400: mode @code{VOIDmode}. 2401: 2402: The @code{REG_NOTES} field of an insn is a chain similar to the 2403: @code{LOG_LINKS} field but it includes @code{expr_list} expressions in 2404: addition to @code{insn_list} expressions. There are several kinds 2405: of register notes, which are distinguished by the machine mode, which 2406: in a register note is really understood as being an @code{enum reg_note}. 2407: The first operand @var{op} of the note is data whose meaning depends on 2408: the kind of note. 2409: 2410: @findex REG_NOTE_KIND 2411: @findex PUT_REG_NOTE_KIND 1.1.1.4 root 2412: The macro @code{REG_NOTE_KIND (@var{x})} returns the kind of 1.1 root 2413: register note. Its counterpart, the macro @code{PUT_REG_NOTE_KIND 2414: (@var{x}, @var{newkind})} sets the register note type of @var{x} to be 2415: @var{newkind}. 2416: 2417: Register notes are of three classes: They may say something about an 2418: input to an insn, they may say something about an output of an insn, or 2419: they may create a linkage between two insns. There are also a set 2420: of values that are only used in @code{LOG_LINKS}. 2421: 2422: These register notes annotate inputs to an insn: 2423: 2424: @table @code 2425: @findex REG_DEAD 2426: @item REG_DEAD 2427: The value in @var{op} dies in this insn; that is to say, altering the 2428: value immediately after this insn would not affect the future behavior 2429: of the program. 2430: 2431: This does not necessarily mean that the register @var{op} has no useful 2432: value after this insn since it may also be an output of the insn. In 2433: such a case, however, a @code{REG_DEAD} note would be redundant and is 2434: usually not present until after the reload pass, but no code relies on 2435: this fact. 2436: 2437: @findex REG_INC 2438: @item REG_INC 2439: The register @var{op} is incremented (or decremented; at this level 2440: there is no distinction) by an embedded side effect inside this insn. 2441: This means it appears in a @code{post_inc}, @code{pre_inc}, 2442: @code{post_dec} or @code{pre_dec} expression. 2443: 2444: @findex REG_NONNEG 2445: @item REG_NONNEG 2446: The register @var{op} is known to have a nonnegative value when this 2447: insn is reached. This is used so that decrement and branch until zero 2448: instructions, such as the m68k dbra, can be matched. 2449: 2450: The @code{REG_NONNEG} note is added to insns only if the machine 1.1.1.5 root 2451: description has a @samp{decrement_and_branch_until_zero} pattern. 1.1 root 2452: 2453: @findex REG_NO_CONFLICT 2454: @item REG_NO_CONFLICT 2455: This insn does not cause a conflict between @var{op} and the item 2456: being set by this insn even though it might appear that it does. 2457: In other words, if the destination register and @var{op} could 2458: otherwise be assigned the same register, this insn does not 2459: prevent that assignment. 2460: 2461: Insns with this note are usually part of a block that begins with a 2462: @code{clobber} insn specifying a multi-word pseudo register (which will 2463: be the output of the block), a group of insns that each set one word of 2464: the value and have the @code{REG_NO_CONFLICT} note attached, and a final 2465: insn that copies the output to itself with an attached @code{REG_EQUAL} 2466: note giving the expression being computed. This block is encapsulated 2467: with @code{REG_LIBCALL} and @code{REG_RETVAL} notes on the first and 2468: last insns, respectively. 2469: 2470: @findex REG_LABEL 2471: @item REG_LABEL 2472: This insn uses @var{op}, a @code{code_label}, but is not a 2473: @code{jump_insn}. The presence of this note allows jump optimization to 2474: be aware that @var{op} is, in fact, being used. 2475: @end table 2476: 2477: The following notes describe attributes of outputs of an insn: 2478: 2479: @table @code 2480: @findex REG_EQUIV 2481: @findex REG_EQUAL 2482: @item REG_EQUIV 2483: @itemx REG_EQUAL 2484: This note is only valid on an insn that sets only one register and 2485: indicates that that register will be equal to @var{op} at run time; the 2486: scope of this equivalence differs between the two types of notes. The 2487: value which the insn explicitly copies into the register may look 2488: different from @var{op}, but they will be equal at run time. If the 2489: output of the single @code{set} is a @code{strict_low_part} expression, 2490: the note refers to the register that is contained in @code{SUBREG_REG} 2491: of the @code{subreg} expression. 2492: 2493: For @code{REG_EQUIV}, the register is equivalent to @var{op} throughout 2494: the entire function, and could validly be replaced in all its 2495: occurrences by @var{op}. (``Validly'' here refers to the data flow of 2496: the program; simple replacement may make some insns invalid.) For 2497: example, when a constant is loaded into a register that is never 2498: assigned any other value, this kind of note is used. 2499: 2500: When a parameter is copied into a pseudo-register at entry to a function, 2501: a note of this kind records that the register is equivalent to the stack 2502: slot where the parameter was passed. Although in this case the register 2503: may be set by other insns, it is still valid to replace the register 2504: by the stack slot throughout the function. 2505: 2506: In the case of @code{REG_EQUAL}, the register that is set by this insn 2507: will be equal to @var{op} at run time at the end of this insn but not 2508: necessarily elsewhere in the function. In this case, @var{op} 2509: is typically an arithmetic expression. For example, when a sequence of 2510: insns such as a library call is used to perform an arithmetic operation, 2511: this kind of note is attached to the insn that produces or copies the 2512: final value. 2513: 2514: These two notes are used in different ways by the compiler passes. 2515: @code{REG_EQUAL} is used by passes prior to register allocation (such as 2516: common subexpression elimination and loop optimization) to tell them how 2517: to think of that value. @code{REG_EQUIV} notes are used by register 2518: allocation to indicate that there is an available substitute expression 2519: (either a constant or a @code{mem} expression for the location of a 2520: parameter on the stack) that may be used in place of a register if 2521: insufficient registers are available. 2522: 2523: Except for stack homes for parameters, which are indicated by a 2524: @code{REG_EQUIV} note and are not useful to the early optimization 2525: passes and pseudo registers that are equivalent to a memory location 2526: throughout there entire life, which is not detected until later in 2527: the compilation, all equivalences are initially indicated by an attached 2528: @code{REG_EQUAL} note. In the early stages of register allocation, a 2529: @code{REG_EQUAL} note is changed into a @code{REG_EQUIV} note if 2530: @var{op} is a constant and the insn represents the only set of its 2531: destination register. 2532: 2533: Thus, compiler passes prior to register allocation need only check for 2534: @code{REG_EQUAL} notes and passes subsequent to register allocation 2535: need only check for @code{REG_EQUIV} notes. 2536: 2537: @findex REG_UNUSED 2538: @item REG_UNUSED 2539: The register @var{op} being set by this insn will not be used in a 2540: subsequent insn. This differs from a @code{REG_DEAD} note, which 2541: indicates that the value in an input will not be used subsequently. 2542: These two notes are independent; both may be present for the same 2543: register. 2544: 2545: @findex REG_WAS_0 2546: @item REG_WAS_0 2547: The single output of this insn contained zero before this insn. 2548: @var{op} is the insn that set it to zero. You can rely on this note if 2549: it is present and @var{op} has not been deleted or turned into a @code{note}; 2550: its absence implies nothing. 2551: @end table 2552: 2553: These notes describe linkages between insns. They occur in pairs: one 2554: insn has one of a pair of notes that points to a second insn, which has 2555: the inverse note pointing back to the first insn. 2556: 2557: @table @code 2558: @findex REG_RETVAL 2559: @item REG_RETVAL 2560: This insn copies the value of a multi-insn sequence (for example, a 2561: library call), and @var{op} is the first insn of the sequence (for a 2562: library call, the first insn that was generated to set up the arguments 2563: for the library call). 2564: 2565: Loop optimization uses this note to treat such a sequence as a single 2566: operation for code motion purposes and flow analysis uses this note to 2567: delete such sequences whose results are dead. 2568: 2569: A @code{REG_EQUAL} note will also usually be attached to this insn to 2570: provide the expression being computed by the sequence. 2571: 2572: @findex REG_LIBCALL 2573: @item REG_LIBCALL 2574: This is the inverse of @code{REG_RETVAL}: it is placed on the first 2575: insn of a multi-insn sequence, and it points to the last one. 2576: 2577: @findex REG_CC_SETTER 2578: @findex REG_CC_USER 2579: @item REG_CC_SETTER 2580: @itemx REG_CC_USER 2581: On machines that use @code{cc0}, the insns which set and use @code{cc0} 2582: set and use @code{cc0} are adjacent. However, when branch delay slot 2583: filling is done, this may no longer be true. In this case a 2584: @code{REG_CC_USER} note will be placed on the insn setting @code{cc0} to 2585: point to the insn using @code{cc0} and a @code{REG_CC_SETTER} note will 2586: be placed on the insn using @code{cc0} to point to the insn setting 2587: @code{cc0}.@refill 2588: @end table 2589: 2590: These values are only used in the @code{LOG_LINKS} field, and indicate 2591: the type of dependency that each link represents. Links which indicate 2592: a data dependence (a read after write dependence) do not use any code, 2593: they simply have mode @code{VOIDmode}, and are printed without any 2594: descriptive text. 2595: 2596: @table @code 2597: @findex REG_DEP_ANTI 2598: @item REG_DEP_ANTI 2599: This indicates an anti dependence (a write after read dependence). 2600: 2601: @findex REG_DEP_OUTPUT 2602: @item REG_DEP_OUTPUT 2603: This indicates an output dependence (a write after write dependence). 2604: @end table 2605: 2606: For convenience, the machine mode in an @code{insn_list} or 2607: @code{expr_list} is printed using these symbolic codes in debugging dumps. 2608: 2609: @findex insn_list 2610: @findex expr_list 2611: The only difference between the expression codes @code{insn_list} and 2612: @code{expr_list} is that the first operand of an @code{insn_list} is 2613: assumed to be an insn and is printed in debugging dumps as the insn's 2614: unique id; the first operand of an @code{expr_list} is printed in the 2615: ordinary way as an expression. 2616: 2617: @node Calls, Sharing, Insns, RTL 2618: @section RTL Representation of Function-Call Insns 2619: @cindex calling functions in RTL 2620: @cindex RTL function-call insns 2621: @cindex function-call insns 2622: 2623: Insns that call subroutines have the RTL expression code @code{call_insn}. 2624: These insns must satisfy special rules, and their bodies must use a special 2625: RTL expression code, @code{call}. 2626: 2627: @cindex @code{call} usage 2628: A @code{call} expression has two operands, as follows: 2629: 2630: @example 2631: (call (mem:@var{fm} @var{addr}) @var{nbytes}) 2632: @end example 2633: 2634: @noindent 2635: Here @var{nbytes} is an operand that represents the number of bytes of 2636: argument data being passed to the subroutine, @var{fm} is a machine mode 2637: (which must equal as the definition of the @code{FUNCTION_MODE} macro in 2638: the machine description) and @var{addr} represents the address of the 2639: subroutine. 2640: 2641: For a subroutine that returns no value, the @code{call} expression as 2642: shown above is the entire body of the insn, except that the insn might 2643: also contain @code{use} or @code{clobber} expressions. 2644: 2645: @cindex @code{BLKmode}, and function return values 2646: For a subroutine that returns a value whose mode is not @code{BLKmode}, 2647: the value is returned in a hard register. If this register's number is 2648: @var{r}, then the body of the call insn looks like this: 2649: 2650: @example 2651: (set (reg:@var{m} @var{r}) 2652: (call (mem:@var{fm} @var{addr}) @var{nbytes})) 2653: @end example 2654: 2655: @noindent 2656: This RTL expression makes it clear (to the optimizer passes) that the 2657: appropriate register receives a useful value in this insn. 2658: 2659: When a subroutine returns a @code{BLKmode} value, it is handled by 2660: passing to the subroutine the address of a place to store the value. 2661: So the call insn itself does not ``return'' any value, and it has the 2662: same RTL form as a call that returns nothing. 2663: 2664: On some machines, the call instruction itself clobbers some register, 2665: for example to contain the return address. @code{call_insn} insns 2666: on these machines should have a body which is a @code{parallel} 2667: that contains both the @code{call} expression and @code{clobber} 2668: expressions that indicate which registers are destroyed. Similarly, 2669: if the call instruction requires some register other than the stack 2670: pointer that is not explicitly mentioned it its RTL, a @code{use} 2671: subexpression should mention that register. 2672: 2673: Functions that are called are assumed to modify all registers listed in 2674: the configuration macro @code{CALL_USED_REGISTERS} (@pxref{Register 2675: Basics}) and, with the exception of @code{const} functions and library 2676: calls, to modify all of memory. 2677: 2678: Insns containing just @code{use} expressions directly precede the 2679: @code{call_insn} insn to indicate which registers contain inputs to the 2680: function. Similarly, if registers other than those in 2681: @code{CALL_USED_REGISTERS} are clobbered by the called function, insns 2682: containing a single @code{clobber} follow immediately after the call to 2683: indicate which registers. 2684: 1.1.1.5 root 2685: @node Sharing 1.1 root 2686: @section Structure Sharing Assumptions 2687: @cindex sharing of RTL components 2688: @cindex RTL structure sharing assumptions 2689: 2690: The compiler assumes that certain kinds of RTL expressions are unique; 2691: there do not exist two distinct objects representing the same value. 2692: In other cases, it makes an opposite assumption: that no RTL expression 2693: object of a certain kind appears in more than one place in the 2694: containing structure. 2695: 2696: These assumptions refer to a single function; except for the RTL 2697: objects that describe global variables and external functions, 2698: and a few standard objects such as small integer constants, 2699: no RTL objects are common to two functions. 2700: 2701: @itemize @bullet 2702: @cindex @code{reg}, RTL sharing 2703: @item 2704: Each pseudo-register has only a single @code{reg} object to represent it, 2705: and therefore only a single machine mode. 2706: 2707: @cindex symbolic label 2708: @cindex @code{symbol_ref}, RTL sharing 2709: @item 2710: For any symbolic label, there is only one @code{symbol_ref} object 2711: referring to it. 2712: 2713: @cindex @code{const_int}, RTL sharing 2714: @item 2715: There is only one @code{const_int} expression with value 0, only 2716: one with value 1, and only one with value @minus{}1. 2717: Some other integer values are also stored uniquely. 2718: 2719: @cindex @code{pc}, RTL sharing 2720: @item 2721: There is only one @code{pc} expression. 2722: 2723: @cindex @code{cc0}, RTL sharing 2724: @item 2725: There is only one @code{cc0} expression. 2726: 2727: @cindex @code{const_double}, RTL sharing 2728: @item 2729: There is only one @code{const_double} expression with value 0 for 2730: each floating point mode. Likewise for values 1 and 2. 2731: 2732: @cindex @code{label_ref}, RTL sharing 2733: @cindex @code{scratch}, RTL sharing 2734: @item 2735: No @code{label_ref} or @code{scratch} appears in more than one place in 2736: the RTL structure; in other words, it is safe to do a tree-walk of all 2737: the insns in the function and assume that each time a @code{label_ref} 2738: or @code{scratch} is seen it is distinct from all others that are seen. 2739: 2740: @cindex @code{mem}, RTL sharing 2741: @item 2742: Only one @code{mem} object is normally created for each static 2743: variable or stack slot, so these objects are frequently shared in all 2744: the places they appear. However, separate but equal objects for these 2745: variables are occasionally made. 2746: 2747: @cindex @code{asm_operands}, RTL sharing 2748: @item 2749: When a single @code{asm} statement has multiple output operands, a 2750: distinct @code{asm_operands} expression is made for each output operand. 2751: However, these all share the vector which contains the sequence of input 2752: operands. This sharing is used later on to test whether two 2753: @code{asm_operands} expressions come from the same statement, so all 2754: optimizations must carefully preserve the sharing if they copy the 2755: vector at all. 2756: 2757: @item 2758: No RTL object appears in more than one place in the RTL structure 2759: except as described above. Many passes of the compiler rely on this 2760: by assuming that they can modify RTL objects in place without unwanted 2761: side-effects on other insns. 2762: 2763: @findex unshare_all_rtl 2764: @item 2765: During initial RTL generation, shared structure is freely introduced. 2766: After all the RTL for a function has been generated, all shared 2767: structure is copied by @code{unshare_all_rtl} in @file{emit-rtl.c}, 2768: after which the above rules are guaranteed to be followed. 2769: 2770: @findex copy_rtx_if_shared 2771: @item 2772: During the combiner pass, shared structure within an insn can exist 2773: temporarily. However, the shared structure is copied before the 2774: combiner is finished with the insn. This is done by calling 2775: @code{copy_rtx_if_shared}, which is a subroutine of 2776: @code{unshare_all_rtl}. 2777: @end itemize 1.1.1.5 root 2778: 2779: @node Reading RTL 2780: @section Reading RTL 2781: 2782: To read an RTL object from a file, call @code{read_rtx}. It takes one 2783: argument, a stdio stream, and returns a single RTL object. 2784: 2785: Reading RTL from a file is very slow. This is no currently not a 2786: problem because reading RTL occurs only as part of building the 2787: compiler. 2788: 2789: People frequently have the idea of using RTL stored as text in a file as 2790: an interface between a language front end and the bulk of GNU CC. This 2791: idea is not feasible. 2792: 2793: GNU CC was designed to use RTL internally only. Correct RTL for a given 2794: program is very dependent on the particular target machine. And the RTL 2795: does not contain all the information about the program. 2796: 2797: The proper way to interface GNU CC to a new language front end is with 2798: the ``tree'' data structure. There is no manual for this data 2799: structure, but it is described in the files @file{tree.h} and 2800: @file{tree.def}.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.