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