[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: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc |
---|
| 34 | |
---|
| 35 | Defining RTL Sequences for Code Generation |
---|
| 36 | ========================================== |
---|
| 37 | |
---|
| 38 | On some target machines, some standard pattern names for RTL |
---|
| 39 | generation cannot be handled with single insn, but a sequence of RTL |
---|
| 40 | insns can represent them. For these target machines, you can write a |
---|
| 41 | `define_expand' to specify how to generate the sequence of RTL. |
---|
| 42 | |
---|
| 43 | A `define_expand' is an RTL expression that looks almost like a |
---|
| 44 | `define_insn'; but, unlike the latter, a `define_expand' is used only |
---|
| 45 | for RTL generation and it can produce more than one RTL insn. |
---|
| 46 | |
---|
| 47 | A `define_expand' RTX has four operands: |
---|
| 48 | |
---|
| 49 | * The name. Each `define_expand' must have a name, since the only |
---|
| 50 | use for it is to refer to it by name. |
---|
| 51 | |
---|
| 52 | * The RTL template. This is just like the RTL template for a |
---|
| 53 | `define_peephole' in that it is a vector of RTL expressions each |
---|
| 54 | being one insn. |
---|
| 55 | |
---|
| 56 | * The condition, a string containing a C expression. This |
---|
| 57 | expression is used to express how the availability of this pattern |
---|
| 58 | depends on subclasses of target machine, selected by command-line |
---|
| 59 | options when GNU CC is run. This is just like the condition of a |
---|
| 60 | `define_insn' that has a standard name. Therefore, the condition |
---|
| 61 | (if present) may not depend on the data in the insn being matched, |
---|
| 62 | but only the target-machine-type flags. The compiler needs to |
---|
| 63 | test these conditions during initialization in order to learn |
---|
| 64 | exactly which named instructions are available in a particular run. |
---|
| 65 | |
---|
| 66 | * The preparation statements, a string containing zero or more C |
---|
| 67 | statements which are to be executed before RTL code is generated |
---|
| 68 | from the RTL template. |
---|
| 69 | |
---|
| 70 | Usually these statements prepare temporary registers for use as |
---|
| 71 | internal operands in the RTL template, but they can also generate |
---|
| 72 | RTL insns directly by calling routines such as `emit_insn', etc. |
---|
| 73 | Any such insns precede the ones that come from the RTL template. |
---|
| 74 | |
---|
| 75 | Every RTL insn emitted by a `define_expand' must match some |
---|
| 76 | `define_insn' in the machine description. Otherwise, the compiler will |
---|
| 77 | crash when trying to generate code for the insn or trying to optimize |
---|
| 78 | it. |
---|
| 79 | |
---|
| 80 | The RTL template, in addition to controlling generation of RTL insns, |
---|
| 81 | also describes the operands that need to be specified when this pattern |
---|
| 82 | is used. In particular, it gives a predicate for each operand. |
---|
| 83 | |
---|
| 84 | A true operand, which needs to be specified in order to generate RTL |
---|
| 85 | from the pattern, should be described with a `match_operand' in its |
---|
| 86 | first occurrence in the RTL template. This enters information on the |
---|
| 87 | operand's predicate into the tables that record such things. GNU CC |
---|
| 88 | uses the information to preload the operand into a register if that is |
---|
| 89 | required for valid RTL code. If the operand is referred to more than |
---|
| 90 | once, subsequent references should use `match_dup'. |
---|
| 91 | |
---|
| 92 | The RTL template may also refer to internal "operands" which are |
---|
| 93 | temporary registers or labels used only within the sequence made by the |
---|
| 94 | `define_expand'. Internal operands are substituted into the RTL |
---|
| 95 | template with `match_dup', never with `match_operand'. The values of |
---|
| 96 | the internal operands are not passed in as arguments by the compiler |
---|
| 97 | when it requests use of this pattern. Instead, they are computed |
---|
| 98 | within the pattern, in the preparation statements. These statements |
---|
| 99 | compute the values and store them into the appropriate elements of |
---|
| 100 | `operands' so that `match_dup' can find them. |
---|
| 101 | |
---|
| 102 | There are two special macros defined for use in the preparation |
---|
| 103 | statements: `DONE' and `FAIL'. Use them with a following semicolon, as |
---|
| 104 | a statement. |
---|
| 105 | |
---|
| 106 | `DONE' |
---|
| 107 | Use the `DONE' macro to end RTL generation for the pattern. The |
---|
| 108 | only RTL insns resulting from the pattern on this occasion will be |
---|
| 109 | those already emitted by explicit calls to `emit_insn' within the |
---|
| 110 | preparation statements; the RTL template will not be generated. |
---|
| 111 | |
---|
| 112 | `FAIL' |
---|
| 113 | Make the pattern fail on this occasion. When a pattern fails, it |
---|
| 114 | means that the pattern was not truly available. The calling |
---|
| 115 | routines in the compiler will try other strategies for code |
---|
| 116 | generation using other patterns. |
---|
| 117 | |
---|
| 118 | Failure is currently supported only for binary (addition, |
---|
| 119 | multiplication, shifting, etc.) and bitfield (`extv', `extzv', and |
---|
| 120 | `insv') operations. |
---|
| 121 | |
---|
| 122 | Here is an example, the definition of left-shift for the SPUR chip: |
---|
| 123 | |
---|
| 124 | (define_expand "ashlsi3" |
---|
| 125 | [(set (match_operand:SI 0 "register_operand" "") |
---|
| 126 | (ashift:SI |
---|
| 127 | |
---|
| 128 | (match_operand:SI 1 "register_operand" "") |
---|
| 129 | (match_operand:SI 2 "nonmemory_operand" "")))] |
---|
| 130 | "" |
---|
| 131 | " |
---|
| 132 | |
---|
| 133 | { |
---|
| 134 | if (GET_CODE (operands[2]) != CONST_INT |
---|
| 135 | || (unsigned) INTVAL (operands[2]) > 3) |
---|
| 136 | FAIL; |
---|
| 137 | }") |
---|
| 138 | |
---|
| 139 | This example uses `define_expand' so that it can generate an RTL insn |
---|
| 140 | for shifting when the shift-count is in the supported range of 0 to 3 |
---|
| 141 | but fail in other cases where machine insns aren't available. When it |
---|
| 142 | fails, the compiler tries another strategy using different patterns |
---|
| 143 | (such as, a library call). |
---|
| 144 | |
---|
| 145 | If the compiler were able to handle nontrivial condition-strings in |
---|
| 146 | patterns with names, then it would be possible to use a `define_insn' |
---|
| 147 | in that case. Here is another case (zero-extension on the 68000) which |
---|
| 148 | makes more use of the power of `define_expand': |
---|
| 149 | |
---|
| 150 | (define_expand "zero_extendhisi2" |
---|
| 151 | [(set (match_operand:SI 0 "general_operand" "") |
---|
| 152 | (const_int 0)) |
---|
| 153 | (set (strict_low_part |
---|
| 154 | (subreg:HI |
---|
| 155 | (match_dup 0) |
---|
| 156 | 0)) |
---|
| 157 | (match_operand:HI 1 "general_operand" ""))] |
---|
| 158 | "" |
---|
| 159 | "operands[1] = make_safe_from (operands[1], operands[0]);") |
---|
| 160 | |
---|
| 161 | Here two RTL insns are generated, one to clear the entire output operand |
---|
| 162 | and the other to copy the input operand into its low half. This |
---|
| 163 | sequence is incorrect if the input operand refers to [the old value of] |
---|
| 164 | the output operand, so the preparation statement makes sure this isn't |
---|
| 165 | so. The function `make_safe_from' copies the `operands[1]' into a |
---|
| 166 | temporary register if it refers to `operands[0]'. It does this by |
---|
| 167 | emitting another RTL insn. |
---|
| 168 | |
---|
| 169 | Finally, a third example shows the use of an internal operand. |
---|
| 170 | Zero-extension on the SPUR chip is done by `and'-ing the result against |
---|
| 171 | a halfword mask. But this mask cannot be represented by a `const_int' |
---|
| 172 | because the constant value is too large to be legitimate on this |
---|
| 173 | machine. So it must be copied into a register with `force_reg' and |
---|
| 174 | then the register used in the `and'. |
---|
| 175 | |
---|
| 176 | (define_expand "zero_extendhisi2" |
---|
| 177 | [(set (match_operand:SI 0 "register_operand" "") |
---|
| 178 | (and:SI (subreg:SI |
---|
| 179 | (match_operand:HI 1 "register_operand" "") |
---|
| 180 | 0) |
---|
| 181 | (match_dup 2)))] |
---|
| 182 | "" |
---|
| 183 | "operands[2] |
---|
| 184 | = force_reg (SImode, gen_rtx (CONST_INT, |
---|
| 185 | VOIDmode, 65535)); ") |
---|
| 186 | |
---|
| 187 | *Note:* If the `define_expand' is used to serve a standard binary or |
---|
| 188 | unary arithmetic operation or a bitfield operation, then the last insn |
---|
| 189 | it generates must not be a `code_label', `barrier' or `note'. It must |
---|
| 190 | be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn |
---|
| 191 | at the end, emit an insn to copy the result of the operation into |
---|
| 192 | itself. Such an insn will generate no code, but it can avoid problems |
---|
| 193 | in the compiler. |
---|
| 194 | |
---|
| 195 | |
---|
| 196 | File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc |
---|
| 197 | |
---|
| 198 | Defining How to Split Instructions |
---|
| 199 | ================================== |
---|
| 200 | |
---|
| 201 | There are two cases where you should specify how to split a pattern |
---|
| 202 | into multiple insns. On machines that have instructions requiring delay |
---|
| 203 | slots (*note Delay Slots::.) or that have instructions whose output is |
---|
| 204 | not available for multiple cycles (*note Function Units::.), the |
---|
| 205 | compiler phases that optimize these cases need to be able to move insns |
---|
| 206 | into one-instruction delay slots. However, some insns may generate |
---|
| 207 | more than one machine instruction. These insns cannot be placed into a |
---|
| 208 | delay slot. |
---|
| 209 | |
---|
| 210 | Often you can rewrite the single insn as a list of individual insns, |
---|
| 211 | each corresponding to one machine instruction. The disadvantage of |
---|
| 212 | doing so is that it will cause the compilation to be slower and require |
---|
| 213 | more space. If the resulting insns are too complex, it may also |
---|
| 214 | suppress some optimizations. The compiler splits the insn if there is a |
---|
| 215 | reason to believe that it might improve instruction or delay slot |
---|
| 216 | scheduling. |
---|
| 217 | |
---|
| 218 | The insn combiner phase also splits putative insns. If three insns |
---|
| 219 | are merged into one insn with a complex expression that cannot be |
---|
| 220 | matched by some `define_insn' pattern, the combiner phase attempts to |
---|
| 221 | split the complex pattern into two insns that are recognized. Usually |
---|
| 222 | it can break the complex pattern into two patterns by splitting out some |
---|
| 223 | subexpression. However, in some other cases, such as performing an |
---|
| 224 | addition of a large constant in two insns on a RISC machine, the way to |
---|
| 225 | split the addition into two insns is machine-dependent. |
---|
| 226 | |
---|
| 227 | The `define_split' definition tells the compiler how to split a |
---|
| 228 | complex insn into several simpler insns. It looks like this: |
---|
| 229 | |
---|
| 230 | (define_split |
---|
| 231 | [INSN-PATTERN] |
---|
| 232 | "CONDITION" |
---|
| 233 | [NEW-INSN-PATTERN-1 |
---|
| 234 | NEW-INSN-PATTERN-2 |
---|
| 235 | ...] |
---|
| 236 | "PREPARATION STATEMENTS") |
---|
| 237 | |
---|
| 238 | INSN-PATTERN is a pattern that needs to be split and CONDITION is |
---|
| 239 | the final condition to be tested, as in a `define_insn'. When an insn |
---|
| 240 | matching INSN-PATTERN and satisfying CONDITION is found, it is replaced |
---|
| 241 | in the insn list with the insns given by NEW-INSN-PATTERN-1, |
---|
| 242 | NEW-INSN-PATTERN-2, etc. |
---|
| 243 | |
---|
| 244 | The PREPARATION STATEMENTS are similar to those statements that are |
---|
| 245 | specified for `define_expand' (*note Expander Definitions::.) and are |
---|
| 246 | executed before the new RTL is generated to prepare for the generated |
---|
| 247 | code or emit some insns whose pattern is not fixed. Unlike those in |
---|
| 248 | `define_expand', however, these statements must not generate any new |
---|
| 249 | pseudo-registers. Once reload has completed, they also must not |
---|
| 250 | allocate any space in the stack frame. |
---|
| 251 | |
---|
| 252 | Patterns are matched against INSN-PATTERN in two different |
---|
| 253 | circumstances. If an insn needs to be split for delay slot scheduling |
---|
| 254 | or insn scheduling, the insn is already known to be valid, which means |
---|
| 255 | that it must have been matched by some `define_insn' and, if |
---|
| 256 | `reload_completed' is non-zero, is known to satisfy the constraints of |
---|
| 257 | that `define_insn'. In that case, the new insn patterns must also be |
---|
| 258 | insns that are matched by some `define_insn' and, if `reload_completed' |
---|
| 259 | is non-zero, must also satisfy the constraints of those definitions. |
---|
| 260 | |
---|
| 261 | As an example of this usage of `define_split', consider the following |
---|
| 262 | example from `a29k.md', which splits a `sign_extend' from `HImode' to |
---|
| 263 | `SImode' into a pair of shift insns: |
---|
| 264 | |
---|
| 265 | (define_split |
---|
| 266 | [(set (match_operand:SI 0 "gen_reg_operand" "") |
---|
| 267 | (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] |
---|
| 268 | "" |
---|
| 269 | [(set (match_dup 0) |
---|
| 270 | (ashift:SI (match_dup 1) |
---|
| 271 | (const_int 16))) |
---|
| 272 | (set (match_dup 0) |
---|
| 273 | (ashiftrt:SI (match_dup 0) |
---|
| 274 | (const_int 16)))] |
---|
| 275 | " |
---|
| 276 | { operands[1] = gen_lowpart (SImode, operands[1]); }") |
---|
| 277 | |
---|
| 278 | When the combiner phase tries to split an insn pattern, it is always |
---|
| 279 | the case that the pattern is *not* matched by any `define_insn'. The |
---|
| 280 | combiner pass first tries to split a single `set' expression and then |
---|
| 281 | the same `set' expression inside a `parallel', but followed by a |
---|
| 282 | `clobber' of a pseudo-reg to use as a scratch register. In these |
---|
| 283 | cases, the combiner expects exactly two new insn patterns to be |
---|
| 284 | generated. It will verify that these patterns match some `define_insn' |
---|
| 285 | definitions, so you need not do this test in the `define_split' (of |
---|
| 286 | course, there is no point in writing a `define_split' that will never |
---|
| 287 | produce insns that match). |
---|
| 288 | |
---|
| 289 | Here is an example of this use of `define_split', taken from |
---|
| 290 | `rs6000.md': |
---|
| 291 | |
---|
| 292 | (define_split |
---|
| 293 | [(set (match_operand:SI 0 "gen_reg_operand" "") |
---|
| 294 | (plus:SI (match_operand:SI 1 "gen_reg_operand" "") |
---|
| 295 | (match_operand:SI 2 "non_add_cint_operand" "")))] |
---|
| 296 | "" |
---|
| 297 | [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) |
---|
| 298 | (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] |
---|
| 299 | " |
---|
| 300 | { |
---|
| 301 | int low = INTVAL (operands[2]) & 0xffff; |
---|
| 302 | int high = (unsigned) INTVAL (operands[2]) >> 16; |
---|
| 303 | |
---|
| 304 | if (low & 0x8000) |
---|
| 305 | high++, low |= 0xffff0000; |
---|
| 306 | |
---|
| 307 | operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16); |
---|
| 308 | operands[4] = gen_rtx (CONST_INT, VOIDmode, low); |
---|
| 309 | }") |
---|
| 310 | |
---|
| 311 | Here the predicate `non_add_cint_operand' matches any `const_int' |
---|
| 312 | that is *not* a valid operand of a single add insn. The add with the |
---|
| 313 | smaller displacement is written so that it can be substituted into the |
---|
| 314 | address of a subsequent operation. |
---|
| 315 | |
---|
| 316 | An example that uses a scratch register, from the same file, |
---|
| 317 | generates an equality comparison of a register and a large constant: |
---|
| 318 | |
---|
| 319 | (define_split |
---|
| 320 | [(set (match_operand:CC 0 "cc_reg_operand" "") |
---|
| 321 | (compare:CC (match_operand:SI 1 "gen_reg_operand" "") |
---|
| 322 | (match_operand:SI 2 "non_short_cint_operand" ""))) |
---|
| 323 | (clobber (match_operand:SI 3 "gen_reg_operand" ""))] |
---|
| 324 | "find_single_use (operands[0], insn, 0) |
---|
| 325 | && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ |
---|
| 326 | || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" |
---|
| 327 | [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) |
---|
| 328 | (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] |
---|
| 329 | " |
---|
| 330 | { |
---|
| 331 | /* Get the constant we are comparing against, C, and see what it |
---|
| 332 | looks like sign-extended to 16 bits. Then see what constant |
---|
| 333 | could be XOR'ed with C to get the sign-extended value. */ |
---|
| 334 | |
---|
| 335 | int c = INTVAL (operands[2]); |
---|
| 336 | int sextc = (c << 16) >> 16; |
---|
| 337 | int xorv = c ^ sextc; |
---|
| 338 | |
---|
| 339 | operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv); |
---|
| 340 | operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc); |
---|
| 341 | }") |
---|
| 342 | |
---|
| 343 | To avoid confusion, don't write a single `define_split' that accepts |
---|
| 344 | some insns that match some `define_insn' as well as some insns that |
---|
| 345 | don't. Instead, write two separate `define_split' definitions, one for |
---|
| 346 | the insns that are valid and one for the insns that are not valid. |
---|
| 347 | |
---|
| 348 | |
---|
| 349 | File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc |
---|
| 350 | |
---|
| 351 | Instruction Attributes |
---|
| 352 | ====================== |
---|
| 353 | |
---|
| 354 | In addition to describing the instruction supported by the target |
---|
| 355 | machine, the `md' file also defines a group of "attributes" and a set of |
---|
| 356 | values for each. Every generated insn is assigned a value for each |
---|
| 357 | attribute. One possible attribute would be the effect that the insn |
---|
| 358 | has on the machine's condition code. This attribute can then be used |
---|
| 359 | by `NOTICE_UPDATE_CC' to track the condition codes. |
---|
| 360 | |
---|
| 361 | * Menu: |
---|
| 362 | |
---|
| 363 | * Defining Attributes:: Specifying attributes and their values. |
---|
| 364 | * Expressions:: Valid expressions for attribute values. |
---|
| 365 | * Tagging Insns:: Assigning attribute values to insns. |
---|
| 366 | * Attr Example:: An example of assigning attributes. |
---|
| 367 | * Insn Lengths:: Computing the length of insns. |
---|
| 368 | * Constant Attributes:: Defining attributes that are constant. |
---|
| 369 | * Delay Slots:: Defining delay slots required for a machine. |
---|
| 370 | * Function Units:: Specifying information for insn scheduling. |
---|
| 371 | |
---|
| 372 | |
---|
| 373 | File: gcc.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes |
---|
| 374 | |
---|
| 375 | Defining Attributes and their Values |
---|
| 376 | ------------------------------------ |
---|
| 377 | |
---|
| 378 | The `define_attr' expression is used to define each attribute |
---|
| 379 | required by the target machine. It looks like: |
---|
| 380 | |
---|
| 381 | (define_attr NAME LIST-OF-VALUES DEFAULT) |
---|
| 382 | |
---|
| 383 | NAME is a string specifying the name of the attribute being defined. |
---|
| 384 | |
---|
| 385 | LIST-OF-VALUES is either a string that specifies a comma-separated |
---|
| 386 | list of values that can be assigned to the attribute, or a null string |
---|
| 387 | to indicate that the attribute takes numeric values. |
---|
| 388 | |
---|
| 389 | DEFAULT is an attribute expression that gives the value of this |
---|
| 390 | attribute for insns that match patterns whose definition does not |
---|
| 391 | include an explicit value for this attribute. *Note Attr Example::, |
---|
| 392 | for more information on the handling of defaults. *Note Constant |
---|
| 393 | Attributes::, for information on attributes that do not depend on any |
---|
| 394 | particular insn. |
---|
| 395 | |
---|
| 396 | For each defined attribute, a number of definitions are written to |
---|
| 397 | the `insn-attr.h' file. For cases where an explicit set of values is |
---|
| 398 | specified for an attribute, the following are defined: |
---|
| 399 | |
---|
| 400 | * A `#define' is written for the symbol `HAVE_ATTR_NAME'. |
---|
| 401 | |
---|
| 402 | * An enumeral class is defined for `attr_NAME' with elements of the |
---|
| 403 | form `UPPER-NAME_UPPER-VALUE' where the attribute name and value |
---|
| 404 | are first converted to upper case. |
---|
| 405 | |
---|
| 406 | * A function `get_attr_NAME' is defined that is passed an insn and |
---|
| 407 | returns the attribute value for that insn. |
---|
| 408 | |
---|
| 409 | For example, if the following is present in the `md' file: |
---|
| 410 | |
---|
| 411 | (define_attr "type" "branch,fp,load,store,arith" ...) |
---|
| 412 | |
---|
| 413 | the following lines will be written to the file `insn-attr.h'. |
---|
| 414 | |
---|
| 415 | #define HAVE_ATTR_type |
---|
| 416 | enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, |
---|
| 417 | TYPE_STORE, TYPE_ARITH}; |
---|
| 418 | extern enum attr_type get_attr_type (); |
---|
| 419 | |
---|
| 420 | If the attribute takes numeric values, no `enum' type will be |
---|
| 421 | defined and the function to obtain the attribute's value will return |
---|
| 422 | `int'. |
---|
| 423 | |
---|
| 424 | |
---|
| 425 | File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes |
---|
| 426 | |
---|
| 427 | Attribute Expressions |
---|
| 428 | --------------------- |
---|
| 429 | |
---|
| 430 | RTL expressions used to define attributes use the codes described |
---|
| 431 | above plus a few specific to attribute definitions, to be discussed |
---|
| 432 | below. Attribute value expressions must have one of the following |
---|
| 433 | forms: |
---|
| 434 | |
---|
| 435 | `(const_int I)' |
---|
| 436 | The integer I specifies the value of a numeric attribute. I must |
---|
| 437 | be non-negative. |
---|
| 438 | |
---|
| 439 | The value of a numeric attribute can be specified either with a |
---|
| 440 | `const_int' or as an integer represented as a string in |
---|
| 441 | `const_string', `eq_attr' (see below), and `set_attr' (*note |
---|
| 442 | Tagging Insns::.) expressions. |
---|
| 443 | |
---|
| 444 | `(const_string VALUE)' |
---|
| 445 | The string VALUE specifies a constant attribute value. If VALUE |
---|
| 446 | is specified as `"*"', it means that the default value of the |
---|
| 447 | attribute is to be used for the insn containing this expression. |
---|
| 448 | `"*"' obviously cannot be used in the DEFAULT expression of a |
---|
| 449 | `define_attr'. |
---|
| 450 | |
---|
| 451 | If the attribute whose value is being specified is numeric, VALUE |
---|
| 452 | must be a string containing a non-negative integer (normally |
---|
| 453 | `const_int' would be used in this case). Otherwise, it must |
---|
| 454 | contain one of the valid values for the attribute. |
---|
| 455 | |
---|
| 456 | `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' |
---|
| 457 | TEST specifies an attribute test, whose format is defined below. |
---|
| 458 | The value of this expression is TRUE-VALUE if TEST is true, |
---|
| 459 | otherwise it is FALSE-VALUE. |
---|
| 460 | |
---|
| 461 | `(cond [TEST1 VALUE1 ...] DEFAULT)' |
---|
| 462 | The first operand of this expression is a vector containing an even |
---|
| 463 | number of expressions and consisting of pairs of TEST and VALUE |
---|
| 464 | expressions. The value of the `cond' expression is that of the |
---|
| 465 | VALUE corresponding to the first true TEST expression. If none of |
---|
| 466 | the TEST expressions are true, the value of the `cond' expression |
---|
| 467 | is that of the DEFAULT expression. |
---|
| 468 | |
---|
| 469 | TEST expressions can have one of the following forms: |
---|
| 470 | |
---|
| 471 | `(const_int I)' |
---|
| 472 | This test is true if I is non-zero and false otherwise. |
---|
| 473 | |
---|
| 474 | `(not TEST)' |
---|
| 475 | `(ior TEST1 TEST2)' |
---|
| 476 | `(and TEST1 TEST2)' |
---|
| 477 | These tests are true if the indicated logical function is true. |
---|
| 478 | |
---|
| 479 | `(match_operand:M N PRED CONSTRAINTS)' |
---|
| 480 | This test is true if operand N of the insn whose attribute value |
---|
| 481 | is being determined has mode M (this part of the test is ignored |
---|
| 482 | if M is `VOIDmode') and the function specified by the string PRED |
---|
| 483 | returns a non-zero value when passed operand N and mode M (this |
---|
| 484 | part of the test is ignored if PRED is the null string). |
---|
| 485 | |
---|
| 486 | The CONSTRAINTS operand is ignored and should be the null string. |
---|
| 487 | |
---|
| 488 | `(le ARITH1 ARITH2)' |
---|
| 489 | `(leu ARITH1 ARITH2)' |
---|
| 490 | `(lt ARITH1 ARITH2)' |
---|
| 491 | `(ltu ARITH1 ARITH2)' |
---|
| 492 | `(gt ARITH1 ARITH2)' |
---|
| 493 | `(gtu ARITH1 ARITH2)' |
---|
| 494 | `(ge ARITH1 ARITH2)' |
---|
| 495 | `(geu ARITH1 ARITH2)' |
---|
| 496 | `(ne ARITH1 ARITH2)' |
---|
| 497 | `(eq ARITH1 ARITH2)' |
---|
| 498 | These tests are true if the indicated comparison of the two |
---|
| 499 | arithmetic expressions is true. Arithmetic expressions are formed |
---|
| 500 | with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', |
---|
| 501 | `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' |
---|
| 502 | expressions. |
---|
| 503 | |
---|
| 504 | `const_int' and `symbol_ref' are always valid terms (*note Insn |
---|
| 505 | Lengths::.,for additional forms). `symbol_ref' is a string |
---|
| 506 | denoting a C expression that yields an `int' when evaluated by the |
---|
| 507 | `get_attr_...' routine. It should normally be a global variable. |
---|
| 508 | |
---|
| 509 | `(eq_attr NAME VALUE)' |
---|
| 510 | NAME is a string specifying the name of an attribute. |
---|
| 511 | |
---|
| 512 | VALUE is a string that is either a valid value for attribute NAME, |
---|
| 513 | a comma-separated list of values, or `!' followed by a value or |
---|
| 514 | list. If VALUE does not begin with a `!', this test is true if |
---|
| 515 | the value of the NAME attribute of the current insn is in the list |
---|
| 516 | specified by VALUE. If VALUE begins with a `!', this test is true |
---|
| 517 | if the attribute's value is *not* in the specified list. |
---|
| 518 | |
---|
| 519 | For example, |
---|
| 520 | |
---|
| 521 | (eq_attr "type" "load,store") |
---|
| 522 | |
---|
| 523 | is equivalent to |
---|
| 524 | |
---|
| 525 | (ior (eq_attr "type" "load") (eq_attr "type" "store")) |
---|
| 526 | |
---|
| 527 | If NAME specifies an attribute of `alternative', it refers to the |
---|
| 528 | value of the compiler variable `which_alternative' (*note Output |
---|
| 529 | Statement::.) and the values must be small integers. For example, |
---|
| 530 | |
---|
| 531 | (eq_attr "alternative" "2,3") |
---|
| 532 | |
---|
| 533 | is equivalent to |
---|
| 534 | |
---|
| 535 | (ior (eq (symbol_ref "which_alternative") (const_int 2)) |
---|
| 536 | (eq (symbol_ref "which_alternative") (const_int 3))) |
---|
| 537 | |
---|
| 538 | Note that, for most attributes, an `eq_attr' test is simplified in |
---|
| 539 | cases where the value of the attribute being tested is known for |
---|
| 540 | all insns matching a particular pattern. This is by far the most |
---|
| 541 | common case. |
---|
| 542 | |
---|
| 543 | `(attr_flag NAME)' |
---|
| 544 | The value of an `attr_flag' expression is true if the flag |
---|
| 545 | specified by NAME is true for the `insn' currently being scheduled. |
---|
| 546 | |
---|
| 547 | NAME is a string specifying one of a fixed set of flags to test. |
---|
| 548 | Test the flags `forward' and `backward' to determine the direction |
---|
| 549 | of a conditional branch. Test the flags `very_likely', `likely', |
---|
| 550 | `very_unlikely', and `unlikely' to determine if a conditional |
---|
| 551 | branch is expected to be taken. |
---|
| 552 | |
---|
| 553 | If the `very_likely' flag is true, then the `likely' flag is also |
---|
| 554 | true. Likewise for the `very_unlikely' and `unlikely' flags. |
---|
| 555 | |
---|
| 556 | This example describes a conditional branch delay slot which can |
---|
| 557 | be nullified for forward branches that are taken (annul-true) or |
---|
| 558 | for backward branches which are not taken (annul-false). |
---|
| 559 | |
---|
| 560 | (define_delay (eq_attr "type" "cbranch") |
---|
| 561 | [(eq_attr "in_branch_delay" "true") |
---|
| 562 | (and (eq_attr "in_branch_delay" "true") |
---|
| 563 | (attr_flag "forward")) |
---|
| 564 | (and (eq_attr "in_branch_delay" "true") |
---|
| 565 | (attr_flag "backward"))]) |
---|
| 566 | |
---|
| 567 | The `forward' and `backward' flags are false if the current `insn' |
---|
| 568 | being scheduled is not a conditional branch. |
---|
| 569 | |
---|
| 570 | The `very_likely' and `likely' flags are true if the `insn' being |
---|
| 571 | scheduled is not a conditional branch. The The `very_unlikely' |
---|
| 572 | and `unlikely' flags are false if the `insn' being scheduled is |
---|
| 573 | not a conditional branch. |
---|
| 574 | |
---|
| 575 | `attr_flag' is only used during delay slot scheduling and has no |
---|
| 576 | meaning to other passes of the compiler. |
---|
| 577 | |
---|
| 578 | |
---|
| 579 | File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes |
---|
| 580 | |
---|
| 581 | Assigning Attribute Values to Insns |
---|
| 582 | ----------------------------------- |
---|
| 583 | |
---|
| 584 | The value assigned to an attribute of an insn is primarily |
---|
| 585 | determined by which pattern is matched by that insn (or which |
---|
| 586 | `define_peephole' generated it). Every `define_insn' and |
---|
| 587 | `define_peephole' can have an optional last argument to specify the |
---|
| 588 | values of attributes for matching insns. The value of any attribute |
---|
| 589 | not specified in a particular insn is set to the default value for that |
---|
| 590 | attribute, as specified in its `define_attr'. Extensive use of default |
---|
| 591 | values for attributes permits the specification of the values for only |
---|
| 592 | one or two attributes in the definition of most insn patterns, as seen |
---|
| 593 | in the example in the next section. |
---|
| 594 | |
---|
| 595 | The optional last argument of `define_insn' and `define_peephole' is |
---|
| 596 | a vector of expressions, each of which defines the value for a single |
---|
| 597 | attribute. The most general way of assigning an attribute's value is |
---|
| 598 | to use a `set' expression whose first operand is an `attr' expression |
---|
| 599 | giving the name of the attribute being set. The second operand of the |
---|
| 600 | `set' is an attribute expression (*note Expressions::.) giving the |
---|
| 601 | value of the attribute. |
---|
| 602 | |
---|
| 603 | When the attribute value depends on the `alternative' attribute |
---|
| 604 | (i.e., which is the applicable alternative in the constraint of the |
---|
| 605 | insn), the `set_attr_alternative' expression can be used. It allows |
---|
| 606 | the specification of a vector of attribute expressions, one for each |
---|
| 607 | alternative. |
---|
| 608 | |
---|
| 609 | When the generality of arbitrary attribute expressions is not |
---|
| 610 | required, the simpler `set_attr' expression can be used, which allows |
---|
| 611 | specifying a string giving either a single attribute value or a list of |
---|
| 612 | attribute values, one for each alternative. |
---|
| 613 | |
---|
| 614 | The form of each of the above specifications is shown below. In |
---|
| 615 | each case, NAME is a string specifying the attribute to be set. |
---|
| 616 | |
---|
| 617 | `(set_attr NAME VALUE-STRING)' |
---|
| 618 | VALUE-STRING is either a string giving the desired attribute value, |
---|
| 619 | or a string containing a comma-separated list giving the values for |
---|
| 620 | succeeding alternatives. The number of elements must match the |
---|
| 621 | number of alternatives in the constraint of the insn pattern. |
---|
| 622 | |
---|
| 623 | Note that it may be useful to specify `*' for some alternative, in |
---|
| 624 | which case the attribute will assume its default value for insns |
---|
| 625 | matching that alternative. |
---|
| 626 | |
---|
| 627 | `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' |
---|
| 628 | Depending on the alternative of the insn, the value will be one of |
---|
| 629 | the specified values. This is a shorthand for using a `cond' with |
---|
| 630 | tests on the `alternative' attribute. |
---|
| 631 | |
---|
| 632 | `(set (attr NAME) VALUE)' |
---|
| 633 | The first operand of this `set' must be the special RTL expression |
---|
| 634 | `attr', whose sole operand is a string giving the name of the |
---|
| 635 | attribute being set. VALUE is the value of the attribute. |
---|
| 636 | |
---|
| 637 | The following shows three different ways of representing the same |
---|
| 638 | attribute value specification: |
---|
| 639 | |
---|
| 640 | (set_attr "type" "load,store,arith") |
---|
| 641 | |
---|
| 642 | (set_attr_alternative "type" |
---|
| 643 | [(const_string "load") (const_string "store") |
---|
| 644 | (const_string "arith")]) |
---|
| 645 | |
---|
| 646 | (set (attr "type") |
---|
| 647 | (cond [(eq_attr "alternative" "1") (const_string "load") |
---|
| 648 | (eq_attr "alternative" "2") (const_string "store")] |
---|
| 649 | (const_string "arith"))) |
---|
| 650 | |
---|
| 651 | The `define_asm_attributes' expression provides a mechanism to |
---|
| 652 | specify the attributes assigned to insns produced from an `asm' |
---|
| 653 | statement. It has the form: |
---|
| 654 | |
---|
| 655 | (define_asm_attributes [ATTR-SETS]) |
---|
| 656 | |
---|
| 657 | where ATTR-SETS is specified the same as for both the `define_insn' and |
---|
| 658 | the `define_peephole' expressions. |
---|
| 659 | |
---|
| 660 | These values will typically be the "worst case" attribute values. |
---|
| 661 | For example, they might indicate that the condition code will be |
---|
| 662 | clobbered. |
---|
| 663 | |
---|
| 664 | A specification for a `length' attribute is handled specially. The |
---|
| 665 | way to compute the length of an `asm' insn is to multiply the length |
---|
| 666 | specified in the expression `define_asm_attributes' by the number of |
---|
| 667 | machine instructions specified in the `asm' statement, determined by |
---|
| 668 | counting the number of semicolons and newlines in the string. |
---|
| 669 | Therefore, the value of the `length' attribute specified in a |
---|
| 670 | `define_asm_attributes' should be the maximum possible length of a |
---|
| 671 | single machine instruction. |
---|
| 672 | |
---|
| 673 | |
---|
| 674 | File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes |
---|
| 675 | |
---|
| 676 | Example of Attribute Specifications |
---|
| 677 | ----------------------------------- |
---|
| 678 | |
---|
| 679 | The judicious use of defaulting is important in the efficient use of |
---|
| 680 | insn attributes. Typically, insns are divided into "types" and an |
---|
| 681 | attribute, customarily called `type', is used to represent this value. |
---|
| 682 | This attribute is normally used only to define the default value for |
---|
| 683 | other attributes. An example will clarify this usage. |
---|
| 684 | |
---|
| 685 | Assume we have a RISC machine with a condition code and in which only |
---|
| 686 | full-word operations are performed in registers. Let us assume that we |
---|
| 687 | can divide all insns into loads, stores, (integer) arithmetic |
---|
| 688 | operations, floating point operations, and branches. |
---|
| 689 | |
---|
| 690 | Here we will concern ourselves with determining the effect of an |
---|
| 691 | insn on the condition code and will limit ourselves to the following |
---|
| 692 | possible effects: The condition code can be set unpredictably |
---|
| 693 | (clobbered), not be changed, be set to agree with the results of the |
---|
| 694 | operation, or only changed if the item previously set into the |
---|
| 695 | condition code has been modified. |
---|
| 696 | |
---|
| 697 | Here is part of a sample `md' file for such a machine: |
---|
| 698 | |
---|
| 699 | (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) |
---|
| 700 | |
---|
| 701 | (define_attr "cc" "clobber,unchanged,set,change0" |
---|
| 702 | (cond [(eq_attr "type" "load") |
---|
| 703 | (const_string "change0") |
---|
| 704 | (eq_attr "type" "store,branch") |
---|
| 705 | (const_string "unchanged") |
---|
| 706 | (eq_attr "type" "arith") |
---|
| 707 | (if_then_else (match_operand:SI 0 "" "") |
---|
| 708 | (const_string "set") |
---|
| 709 | (const_string "clobber"))] |
---|
| 710 | (const_string "clobber"))) |
---|
| 711 | |
---|
| 712 | (define_insn "" |
---|
| 713 | [(set (match_operand:SI 0 "general_operand" "=r,r,m") |
---|
| 714 | (match_operand:SI 1 "general_operand" "r,m,r"))] |
---|
| 715 | "" |
---|
| 716 | "@ |
---|
| 717 | move %0,%1 |
---|
| 718 | load %0,%1 |
---|
| 719 | store %0,%1" |
---|
| 720 | [(set_attr "type" "arith,load,store")]) |
---|
| 721 | |
---|
| 722 | Note that we assume in the above example that arithmetic operations |
---|
| 723 | performed on quantities smaller than a machine word clobber the |
---|
| 724 | condition code since they will set the condition code to a value |
---|
| 725 | corresponding to the full-word result. |
---|
| 726 | |
---|
| 727 | |
---|
| 728 | File: gcc.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes |
---|
| 729 | |
---|
| 730 | Computing the Length of an Insn |
---|
| 731 | ------------------------------- |
---|
| 732 | |
---|
| 733 | For many machines, multiple types of branch instructions are |
---|
| 734 | provided, each for different length branch displacements. In most |
---|
| 735 | cases, the assembler will choose the correct instruction to use. |
---|
| 736 | However, when the assembler cannot do so, GCC can when a special |
---|
| 737 | attribute, the `length' attribute, is defined. This attribute must be |
---|
| 738 | defined to have numeric values by specifying a null string in its |
---|
| 739 | `define_attr'. |
---|
| 740 | |
---|
| 741 | In the case of the `length' attribute, two additional forms of |
---|
| 742 | arithmetic terms are allowed in test expressions: |
---|
| 743 | |
---|
| 744 | `(match_dup N)' |
---|
| 745 | This refers to the address of operand N of the current insn, which |
---|
| 746 | must be a `label_ref'. |
---|
| 747 | |
---|
| 748 | `(pc)' |
---|
| 749 | This refers to the address of the *current* insn. It might have |
---|
| 750 | been more consistent with other usage to make this the address of |
---|
| 751 | the *next* insn but this would be confusing because the length of |
---|
| 752 | the current insn is to be computed. |
---|
| 753 | |
---|
| 754 | For normal insns, the length will be determined by value of the |
---|
| 755 | `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn |
---|
| 756 | patterns, the length is computed as the number of vectors multiplied by |
---|
| 757 | the size of each vector. |
---|
| 758 | |
---|
| 759 | Lengths are measured in addressable storage units (bytes). |
---|
| 760 | |
---|
| 761 | The following macros can be used to refine the length computation: |
---|
| 762 | |
---|
| 763 | `FIRST_INSN_ADDRESS' |
---|
| 764 | When the `length' insn attribute is used, this macro specifies the |
---|
| 765 | value to be assigned to the address of the first insn in a |
---|
| 766 | function. If not specified, 0 is used. |
---|
| 767 | |
---|
| 768 | `ADJUST_INSN_LENGTH (INSN, LENGTH)' |
---|
| 769 | If defined, modifies the length assigned to instruction INSN as a |
---|
| 770 | function of the context in which it is used. LENGTH is an lvalue |
---|
| 771 | that contains the initially computed length of the insn and should |
---|
| 772 | be updated with the correct length of the insn. If updating is |
---|
| 773 | required, INSN must not be a varying-length insn. |
---|
| 774 | |
---|
| 775 | This macro will normally not be required. A case in which it is |
---|
| 776 | required is the ROMP. On this machine, the size of an `addr_vec' |
---|
| 777 | insn must be increased by two to compensate for the fact that |
---|
| 778 | alignment may be required. |
---|
| 779 | |
---|
| 780 | The routine that returns `get_attr_length' (the value of the |
---|
| 781 | `length' attribute) can be used by the output routine to determine the |
---|
| 782 | form of the branch instruction to be written, as the example below |
---|
| 783 | illustrates. |
---|
| 784 | |
---|
| 785 | As an example of the specification of variable-length branches, |
---|
| 786 | consider the IBM 360. If we adopt the convention that a register will |
---|
| 787 | be set to the starting address of a function, we can jump to labels |
---|
| 788 | within 4k of the start using a four-byte instruction. Otherwise, we |
---|
| 789 | need a six-byte sequence to load the address from memory and then |
---|
| 790 | branch to it. |
---|
| 791 | |
---|
| 792 | On such a machine, a pattern for a branch instruction might be |
---|
| 793 | specified as follows: |
---|
| 794 | |
---|
| 795 | (define_insn "jump" |
---|
| 796 | [(set (pc) |
---|
| 797 | (label_ref (match_operand 0 "" "")))] |
---|
| 798 | "" |
---|
| 799 | "* |
---|
| 800 | { |
---|
| 801 | return (get_attr_length (insn) == 4 |
---|
| 802 | ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); |
---|
| 803 | }" |
---|
| 804 | [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) |
---|
| 805 | (const_int 4) |
---|
| 806 | (const_int 6)))]) |
---|
| 807 | |
---|
| 808 | |
---|
| 809 | File: gcc.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes |
---|
| 810 | |
---|
| 811 | Constant Attributes |
---|
| 812 | ------------------- |
---|
| 813 | |
---|
| 814 | A special form of `define_attr', where the expression for the |
---|
| 815 | default value is a `const' expression, indicates an attribute that is |
---|
| 816 | constant for a given run of the compiler. Constant attributes may be |
---|
| 817 | used to specify which variety of processor is used. For example, |
---|
| 818 | |
---|
| 819 | (define_attr "cpu" "m88100,m88110,m88000" |
---|
| 820 | (const |
---|
| 821 | (cond [(symbol_ref "TARGET_88100") (const_string "m88100") |
---|
| 822 | (symbol_ref "TARGET_88110") (const_string "m88110")] |
---|
| 823 | (const_string "m88000")))) |
---|
| 824 | |
---|
| 825 | (define_attr "memory" "fast,slow" |
---|
| 826 | (const |
---|
| 827 | (if_then_else (symbol_ref "TARGET_FAST_MEM") |
---|
| 828 | (const_string "fast") |
---|
| 829 | (const_string "slow")))) |
---|
| 830 | |
---|
| 831 | The routine generated for constant attributes has no parameters as it |
---|
| 832 | does not depend on any particular insn. RTL expressions used to define |
---|
| 833 | the value of a constant attribute may use the `symbol_ref' form, but |
---|
| 834 | may not use either the `match_operand' form or `eq_attr' forms |
---|
| 835 | involving insn attributes. |
---|
| 836 | |
---|
| 837 | |
---|
| 838 | File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes |
---|
| 839 | |
---|
| 840 | Delay Slot Scheduling |
---|
| 841 | --------------------- |
---|
| 842 | |
---|
| 843 | The insn attribute mechanism can be used to specify the requirements |
---|
| 844 | for delay slots, if any, on a target machine. An instruction is said to |
---|
| 845 | require a "delay slot" if some instructions that are physically after |
---|
| 846 | the instruction are executed as if they were located before it. |
---|
| 847 | Classic examples are branch and call instructions, which often execute |
---|
| 848 | the following instruction before the branch or call is performed. |
---|
| 849 | |
---|
| 850 | On some machines, conditional branch instructions can optionally |
---|
| 851 | "annul" instructions in the delay slot. This means that the |
---|
| 852 | instruction will not be executed for certain branch outcomes. Both |
---|
| 853 | instructions that annul if the branch is true and instructions that |
---|
| 854 | annul if the branch is false are supported. |
---|
| 855 | |
---|
| 856 | Delay slot scheduling differs from instruction scheduling in that |
---|
| 857 | determining whether an instruction needs a delay slot is dependent only |
---|
| 858 | on the type of instruction being generated, not on data flow between the |
---|
| 859 | instructions. See the next section for a discussion of data-dependent |
---|
| 860 | instruction scheduling. |
---|
| 861 | |
---|
| 862 | The requirement of an insn needing one or more delay slots is |
---|
| 863 | indicated via the `define_delay' expression. It has the following form: |
---|
| 864 | |
---|
| 865 | (define_delay TEST |
---|
| 866 | [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 |
---|
| 867 | DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 |
---|
| 868 | ...]) |
---|
| 869 | |
---|
| 870 | TEST is an attribute test that indicates whether this `define_delay' |
---|
| 871 | applies to a particular insn. If so, the number of required delay |
---|
| 872 | slots is determined by the length of the vector specified as the second |
---|
| 873 | argument. An insn placed in delay slot N must satisfy attribute test |
---|
| 874 | DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns |
---|
| 875 | may be annulled if the branch is true. Similarly, ANNUL-FALSE-N |
---|
| 876 | specifies which insns in the delay slot may be annulled if the branch |
---|
| 877 | is false. If annulling is not supported for that delay slot, `(nil)' |
---|
| 878 | should be coded. |
---|
| 879 | |
---|
| 880 | For example, in the common case where branch and call insns require |
---|
| 881 | a single delay slot, which may contain any insn other than a branch or |
---|
| 882 | call, the following would be placed in the `md' file: |
---|
| 883 | |
---|
| 884 | (define_delay (eq_attr "type" "branch,call") |
---|
| 885 | [(eq_attr "type" "!branch,call") (nil) (nil)]) |
---|
| 886 | |
---|
| 887 | Multiple `define_delay' expressions may be specified. In this case, |
---|
| 888 | each such expression specifies different delay slot requirements and |
---|
| 889 | there must be no insn for which tests in two `define_delay' expressions |
---|
| 890 | are both true. |
---|
| 891 | |
---|
| 892 | For example, if we have a machine that requires one delay slot for |
---|
| 893 | branches but two for calls, no delay slot can contain a branch or call |
---|
| 894 | insn, and any valid insn in the delay slot for the branch can be |
---|
| 895 | annulled if the branch is true, we might represent this as follows: |
---|
| 896 | |
---|
| 897 | (define_delay (eq_attr "type" "branch") |
---|
| 898 | [(eq_attr "type" "!branch,call") |
---|
| 899 | (eq_attr "type" "!branch,call") |
---|
| 900 | (nil)]) |
---|
| 901 | |
---|
| 902 | (define_delay (eq_attr "type" "call") |
---|
| 903 | [(eq_attr "type" "!branch,call") (nil) (nil) |
---|
| 904 | (eq_attr "type" "!branch,call") (nil) (nil)]) |
---|
| 905 | |
---|
| 906 | |
---|
| 907 | File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes |
---|
| 908 | |
---|
| 909 | Specifying Function Units |
---|
| 910 | ------------------------- |
---|
| 911 | |
---|
| 912 | On most RISC machines, there are instructions whose results are not |
---|
| 913 | available for a specific number of cycles. Common cases are |
---|
| 914 | instructions that load data from memory. On many machines, a pipeline |
---|
| 915 | stall will result if the data is referenced too soon after the load |
---|
| 916 | instruction. |
---|
| 917 | |
---|
| 918 | In addition, many newer microprocessors have multiple function |
---|
| 919 | units, usually one for integer and one for floating point, and often |
---|
| 920 | will incur pipeline stalls when a result that is needed is not yet |
---|
| 921 | ready. |
---|
| 922 | |
---|
| 923 | The descriptions in this section allow the specification of how much |
---|
| 924 | time must elapse between the execution of an instruction and the time |
---|
| 925 | when its result is used. It also allows specification of when the |
---|
| 926 | execution of an instruction will delay execution of similar instructions |
---|
| 927 | due to function unit conflicts. |
---|
| 928 | |
---|
| 929 | For the purposes of the specifications in this section, a machine is |
---|
| 930 | divided into "function units", each of which execute a specific class |
---|
| 931 | of instructions in first-in-first-out order. Function units that |
---|
| 932 | accept one instruction each cycle and allow a result to be used in the |
---|
| 933 | succeeding instruction (usually via forwarding) need not be specified. |
---|
| 934 | Classic RISC microprocessors will normally have a single function unit, |
---|
| 935 | which we can call `memory'. The newer "superscalar" processors will |
---|
| 936 | often have function units for floating point operations, usually at |
---|
| 937 | least a floating point adder and multiplier. |
---|
| 938 | |
---|
| 939 | Each usage of a function units by a class of insns is specified with |
---|
| 940 | a `define_function_unit' expression, which looks like this: |
---|
| 941 | |
---|
| 942 | (define_function_unit NAME MULTIPLICITY SIMULTANEITY |
---|
| 943 | TEST READY-DELAY ISSUE-DELAY |
---|
| 944 | [CONFLICT-LIST]) |
---|
| 945 | |
---|
| 946 | NAME is a string giving the name of the function unit. |
---|
| 947 | |
---|
| 948 | MULTIPLICITY is an integer specifying the number of identical units |
---|
| 949 | in the processor. If more than one unit is specified, they will be |
---|
| 950 | scheduled independently. Only truly independent units should be |
---|
| 951 | counted; a pipelined unit should be specified as a single unit. (The |
---|
| 952 | only common example of a machine that has multiple function units for a |
---|
| 953 | single instruction class that are truly independent and not pipelined |
---|
| 954 | are the two multiply and two increment units of the CDC 6600.) |
---|
| 955 | |
---|
| 956 | SIMULTANEITY specifies the maximum number of insns that can be |
---|
| 957 | executing in each instance of the function unit simultaneously or zero |
---|
| 958 | if the unit is pipelined and has no limit. |
---|
| 959 | |
---|
| 960 | All `define_function_unit' definitions referring to function unit |
---|
| 961 | NAME must have the same name and values for MULTIPLICITY and |
---|
| 962 | SIMULTANEITY. |
---|
| 963 | |
---|
| 964 | TEST is an attribute test that selects the insns we are describing |
---|
| 965 | in this definition. Note that an insn may use more than one function |
---|
| 966 | unit and a function unit may be specified in more than one |
---|
| 967 | `define_function_unit'. |
---|
| 968 | |
---|
| 969 | READY-DELAY is an integer that specifies the number of cycles after |
---|
| 970 | which the result of the instruction can be used without introducing any |
---|
| 971 | stalls. |
---|
| 972 | |
---|
| 973 | ISSUE-DELAY is an integer that specifies the number of cycles after |
---|
| 974 | the instruction matching the TEST expression begins using this unit |
---|
| 975 | until a subsequent instruction can begin. A cost of N indicates an N-1 |
---|
| 976 | cycle delay. A subsequent instruction may also be delayed if an |
---|
| 977 | earlier instruction has a longer READY-DELAY value. This blocking |
---|
| 978 | effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY, |
---|
| 979 | and CONFLICT-LIST terms. For a normal non-pipelined function unit, |
---|
| 980 | SIMULTANEITY is one, the unit is taken to block for the READY-DELAY |
---|
| 981 | cycles of the executing insn, and smaller values of ISSUE-DELAY are |
---|
| 982 | ignored. |
---|
| 983 | |
---|
| 984 | CONFLICT-LIST is an optional list giving detailed conflict costs for |
---|
| 985 | this unit. If specified, it is a list of condition test expressions to |
---|
| 986 | be applied to insns chosen to execute in NAME following the particular |
---|
| 987 | insn matching TEST that is already executing in NAME. For each insn in |
---|
| 988 | the list, ISSUE-DELAY specifies the conflict cost; for insns not in the |
---|
| 989 | list, the cost is zero. If not specified, CONFLICT-LIST defaults to |
---|
| 990 | all instructions that use the function unit. |
---|
| 991 | |
---|
| 992 | Typical uses of this vector are where a floating point function unit |
---|
| 993 | can pipeline either single- or double-precision operations, but not |
---|
| 994 | both, or where a memory unit can pipeline loads, but not stores, etc. |
---|
| 995 | |
---|
| 996 | As an example, consider a classic RISC machine where the result of a |
---|
| 997 | load instruction is not available for two cycles (a single "delay" |
---|
| 998 | instruction is required) and where only one load instruction can be |
---|
| 999 | executed simultaneously. This would be specified as: |
---|
| 1000 | |
---|
| 1001 | (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0) |
---|
| 1002 | |
---|
| 1003 | For the case of a floating point function unit that can pipeline |
---|
| 1004 | either single or double precision, but not both, the following could be |
---|
| 1005 | specified: |
---|
| 1006 | |
---|
| 1007 | (define_function_unit |
---|
| 1008 | "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")]) |
---|
| 1009 | (define_function_unit |
---|
| 1010 | "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")]) |
---|
| 1011 | |
---|
| 1012 | *Note:* The scheduler attempts to avoid function unit conflicts and |
---|
| 1013 | uses all the specifications in the `define_function_unit' expression. |
---|
| 1014 | It has recently come to our attention that these specifications may not |
---|
| 1015 | allow modeling of some of the newer "superscalar" processors that have |
---|
| 1016 | insns using multiple pipelined units. These insns will cause a |
---|
| 1017 | potential conflict for the second unit used during their execution and |
---|
| 1018 | there is no way of representing that conflict. We welcome any examples |
---|
| 1019 | of how function unit conflicts work in such processors and suggestions |
---|
| 1020 | for their representation. |
---|
| 1021 | |
---|
| 1022 | |
---|
| 1023 | File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top |
---|
| 1024 | |
---|
| 1025 | Target Description Macros |
---|
| 1026 | ************************* |
---|
| 1027 | |
---|
| 1028 | In addition to the file `MACHINE.md', a machine description includes |
---|
| 1029 | a C header file conventionally given the name `MACHINE.h'. This header |
---|
| 1030 | file defines numerous macros that convey the information about the |
---|
| 1031 | target machine that does not fit into the scheme of the `.md' file. |
---|
| 1032 | The file `tm.h' should be a link to `MACHINE.h'. The header file |
---|
| 1033 | `config.h' includes `tm.h' and most compiler source files include |
---|
| 1034 | `config.h'. |
---|
| 1035 | |
---|
| 1036 | * Menu: |
---|
| 1037 | |
---|
| 1038 | * Driver:: Controlling how the driver runs the compilation passes. |
---|
| 1039 | * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. |
---|
| 1040 | * Storage Layout:: Defining sizes and alignments of data. |
---|
| 1041 | * Type Layout:: Defining sizes and properties of basic user data types. |
---|
| 1042 | * Registers:: Naming and describing the hardware registers. |
---|
| 1043 | * Register Classes:: Defining the classes of hardware registers. |
---|
| 1044 | * Stack and Calling:: Defining which way the stack grows and by how much. |
---|
| 1045 | * Varargs:: Defining the varargs macros. |
---|
| 1046 | * Trampolines:: Code set up at run time to enter a nested function. |
---|
| 1047 | * Library Calls:: Controlling how library routines are implicitly called. |
---|
| 1048 | * Addressing Modes:: Defining addressing modes valid for memory operands. |
---|
| 1049 | * Condition Code:: Defining how insns update the condition code. |
---|
| 1050 | * Costs:: Defining relative costs of different operations. |
---|
| 1051 | * Sections:: Dividing storage into text, data, and other sections. |
---|
| 1052 | * PIC:: Macros for position independent code. |
---|
| 1053 | * Assembler Format:: Defining how to write insns and pseudo-ops to output. |
---|
| 1054 | * Debugging Info:: Defining the format of debugging output. |
---|
| 1055 | * Cross-compilation:: Handling floating point for cross-compilers. |
---|
| 1056 | * Misc:: Everything else. |
---|
| 1057 | |
---|