![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-9 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-9 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 8: Permission is granted to make and distribute verbatim copies of 9: this manual provided the copyright notice and this permission notice 10: are preserved on all copies. 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 14: that the section entitled "GNU General Public License" is included 15: exactly as in the original, and provided that the entire resulting 16: derived work is distributed under the terms of a permission notice 17: identical to this one. 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 21: versions, except that the section entitled "GNU General Public 22: License" and this permission notice may be included in translations 23: approved by the Free Software Foundation instead of in the original 24: English. 25: 26: 1.1.1.2 ! root 27: File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL ! 28: ! 29: Insns ! 30: ===== ! 31: ! 32: The RTL representation of the code for a function is a doubly-linked ! 33: chain of objects called "insns". Insns are expressions with special ! 34: codes that are used for no other purpose. Some insns are actual ! 35: instructions; others represent dispatch tables for `switch' ! 36: statements; others represent labels to jump to or various sorts of ! 37: declarative information. ! 38: ! 39: In addition to its own specific data, each insn must have a unique ! 40: id-number that distinguishes it from all other insns in the current ! 41: function (after delayed branch scheduling, copies of an insn with the ! 42: same id-number may be present in multiple places in a function, but ! 43: these copies will always be identical and will only appear inside a ! 44: `sequence'), and chain pointers to the preceding and following insns. ! 45: These three fields occupy the same position in every insn, independent ! 46: of the expression code of the insn. They could be accessed with ! 47: `XEXP' and `XINT', but instead three special macros are always used: ! 48: ! 49: `INSN_UID (I)' ! 50: Accesses the unique id of insn I. ! 51: ! 52: `PREV_INSN (I)' ! 53: Accesses the chain pointer to the insn preceding I. If I is the ! 54: first insn, this is a null pointer. ! 55: ! 56: `NEXT_INSN (I)' ! 57: Accesses the chain pointer to the insn following I. If I is the ! 58: last insn, this is a null pointer. ! 59: ! 60: The first insn in the chain is obtained by calling `get_insns'; the ! 61: last insn is the result of calling `get_last_insn'. Within the chain ! 62: delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers ! 63: must always correspond: if INSN is not the first insn, ! 64: ! 65: NEXT_INSN (PREV_INSN (INSN)) == INSN ! 66: ! 67: is always true and if INSN is not the last insn, ! 68: ! 69: PREV_INSN (NEXT_INSN (INSN)) == INSN ! 70: ! 71: is always true. ! 72: ! 73: After delay slot scheduling, some of the insns in the chain might be ! 74: `sequence' expressions, which contain a vector of insns. The value of ! 75: `NEXT_INSN' in all but the last of these insns is the next insn in the ! 76: vector; the value of `NEXT_INSN' of the last insn in the vector is the ! 77: same as the value of `NEXT_INSN' for the `sequence' in which it is ! 78: contained. Similar rules apply for `PREV_INSN'. ! 79: ! 80: This means that the above invariants are not necessarily true for ! 81: insns inside `sequence' expressions. Specifically, if INSN is the ! 82: first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn ! 83: containing the `sequence' expression, as is the value of `PREV_INSN ! 84: (NEXT_INSN (INSN))' is INSN is the last insn in the `sequence' ! 85: expression. You can use these expressions to find the containing ! 86: `sequence' expression. ! 87: ! 88: Every insn has one of the following six expression codes: ! 89: ! 90: `insn' ! 91: The expression code `insn' is used for instructions that do not ! 92: jump and do not do function calls. `sequence' expressions are ! 93: always contained in insns with code `insn' even if one of those ! 94: insns should jump or do function calls. ! 95: ! 96: Insns with code `insn' have four additional fields beyond the ! 97: three mandatory ones listed above. These four are described in a ! 98: table below. ! 99: ! 100: `jump_insn' ! 101: The expression code `jump_insn' is used for instructions that may ! 102: jump (or, more generally, may contain `label_ref' expressions). ! 103: If there is an instruction to return from the current function, ! 104: it is recorded as a `jump_insn'. ! 105: ! 106: `jump_insn' insns have the same extra fields as `insn' insns, ! 107: accessed in the same way and in addition contains a field ! 108: `JUMP_LABEL' which is defined once jump optimization has ! 109: completed. ! 110: ! 111: For simple conditional and unconditional jumps, this field ! 112: contains the `code_label' to which this insn will (possibly ! 113: conditionally) branch. In a more complex jump, `JUMP_LABEL' ! 114: records one of the labels that the insn refers to; the only way ! 115: to find the others is to scan the entire body of the insn. ! 116: ! 117: Return insns count as jumps, but since they do not refer to any ! 118: labels, they have zero in the `JUMP_LABEL' field. ! 119: ! 120: `call_insn' ! 121: The expression code `call_insn' is used for instructions that may ! 122: do function calls. It is important to distinguish these ! 123: instructions because they imply that certain registers and memory ! 124: locations may be altered unpredictably. ! 125: ! 126: A `call_insn' insn may be preceded by insns that contain a single ! 127: `use' expression and be followed by insns the contain a single ! 128: `clobber' expression. If so, these `use' and `clobber' ! 129: expressions are treated as being part of the function call. ! 130: There must not even be a `note' between the `call_insn' and the ! 131: `use' or `clobber' insns for this special treatment to take ! 132: place. This is somewhat of a kludge and will be removed in a ! 133: later version of GNU CC. ! 134: ! 135: `call_insn' insns have the same extra fields as `insn' insns, ! 136: accessed in the same way. ! 137: ! 138: `code_label' ! 139: A `code_label' insn represents a label that a jump insn can jump ! 140: to. It contains two special fields of data in addition to the ! 141: three standard ones. `CODE_LABEL_NUMBER' is used to hold the ! 142: "label number", a number that identifies this label uniquely ! 143: among all the labels in the compilation (not just in the current ! 144: function). Ultimately, the label is represented in the assembler ! 145: output as an assembler label, usually of the form `LN' where N is ! 146: the label number. ! 147: ! 148: When a `code_label' appears in an RTL expression, it normally ! 149: appears within a `label_ref' which represents the address of the ! 150: label, as a number. ! 151: ! 152: The field `LABEL_NUSES' is only defined once the jump optimization ! 153: phase is completed and contains the number of times this label is ! 154: referenced in the current function. ! 155: ! 156: `barrier' ! 157: Barriers are placed in the instruction stream when control cannot ! 158: flow past them. They are placed after unconditional jump ! 159: instructions to indicate that the jumps are unconditional and ! 160: after calls to `volatile' functions, which do not return (e.g., ! 161: `exit'). They contain no information beyond the three standard ! 162: fields. ! 163: ! 164: `note' ! 165: `note' insns are used to represent additional debugging and ! 166: declarative information. They contain two nonstandard fields, an ! 167: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a ! 168: string accessed with `NOTE_SOURCE_FILE'. ! 169: ! 170: If `NOTE_LINE_NUMBER' is positive, the note represents the ! 171: position of a source line and `NOTE_SOURCE_FILE' is the source ! 172: file name that the line came from. These notes control ! 173: generation of line number data in the assembler output. ! 174: ! 175: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a ! 176: code with one of the following values (and `NOTE_SOURCE_FILE' ! 177: must contain a null pointer): ! 178: ! 179: `NOTE_INSN_DELETED' ! 180: Such a note is completely ignorable. Some passes of the ! 181: compiler delete insns by altering them into notes of this ! 182: kind. ! 183: ! 184: `NOTE_INSN_BLOCK_BEG' ! 185: `NOTE_INSN_BLOCK_END' ! 186: These types of notes indicate the position of the beginning ! 187: and end of a level of scoping of variable names. They ! 188: control the output of debugging information. ! 189: ! 190: `NOTE_INSN_LOOP_BEG' ! 191: `NOTE_INSN_LOOP_END' ! 192: These types of notes indicate the position of the beginning ! 193: and end of a `while' or `for' loop. They enable the loop ! 194: optimizer to find loops quickly. ! 195: ! 196: `NOTE_INSN_LOOP_CONT' ! 197: Appears at the place in a loop that `continue' statements ! 198: jump to. ! 199: ! 200: `NOTE_INSN_LOOP_VTOP' ! 201: This note indicates the place in a loop where the exit test ! 202: begins for those loops in which the exit test has been ! 203: duplicated. This position becomes another virtual start of ! 204: the loop when considering loop invariants. ! 205: ! 206: `NOTE_INSN_FUNCTION_END' ! 207: Appears near the end of the function body, just before the ! 208: label that `return' statements jump to (on machine where a ! 209: single instruction does not suffice for returning). This ! 210: note may be deleted by jump optimization. ! 211: ! 212: `NOTE_INSN_SETJMP' ! 213: Appears following each call to `setjmp' or a related ! 214: function. ! 215: ! 216: These codes are printed symbolically when they appear in ! 217: debugging dumps. ! 218: ! 219: The machine mode of an insn is normally `VOIDmode', but some phases ! 220: use the mode for various purposes; for example, the reload pass sets ! 221: it to `HImode' if the insn needs reloading but not register ! 222: elimination and `QImode' if both are required. The common ! 223: subexpression elimination pass sets the mode of an insn to `QImode' ! 224: when it is the first insn in a block that has already been processed. ! 225: ! 226: Here is a table of the extra fields of `insn', `jump_insn' and ! 227: `call_insn' insns: ! 228: ! 229: `PATTERN (I)' ! 230: An expression for the side effect performed by this insn. This ! 231: must be one of the following codes: `set', `call', `use', ! 232: `clobber', `return', `asm_input', `asm_output', `addr_vec', ! 233: `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', or ! 234: `parallel'. If it is a `parallel', each element of the ! 235: `parallel' must be one these codes, except that `parallel' ! 236: expressions cannot be nested and `addr_vec' and `addr_diff_vec' ! 237: are not permitted inside a `parallel' expression. ! 238: ! 239: `INSN_CODE (I)' ! 240: An integer that says which pattern in the machine description ! 241: matches this insn, or -1 if the matching has not yet been ! 242: attempted. ! 243: ! 244: Such matching is never attempted and this field remains -1 on an ! 245: insn whose pattern consists of a single `use', `clobber', ! 246: `asm_input', `addr_vec' or `addr_diff_vec' expression. ! 247: ! 248: Matching is also never attempted on insns that result from an ! 249: `asm' statement. These contain at least one `asm_operands' ! 250: expression. The function `asm_noperands' returns a non-negative ! 251: value for such insns. ! 252: ! 253: In the debugging output, this field is printed as a number ! 254: followed by a symbolic representation that locates the pattern in ! 255: the `md' file as some small positive or negative offset from a ! 256: named pattern. ! 257: ! 258: `LOG_LINKS (I)' ! 259: A list (chain of `insn_list' expressions) giving information about ! 260: dependencies between instructions within a basic block. Neither ! 261: a jump nor a label may come between the related insns. ! 262: ! 263: `REG_NOTES (I)' ! 264: A list (chain of `expr_list' and `insn_list' expressions) giving ! 265: miscellaneous information about the insn. It is often information ! 266: pertaining to the registers used in this insn. ! 267: ! 268: The `LOG_LINKS' field of an insn is a chain of `insn_list' ! 269: expressions. Each of these has two operands: the first is an insn, ! 270: and the second is another `insn_list' expression (the next one in the ! 271: chain). The last `insn_list' in the chain has a null pointer as ! 272: second operand. The significant thing about the chain is which insns ! 273: appear in it (as first operands of `insn_list' expressions). Their ! 274: order is not significant. ! 275: ! 276: This list is originally set up by the flow analysis pass; it is a ! 277: null pointer until then. Flow only adds links for those data ! 278: dependencies which can be used for instruction combination. For each ! 279: insn, the flow analysis pass adds a link to insns which store into ! 280: registers values that are used for the first time in this insn. The ! 281: instruction scheduling pass adds extra links so that every dependence ! 282: will be represented. Links represent data dependencies, ! 283: antidependencies and output dependencies; the machine mode of the link ! 284: distinguishes these three types: antidependencies have mode ! 285: `REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and ! 286: data dependencies have mode `VOIDmode'. ! 287: ! 288: The `REG_NOTES' field of an insn is a chain similar to the ! 289: `LOG_LINKS' field but it includes `expr_list' expressions in addition ! 290: to `insn_list' expressions. There are several kinds of register ! 291: notes, which are distinguished by the machine mode, which in a ! 292: register note is really understood as being an `enum reg_note'. The ! 293: first operand OP of the note is data whose meaning depends on the kind ! 294: of note. ! 295: ! 296: The macro `REG_NOTE_KIND (X)' returns the the kind of register ! 297: note. Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' ! 298: sets the register note type of X to be NEWKIND. ! 299: ! 300: Register notes are of three classes: They may say something about an ! 301: input to an insn, they may say something about an output of an insn, or ! 302: they may create a linkage between two insns. There are also a set of ! 303: values that are only used in `LOG_LINKS'. ! 304: ! 305: These register notes annotate inputs to an insn: ! 306: ! 307: `REG_DEAD' ! 308: The value in OP dies in this insn; that is to say, altering the ! 309: value immediately after this insn would not affect the future ! 310: behavior of the program. ! 311: ! 312: This does not necessarily mean that the register OP has no useful ! 313: value after this insn since it may also be an output of the insn. ! 314: In such a case, however, a `REG_DEAD' note would be redundant ! 315: and is usually not present until after the reload pass, but no ! 316: code relies on this fact. ! 317: ! 318: `REG_INC' ! 319: The register OP is incremented (or decremented; at this level ! 320: there is no distinction) by an embedded side effect inside this ! 321: insn. This means it appears in a `post_inc', `pre_inc', ! 322: `post_dec' or `pre_dec' expression. ! 323: ! 324: `REG_NONNEG' ! 325: The register OP is known to have a nonnegative value when this ! 326: insn is reached. This is used so that decrement and branch until ! 327: zero instructions, such as the m68k dbra, can be matched. ! 328: ! 329: The `REG_NONNEG' note is added to insns only if the machine ! 330: description contains a pattern named ! 331: `decrement_and_branch_until_zero'. ! 332: ! 333: `REG_NO_CONFLICT' ! 334: This insn does not cause a conflict between OP and the item being ! 335: set by this insn even though it might appear that it does. In ! 336: other words, if the destination register and OP could otherwise ! 337: be assigned the same register, this insn does not prevent that ! 338: assignment. ! 339: ! 340: Insns with this note are usually part of a block that begins with ! 341: a `clobber' insn specifying a multi-word pseudo register (which ! 342: will be the output of the block), a group of insns that each set ! 343: one word of the value and have the `REG_NO_CONFLICT' note ! 344: attached, and a final insn that copies the output to itself with ! 345: an attached `REG_EQUAL' note giving the expression being ! 346: computed. This block is encapsulated with `REG_LIBCALL' and ! 347: `REG_RETVAL' notes on the first and last insns, respectively. ! 348: ! 349: `REG_LABEL' ! 350: This insn uses OP, a `code_label', but is not a `jump_insn'. The ! 351: presence of this note allows jump optimization to be aware that ! 352: OP is, in fact, being used. ! 353: ! 354: The following notes describe attributes of outputs of an insn: ! 355: ! 356: `REG_EQUIV' ! 357: `REG_EQUAL' ! 358: This note is only valid on an insn that sets only one register and ! 359: indicates that that register will be equal to OP at run time; the ! 360: scope of this equivalence differs between the two types of notes. ! 361: The value which the insn explicitly copies into the register may ! 362: look different from OP, but they will be equal at run time. If ! 363: the output of the single `set' is a `strict_low_part' expression, ! 364: the note refers to the register that is contained in `SUBREG_REG' ! 365: of the `subreg' expression. ! 366: ! 367: For `REG_EQUIV', the register is equivalent to OP throughout the ! 368: entire function, and could validly be replaced in all its ! 369: occurrences by OP. ("Validly" here refers to the data flow of ! 370: the program; simple replacement may make some insns invalid.) For ! 371: example, when a constant is loaded into a register that is never ! 372: assigned any other value, this kind of note is used. ! 373: ! 374: When a parameter is copied into a pseudo-register at entry to a ! 375: function, a note of this kind records that the register is ! 376: equivalent to the stack slot where the parameter was passed. ! 377: Although in this case the register may be set by other insns, it ! 378: is still valid to replace the register by the stack slot ! 379: throughout the function. ! 380: ! 381: In the case of `REG_EQUAL', the register that is set by this insn ! 382: will be equal to OP at run time at the end of this insn but not ! 383: necessarily elsewhere in the function. In this case, OP is ! 384: typically an arithmetic expression. For example, when a sequence ! 385: of insns such as a library call is used to perform an arithmetic ! 386: operation, this kind of note is attached to the insn that ! 387: produces or copies the final value. ! 388: ! 389: These two notes are used in different ways by the compiler passes. ! 390: `REG_EQUAL' is used by passes prior to register allocation (such ! 391: as common subexpression elimination and loop optimization) to ! 392: tell them how to think of that value. `REG_EQUIV' notes are used ! 393: by register allocation to indicate that there is an available ! 394: substitute expression (either a constant or a `mem' expression ! 395: for the location of a parameter on the stack) that may be used in ! 396: place of a register if insufficient registers are available. ! 397: ! 398: Except for stack homes for parameters, which are indicated by a ! 399: `REG_EQUIV' note and are not useful to the early optimization ! 400: passes and pseudo registers that are equivalent to a memory ! 401: location throughout there entire life, which is not detected ! 402: until later in the compilation, all equivalences are initially ! 403: indicated by an attached `REG_EQUAL' note. In the early stages ! 404: of register allocation, a `REG_EQUAL' note is changed into a ! 405: `REG_EQUIV' note if OP is a constant and the insn represents the ! 406: only set of its destination register. ! 407: ! 408: Thus, compiler passes prior to register allocation need only ! 409: check for `REG_EQUAL' notes and passes subsequent to register ! 410: allocation need only check for `REG_EQUIV' notes. ! 411: ! 412: `REG_UNUSED' ! 413: The register OP being set by this insn will not be used in a ! 414: subsequent insn. This differs from a `REG_DEAD' note, which ! 415: indicates that the value in an input will not be used ! 416: subsequently. These two notes are independent; both may be ! 417: present for the same register. ! 418: ! 419: `REG_WAS_0' ! 420: The single output of this insn contained zero before this insn. ! 421: OP is the insn that set it to zero. You can rely on this note if ! 422: it is present and OP has not been deleted or turned into a `note'; ! 423: its absence implies nothing. ! 424: ! 425: These notes describe linkages between insns. They occur in pairs: ! 426: one insn has one of a pair of notes that points to a second insn, ! 427: which has the inverse note pointing back to the first insn. ! 428: ! 429: `REG_RETVAL' ! 430: This insn copies the value of a multi-insn sequence (for example, ! 431: a library call), and OP is the first insn of the sequence (for a ! 432: library call, the first insn that was generated to set up the ! 433: arguments for the library call). ! 434: ! 435: Loop optimization uses this note to treat such a sequence as a ! 436: single operation for code motion purposes and flow analysis uses ! 437: this note to delete such sequences whose results are dead. ! 438: ! 439: A `REG_EQUAL' note will also usually be attached to this insn to ! 440: provide the expression being computed by the sequence. ! 441: ! 442: `REG_LIBCALL' ! 443: This is the inverse of `REG_RETVAL': it is placed on the first ! 444: insn of a multi-insn sequence, and it points to the last one. ! 445: ! 446: `REG_CC_SETTER' ! 447: `REG_CC_USER' ! 448: On machines that use `cc0', the insns which set and use `cc0' set ! 449: and use `cc0' are adjacent. However, when branch delay slot ! 450: filling is done, this may no longer be true. In this case a ! 451: `REG_CC_USER' note will be placed on the insn setting `cc0' to ! 452: point to the insn using `cc0' and a `REG_CC_SETTER' note will be ! 453: placed on the insn using `cc0' to point to the insn setting `cc0'. ! 454: ! 455: These values are only used in the `LOG_LINKS' field, and indicate ! 456: the type of dependency that each link represents. Links which indicate ! 457: a data dependence (a read after write dependence) do not use any code, ! 458: they simply have mode `VOIDmode', and are printed without any ! 459: descriptive text. ! 460: ! 461: `REG_DEP_ANTI' ! 462: This indicates an anti dependence (a write after read dependence). ! 463: ! 464: `REG_DEP_OUTPUT' ! 465: This indicates an output dependence (a write after write ! 466: dependence). ! 467: ! 468: For convenience, the machine mode in an `insn_list' or `expr_list' ! 469: is printed using these symbolic codes in debugging dumps. ! 470: ! 471: The only difference between the expression codes `insn_list' and ! 472: `expr_list' is that the first operand of an `insn_list' is assumed to ! 473: be an insn and is printed in debugging dumps as the insn's unique id; ! 474: the first operand of an `expr_list' is printed in the ordinary way as ! 475: an expression. ! 476: ! 477: ! 478: File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL ! 479: ! 480: RTL Representation of Function-Call Insns ! 481: ========================================= ! 482: ! 483: Insns that call subroutines have the RTL expression code ! 484: `call_insn'. These insns must satisfy special rules, and their bodies ! 485: must use a special RTL expression code, `call'. ! 486: ! 487: A `call' expression has two operands, as follows: ! 488: ! 489: (call (mem:FM ADDR) NBYTES) ! 490: ! 491: Here NBYTES is an operand that represents the number of bytes of ! 492: argument data being passed to the subroutine, FM is a machine mode ! 493: (which must equal as the definition of the `FUNCTION_MODE' macro in ! 494: the machine description) and ADDR represents the address of the ! 495: subroutine. ! 496: ! 497: For a subroutine that returns no value, the `call' expression as ! 498: shown above is the entire body of the insn, except that the insn might ! 499: also contain `use' or `clobber' expressions. ! 500: ! 501: For a subroutine that returns a value whose mode is not `BLKmode', ! 502: the value is returned in a hard register. If this register's number is ! 503: R, then the body of the call insn looks like this: ! 504: ! 505: (set (reg:M R) ! 506: (call (mem:FM ADDR) NBYTES)) ! 507: ! 508: This RTL expression makes it clear (to the optimizer passes) that the ! 509: appropriate register receives a useful value in this insn. ! 510: ! 511: When a subroutine returns a `BLKmode' value, it is handled by ! 512: passing to the subroutine the address of a place to store the value. ! 513: So the call insn itself does not "return" any value, and it has the ! 514: same RTL form as a call that returns nothing. ! 515: ! 516: On some machines, the call instruction itself clobbers some ! 517: register, for example to contain the return address. `call_insn' insns ! 518: on these machines should have a body which is a `parallel' that ! 519: contains both the `call' expression and `clobber' expressions that ! 520: indicate which registers are destroyed. Similarly, if the call ! 521: instruction requires some register other than the stack pointer that ! 522: is not explicitly mentioned it its RTL, a `use' subexpression should ! 523: mention that register. ! 524: ! 525: Functions that are called are assumed to modify all registers ! 526: listed in the configuration macro `CALL_USED_REGISTERS' (*note ! 527: Register Basics::.) and, with the exception of `const' functions and ! 528: library calls, to modify all of memory. ! 529: ! 530: Insns containing just `use' expressions directly precede the ! 531: `call_insn' insn to indicate which registers contain inputs to the ! 532: function. Similarly, if registers other than those in ! 533: `CALL_USED_REGISTERS' are clobbered by the called function, insns ! 534: containing a single `clobber' follow immediately after the call to ! 535: indicate which registers. ! 536: ! 537: ! 538: File: gcc.info, Node: Sharing, Prev: Calls, Up: RTL ! 539: ! 540: Structure Sharing Assumptions ! 541: ============================= ! 542: ! 543: The compiler assumes that certain kinds of RTL expressions are ! 544: unique; there do not exist two distinct objects representing the same ! 545: value. In other cases, it makes an opposite assumption: that no RTL ! 546: expression object of a certain kind appears in more than one place in ! 547: the containing structure. ! 548: ! 549: These assumptions refer to a single function; except for the RTL ! 550: objects that describe global variables and external functions, and a ! 551: few standard objects such as small integer constants, no RTL objects ! 552: are common to two functions. ! 553: ! 554: * Each pseudo-register has only a single `reg' object to represent ! 555: it, and therefore only a single machine mode. ! 556: ! 557: * For any symbolic label, there is only one `symbol_ref' object ! 558: referring to it. ! 559: ! 560: * There is only one `const_int' expression with value 0, only one ! 561: with value 1, and only one with value -1. Some other integer ! 562: values are also stored uniquely. ! 563: ! 564: * There is only one `pc' expression. ! 565: ! 566: * There is only one `cc0' expression. ! 567: ! 568: * There is only one `const_double' expression with value 0 for each ! 569: floating point mode. Likewise for values 1 and 2. ! 570: ! 571: * No `label_ref' or `scratch' appears in more than one place in the ! 572: RTL structure; in other words, it is safe to do a tree-walk of all ! 573: the insns in the function and assume that each time a `label_ref' ! 574: or `scratch' is seen it is distinct from all others that are seen. ! 575: ! 576: * Only one `mem' object is normally created for each static ! 577: variable or stack slot, so these objects are frequently shared in ! 578: all the places they appear. However, separate but equal objects ! 579: for these variables are occasionally made. ! 580: ! 581: * When a single `asm' statement has multiple output operands, a ! 582: distinct `asm_operands' expression is made for each output ! 583: operand. However, these all share the vector which contains the ! 584: sequence of input operands. This sharing is used later on to ! 585: test whether two `asm_operands' expressions come from the same ! 586: statement, so all optimizations must carefully preserve the ! 587: sharing if they copy the vector at all. ! 588: ! 589: * No RTL object appears in more than one place in the RTL structure ! 590: except as described above. Many passes of the compiler rely on ! 591: this by assuming that they can modify RTL objects in place ! 592: without unwanted side-effects on other insns. ! 593: ! 594: * During initial RTL generation, shared structure is freely ! 595: introduced. After all the RTL for a function has been generated, ! 596: all shared structure is copied by `unshare_all_rtl' in ! 597: `emit-rtl.c', after which the above rules are guaranteed to be ! 598: followed. ! 599: ! 600: * During the combiner pass, shared structure within an insn can ! 601: exist temporarily. However, the shared structure is copied ! 602: before the combiner is finished with the insn. This is done by ! 603: calling `copy_rtx_if_shared', which is a subroutine of ! 604: `unshare_all_rtl'. ! 605: ! 606: ! 607: File: gcc.info, Node: Machine Desc, Next: Target Macros, Prev: RTL, Up: Top ! 608: ! 609: Machine Descriptions ! 610: ******************** ! 611: ! 612: A machine description has two parts: a file of instruction patterns ! 613: (`.md' file) and a C header file of macro definitions. ! 614: ! 615: The `.md' file for a target machine contains a pattern for each ! 616: instruction that the target machine supports (or at least each ! 617: instruction that is worth telling the compiler about). It may also ! 618: contain comments. A semicolon causes the rest of the line to be a ! 619: comment, unless the semicolon is inside a quoted string. ! 620: ! 621: See the next chapter for information on the C header file. ! 622: ! 623: * Menu: ! 624: ! 625: * Patterns:: How to write instruction patterns. ! 626: * Example:: An explained example of a `define_insn' pattern. ! 627: * RTL Template:: The RTL template defines what insns match a pattern. ! 628: * Output Template:: The output template says how to make assembler code ! 629: from such an insn. ! 630: * Output Statement:: For more generality, write C code to output ! 631: the assembler code. ! 632: * Constraints:: When not all operands are general operands. ! 633: * Standard Names:: Names mark patterns to use for code generation. ! 634: * Pattern Ordering:: When the order of patterns makes a difference. ! 635: * Dependent Patterns:: Having one pattern may make you need another. ! 636: * Jump Patterns:: Special considerations for patterns for jump insns. ! 637: * Insn Canonicalizations::Canonicalization of Instructions ! 638: * Peephole Definitions::Defining machine-specific peephole optimizations. ! 639: * Expander Definitions::Generating a sequence of several RTL insns ! 640: for a standard operation. ! 641: * Insn Splitting:: Splitting Instructions into Multiple Instructions ! 642: * Insn Attributes:: Specifying the value of attributes for generated insns. ! 643: ! 644: 1.1 root 645: File: gcc.info, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc 646: 647: Everything about Instruction Patterns 648: ===================================== 649: 650: Each instruction pattern contains an incomplete RTL expression, 651: with pieces to be filled in later, operand constraints that restrict 652: how the pieces can be filled in, and an output pattern or C code to 653: generate the assembler output, all wrapped up in a `define_insn' 654: expression. 655: 656: A `define_insn' is an RTL expression containing four or five 657: operands: 658: 659: 1. An optional name. The presence of a name indicate that this 660: instruction pattern can perform a certain standard job for the 661: RTL-generation pass of the compiler. This pass knows certain 662: names and will use the instruction patterns with those names, if 663: the names are defined in the machine description. 664: 665: The absence of a name is indicated by writing an empty string 666: where the name should go. Nameless instruction patterns are never 667: used for generating RTL code, but they may permit several simpler 668: insns to be combined later on. 669: 670: Names that are not thus known and used in RTL-generation have 671: no effect; they are equivalent to no name at all. 672: 673: 2. The "RTL template" (*note RTL Template::.) is a vector of 674: incomplete RTL expressions which show what the instruction should 675: look like. It is incomplete because it may contain 676: `match_operand', `match_operator', and `match_dup' expressions 677: that stand for operands of the instruction. 678: 679: If the vector has only one element, that element is the 680: template for the instruction pattern. If the vector has multiple 681: elements, then the instruction pattern is a `parallel' expression 682: containing the elements described. 683: 684: 3. A condition. This is a string which contains a C expression that 685: is the final test to decide whether an insn body matches this 686: pattern. 687: 688: For a named pattern, the condition (if present) may not depend 689: on the data in the insn being matched, but only the 690: target-machine-type flags. The compiler needs to test these 691: conditions during initialization in order to learn exactly which 692: named instructions are available in a particular run. 693: 694: For nameless patterns, the condition is applied only when 695: matching an individual insn, and only after the insn has matched 696: the pattern's recognition template. The insn's operands may be 697: found in the vector `operands'. 698: 699: 4. The "output template": a string that says how to output matching 700: insns as assembler code. `%' in this string specifies where to 701: substitute the value of an operand. *Note Output Template::. 702: 703: When simple substitution isn't general enough, you can specify 704: a piece of C code to compute the output. *Note Output 705: Statement::. 706: 707: 5. Optionally, a vector containing the values of attributes for 708: insns matching this pattern. *Note Insn Attributes::. 709: 710: 711: File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 712: 713: Example of `define_insn' 714: ======================== 715: 716: Here is an actual example of an instruction pattern, for the 717: 68000/68020. 718: 719: (define_insn "tstsi" 720: [(set (cc0) 721: (match_operand:SI 0 "general_operand" "rm"))] 722: "" 723: "* 724: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 725: return \"tstl %0\"; 726: return \"cmpl #0,%0\"; }") 727: 728: This is an instruction that sets the condition codes based on the 729: value of a general operand. It has no condition, so any insn whose 730: RTL description has the form shown may be handled according to this 731: pattern. The name `tstsi' means "test a `SImode' value" and tells the 732: RTL generation pass that, when it is necessary to test such a value, 733: an insn to do so can be constructed using this pattern. 734: 735: The output control string is a piece of C code which chooses which 736: output template to return based on the kind of operand and the specific 737: type of CPU for which code is being generated. 738: 739: `"rm"' is an operand constraint. Its meaning is explained below. 740: 741: 742: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 743: 744: RTL Template for Generating and Recognizing Insns 745: ================================================= 746: 747: The RTL template is used to define which insns match the particular 748: pattern and how to find their operands. For named patterns, the RTL 749: template also says how to construct an insn from specified operands. 750: 751: Construction involves substituting specified operands into a copy 752: of the template. Matching involves determining the values that serve 753: as the operands in the insn being matched. Both of these activities 754: are controlled by special expression types that direct matching and 755: substitution of the operands. 756: 757: `(match_operand:M N PREDICATE CONSTRAINT)' 758: This expression is a placeholder for operand number N of the 759: insn. When constructing an insn, operand number N will be 760: substituted at this point. When matching an insn, whatever 761: appears at this position in the insn will be taken as operand 762: number N; but it must satisfy PREDICATE or this instruction 763: pattern will not match at all. 764: 765: Operand numbers must be chosen consecutively counting from zero in 766: each instruction pattern. There may be only one `match_operand' 767: expression in the pattern for each operand number. Usually 768: operands are numbered in the order of appearance in 769: `match_operand' expressions. 770: 771: PREDICATE is a string that is the name of a C function that 772: accepts two arguments, an expression and a machine mode. During 773: matching, the function will be called with the putative operand 774: as the expression and M as the mode argument (if M is not 775: specified, `VOIDmode' will be used, which normally causes 776: PREDICATE to accept any mode). If it returns zero, this 777: instruction pattern fails to match. PREDICATE may be an empty 778: string; then it means no test is to be done on the operand, so 779: anything which occurs in this position is valid. 780: 781: Most of the time, PREDICATE will reject modes other than M--but 782: not always. For example, the predicate `address_operand' uses M 783: as the mode of memory ref that the address should be valid for. 784: Many predicates accept `const_int' nodes even though their mode is 785: `VOIDmode'. 786: 787: CONSTRAINT controls reloading and the choice of the best register 788: class to use for a value, as explained later (*note 789: Constraints::.). 790: 791: People are often unclear on the difference between the constraint 792: and the predicate. The predicate helps decide whether a given 793: insn matches the pattern. The constraint plays no role in this 794: decision; instead, it controls various decisions in the case of 795: an insn which does match. 796: 797: On CISC machines, PREDICATE is most often `"general_operand"'. 798: This function checks that the putative operand is either a 799: constant, a register or a memory reference, and that it is valid 800: for mode M. 801: 802: For an operand that must be a register, PREDICATE should be 803: `"register_operand"'. It would be valid to use 804: `"general_operand"', since the reload pass would copy any 805: non-register operands through registers, but this would make GNU 806: CC do extra work, it would prevent invariant operands (such as 807: constant) from being removed from loops, and it would prevent the 808: register allocator from doing the best possible job. On RISC 809: machines, it is usually most efficient to allow PREDICATE to 810: accept only objects that the constraints allow. 811: 812: For an operand that must be a constant, either use 813: `"immediate_operand"' for PREDICATE, or make the instruction 814: pattern's extra condition require a constant, or both. You cannot 815: expect the constraints to do this work! If the constraints allow 816: only constants, but the predicate allows something else, the 817: compiler will crash when that case arises. 818: 819: `(match_scratch:M N CONSTRAINT)' 820: This expression is also a placeholder for operand number N and 821: indicates that operand must be a `scratch' or `reg' expression. 822: 823: When matching patterns, this is completely equivalent to 824: 825: (match_operand:M N "scratch_operand" PRED) 826: 827: but, when generating RTL, it produces a (`scratch':M) expression. 828: 829: If the last few expressions in a `parallel' are `clobber' 830: expressions whose operands are either a hard register or 831: `match_scratch', the combiner can add them when necessary. *Note 832: Side Effects::. 833: 834: `(match_dup N)' 835: This expression is also a placeholder for operand number N. It 836: is used when the operand needs to appear more than once in the 837: insn. 838: 839: In construction, `match_dup' behaves exactly like 840: `match_operand': the operand is substituted into the insn being 841: constructed. But in matching, `match_dup' behaves differently. 842: It assumes that operand number N has already been determined by a 843: `match_operand' appearing earlier in the recognition template, 844: and it matches only an identical-looking expression. 845: 846: `(match_operator:M N PREDICATE [OPERANDS...])' 847: This pattern is a kind of placeholder for a variable RTL 848: expression code. 849: 850: When constructing an insn, it stands for an RTL expression whose 851: expression code is taken from that of operand N, and whose 852: operands are constructed from the patterns OPERANDS. 853: 854: When matching an expression, it matches an expression if the 855: function PREDICATE returns nonzero on that expression *and* the 856: patterns OPERANDS match the operands of the expression. 857: 858: Suppose that the function `commutative_operator' is defined as 859: follows, to match any expression whose operator is one of the 860: commutative arithmetic operators of RTL and whose mode is MODE: 861: 862: int 863: commutative_operator (x, mode) 864: rtx x; 865: enum machine_mode mode; 866: { 867: enum rtx_code code = GET_CODE (x); 868: if (GET_MODE (x) != mode) 869: return 0; 870: return GET_RTX_CLASS (code) == 'c' || code == EQ || code == NE; 871: } 872: 873: Then the following pattern will match any RTL expression 874: consisting of a commutative operator applied to two general 875: operands: 876: 877: (match_operator:SI 3 "commutative_operator" 878: [(match_operand:SI 1 "general_operand" "g") 879: (match_operand:SI 2 "general_operand" "g")]) 880: 881: Here the vector `[OPERANDS...]' contains two patterns because the 882: expressions to be matched all contain two operands. 883: 884: When this pattern does match, the two operands of the commutative 885: operator are recorded as operands 1 and 2 of the insn. (This is 886: done by the two instances of `match_operand'.) Operand 3 of the 887: insn will be the entire commutative expression: use `GET_CODE 888: (operands[3])' to see which commutative operator was used. 889: 890: The machine mode M of `match_operator' works like that of 891: `match_operand': it is passed as the second argument to the 892: predicate function, and that function is solely responsible for 893: deciding whether the expression to be matched "has" that mode. 894: 895: When constructing an insn, argument 3 of the gen-function will 896: specify the operation (i.e. the expression code) for the 897: expression to be made. It should be an RTL expression, whose 898: expression code is copied into a new expression whose operands 899: are arguments 1 and 2 of the gen-function. The subexpressions of 900: argument 3 are not used; only its expression code matters. 901: 902: When `match_operator' is used in a pattern for matching an insn, 903: it usually best if the operand number of the `match_operator' is 904: higher than that of the actual operands of the insn. This 905: improves register allocation because the register allocator often 906: looks at operands 1 and 2 of insns to see if it can do register 907: tying. 908: 909: There is no way to specify constraints in `match_operator'. The 910: operand of the insn which corresponds to the `match_operator' 911: never has any constraints because it is never reloaded as a whole. 912: However, if parts of its OPERANDS are matched by `match_operand' 913: patterns, those parts may have constraints of their own. 914: 915: `(address (match_operand:M N "address_operand" ""))' 916: This complex of expressions is a placeholder for an operand number 917: N in a "load address" instruction: an operand which specifies a 918: memory location in the usual way, but for which the actual operand 919: value used is the address of the location, not the contents of the 920: location. 921: 922: `address' expressions never appear in RTL code, only in machine 923: descriptions. And they are used only in machine descriptions 924: that do not use the operand constraint feature. When operand 925: constraints are in use, the letter `p' in the constraint serves 926: this purpose. 927: 928: M is the machine mode of the *memory location being addressed*, 929: not the machine mode of the address itself. That mode is always 930: the same on a given target machine (it is `Pmode', which normally 931: is `SImode'), so there is no point in mentioning it; thus, no 932: machine mode is written in the `address' expression. If some day 933: support is added for machines in which addresses of different 934: kinds of objects appear differently or are used differently (such 935: as the PDP-10), different formats would perhaps need different 936: machine modes and these modes might be written in the `address' 937: expression. 938: 939: 940: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 941: 942: Output Templates and Operand Substitution 943: ========================================= 944: 945: The "output template" is a string which specifies how to output the 946: assembler code for an instruction pattern. Most of the template is a 947: fixed string which is output literally. The character `%' is used to 948: specify where to substitute an operand; it can also be used to 949: identify places where different variants of the assembler require 950: different syntax. 951: 952: In the simplest case, a `%' followed by a digit N says to output 953: operand N at that point in the string. 954: 955: `%' followed by a letter and a digit says to output an operand in an 956: alternate fashion. Four letters have standard, built-in meanings 957: described below. The machine description macro `PRINT_OPERAND' can 958: define additional letters with nonstandard meanings. 959: 960: `%cDIGIT' can be used to substitute an operand that is a constant 961: value without the syntax that normally indicates an immediate operand. 962: 963: `%nDIGIT' is like `%cDIGIT' except that the value of the constant 964: is negated before printing. 965: 966: `%aDIGIT' can be used to substitute an operand as if it were a 967: memory reference, with the actual operand treated as the address. 968: This may be useful when outputting a "load address" instruction, 969: because often the assembler syntax for such an instruction requires 970: you to write the operand as if it were a memory reference. 971: 972: `%lDIGIT' is used to substitute a `label_ref' into a jump 973: instruction. 974: 975: `%' followed by a punctuation character specifies a substitution 976: that does not use an operand. Only one case is standard: `%%' outputs 977: a `%' into the assembler code. Other nonstandard cases can be defined 978: in the `PRINT_OPERAND' macro. You must also define which punctuation 979: characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 980: 981: The template may generate multiple assembler instructions. Write 982: the text for the instructions, with `\;' between them. 983: 984: When the RTL contains two operands which are required by constraint 985: to match each other, the output template must refer only to the 986: lower-numbered operand. Matching operands are not always identical, 987: and the rest of the compiler arranges to put the proper RTL expression 988: for printing into the lower-numbered operand. 989: 990: One use of nonstandard letters or punctuation following `%' is to 991: distinguish between different assembler languages for the same 992: machine; for example, Motorola syntax versus MIT syntax for the 68000. 993: Motorola syntax requires periods in most opcode names, while MIT 994: syntax does not. For example, the opcode `movel' in MIT syntax is 995: `move.l' in Motorola syntax. The same file of patterns is used for 996: both kinds of output syntax, but the character sequence `%.' is used 997: in each place where Motorola syntax wants a period. The 998: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to 999: output a period; the macro for MIT syntax defines it to do nothing. 1000: 1001: 1002: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc 1003: 1004: C Statements for Generating Assembler Output 1005: ============================================ 1006: 1007: Often a single fixed template string cannot produce correct and 1008: efficient assembler code for all the cases that are recognized by a 1009: single instruction pattern. For example, the opcodes may depend on 1010: the kinds of operands; or some unfortunate combinations of operands 1011: may require extra machine instructions. 1012: 1013: If the output control string starts with a `@', then it is actually 1014: a series of templates, each on a separate line. (Blank lines and 1015: leading spaces and tabs are ignored.) The templates correspond to the 1016: pattern's constraint alternatives (*note Multi-Alternative::.). For 1017: example, if a target machine has a two-address add instruction `addr' 1018: to add into a register and another `addm' to add a register to memory, 1019: you might write this pattern: 1020: 1021: (define_insn "addsi3" 1022: [(set (match_operand:SI 0 "general_operand" "r,m") 1023: (plus:SI (match_operand:SI 1 "general_operand" "0,0") 1024: (match_operand:SI 2 "general_operand" "g,r")))] 1025: "" 1026: "@ 1027: addr %1,%0 1028: addm %1,%0") 1029: 1030: If the output control string starts with a `*', then it is not an 1031: output template but rather a piece of C program that should compute a 1032: template. It should execute a `return' statement to return the 1033: template-string you want. Most such templates use C string literals, 1034: which require doublequote characters to delimit them. To include these 1035: doublequote characters in the string, prefix each one with `\'. 1036: 1037: The operands may be found in the array `operands', whose C data type 1038: is `rtx []'. 1039: 1040: It is very common to select different ways of generating assembler 1041: code based on whether an immediate operand is within a certain range. 1042: Be careful when doing this, because the result of `INTVAL' is an 1043: integer on the host machine. If the host machine has more bits in an 1044: `int' than the target machine has in the mode in which the constant 1045: will be used, then some of the bits you get from `INTVAL' will be 1046: superfluous. For proper results, you must carefully disregard the 1047: values of those bits. 1048: 1049: It is possible to output an assembler instruction and then go on to 1050: output or compute more of them, using the subroutine 1051: `output_asm_insn'. This receives two arguments: a template-string and 1052: a vector of operands. The vector may be `operands', or it may be 1053: another array of `rtx' that you declare locally and initialize 1054: yourself. 1055: 1056: When an insn pattern has multiple alternatives in its constraints, 1057: often the appearance of the assembler code is determined mostly by 1058: which alternative was matched. When this is so, the C code can test 1059: the variable `which_alternative', which is the ordinal number of the 1060: alternative that was actually satisfied (0 for the first, 1 for the 1061: second alternative, etc.). 1062: 1063: For example, suppose there are two opcodes for storing zero, 1064: `clrreg' for registers and `clrmem' for memory locations. Here is how 1065: a pattern could use `which_alternative' to choose between them: 1066: 1067: (define_insn "" 1068: [(set (match_operand:SI 0 "general_operand" "r,m") 1069: (const_int 0))] 1070: "" 1071: "* 1072: return (which_alternative == 0 1073: ? \"clrreg %0\" : \"clrmem %0\"); 1074: ") 1075: 1076: The example above, where the assembler code to generate was 1077: *solely* determined by the alternative, could also have been specified 1078: as follows, having the output control string start with a `@': 1079: 1080: (define_insn "" 1081: [(set (match_operand:SI 0 "general_operand" "r,m") 1082: (const_int 0))] 1083: "" 1084: "@ 1085: clrreg %0 1086: clrmem %0") 1087: 1088: 1089: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc 1090: 1091: Operand Constraints 1092: =================== 1093: 1094: Each `match_operand' in an instruction pattern can specify a 1095: constraint for the type of operands allowed. Constraints can say 1096: whether an operand may be in a register, and which kinds of register; 1097: whether the operand can be a memory reference, and which kinds of 1098: address; whether the operand may be an immediate constant, and which 1099: possible values it may have. Constraints can also require two 1100: operands to match. 1101: 1102: * Menu: 1103: 1104: * Simple Constraints:: Basic use of constraints. 1105: * Multi-Alternative:: When an insn has two alternative constraint-patterns. 1106: * Class Preferences:: Constraints guide which hard register to put things in. 1107: * Modifiers:: More precise control over effects of constraints. 1108: * No Constraints:: Describing a clean machine without constraints. 1109: 1110:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.