![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to internals-4 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: 1.1.1.2 ! root 2: ! 3: File: internals, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL ! 4: ! 5: Side Effect Expressions ! 6: ======================= ! 7: ! 8: The expression codes described so far represent values, not actions. But ! 9: machine instructions never produce values; they are meaningful only for ! 10: their side effects on the state of the machine. Special expression codes ! 11: are used to represent side effects. ! 12: ! 13: The body of an instruction is always one of these side effect codes; the ! 14: codes described above, which represent values, appear only as the operands ! 15: of these. ! 16: ! 17: `(set LVAL X)' ! 18: Represents the action of storing the value of X into the place ! 19: represented by LVAL. LVAL must be an expression representing a place ! 20: that can be stored in: `reg' (or `subreg' or `strict_low_part'), ! 21: `mem', `pc' or `cc0'. ! 22: ! 23: If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then X ! 24: must be valid for that mode. ! 25: ! 26: If LVAL is a `reg' whose machine mode is less than the full width of ! 27: the register, then it means that the part of the register specified by ! 28: the machine mode is given the specified value and the rest of the ! 29: register receives an undefined value. Likewise, if LVAL is a `subreg' ! 30: whose machine mode is narrower than `SImode', the rest of the register ! 31: can be changed in an undefined way. ! 32: ! 33: If LVAL is a `strict_low_part' of a `subreg', then the part of the ! 34: register specified by the machine mode of the `subreg' is given the ! 35: value X and the rest of the register is not changed. ! 36: ! 37: If LVAL is `(cc0)', it has no machine mode, and X may have any mode. ! 38: This represents a ``test'' or ``compare'' instruction. ! 39: ! 40: If LVAL is `(pc)', we have a jump instruction, and the possibilities ! 41: for X are very limited. It may be a `label_ref' expression ! 42: (unconditional jump). It may be an `if_then_else' (conditional jump), ! 43: in which case either the second or the third operand must be `(pc)' ! 44: (for the case which does not jump) and the other of the two must be a ! 45: `label_ref' (for the case which does jump). X may also be a `mem' or ! 46: `(plus:SI (pc) Y)', where Y may be a `reg' or a `mem'; these unusual ! 47: patterns are used to represent jumps through branch tables. ! 48: ! 49: `(return)' ! 50: Represents a return from the current function, on machines where this ! 51: can be done with one instruction, such as Vaxes. On machines where a ! 52: multi-instruction ``epilogue'' must be executed in order to return ! 53: from the function, returning is done by jumping to a label which ! 54: precedes the epilogue, and the `return' expression code is never used. ! 55: ! 56: `(call FUNCTION NARGS)' ! 57: Represents a function call. FUNCTION is a `mem' expression whose ! 58: address is the address of the function to be called. NARGS is an ! 59: expression representing the number of words of argument. ! 60: ! 61: Each machine has a standard machine mode which FUNCTION must have. ! 62: The machine description defines macro `FUNCTION_MODE' to expand into ! 63: the requisite mode name. The purpose of this mode is to specify what ! 64: kind of addressing is allowed, on machines where the allowed kinds of ! 65: addressing depend on the machine mode being addressed. ! 66: ! 67: `(clobber X)' ! 68: Represents the storing or possible storing of an unpredictable, ! 69: undescribed value into X, which must be a `reg' or `mem' expression. ! 70: ! 71: One place this is used is in string instructions that store standard ! 72: values into particular hard registers. It may not be worth the ! 73: trouble to describe the values that are stored, but it is essential to ! 74: inform the compiler that the registers will be altered, lest it ! 75: attempt to keep data in them across the string instruction. ! 76: ! 77: X may also be null---a null C pointer, no expression at all. Such a ! 78: `(clobber (null))' expression means that all memory locations must be ! 79: presumed clobbered. ! 80: ! 81: Note that the machine description classifies certain hard registers as ! 82: ``call-clobbered''. All function call instructions are assumed by ! 83: default to clobber these registers, so there is no need to use ! 84: `clobber' expressions to indicate this fact. Also, each function call ! 85: is assumed to have the potential to alter any memory location. ! 86: ! 87: `(use X)' ! 88: Represents the use of the value of X. It indicates that the value in ! 89: X at this point in the program is needed, even though it may not be ! 90: apparent why this is so. Therefore, the compiler will not attempt to ! 91: delete instructions whose only effect is to store a value in X. X ! 92: must be a `reg' expression. ! 93: ! 94: `(parallel [X0 X1 ...])' ! 95: Represents several side effects performed in parallel. The square ! 96: brackets stand for a vector; the operand of `parallel' is a vector of ! 97: expressions. X0, X1 and so on are individual side ! 98: effects---expressions of code `set', `call', `return', `clobber' or ! 99: `use'. ! 100: ! 101: ``In parallel'' means that first all the values used in the individual ! 102: side-effects are computed, and second all the actual side-effects are ! 103: performed. For example, ! 104: ! 105: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) ! 106: (set (mem:SI (reg:SI 1)) (reg:SI 1))]) ! 107: ! 108: says unambiguously that the values of hard register 1 and the memory ! 109: location addressed by it are interchanged. In both places where ! 110: `(reg:SI 1)' appears as a memory address it refers to the value in ! 111: register 1 *before* the execution of the instruction. ! 112: ! 113: `(sequence [INSNS ...])' ! 114: Represents a sequence of insns. Each of the INSNS that appears in the ! 115: vector is suitable for appearing in the chain of insns, so it must be ! 116: an `insn', `jump_insn', `call_insn', `code_label', `barrier' or `note'. ! 117: ! 118: A `sequence' RTX never appears in an actual insn. It represents the ! 119: sequence of insns that result from a `define_expand' *before* those ! 120: insns are passed to `emit_insn' to insert them in the chain of insns. ! 121: When actually inserted, the individual sub-insns are separated out and ! 122: the `sequence' is forgotten. ! 123: ! 124: Three expression codes appear in place of a side effect, as the body of an ! 125: insn, though strictly speaking they do not describe side effects as such: ! 126: ! 127: `(asm_input S)' ! 128: Represents literal assembler code as described by the string S. ! 129: ! 130: `(addr_vec:M [LR0 LR1 ...])' ! 131: Represents a table of jump addresses. The vector elements LR0, etc., ! 132: are `label_ref' expressions. The mode M specifies how much space is ! 133: given to each address; normally M would be `Pmode'. ! 134: ! 135: `(addr_diff_vec:M BASE [LR0 LR1 ...])' ! 136: Represents a table of jump addresses expressed as offsets from BASE. ! 137: The vector elements LR0, etc., are `label_ref' expressions and so is ! 138: BASE. The mode M specifies how much space is given to each ! 139: address-difference. ! 140: ! 141: ! 142: File: internals, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 1.1 root 143: 1.1.1.2 ! root 144: Embedded Side-Effects on Addresses ! 145: ================================== 1.1 root 146: 1.1.1.2 ! root 147: Four special side-effect expression codes appear as memory addresses. 1.1 root 148: 1.1.1.2 ! root 149: `(pre_dec:M X)' ! 150: Represents the side effect of decrementing X by a standard amount and ! 151: represents also the value that X has after being decremented. X must ! 152: be a `reg' or `mem', but most machines allow only a `reg'. M must be ! 153: the machine mode for pointers on the machine in use. The amount X is ! 154: decremented by is the length in bytes of the machine mode of the ! 155: containing memory reference of which this expression serves as the ! 156: address. Here is an example of its use: ! 157: ! 158: (mem:DF (pre_dec:SI (reg:SI 39))) ! 159: ! 160: This says to decrement pseudo register 39 by the length of a `DFmode' ! 161: value and use the result to address a `DFmode' value. ! 162: ! 163: `(pre_inc:M X)' ! 164: Similar, but specifies incrementing X instead of decrementing it. ! 165: ! 166: `(post_dec:M X)' ! 167: Represents the same side effect as `pre_decrement' but a different ! 168: value. The value represented here is the value X has before being ! 169: decremented. ! 170: ! 171: `(post_inc:M X)' ! 172: Similar, but specifies incrementing X instead of decrementing it. ! 173: ! 174: These embedded side effect expressions must be used with care. Instruction ! 175: patterns may not use them. Until the `flow' pass of the compiler, they may ! 176: occur only to represent pushes onto the stack. The `flow' pass finds cases ! 177: where registers are incremented or decremented in one instruction and used ! 178: as an address shortly before or after; these cases are then transformed to ! 179: use pre- or post-increment or -decrement. ! 180: ! 181: Explicit popping of the stack could be represented with these embedded side ! 182: effect operators, but that would not be safe; the instruction combination ! 183: pass could move the popping past pushes, thus changing the meaning of the ! 184: code. ! 185: ! 186: An instruction that can be represented with an embedded side effect could ! 187: also be represented using `parallel' containing an additional `set' to ! 188: describe how the address register is altered. This is not done because ! 189: machines that allow these operations at all typically allow them wherever a ! 190: memory address is called for. Describing them as additional parallel ! 191: stores would require doubling the number of entries in the machine ! 192: description. 1.1 root 193: 1.1.1.2 ! root 194: ! 195: File: internals, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL 1.1 root 196: 1.1.1.2 ! root 197: Assembler Instructions as Expressions ! 198: ===================================== 1.1 root 199: 1.1.1.2 ! root 200: The RTX code `asm_operands' represents a value produced by a user-specified ! 201: assembler instruction. It is used to represent an `asm' statement with ! 202: arguments. An `asm' statement with a single output operand, like this: ! 203: ! 204: asm ("foo %1,%2,%0" : "a" (outputvar) : "g" (x + y), "di" (*z)); ! 205: ! 206: is represented using a single `asm_operands' RTX which represents the value ! 207: that is stored in `outputvar': ! 208: ! 209: (set RTX-FOR-OUTPUTVAR ! 210: (asm_operands "foo %1,%2,%0" "a" 0 ! 211: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] ! 212: [(asm_input:M1 "g") ! 213: (asm_input:M2 "di")])) ! 214: ! 215: Here the operands of the `asm_operands' RTX are the assembler template ! 216: string, the output-operand's constraint, the index-number of the output ! 217: operand among the output operands specified, a vector of input operand ! 218: RTX's, and a vector of input-operand modes and constraints. The mode M1 is ! 219: the mode of the sum `x+y'; M2 is that of `*z'. ! 220: ! 221: When an `asm' statement has multiple output values, its insn has several ! 222: such `set' RTX's inside of a `parallel'. Each `set' contains a ! 223: `asm_operands'; all of these share the same assembler template and vectors, ! 224: but each contains the constraint for the respective output operand. They ! 225: are also distinguished by the output-operand index number, which is 0, 1, ! 226: ... for successive output operands. 1.1 root 227: 1.1.1.2 ! root 228: ! 229: File: internals, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL 1.1 root 230: 1.1.1.2 ! root 231: Insns ! 232: ===== 1.1 root 233: 1.1.1.2 ! root 234: The RTL representation of the code for a function is a doubly-linked chain ! 235: of objects called "insns". Insns are expressions with special codes that ! 236: are used for no other purpose. Some insns are actual instructions; others ! 237: represent dispatch tables for `switch' statements; others represent labels ! 238: to jump to or various sorts of declarative information. ! 239: ! 240: In addition to its own specific data, each insn must have a unique ! 241: id-number that distinguishes it from all other insns in the current ! 242: function, and chain pointers to the preceding and following insns. These ! 243: three fields occupy the same position in every insn, independent of the ! 244: expression code of the insn. They could be accessed with `XEXP' and ! 245: `XINT', but instead three special macros are always used: ! 246: ! 247: `INSN_UID (I)' ! 248: Accesses the unique id of insn I. ! 249: ! 250: `PREV_INSN (I)' ! 251: Accesses the chain pointer to the insn preceding I. If I is the first ! 252: insn, this is a null pointer. ! 253: ! 254: `NEXT_INSN (I)' ! 255: Accesses the chain pointer to the insn following I. If I is the last ! 256: insn, this is a null pointer. ! 257: ! 258: The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if I is ! 259: not the first insn, ! 260: ! 261: NEXT_INSN (PREV_INSN (INSN)) == INSN ! 262: ! 263: is always true. ! 264: ! 265: Every insn has one of the following six expression codes: ! 266: ! 267: `insn' ! 268: The expression code `insn' is used for instructions that do not jump ! 269: and do not do function calls. Insns with code `insn' have four ! 270: additional fields beyond the three mandatory ones listed above. These ! 271: four are described in a table below. ! 272: ! 273: `jump_insn' ! 274: The expression code `jump_insn' is used for instructions that may jump ! 275: (or, more generally, may contain `label_ref' expressions). ! 276: `jump_insn' insns have the same extra fields as `insn' insns, accessed ! 277: in the same way. ! 278: ! 279: `call_insn' ! 280: The expression code `call_insn' is used for instructions that may do ! 281: function calls. It is important to distinguish these instructions ! 282: because they imply that certain registers and memory locations may be ! 283: altered unpredictably. ! 284: ! 285: `call_insn' insns have the same extra fields as `insn' insns, accessed ! 286: in the same way. ! 287: ! 288: `code_label' ! 289: A `code_label' insn represents a label that a jump insn can jump to. ! 290: It contains one special field of data in addition to the three ! 291: standard ones. It is used to hold the "label number", a number that ! 292: identifies this label uniquely among all the labels in the compilation ! 293: (not just in the current function). Ultimately, the label is ! 294: represented in the assembler output as an assembler label `LN' where N ! 295: is the label number. ! 296: ! 297: `barrier' ! 298: Barriers are placed in the instruction stream after unconditional jump ! 299: instructions to indicate that the jumps are unconditional. They ! 300: contain no information beyond the three standard fields. ! 301: ! 302: `note' ! 303: `note' insns are used to represent additional debugging and ! 304: declarative information. They contain two nonstandard fields, an ! 305: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a ! 306: string accessed with `NOTE_SOURCE_FILE'. ! 307: ! 308: If `NOTE_LINE_NUMBER' is positive, the note represents the position of ! 309: a source line and `NOTE_SOURCE_FILE' is the source file name that the ! 310: line came from. These notes control generation of line number data in ! 311: the assembler output. ! 312: ! 313: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a code ! 314: with one of the following values (and `NOTE_SOURCE_FILE' must contain ! 315: a null pointer): ! 316: ! 317: `NOTE_INSN_DELETED' ! 318: Such a note is completely ignorable. Some passes of the compiler ! 319: delete insns by altering them into notes of this kind. ! 320: ! 321: `NOTE_INSN_BLOCK_BEG' ! 322: `NOTE_INSN_BLOCK_END' ! 323: These types of notes indicate the position of the beginning and ! 324: end of a level of scoping of variable names. They control the ! 325: output of debugging information. ! 326: ! 327: `NOTE_INSN_LOOP_BEG' ! 328: `NOTE_INSN_LOOP_END' ! 329: These types of notes indicate the position of the beginning and ! 330: end of a `while' or `for' loop. They enable the loop optimizer ! 331: to find loops quickly. ! 332: ! 333: Here is a table of the extra fields of `insn', `jump_insn' and `call_insn' ! 334: insns: ! 335: ! 336: `PATTERN (I)' ! 337: An expression for the side effect performed by this insn. ! 338: ! 339: `REG_NOTES (I)' ! 340: A list (chain of `expr_list' expressions) giving information about the ! 341: usage of registers in this insn. This list is set up by the flow ! 342: analysis pass; it is a null pointer until then. ! 343: ! 344: `LOG_LINKS (I)' ! 345: A list (chain of `insn_list' expressions) of previous ``related'' ! 346: insns: insns which store into registers values that are used for the ! 347: first time in this insn. (An additional constraint is that neither a ! 348: jump nor a label may come between the related insns). This list is ! 349: set up by the flow analysis pass; it is a null pointer until then. ! 350: ! 351: `INSN_CODE (I)' ! 352: An integer that says which pattern in the machine description matches ! 353: this insn, or -1 if the matching has not yet been attempted. ! 354: ! 355: Such matching is never attempted and this field is not used on an insn ! 356: whose pattern consists of a single `use', `clobber', `asm', `addr_vec' ! 357: or `addr_diff_vec' expression. ! 358: ! 359: The `LOG_LINKS' field of an insn is a chain of `insn_list' expressions. ! 360: Each of these has two operands: the first is an insn, and the second is ! 361: another `insn_list' expression (the next one in the chain). The last ! 362: `insn_list' in the chain has a null pointer as second operand. The ! 363: significant thing about the chain is which insns appear in it (as first ! 364: operands of `insn_list' expressions). Their order is not significant. ! 365: ! 366: The `REG_NOTES' field of an insn is a similar chain but of `expr_list' ! 367: expressions instead of `insn_list'. There are four kinds of register ! 368: notes, which are distinguished by the machine mode of the `expr_list', ! 369: which a register note is really understood as being an `enum reg_note'. ! 370: The first operand OP of the `expr_list' is data whose meaning depends on ! 371: the kind of note. Here are the four kinds: ! 372: ! 373: `REG_DEAD' ! 374: The register OP dies in this insn; that is to say, altering the value ! 375: immediately after this insn would not affect the future behavior of ! 376: the program. ! 377: ! 378: `REG_INC' ! 379: The register OP is incremented (or decremented; at this level there is ! 380: no distinction) by an embedded side effect inside this insn. This ! 381: means it appears in a `POST_INC', `PRE_INC', `POST_DEC' or `PRE_DEC' ! 382: RTX. ! 383: ! 384: `REG_EQUIV' ! 385: The register that is set by this insn will be equal to OP at run time, ! 386: and could validly be replaced in all its occurrences by OP. ! 387: (``Validly'' here refers to the data flow of the program; simple ! 388: replacement may make some insns invalid.) ! 389: ! 390: The value which the insn explicitly copies into the register may look ! 391: different from OP, but they will be equal at run time. ! 392: ! 393: For example, when a constant is loaded into a register that is never ! 394: assigned any other value, this kind of note is used. ! 395: ! 396: When a parameter is copied into a pseudo-register at entry to a ! 397: function, a note of this kind records that the register is equivalent ! 398: to the stack slot where the parameter was passed. Although in this ! 399: case the register may be set by other insns, it is still valid to ! 400: replace the register by the stack slot throughout the function. ! 401: ! 402: `REG_EQUAL' ! 403: The register that is set by this insn will be equal to OP at run time ! 404: at the end of this insn (but not necessarily elsewhere in the function). ! 405: ! 406: The RTX OP is typically an arithmetic expression. For example, when a ! 407: sequence of insns such as a library call is used to perform an ! 408: arithmetic operation, this kind of note is attached to the insn that ! 409: produces or copies the final value. It tells the CSE pass how to ! 410: think of that value. ! 411: ! 412: `REG_RETVAL' ! 413: This insn copies the value of a library call, and OP is the first insn ! 414: that was generated to set up the arguments for the library call. ! 415: ! 416: Flow analysis uses this note to delete all of a library call whose ! 417: result is dead. ! 418: ! 419: `REG_WAS_0' ! 420: The register OP contained zero before this insn. You can rely on this ! 421: note if it is present; its absence implies nothing. ! 422: ! 423: (The only difference between the expression codes `insn_list' and ! 424: `expr_list' is that the first operand of an `insn_list' is assumed to be an ! 425: insn and is printed in debugging dumps as the insn's unique id; the first ! 426: operand of an `expr_list' is printed in the ordinary way as an expression.) ! 427: ! 428: ! 429: File: internals, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL ! 430: ! 431: RTL Representation of Function-Call Insns ! 432: ========================================= ! 433: ! 434: Insns that call subroutines have the RTL expression code `call_insn'. ! 435: These insns must satisfy special rules, and their bodies must use a special ! 436: RTL expression code, `call'. ! 437: ! 438: A `call' expression has two operands, as follows: ! 439: ! 440: (call NBYTES (mem:FM ADDR)) ! 441: ! 442: Here NBYTES is an operand that represents the number of bytes of argument ! 443: data being passed to the subroutine, FM is a machine mode (which must equal ! 444: as the definition of the `FUNCTION_MODE' macro in the machine description) ! 445: and ADDR represents the address of the subroutine. ! 446: ! 447: For a subroutine that returns no value, the `call' RTX as shown above is ! 448: the entire body of the insn. ! 449: ! 450: For a subroutine that returns a value whose mode is not `BLKmode', the ! 451: value is returned in a hard register. If this register's number is R, then ! 452: the body of the call insn looks like this: ! 453: ! 454: (set (reg:M R) ! 455: (call NBYTES (mem:FM ADDR))) ! 456: ! 457: This RTL expression makes it clear (to the optimizer passes) that the ! 458: appropriate register receives a useful value in this insn. ! 459: ! 460: Immediately after RTL generation, if the value of the subroutine is ! 461: actually used, this call insn is always followed closely by an insn which ! 462: refers to the register R. This remains true through all the optimizer ! 463: passes until cross jumping occurs. ! 464: ! 465: The following insn has one of two forms. Either it copies the value into a ! 466: pseudo-register, like this: ! 467: ! 468: (set (reg:M P) (reg:M R)) ! 469: ! 470: or (in the case where the calling function will simply return whatever ! 471: value the call produced, and no operation is needed to do this): ! 472: ! 473: (use (reg:M R)) ! 474: ! 475: Between the call insn and this following insn there may intervene only a ! 476: stack-adjustment insn (and perhaps some `note' insns). ! 477: ! 478: When a subroutine returns a `BLKmode' value, it is handled by passing to ! 479: the subroutine the address of a place to store the value. So the call insn ! 480: itself does not ``return'' any value, and it has the same RTL form as a ! 481: call that returns nothing. 1.1 root 482: 483: 484: File: internals, Node: Sharing, Prev: Calls, Up: RTL 485: 486: Structure Sharing Assumptions 487: ============================= 488: 489: The compiler assumes that certain kinds of RTL expressions are unique; 490: there do not exist two distinct objects representing the same value. In 491: other cases, it makes an opposite assumption: that no RTL expression object 492: of a certain kind appears in more than one place in the containing structure. 493: 494: These assumptions refer to a single function; except for the RTL objects 495: that describe global variables and external functions, no RTL objects are 496: common to two functions. 497: 498: * Each pseudo-register has only a single `reg' object to represent it, 499: and therefore only a single machine mode. 500: 501: * For any symbolic label, there is only one `symbol_ref' object 502: referring to it. 503: 504: * There is only one `const_int' expression with value zero, and only one 505: with value one. 506: 507: * There is only one `pc' expression. 508: 509: * There is only one `cc0' expression. 510: 511: * There is only one `const_double' expression with mode `SFmode' and 512: value zero, and only one with mode `DFmode' and value zero. 513: 514: * No `label_ref' appears in more than one place in the RTL structure; in 515: other words, it is safe to do a tree-walk of all the insns in the 516: function and assume that each time a `label_ref' is seen it is 517: distinct from all others that are seen. 518: 519: * Only one `mem' object is normally created for each static variable or 520: stack slot, so these objects are frequently shared in all the places 521: they appear. However, separate but equal objects for these variables 522: are occasionally made. 523: 524: * No RTL object appears in more than one place in the RTL structure 525: except as described above. Many passes of the compiler rely on this 526: by assuming that they can modify RTL objects in place without unwanted 527: side-effects on other insns. 528: 529: * During initial RTL generation, shared structure is freely introduced. 530: After all the RTL for a function has been generated, all shared 531: structure is copied by `unshare_all_rtl' in `emit-rtl.c', after which 532: the above rules are guaranteed to be followed. 533: 534: * During the combiner pass, shared structure with an insn can exist 535: temporarily. However, the shared structure is copied before the 536: combiner is finished with the insn. This is done by 537: `copy_substitutions' in `combine.c'. 538: 539: 540: File: internals, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top 541: 542: Machine Descriptions 543: ******************** 544: 545: A machine description has two parts: a file of instruction patterns (`.md' 546: file) and a C header file of macro definitions. 547: 548: The `.md' file for a target machine contains a pattern for each instruction 549: that the target machine supports (or at least each instruction that is 550: worth telling the compiler about). It may also contain comments. A 551: semicolon causes the rest of the line to be a comment, unless the semicolon 552: is inside a quoted string. 553: 554: See the next chapter for information on the C header file. 555: 556: * Menu: 557: 558: * Patterns:: How to write instruction patterns. 559: * Example:: An explained example of a `define_insn' pattern. 560: * RTL Template:: The RTL template defines what insns match a pattern. 561: * Output Template:: The output template says how to make assembler code 562: from such an insn. 563: * Output Statement:: For more generality, write C code to output 564: the assembler code. 565: * Constraints:: When not all operands are general operands. 566: * Standard Names:: Names mark patterns to use for code generation. 567: * Pattern Ordering:: When the order of patterns makes a difference. 568: * Dependent Patterns:: Having one pattern may make you need another. 569: * Jump Patterns:: Special considerations for patterns for jump insns. 570: * Peephole Definitions::Defining machine-specific peephole optimizations. 571: * Expander Definitions::Generating a sequence of several RTL insns 572: for a standard operation. 573: 574: 575: 576: File: internals, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc 577: 578: Everything about Instruction Patterns 579: ===================================== 580: 581: Each instruction pattern contains an incomplete RTL expression, with pieces 582: to be filled in later, operand constraints that restrict how the pieces can 583: be filled in, and an output pattern or C code to generate the assembler 584: output, all wrapped up in a `define_insn' expression. 585: 586: A `define_insn' is an RTL expression containing four operands: 587: 588: 1. An optional name. The presence of a name indicate that this instruction 589: pattern can perform a certain standard job for the RTL-generation pass 590: of the compiler. This pass knows certain names and will use the 591: instruction patterns with those names, if the names are defined in the 592: machine description. 593: 594: The absence of a name is indicated by writing an empty string where 595: the name should go. Nameless instruction patterns are never used for 596: generating RTL code, but they may permit several simpler insns to be 597: combined later on. 598: 599: Names that are not thus known and used in RTL-generation have no 600: effect; they are equivalent to no name at all. 601: 602: 2. The "RTL template" (*Note RTL Template::.) is a vector of incomplete RTL 603: expressions which show what the instruction should look like. It is 604: incomplete because it may contain `match_operand' and `match_dup' 605: expressions that stand for operands of the instruction. 606: 607: If the vector has only one element, that element is what the 608: instruction should look like. If the vector has multiple elements, 609: then the instruction looks like a `parallel' expression containing 610: that many elements as described. 611: 612: 3. A condition. This is a string which contains a C expression that is the 613: final test to decide whether an insn body matches this pattern. 614: 615: For a named pattern, the condition (if present) may not depend on the 616: data in the insn being matched, but only the target-machine-type 617: flags. The compiler needs to test these conditions during 618: initialization in order to learn exactly which named instructions are 619: available in a particular run. 620: 621: For nameless patterns, the condition is applied only when matching an 622: individual insn, and only after the insn has matched the pattern's 623: recognition template. The insn's operands may be found in the vector 624: `operands'. 625: 626: 4. The "output template": a string that says how to output matching insns 627: as assembler code. `%' in this string specifies where to substitute 628: the value of an operand. *note Output Template::. 629: 630: When simple substitution isn't general enough, you can specify a piece 631: of C code to compute the output. *note Output Statement::. 632: 633: 634: File: internals, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 635: 636: Example of `define_insn' 637: ======================== 638: 639: Here is an actual example of an instruction pattern, for the 68000/68020. 640: 641: (define_insn "tstsi" 642: [(set (cc0) 643: (match_operand:SI 0 "general_operand" "rm"))] 644: "" 645: "* 646: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 647: return \"tstl %0\"; 648: return \"cmpl #0,%0\"; }") 649: 650: This is an instruction that sets the condition codes based on the value of 651: a general operand. It has no condition, so any insn whose RTL description 652: has the form shown may be handled according to this pattern. The name 653: `tstsi' means ``test a `SImode' value'' and tells the RTL generation pass 654: that, when it is necessary to test such a value, an insn to do so can be 655: constructed using this pattern. 656: 657: The output control string is a piece of C code which chooses which output 658: template to return based on the kind of operand and the specific type of 659: CPU for which code is being generated. 660: 661: `"rm"' is an operand constraint. Its meaning is explained below. 662: 663: 664: File: internals, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 665: 666: RTL Template for Generating and Recognizing Insns 667: ================================================= 668: 669: The RTL template is used to define which insns match the particular pattern 670: and how to find their operands. For named patterns, the RTL template also 671: says how to construct an insn from specified operands. 672: 673: Construction involves substituting specified operands into a copy of the 674: template. Matching involves determining the values that serve as the 675: operands in the insn being matched. Both of these activities are 676: controlled by special expression types that direct matching and 677: substitution of the operands. 678: 679: `(match_operand:M N TESTFN CONSTRAINT)' 680: This expression is a placeholder for operand number N of the insn. 681: When constructing an insn, operand number N will be substituted at 682: this point. When matching an insn, whatever appears at this position 683: in the insn will be taken as operand number N; but it must satisfy 684: TESTFN or this instruction pattern will not match at all. 685: 686: Operand numbers must be chosen consecutively counting from zero in 687: each instruction pattern. There may be only one `match_operand' 688: expression in the pattern for each expression number, and they must 689: appear in order of increasing expression number. 690: 691: TESTFN is a string that is the name of a C function that accepts two 692: arguments, a machine mode and an expression. During matching, the 693: function will be called with M as the mode argument and the putative 694: operand as the other argument. If it returns zero, this instruction 695: pattern fails to match. TESTFN may be an empty string; then it means 696: no test is to be done on the operand. 697: 698: Most often, TESTFN is `"general_operand"'. It checks that the 699: putative operand is either a constant, a register or a memory 700: reference, and that it is valid for mode M. 701: 702: For an operand that must be a register, TESTFN should be 703: `"register_operand"'. This prevents GNU CC from creating insns that 704: have memory references in these operands, insns which would only have 705: to be taken apart in the reload pass. 706: 707: For an operand that must be a constant, either TESTFN should be 708: `"immediate_operand"', or the instruction pattern's extra condition 709: should check for constants, or both. 710: 711: CONSTRAINT is explained later (*Note Constraints::.). 712: 713: `(match_dup N)' 714: This expression is also a placeholder for operand number N. It is 715: used when the operand needs to appear more than once in the insn. 716: 717: In construction, `match_dup' behaves exactly like `match_operand': the 718: operand is substituted into the insn being constructed. But in 719: matching, `match_dup' behaves differently. It assumes that operand 720: number N has already been determined by a `match_operand' appearing 721: earlier in the recognition template, and it matches only an 722: identical-looking expression. 723: 724: `(address (match_operand:M N "address_operand" ""))' 725: This complex of expressions is a placeholder for an operand number N 726: in a ``load address'' instruction: an operand which specifies a memory 727: location in the usual way, but for which the actual operand value used 728: is the address of the location, not the contents of the location. 729: 730: `address' expressions never appear in RTL code, only in machine 731: descriptions. And they are used only in machine descriptions that do 732: not use the operand constraint feature. When operand constraints are 733: in use, the letter `p' in the constraint serves this purpose. 734: 735: M is the machine mode of the *memory location being addressed*, not 736: the machine mode of the address itself. That mode is always the same 737: on a given target machine (it is `Pmode', which normally is `SImode'), 738: so there is no point in mentioning it; thus, no machine mode is 739: written in the `address' expression. If some day support is added for 740: machines in which addresses of different kinds of objects appear 741: differently or are used differently (such as the PDP-10), different 742: formats would perhaps need different machine modes and these modes 743: might be written in the `address' expression. 744: 745: 746: File: internals, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 747: 748: Output Templates and Operand Substitution 749: ========================================= 750: 751: The "output template" is a string which specifies how to output the 752: assembler code for an instruction pattern. Most of the template is a fixed 753: string which is output literally. The character `%' is used to specify 754: where to substitute an operand; it can also be used to identify places 755: different variants of the assembler require different syntax. 756: 757: In the simplest case, a `%' followed by a digit N says to output operand N 758: at that point in the string. 759: 760: `%' followed by a letter and a digit says to output an operand in an 761: alternate fashion. Four letters have standard, built-in meanings described 762: below. The machine description macro `PRINT_OPERAND' can define additional 763: letters with nonstandard meanings. 764: 765: `%cDIGIT' can be used to substitute an operand that is a constant value 766: without the syntax that normally indicates an immediate operand. 767: 768: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 769: negated before printing. 770: 771: `%aDIGIT' can be used to substitute an operand as if it were a memory 772: reference, with the actual operand treated as the address. This may be 773: useful when outputting a ``load address'' instruction, because often the 774: assembler syntax for such an instruction requires you to write the operand 775: as if it were a memory reference. 776: 777: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 778: 779: `%' followed by a punctuation character specifies a substitution that does 780: not use an operand. Only one case is standard: `%%' outputs a `%' into the 781: assembler code. Other nonstandard cases can be defined in the 782: `PRINT_OPERAND' macro. 783: 784: The template may generate multiple assembler instructions. Write the text 785: for the instructions, with `\;' between them. 786: 787: When the RTL contains two operand which are required by constraint to match 788: each other, the output template must refer only to the lower-numbered 789: operand. Matching operands are not always identical, and the rest of the 790: compiler arranges to put the proper RTL expression for printing into the 791: lower-numbered operand. 792: 793: One use of nonstandard letters or punctuation following `%' is to 794: distinguish between different assembler languages for the same machine; for 795: example, Motorola syntax versus MIT syntax for the 68000. Motorola syntax 796: requires periods in most opcode names, while MIT syntax does not. For 797: example, the opcode `movel' in MIT syntax is `move.l' in Motorola syntax. 798: The same file of patterns is used for both kinds of output syntax, but the 799: character sequence `%.' is used in each place where Motorola syntax wants a 800: period. The `PRINT_OPERAND' macro for Motorola syntax defines the sequence 801: to output a period; the macro for MIT syntax defines it to do nothing. 802: 803: 804: File: internals, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc 805: 806: C Statements for Generating Assembler Output 807: ============================================ 808: 809: Often a single fixed template string cannot produce correct and efficient 810: assembler code for all the cases that are recognized by a single 811: instruction pattern. For example, the opcodes may depend on the kinds of 812: operands; or some unfortunate combinations of operands may require extra 813: machine instructions. 814: 815: If the output control string starts with a `*', then it is not an output 816: template but rather a piece of C program that should compute a template. 817: It should execute a `return' statement to return the template-string you 818: want. Most such templates use C string literals, which require doublequote 819: characters to delimit them. To include these doublequote characters in the 820: string, prefix each one with `\'. 821: 822: The operands may be found in the array `operands', whose C data type is 823: `rtx []'. 824: 825: It is possible to output an assembler instruction and then go on to output 826: or compute more of them, using the subroutine `output_asm_insn'. This 827: receives two arguments: a template-string and a vector of operands. The 828: vector may be `operands', or it may be another array of `rtx' that you 829: declare locally and initialize yourself. 830: 831: When an insn pattern has multiple alternatives in its constraints, often 832: the appearance of the assembler code determined mostly by which alternative 833: was matched. When this is so, the C code can test the variable 834: `which_alternative', which is the ordinal number of the alternative that 835: was actually satisfied (0 for the first, 1 for the second alternative, etc.). 836: 837: For example, suppose there are two opcodes for storing zero, `clrreg' for 838: registers and `clrmem' for memory locations. Here is how a pattern could 839: use `which_alternative' to choose between them: 840: 841: (define_insn "" 842: [(set (match_operand:SI 0 "general_operand" "r,m") 843: (const_int 0))] 844: "" 845: "* 846: return (which_alternative == 0 847: ? \"clrreg %0\" : \"clrmem %0\"); 848: ") 849: 850: 851: File: internals, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc 852: 853: Operand Constraints 854: =================== 855: 856: Each `match_operand' in an instruction pattern can specify a constraint for 857: the type of operands allowed. Constraints can say whether an operand may 858: be in a register, and which kinds of register; whether the operand can be a 859: memory reference, and which kinds of address; whether the operand may be an 860: immediate constant, and which possible values it may have. Constraints can 861: also require two operands to match. 862: 863: * Menu: 864: 865: * Simple Constraints:: Basic use of constraints. 866: * Multi-Alternative:: When an insn has two alternative constraint-patterns. 867: * Class Preferences:: Constraints guide which hard register to put things in. 868: * Modifiers:: More precise control over effects of constraints. 869: * No Constraints:: Describing a clean machine without constraints. 870: 871: 872: 873: File: internals, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints 874: 875: Simple Constraints 876: ------------------ 877: 878: The simplest kind of constraint is a string full of letters, each of which 879: describes one kind of operand that is permitted. Here are the letters that 880: are allowed: 881: 882: `m' 883: A memory operand is allowed, with any kind of address that the machine 884: supports in general. 885: 886: `o' 887: A memory operand is allowed, but only if the address is "offsetable". 888: This means that adding a small integer (actually, the width in bytes 889: of the operand, as determined by its machine mode) may be added to the 890: address and the result is also a valid memory address. 891: 892: For example, an address which is constant is offsetable; so is an 893: address that is the sum of a register and a constant (as long as a 894: slightly larger constant is also within the range of address-offsets 895: supported by the machine); but an autoincrement or autodecrement 896: address is not offsetable. More complicated indirect/indexed 897: addresses may or may not be offsetable depending on the other 898: addressing modes that the machine supports. 899: 900: Note that in an output operand which can be matched by another 901: operand, the constraint letter `o' is valid only when accompanied by 902: both `<' (if the target machine has predecrement addressing) and `>' 903: (if the target machine has preincrement addressing). 904: 905: `<' 906: A memory operand with autodecrement addressing (either predecrement or 907: postdecrement) is allowed. 908: 909: `>' 910: A memory operand with autoincrement addressing (either preincrement or 911: postincrement) is allowed. 912: 913: `r' 914: A register operand is allowed provided that it is in a general register. 915: 916: `d', `a', `f', ... 917: Other letters can be defined in machine-dependent fashion to stand for 918: particular classes of registers. `d', `a' and `f' are defined on the 919: 68000/68020 to stand for data, address and floating point registers. 920: 921: `i' 922: An immediate integer operand (one with constant value) is allowed. 923: This includes symbolic constants whose values will be known only at 924: assembly time. 925: 926: `n' 927: An immediate integer operand with a known numeric value is allowed. 928: Many systems cannot support assembly-time constants for operands less 929: than a word wide. Constraints for these operands should use `n' 930: rather than `i'. 931: 932: `I', `J', `K', ... 933: Other letters in the range `I' through `M' may be defined in a 934: machine-dependent fashion to permit immediate integer operands with 935: explicit integer values in specified ranges. For example, on the 936: 68000, `I' is defined to stand for the range of values 1 to 8. This 937: is the range permitted as a shift count in the shift instructions. 938: 939: `F' 940: An immediate floating operand (expression code `const_double') is 941: allowed. 942: 943: `G', `H' 944: `G' and `H' may be defined in a machine-dependent fashion to permit 945: immediate floating operands in particular ranges of values. 946: 947: `s' 948: An immediate integer operand whose value is not an explicit integer is 949: allowed. 950: 951: This might appear strange; if an insn allows a constant operand with a 952: value not known at compile time, it certainly must allow any known 953: value. So why use `s' instead of `i'? Sometimes it allows better 954: code to be generated. 955: 956: For example, on the 68000 in a fullword instruction it is possible to 957: use an immediate operand; but if the immediate value is between -32 958: and 31, better code results from loading the value into a register and 959: using the register. This is because the load into the register can be 960: done with a `moveq' instruction. We arrange for this to happen by 961: defining the letter `K' to mean ``any integer outside the range -32 to 962: 31'', and then specifying `Ks' in the operand constraints. 963: 964: `g' 965: Any register, memory or immediate integer operand is allowed, except 966: for registers that are not general registers. 967: 968: `N' (a digit) 969: An operand that matches operand number N is allowed. If a digit is 970: used together with letters, the digit should come last. 971: 972: This is called a "matching constraint" and what it really means is 973: that the assembler has only a single operand that fills two roles 974: considered separate in the RTL insn. For example, an add insn has two 975: input operands and one output operand in the RTL, but on most machines 976: an add instruction really has only two operands, one of them an 977: input-output operand. 978: 979: Matching constraints work only in circumstances like that add insn. 980: More precisely, the matching constraint must appear in an input-only 981: operand and the operand that it matches must be an output-only operand 982: with a lower number. 983: 984: For operands to match in a particular case usually means that they are 985: identical-looking RTL expressions. But in a few special cases 986: specific kinds of dissimilarity are allowed. For example, `*x' as an 987: input operand will match `*x++' as an output operand. For proper 988: results in such cases, the output template should always use the 989: output-operand's number when printing the operand. 990: 991: `p' 992: An operand that is a valid memory address is allowed. This is for 993: ``load address'' and ``push address'' instructions. 994: 995: If `p' is used in the constraint, the test-function in the 996: `match_operand' must be `address_operand'. 997: 998: In order to have valid assembler code, each operand must satisfy its 999: constraint. But a failure to do so does not prevent the pattern from 1000: applying to an insn. Instead, it directs the compiler to modify the code 1001: so that the constraint will be satisfied. Usually this is done by copying 1002: an operand into a register. 1003: 1004: Contrast, therefore, the two instruction patterns that follow: 1005: 1006: (define_insn "" 1007: [(set (match_operand:SI 0 "general_operand" "r") 1008: (plus:SI (match_dup 0) 1009: (match_operand:SI 1 "general_operand" "r")))] 1010: "" 1011: "...") 1012: 1013: which has two operands, one of which must appear in two places, and 1014: 1015: (define_insn "" 1016: [(set (match_operand:SI 0 "general_operand" "r") 1017: (plus:SI (match_operand:SI 1 "general_operand" "0") 1018: (match_operand:SI 2 "general_operand" "r")))] 1019: "" 1020: "...") 1021: 1022: which has three operands, two of which are required by a constraint to be 1023: identical. If we are considering an insn of the form 1024: 1025: (insn N PREV NEXT 1026: (set (reg:SI 3) 1027: (plus:SI (reg:SI 6) (reg:SI 109))) 1028: ...) 1029: 1030: the first pattern would not apply at all, because this insn does not 1031: contain two identical subexpressions in the right place. The pattern would 1032: say, ``That does not look like an add instruction; try other patterns.'' 1033: The second pattern would say, ``Yes, that's an add instruction, but there 1034: is something wrong with it.'' It would direct the reload pass of the 1035: compiler to generate additional insns to make the constraint true. The 1036: results might look like this: 1037: 1038: (insn N2 PREV N 1039: (set (reg:SI 3) (reg:SI 6)) 1040: ...) 1041: 1042: (insn N N2 NEXT 1043: (set (reg:SI 3) 1044: (plus:SI (reg:SI 3) (reg:SI 109))) 1045: ...) 1046: 1047: Because insns that don't fit the constraints are fixed up by loading 1048: operands into registers, every instruction pattern's constraints must 1049: permit the case where all the operands are in registers. It need not 1050: permit all classes of registers; the compiler knows how to copy registers 1051: into other registers of the proper class in order to make an instruction 1052: valid. But if no registers are permitted, the compiler will be stymied: it 1053: does not know how to save a register in memory in order to make an 1054: instruction valid. Instruction patterns that reject registers can be made 1055: valid by attaching a condition-expression that refuses to match an insn at 1056: all if the crucial operand is a register. 1057: 1.1.1.2 ! root 1058:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.