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