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