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