1 | This is Info file gcc.info, produced by Makeinfo version 1.67 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, 1998 |
---|
10 | Free 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 | |
---|
33 | File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc |
---|
34 | |
---|
35 | Standard Pattern Names For Generation |
---|
36 | ===================================== |
---|
37 | |
---|
38 | Here is a table of the instruction names that are meaningful in the |
---|
39 | RTL generation pass of the compiler. Giving one of these names to an |
---|
40 | instruction pattern tells the RTL generation pass that it can use the |
---|
41 | pattern to accomplish a certain task. |
---|
42 | |
---|
43 | `movM' |
---|
44 | Here M stands for a two-letter machine mode name, in lower case. |
---|
45 | This instruction pattern moves data with that machine mode from |
---|
46 | operand 1 to operand 0. For example, `movsi' moves full-word data. |
---|
47 | |
---|
48 | If operand 0 is a `subreg' with mode M of a register whose own |
---|
49 | mode is wider than M, the effect of this instruction is to store |
---|
50 | the specified value in the part of the register that corresponds |
---|
51 | to mode M. The effect on the rest of the register is undefined. |
---|
52 | |
---|
53 | This class of patterns is special in several ways. First of all, |
---|
54 | each of these names *must* be defined, because there is no other |
---|
55 | way to copy a datum from one place to another. |
---|
56 | |
---|
57 | Second, these patterns are not used solely in the RTL generation |
---|
58 | pass. Even the reload pass can generate move insns to copy values |
---|
59 | from stack slots into temporary registers. When it does so, one |
---|
60 | of the operands is a hard register and the other is an operand |
---|
61 | that can need to be reloaded into a register. |
---|
62 | |
---|
63 | Therefore, when given such a pair of operands, the pattern must |
---|
64 | generate RTL which needs no reloading and needs no temporary |
---|
65 | registers--no registers other than the operands. For example, if |
---|
66 | you support the pattern with a `define_expand', then in such a |
---|
67 | case the `define_expand' mustn't call `force_reg' or any other such |
---|
68 | function which might generate new pseudo registers. |
---|
69 | |
---|
70 | This requirement exists even for subword modes on a RISC machine |
---|
71 | where fetching those modes from memory normally requires several |
---|
72 | insns and some temporary registers. Look in `spur.md' to see how |
---|
73 | the requirement can be satisfied. |
---|
74 | |
---|
75 | During reload a memory reference with an invalid address may be |
---|
76 | passed as an operand. Such an address will be replaced with a |
---|
77 | valid address later in the reload pass. In this case, nothing may |
---|
78 | be done with the address except to use it as it stands. If it is |
---|
79 | copied, it will not be replaced with a valid address. No attempt |
---|
80 | should be made to make such an address into a valid address and no |
---|
81 | routine (such as `change_address') that will do so may be called. |
---|
82 | Note that `general_operand' will fail when applied to such an |
---|
83 | address. |
---|
84 | |
---|
85 | The global variable `reload_in_progress' (which must be explicitly |
---|
86 | declared if required) can be used to determine whether such special |
---|
87 | handling is required. |
---|
88 | |
---|
89 | The variety of operands that have reloads depends on the rest of |
---|
90 | the machine description, but typically on a RISC machine these can |
---|
91 | only be pseudo registers that did not get hard registers, while on |
---|
92 | other machines explicit memory references will get optional |
---|
93 | reloads. |
---|
94 | |
---|
95 | If a scratch register is required to move an object to or from |
---|
96 | memory, it can be allocated using `gen_reg_rtx' prior to reload. |
---|
97 | But this is impossible during and after reload. If there are |
---|
98 | cases needing scratch registers after reload, you must define |
---|
99 | `SECONDARY_INPUT_RELOAD_CLASS' and perhaps also |
---|
100 | `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide |
---|
101 | patterns `reload_inM' or `reload_outM' to handle them. *Note |
---|
102 | Register Classes::. |
---|
103 | |
---|
104 | The constraints on a `movM' must permit moving any hard register |
---|
105 | to any other hard register provided that `HARD_REGNO_MODE_OK' |
---|
106 | permits mode M in both registers and `REGISTER_MOVE_COST' applied |
---|
107 | to their classes returns a value of 2. |
---|
108 | |
---|
109 | It is obligatory to support floating point `movM' instructions |
---|
110 | into and out of any registers that can hold fixed point values, |
---|
111 | because unions and structures (which have modes `SImode' or |
---|
112 | `DImode') can be in those registers and they may have floating |
---|
113 | point members. |
---|
114 | |
---|
115 | There may also be a need to support fixed point `movM' |
---|
116 | instructions in and out of floating point registers. |
---|
117 | Unfortunately, I have forgotten why this was so, and I don't know |
---|
118 | whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed |
---|
119 | point values in floating point registers, then the constraints of |
---|
120 | the fixed point `movM' instructions must be designed to avoid ever |
---|
121 | trying to reload into a floating point register. |
---|
122 | |
---|
123 | `reload_inM' |
---|
124 | `reload_outM' |
---|
125 | Like `movM', but used when a scratch register is required to move |
---|
126 | between operand 0 and operand 1. Operand 2 describes the scratch |
---|
127 | register. See the discussion of the `SECONDARY_RELOAD_CLASS' |
---|
128 | macro in *note Register Classes::.. |
---|
129 | |
---|
130 | `movstrictM' |
---|
131 | Like `movM' except that if operand 0 is a `subreg' with mode M of |
---|
132 | a register whose natural mode is wider, the `movstrictM' |
---|
133 | instruction is guaranteed not to alter any of the register except |
---|
134 | the part which belongs to mode M. |
---|
135 | |
---|
136 | `load_multiple' |
---|
137 | Load several consecutive memory locations into consecutive |
---|
138 | registers. Operand 0 is the first of the consecutive registers, |
---|
139 | operand 1 is the first memory location, and operand 2 is a |
---|
140 | constant: the number of consecutive registers. |
---|
141 | |
---|
142 | Define this only if the target machine really has such an |
---|
143 | instruction; do not define this if the most efficient way of |
---|
144 | loading consecutive registers from memory is to do them one at a |
---|
145 | time. |
---|
146 | |
---|
147 | On some machines, there are restrictions as to which consecutive |
---|
148 | registers can be stored into memory, such as particular starting or |
---|
149 | ending register numbers or only a range of valid counts. For those |
---|
150 | machines, use a `define_expand' (*note Expander Definitions::.) |
---|
151 | and make the pattern fail if the restrictions are not met. |
---|
152 | |
---|
153 | Write the generated insn as a `parallel' with elements being a |
---|
154 | `set' of one register from the appropriate memory location (you may |
---|
155 | also need `use' or `clobber' elements). Use a `match_parallel' |
---|
156 | (*note RTL Template::.) to recognize the insn. See `a29k.md' and |
---|
157 | `rs6000.md' for examples of the use of this insn pattern. |
---|
158 | |
---|
159 | `store_multiple' |
---|
160 | Similar to `load_multiple', but store several consecutive registers |
---|
161 | into consecutive memory locations. Operand 0 is the first of the |
---|
162 | consecutive memory locations, operand 1 is the first register, and |
---|
163 | operand 2 is a constant: the number of consecutive registers. |
---|
164 | |
---|
165 | `addM3' |
---|
166 | Add operand 2 and operand 1, storing the result in operand 0. All |
---|
167 | operands must have mode M. This can be used even on two-address |
---|
168 | machines, by means of constraints requiring operands 1 and 0 to be |
---|
169 | the same location. |
---|
170 | |
---|
171 | `subM3', `mulM3' |
---|
172 | `divM3', `udivM3', `modM3', `umodM3' |
---|
173 | `sminM3', `smaxM3', `uminM3', `umaxM3' |
---|
174 | `andM3', `iorM3', `xorM3' |
---|
175 | Similar, for other arithmetic operations. |
---|
176 | |
---|
177 | `mulhisi3' |
---|
178 | Multiply operands 1 and 2, which have mode `HImode', and store a |
---|
179 | `SImode' product in operand 0. |
---|
180 | |
---|
181 | `mulqihi3', `mulsidi3' |
---|
182 | Similar widening-multiplication instructions of other widths. |
---|
183 | |
---|
184 | `umulqihi3', `umulhisi3', `umulsidi3' |
---|
185 | Similar widening-multiplication instructions that do unsigned |
---|
186 | multiplication. |
---|
187 | |
---|
188 | `mulM3_highpart' |
---|
189 | Perform a signed multiplication of operands 1 and 2, which have |
---|
190 | mode M, and store the most significant half of the product in |
---|
191 | operand 0. The least significant half of the product is discarded. |
---|
192 | |
---|
193 | `umulM3_highpart' |
---|
194 | Similar, but the multiplication is unsigned. |
---|
195 | |
---|
196 | `divmodM4' |
---|
197 | Signed division that produces both a quotient and a remainder. |
---|
198 | Operand 1 is divided by operand 2 to produce a quotient stored in |
---|
199 | operand 0 and a remainder stored in operand 3. |
---|
200 | |
---|
201 | For machines with an instruction that produces both a quotient and |
---|
202 | a remainder, provide a pattern for `divmodM4' but do not provide |
---|
203 | patterns for `divM3' and `modM3'. This allows optimization in the |
---|
204 | relatively common case when both the quotient and remainder are |
---|
205 | computed. |
---|
206 | |
---|
207 | If an instruction that just produces a quotient or just a remainder |
---|
208 | exists and is more efficient than the instruction that produces |
---|
209 | both, write the output routine of `divmodM4' to call |
---|
210 | `find_reg_note' and look for a `REG_UNUSED' note on the quotient |
---|
211 | or remainder and generate the appropriate instruction. |
---|
212 | |
---|
213 | `udivmodM4' |
---|
214 | Similar, but does unsigned division. |
---|
215 | |
---|
216 | `ashlM3' |
---|
217 | Arithmetic-shift operand 1 left by a number of bits specified by |
---|
218 | operand 2, and store the result in operand 0. Here M is the mode |
---|
219 | of operand 0 and operand 1; operand 2's mode is specified by the |
---|
220 | instruction pattern, and the compiler will convert the operand to |
---|
221 | that mode before generating the instruction. |
---|
222 | |
---|
223 | `ashrM3', `lshrM3', `rotlM3', `rotrM3' |
---|
224 | Other shift and rotate instructions, analogous to the `ashlM3' |
---|
225 | instructions. |
---|
226 | |
---|
227 | `negM2' |
---|
228 | Negate operand 1 and store the result in operand 0. |
---|
229 | |
---|
230 | `absM2' |
---|
231 | Store the absolute value of operand 1 into operand 0. |
---|
232 | |
---|
233 | `sqrtM2' |
---|
234 | Store the square root of operand 1 into operand 0. |
---|
235 | |
---|
236 | The `sqrt' built-in function of C always uses the mode which |
---|
237 | corresponds to the C data type `double'. |
---|
238 | |
---|
239 | `ffsM2' |
---|
240 | Store into operand 0 one plus the index of the least significant |
---|
241 | 1-bit of operand 1. If operand 1 is zero, store zero. M is the |
---|
242 | mode of operand 0; operand 1's mode is specified by the instruction |
---|
243 | pattern, and the compiler will convert the operand to that mode |
---|
244 | before generating the instruction. |
---|
245 | |
---|
246 | The `ffs' built-in function of C always uses the mode which |
---|
247 | corresponds to the C data type `int'. |
---|
248 | |
---|
249 | `one_cmplM2' |
---|
250 | Store the bitwise-complement of operand 1 into operand 0. |
---|
251 | |
---|
252 | `cmpM' |
---|
253 | Compare operand 0 and operand 1, and set the condition codes. The |
---|
254 | RTL pattern should look like this: |
---|
255 | |
---|
256 | (set (cc0) (compare (match_operand:M 0 ...) |
---|
257 | (match_operand:M 1 ...))) |
---|
258 | |
---|
259 | `tstM' |
---|
260 | Compare operand 0 against zero, and set the condition codes. The |
---|
261 | RTL pattern should look like this: |
---|
262 | |
---|
263 | (set (cc0) (match_operand:M 0 ...)) |
---|
264 | |
---|
265 | `tstM' patterns should not be defined for machines that do not use |
---|
266 | `(cc0)'. Doing so would confuse the optimizer since it would no |
---|
267 | longer be clear which `set' operations were comparisons. The |
---|
268 | `cmpM' patterns should be used instead. |
---|
269 | |
---|
270 | `movstrM' |
---|
271 | Block move instruction. The addresses of the destination and |
---|
272 | source strings are the first two operands, and both are in mode |
---|
273 | `Pmode'. |
---|
274 | |
---|
275 | The number of bytes to move is the third operand, in mode M. |
---|
276 | Usually, you specify `word_mode' for M. However, if you can |
---|
277 | generate better code knowing the range of valid lengths is smaller |
---|
278 | than those representable in a full word, you should provide a |
---|
279 | pattern with a mode corresponding to the range of values you can |
---|
280 | handle efficiently (e.g., `QImode' for values in the range 0-127; |
---|
281 | note we avoid numbers that appear negative) and also a pattern |
---|
282 | with `word_mode'. |
---|
283 | |
---|
284 | The fourth operand is the known shared alignment of the source and |
---|
285 | destination, in the form of a `const_int' rtx. Thus, if the |
---|
286 | compiler knows that both source and destination are word-aligned, |
---|
287 | it may provide the value 4 for this operand. |
---|
288 | |
---|
289 | These patterns need not give special consideration to the |
---|
290 | possibility that the source and destination strings might overlap. |
---|
291 | |
---|
292 | `clrstrM' |
---|
293 | Block clear instruction. The addresses of the destination string |
---|
294 | is the first operand, in mode `Pmode'. The number of bytes to |
---|
295 | clear is the second operand, in mode M. See `movstrM' for a |
---|
296 | discussion of the choice of mode. |
---|
297 | |
---|
298 | The third operand is the known alignment of the destination, in |
---|
299 | the form of a `const_int' rtx. Thus, if the compiler knows that |
---|
300 | the destination is word-aligned, it may provide the value 4 for |
---|
301 | this operand. |
---|
302 | |
---|
303 | `cmpstrM' |
---|
304 | Block compare instruction, with five operands. Operand 0 is the |
---|
305 | output; it has mode M. The remaining four operands are like the |
---|
306 | operands of `movstrM'. The two memory blocks specified are |
---|
307 | compared byte by byte in lexicographic order. The effect of the |
---|
308 | instruction is to store a value in operand 0 whose sign indicates |
---|
309 | the result of the comparison. |
---|
310 | |
---|
311 | `strlenM' |
---|
312 | Compute the length of a string, with three operands. Operand 0 is |
---|
313 | the result (of mode M), operand 1 is a `mem' referring to the |
---|
314 | first character of the string, operand 2 is the character to |
---|
315 | search for (normally zero), and operand 3 is a constant describing |
---|
316 | the known alignment of the beginning of the string. |
---|
317 | |
---|
318 | `floatMN2' |
---|
319 | Convert signed integer operand 1 (valid for fixed point mode M) to |
---|
320 | floating point mode N and store in operand 0 (which has mode N). |
---|
321 | |
---|
322 | `floatunsMN2' |
---|
323 | Convert unsigned integer operand 1 (valid for fixed point mode M) |
---|
324 | to floating point mode N and store in operand 0 (which has mode N). |
---|
325 | |
---|
326 | `fixMN2' |
---|
327 | Convert operand 1 (valid for floating point mode M) to fixed point |
---|
328 | mode N as a signed number and store in operand 0 (which has mode |
---|
329 | N). This instruction's result is defined only when the value of |
---|
330 | operand 1 is an integer. |
---|
331 | |
---|
332 | `fixunsMN2' |
---|
333 | Convert operand 1 (valid for floating point mode M) to fixed point |
---|
334 | mode N as an unsigned number and store in operand 0 (which has |
---|
335 | mode N). This instruction's result is defined only when the value |
---|
336 | of operand 1 is an integer. |
---|
337 | |
---|
338 | `ftruncM2' |
---|
339 | Convert operand 1 (valid for floating point mode M) to an integer |
---|
340 | value, still represented in floating point mode M, and store it in |
---|
341 | operand 0 (valid for floating point mode M). |
---|
342 | |
---|
343 | `fix_truncMN2' |
---|
344 | Like `fixMN2' but works for any floating point value of mode M by |
---|
345 | converting the value to an integer. |
---|
346 | |
---|
347 | `fixuns_truncMN2' |
---|
348 | Like `fixunsMN2' but works for any floating point value of mode M |
---|
349 | by converting the value to an integer. |
---|
350 | |
---|
351 | `truncMN2' |
---|
352 | Truncate operand 1 (valid for mode M) to mode N and store in |
---|
353 | operand 0 (which has mode N). Both modes must be fixed point or |
---|
354 | both floating point. |
---|
355 | |
---|
356 | `extendMN2' |
---|
357 | Sign-extend operand 1 (valid for mode M) to mode N and store in |
---|
358 | operand 0 (which has mode N). Both modes must be fixed point or |
---|
359 | both floating point. |
---|
360 | |
---|
361 | `zero_extendMN2' |
---|
362 | Zero-extend operand 1 (valid for mode M) to mode N and store in |
---|
363 | operand 0 (which has mode N). Both modes must be fixed point. |
---|
364 | |
---|
365 | `extv' |
---|
366 | Extract a bit field from operand 1 (a register or memory operand), |
---|
367 | where operand 2 specifies the width in bits and operand 3 the |
---|
368 | starting bit, and store it in operand 0. Operand 0 must have mode |
---|
369 | `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; |
---|
370 | often `word_mode' is allowed only for registers. Operands 2 and 3 |
---|
371 | must be valid for `word_mode'. |
---|
372 | |
---|
373 | The RTL generation pass generates this instruction only with |
---|
374 | constants for operands 2 and 3. |
---|
375 | |
---|
376 | The bit-field value is sign-extended to a full word integer before |
---|
377 | it is stored in operand 0. |
---|
378 | |
---|
379 | `extzv' |
---|
380 | Like `extv' except that the bit-field value is zero-extended. |
---|
381 | |
---|
382 | `insv' |
---|
383 | Store operand 3 (which must be valid for `word_mode') into a bit |
---|
384 | field in operand 0, where operand 1 specifies the width in bits and |
---|
385 | operand 2 the starting bit. Operand 0 may have mode `byte_mode' or |
---|
386 | `word_mode'; often `word_mode' is allowed only for registers. |
---|
387 | Operands 1 and 2 must be valid for `word_mode'. |
---|
388 | |
---|
389 | The RTL generation pass generates this instruction only with |
---|
390 | constants for operands 1 and 2. |
---|
391 | |
---|
392 | `movMODEcc' |
---|
393 | Conditionally move operand 2 or operand 3 into operand 0 according |
---|
394 | to the comparison in operand 1. If the comparison is true, |
---|
395 | operand 2 is moved into operand 0, otherwise operand 3 is moved. |
---|
396 | |
---|
397 | The mode of the operands being compared need not be the same as |
---|
398 | the operands being moved. Some machines, sparc64 for example, |
---|
399 | have instructions that conditionally move an integer value based |
---|
400 | on the floating point condition codes and vice versa. |
---|
401 | |
---|
402 | If the machine does not have conditional move instructions, do not |
---|
403 | define these patterns. |
---|
404 | |
---|
405 | `sCOND' |
---|
406 | Store zero or nonzero in the operand according to the condition |
---|
407 | codes. Value stored is nonzero iff the condition COND is true. |
---|
408 | COND is the name of a comparison operation expression code, such |
---|
409 | as `eq', `lt' or `leu'. |
---|
410 | |
---|
411 | You specify the mode that the operand must have when you write the |
---|
412 | `match_operand' expression. The compiler automatically sees which |
---|
413 | mode you have used and supplies an operand of that mode. |
---|
414 | |
---|
415 | The value stored for a true condition must have 1 as its low bit, |
---|
416 | or else must be negative. Otherwise the instruction is not |
---|
417 | suitable and you should omit it from the machine description. You |
---|
418 | describe to the compiler exactly which value is stored by defining |
---|
419 | the macro `STORE_FLAG_VALUE' (*note Misc::.). If a description |
---|
420 | cannot be found that can be used for all the `sCOND' patterns, you |
---|
421 | should omit those operations from the machine description. |
---|
422 | |
---|
423 | These operations may fail, but should do so only in relatively |
---|
424 | uncommon cases; if they would fail for common cases involving |
---|
425 | integer comparisons, it is best to omit these patterns. |
---|
426 | |
---|
427 | If these operations are omitted, the compiler will usually |
---|
428 | generate code that copies the constant one to the target and |
---|
429 | branches around an assignment of zero to the target. If this code |
---|
430 | is more efficient than the potential instructions used for the |
---|
431 | `sCOND' pattern followed by those required to convert the result |
---|
432 | into a 1 or a zero in `SImode', you should omit the `sCOND' |
---|
433 | operations from the machine description. |
---|
434 | |
---|
435 | `bCOND' |
---|
436 | Conditional branch instruction. Operand 0 is a `label_ref' that |
---|
437 | refers to the label to jump to. Jump if the condition codes meet |
---|
438 | condition COND. |
---|
439 | |
---|
440 | Some machines do not follow the model assumed here where a |
---|
441 | comparison instruction is followed by a conditional branch |
---|
442 | instruction. In that case, the `cmpM' (and `tstM') patterns should |
---|
443 | simply store the operands away and generate all the required insns |
---|
444 | in a `define_expand' (*note Expander Definitions::.) for the |
---|
445 | conditional branch operations. All calls to expand `bCOND' |
---|
446 | patterns are immediately preceded by calls to expand either a |
---|
447 | `cmpM' pattern or a `tstM' pattern. |
---|
448 | |
---|
449 | Machines that use a pseudo register for the condition code value, |
---|
450 | or where the mode used for the comparison depends on the condition |
---|
451 | being tested, should also use the above mechanism. *Note Jump |
---|
452 | Patterns:: |
---|
453 | |
---|
454 | The above discussion also applies to the `movMODEcc' and `sCOND' |
---|
455 | patterns. |
---|
456 | |
---|
457 | `call' |
---|
458 | Subroutine call instruction returning no value. Operand 0 is the |
---|
459 | function to call; operand 1 is the number of bytes of arguments |
---|
460 | pushed (in mode `SImode', except it is normally a `const_int'); |
---|
461 | operand 2 is the number of registers used as operands. |
---|
462 | |
---|
463 | On most machines, operand 2 is not actually stored into the RTL |
---|
464 | pattern. It is supplied for the sake of some RISC machines which |
---|
465 | need to put this information into the assembler code; they can put |
---|
466 | it in the RTL instead of operand 1. |
---|
467 | |
---|
468 | Operand 0 should be a `mem' RTX whose address is the address of the |
---|
469 | function. Note, however, that this address can be a `symbol_ref' |
---|
470 | expression even if it would not be a legitimate memory address on |
---|
471 | the target machine. If it is also not a valid argument for a call |
---|
472 | instruction, the pattern for this operation should be a |
---|
473 | `define_expand' (*note Expander Definitions::.) that places the |
---|
474 | address into a register and uses that register in the call |
---|
475 | instruction. |
---|
476 | |
---|
477 | `call_value' |
---|
478 | Subroutine call instruction returning a value. Operand 0 is the |
---|
479 | hard register in which the value is returned. There are three more |
---|
480 | operands, the same as the three operands of the `call' instruction |
---|
481 | (but with numbers increased by one). |
---|
482 | |
---|
483 | Subroutines that return `BLKmode' objects use the `call' insn. |
---|
484 | |
---|
485 | `call_pop', `call_value_pop' |
---|
486 | Similar to `call' and `call_value', except used if defined and if |
---|
487 | `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' |
---|
488 | that contains both the function call and a `set' to indicate the |
---|
489 | adjustment made to the frame pointer. |
---|
490 | |
---|
491 | For machines where `RETURN_POPS_ARGS' can be non-zero, the use of |
---|
492 | these patterns increases the number of functions for which the |
---|
493 | frame pointer can be eliminated, if desired. |
---|
494 | |
---|
495 | `untyped_call' |
---|
496 | Subroutine call instruction returning a value of any type. |
---|
497 | Operand 0 is the function to call; operand 1 is a memory location |
---|
498 | where the result of calling the function is to be stored; operand |
---|
499 | 2 is a `parallel' expression where each element is a `set' |
---|
500 | expression that indicates the saving of a function return value |
---|
501 | into the result block. |
---|
502 | |
---|
503 | This instruction pattern should be defined to support |
---|
504 | `__builtin_apply' on machines where special instructions are needed |
---|
505 | to call a subroutine with arbitrary arguments or to save the value |
---|
506 | returned. This instruction pattern is required on machines that |
---|
507 | have multiple registers that can hold a return value (i.e. |
---|
508 | `FUNCTION_VALUE_REGNO_P' is true for more than one register). |
---|
509 | |
---|
510 | `return' |
---|
511 | Subroutine return instruction. This instruction pattern name |
---|
512 | should be defined only if a single instruction can do all the work |
---|
513 | of returning from a function. |
---|
514 | |
---|
515 | Like the `movM' patterns, this pattern is also used after the RTL |
---|
516 | generation phase. In this case it is to support machines where |
---|
517 | multiple instructions are usually needed to return from a |
---|
518 | function, but some class of functions only requires one |
---|
519 | instruction to implement a return. Normally, the applicable |
---|
520 | functions are those which do not need to save any registers or |
---|
521 | allocate stack space. |
---|
522 | |
---|
523 | For such machines, the condition specified in this pattern should |
---|
524 | only be true when `reload_completed' is non-zero and the function's |
---|
525 | epilogue would only be a single instruction. For machines with |
---|
526 | register windows, the routine `leaf_function_p' may be used to |
---|
527 | determine if a register window push is required. |
---|
528 | |
---|
529 | Machines that have conditional return instructions should define |
---|
530 | patterns such as |
---|
531 | |
---|
532 | (define_insn "" |
---|
533 | [(set (pc) |
---|
534 | (if_then_else (match_operator |
---|
535 | 0 "comparison_operator" |
---|
536 | [(cc0) (const_int 0)]) |
---|
537 | (return) |
---|
538 | (pc)))] |
---|
539 | "CONDITION" |
---|
540 | "...") |
---|
541 | |
---|
542 | where CONDITION would normally be the same condition specified on |
---|
543 | the named `return' pattern. |
---|
544 | |
---|
545 | `untyped_return' |
---|
546 | Untyped subroutine return instruction. This instruction pattern |
---|
547 | should be defined to support `__builtin_return' on machines where |
---|
548 | special instructions are needed to return a value of any type. |
---|
549 | |
---|
550 | Operand 0 is a memory location where the result of calling a |
---|
551 | function with `__builtin_apply' is stored; operand 1 is a |
---|
552 | `parallel' expression where each element is a `set' expression |
---|
553 | that indicates the restoring of a function return value from the |
---|
554 | result block. |
---|
555 | |
---|
556 | `nop' |
---|
557 | No-op instruction. This instruction pattern name should always be |
---|
558 | defined to output a no-op in assembler code. `(const_int 0)' will |
---|
559 | do as an RTL pattern. |
---|
560 | |
---|
561 | `indirect_jump' |
---|
562 | An instruction to jump to an address which is operand zero. This |
---|
563 | pattern name is mandatory on all machines. |
---|
564 | |
---|
565 | `casesi' |
---|
566 | Instruction to jump through a dispatch table, including bounds |
---|
567 | checking. This instruction takes five operands: |
---|
568 | |
---|
569 | 1. The index to dispatch on, which has mode `SImode'. |
---|
570 | |
---|
571 | 2. The lower bound for indices in the table, an integer constant. |
---|
572 | |
---|
573 | 3. The total range of indices in the table--the largest index |
---|
574 | minus the smallest one (both inclusive). |
---|
575 | |
---|
576 | 4. A label that precedes the table itself. |
---|
577 | |
---|
578 | 5. A label to jump to if the index has a value outside the |
---|
579 | bounds. (If the machine-description macro |
---|
580 | `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index |
---|
581 | drops through to the code following the jump table instead of |
---|
582 | jumping to this label. In that case, this label is not |
---|
583 | actually used by the `casesi' instruction, but it is always |
---|
584 | provided as an operand.) |
---|
585 | |
---|
586 | The table is a `addr_vec' or `addr_diff_vec' inside of a |
---|
587 | `jump_insn'. The number of elements in the table is one plus the |
---|
588 | difference between the upper bound and the lower bound. |
---|
589 | |
---|
590 | `tablejump' |
---|
591 | Instruction to jump to a variable address. This is a low-level |
---|
592 | capability which can be used to implement a dispatch table when |
---|
593 | there is no `casesi' pattern. |
---|
594 | |
---|
595 | This pattern requires two operands: the address or offset, and a |
---|
596 | label which should immediately precede the jump table. If the |
---|
597 | macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand |
---|
598 | is an offset which counts from the address of the table; |
---|
599 | otherwise, it is an absolute address to jump to. In either case, |
---|
600 | the first operand has mode `Pmode'. |
---|
601 | |
---|
602 | The `tablejump' insn is always the last insn before the jump table |
---|
603 | it uses. Its assembler code normally has no need to use the |
---|
604 | second operand, but you should incorporate it in the RTL pattern so |
---|
605 | that the jump optimizer will not delete the table as unreachable |
---|
606 | code. |
---|
607 | |
---|
608 | `canonicalize_funcptr_for_compare' |
---|
609 | Canonicalize the function pointer in operand 1 and store the result |
---|
610 | into operand 0. |
---|
611 | |
---|
612 | Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be |
---|
613 | a `reg', `mem', `symbol_ref', `const_int', etc and also has mode |
---|
614 | `Pmode'. |
---|
615 | |
---|
616 | Canonicalization of a function pointer usually involves computing |
---|
617 | the address of the function which would be called if the function |
---|
618 | pointer were used in an indirect call. |
---|
619 | |
---|
620 | Only define this pattern if function pointers on the target machine |
---|
621 | can have different values but still call the same function when |
---|
622 | used in an indirect call. |
---|
623 | |
---|
624 | `save_stack_block' |
---|
625 | `save_stack_function' |
---|
626 | `save_stack_nonlocal' |
---|
627 | `restore_stack_block' |
---|
628 | `restore_stack_function' |
---|
629 | `restore_stack_nonlocal' |
---|
630 | Most machines save and restore the stack pointer by copying it to |
---|
631 | or from an object of mode `Pmode'. Do not define these patterns on |
---|
632 | such machines. |
---|
633 | |
---|
634 | Some machines require special handling for stack pointer saves and |
---|
635 | restores. On those machines, define the patterns corresponding to |
---|
636 | the non-standard cases by using a `define_expand' (*note Expander |
---|
637 | Definitions::.) that produces the required insns. The three types |
---|
638 | of saves and restores are: |
---|
639 | |
---|
640 | 1. `save_stack_block' saves the stack pointer at the start of a |
---|
641 | block that allocates a variable-sized object, and |
---|
642 | `restore_stack_block' restores the stack pointer when the |
---|
643 | block is exited. |
---|
644 | |
---|
645 | 2. `save_stack_function' and `restore_stack_function' do a |
---|
646 | similar job for the outermost block of a function and are |
---|
647 | used when the function allocates variable-sized objects or |
---|
648 | calls `alloca'. Only the epilogue uses the restored stack |
---|
649 | pointer, allowing a simpler save or restore sequence on some |
---|
650 | machines. |
---|
651 | |
---|
652 | 3. `save_stack_nonlocal' is used in functions that contain labels |
---|
653 | branched to by nested functions. It saves the stack pointer |
---|
654 | in such a way that the inner function can use |
---|
655 | `restore_stack_nonlocal' to restore the stack pointer. The |
---|
656 | compiler generates code to restore the frame and argument |
---|
657 | pointer registers, but some machines require saving and |
---|
658 | restoring additional data such as register window information |
---|
659 | or stack backchains. Place insns in these patterns to save |
---|
660 | and restore any such required data. |
---|
661 | |
---|
662 | When saving the stack pointer, operand 0 is the save area and |
---|
663 | operand 1 is the stack pointer. The mode used to allocate the |
---|
664 | save area is the mode of operand 0. You must specify an integral |
---|
665 | mode, or `VOIDmode' if no save area is needed for a particular |
---|
666 | type of save (either because no save is needed or because a |
---|
667 | machine-specific save area can be used). Operand 0 is the stack |
---|
668 | pointer and operand 1 is the save area for restore operations. If |
---|
669 | `save_stack_block' is defined, operand 0 must not be `VOIDmode' |
---|
670 | since these saves can be arbitrarily nested. |
---|
671 | |
---|
672 | A save area is a `mem' that is at a constant offset from |
---|
673 | `virtual_stack_vars_rtx' when the stack pointer is saved for use by |
---|
674 | nonlocal gotos and a `reg' in the other two cases. |
---|
675 | |
---|
676 | `allocate_stack' |
---|
677 | Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 |
---|
678 | from the stack pointer to create space for dynamically allocated |
---|
679 | data. |
---|
680 | |
---|
681 | Store the resultant pointer to this space into operand 0. If you |
---|
682 | are allocating space from the main stack, do this by emitting a |
---|
683 | move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If |
---|
684 | you are allocating the space elsewhere, generate code to copy the |
---|
685 | location of the space to operand 0. In the latter case, you must |
---|
686 | ensure this space gets freed when the corresponding space on the |
---|
687 | main stack is free. |
---|
688 | |
---|
689 | Do not define this pattern if all that must be done is the |
---|
690 | subtraction. Some machines require other operations such as stack |
---|
691 | probes or maintaining the back chain. Define this pattern to emit |
---|
692 | those operations in addition to updating the stack pointer. |
---|
693 | |
---|
694 | `probe' |
---|
695 | Some machines require instructions to be executed after space is |
---|
696 | allocated from the stack, for example to generate a reference at |
---|
697 | the bottom of the stack. |
---|
698 | |
---|
699 | If you need to emit instructions before the stack has been |
---|
700 | adjusted, put them into the `allocate_stack' pattern. Otherwise, |
---|
701 | define this pattern to emit the required instructions. |
---|
702 | |
---|
703 | No operands are provided. |
---|
704 | |
---|
705 | `check_stack' |
---|
706 | If stack checking cannot be done on your system by probing the |
---|
707 | stack with a load or store instruction (*note Stack Checking::.), |
---|
708 | define this pattern to perform the needed check and signaling an |
---|
709 | error if the stack has overflowed. The single operand is the |
---|
710 | location in the stack furthest from the current stack pointer that |
---|
711 | you need to validate. Normally, on machines where this pattern is |
---|
712 | needed, you would obtain the stack limit from a global or |
---|
713 | thread-specific variable or register. |
---|
714 | |
---|
715 | `nonlocal_goto' |
---|
716 | Emit code to generate a non-local goto, e.g., a jump from one |
---|
717 | function to a label in an outer function. This pattern has four |
---|
718 | arguments, each representing a value to be used in the jump. The |
---|
719 | first argument is to be loadedd into the frame pointer, the second |
---|
720 | is the address to branch to (code to dispatch to the actual label), |
---|
721 | the third is the address of a location where the stack is saved, |
---|
722 | and the last is the address of the label, to be placed in the |
---|
723 | location for the incoming static chain. |
---|
724 | |
---|
725 | On most machines you need not define this pattern, since GNU CC |
---|
726 | will already generate the correct code, which is to load the frame |
---|
727 | pointer and static chain, restore the stack (using the |
---|
728 | `restore_stack_nonlocal' pattern, if defined), and jump indirectly |
---|
729 | to the dispatcher. You need only define this pattern if this code |
---|
730 | will not work on your machine. |
---|
731 | |
---|
732 | `nonlocal_goto_receiver' |
---|
733 | This pattern, if defined, contains code needed at the target of a |
---|
734 | nonlocal goto after the code already generated by GNU CC. You |
---|
735 | will not normally need to define this pattern. A typical reason |
---|
736 | why you might need this pattern is if some value, such as a |
---|
737 | pointer to a global table, must be restored when the frame pointer |
---|
738 | is restored. There are no arguments. |
---|
739 | |
---|
740 | `exception_receiver' |
---|
741 | This pattern, if defined, contains code needed at the site of an |
---|
742 | exception handler that isn't needed at the site of a nonlocal |
---|
743 | goto. You will not normally need to define this pattern. A |
---|
744 | typical reason why you might need this pattern is if some value, |
---|
745 | such as a pointer to a global table, must be restored after |
---|
746 | control flow is branched to the handler of an exception. There |
---|
747 | are no arguments. |
---|
748 | |
---|
749 | `builtin_setjmp_receiver' |
---|
750 | This pattern, if defined, contains code needed at the site of an |
---|
751 | builtin setjmp that isn't needed at the site of a nonlocal goto. |
---|
752 | You will not normally need to define this pattern. A typical |
---|
753 | reason why you might need this pattern is if some value, such as a |
---|
754 | pointer to a global table, must be restored. This pattern is |
---|
755 | called immediate after the call to `__dummy' has been emitted. |
---|
756 | There are no arguments. |
---|
757 | |
---|
758 | |
---|
759 | File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc |
---|
760 | |
---|
761 | When the Order of Patterns Matters |
---|
762 | ================================== |
---|
763 | |
---|
764 | Sometimes an insn can match more than one instruction pattern. Then |
---|
765 | the pattern that appears first in the machine description is the one |
---|
766 | used. Therefore, more specific patterns (patterns that will match |
---|
767 | fewer things) and faster instructions (those that will produce better |
---|
768 | code when they do match) should usually go first in the description. |
---|
769 | |
---|
770 | In some cases the effect of ordering the patterns can be used to hide |
---|
771 | a pattern when it is not valid. For example, the 68000 has an |
---|
772 | instruction for converting a fullword to floating point and another for |
---|
773 | converting a byte to floating point. An instruction converting an |
---|
774 | integer to floating point could match either one. We put the pattern |
---|
775 | to convert the fullword first to make sure that one will be used rather |
---|
776 | than the other. (Otherwise a large integer might be generated as a |
---|
777 | single-byte immediate quantity, which would not work.) Instead of using |
---|
778 | this pattern ordering it would be possible to make the pattern for |
---|
779 | convert-a-byte smart enough to deal properly with any constant value. |
---|
780 | |
---|
781 | |
---|
782 | File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc |
---|
783 | |
---|
784 | Interdependence of Patterns |
---|
785 | =========================== |
---|
786 | |
---|
787 | Every machine description must have a named pattern for each of the |
---|
788 | conditional branch names `bCOND'. The recognition template must always |
---|
789 | have the form |
---|
790 | |
---|
791 | (set (pc) |
---|
792 | (if_then_else (COND (cc0) (const_int 0)) |
---|
793 | (label_ref (match_operand 0 "" "")) |
---|
794 | (pc))) |
---|
795 | |
---|
796 | In addition, every machine description must have an anonymous pattern |
---|
797 | for each of the possible reverse-conditional branches. Their templates |
---|
798 | look like |
---|
799 | |
---|
800 | (set (pc) |
---|
801 | (if_then_else (COND (cc0) (const_int 0)) |
---|
802 | (pc) |
---|
803 | (label_ref (match_operand 0 "" "")))) |
---|
804 | |
---|
805 | They are necessary because jump optimization can turn direct-conditional |
---|
806 | branches into reverse-conditional branches. |
---|
807 | |
---|
808 | It is often convenient to use the `match_operator' construct to |
---|
809 | reduce the number of patterns that must be specified for branches. For |
---|
810 | example, |
---|
811 | |
---|
812 | (define_insn "" |
---|
813 | [(set (pc) |
---|
814 | (if_then_else (match_operator 0 "comparison_operator" |
---|
815 | [(cc0) (const_int 0)]) |
---|
816 | (pc) |
---|
817 | (label_ref (match_operand 1 "" ""))))] |
---|
818 | "CONDITION" |
---|
819 | "...") |
---|
820 | |
---|
821 | In some cases machines support instructions identical except for the |
---|
822 | machine mode of one or more operands. For example, there may be |
---|
823 | "sign-extend halfword" and "sign-extend byte" instructions whose |
---|
824 | patterns are |
---|
825 | |
---|
826 | (set (match_operand:SI 0 ...) |
---|
827 | (extend:SI (match_operand:HI 1 ...))) |
---|
828 | |
---|
829 | (set (match_operand:SI 0 ...) |
---|
830 | (extend:SI (match_operand:QI 1 ...))) |
---|
831 | |
---|
832 | Constant integers do not specify a machine mode, so an instruction to |
---|
833 | extend a constant value could match either pattern. The pattern it |
---|
834 | actually will match is the one that appears first in the file. For |
---|
835 | correct results, this must be the one for the widest possible mode |
---|
836 | (`HImode', here). If the pattern matches the `QImode' instruction, the |
---|
837 | results will be incorrect if the constant value does not actually fit |
---|
838 | that mode. |
---|
839 | |
---|
840 | Such instructions to extend constants are rarely generated because |
---|
841 | they are optimized away, but they do occasionally happen in nonoptimized |
---|
842 | compilations. |
---|
843 | |
---|
844 | If a constraint in a pattern allows a constant, the reload pass may |
---|
845 | replace a register with a constant permitted by the constraint in some |
---|
846 | cases. Similarly for memory references. Because of this substitution, |
---|
847 | you should not provide separate patterns for increment and decrement |
---|
848 | instructions. Instead, they should be generated from the same pattern |
---|
849 | that supports register-register add insns by examining the operands and |
---|
850 | generating the appropriate machine instruction. |
---|
851 | |
---|
852 | |
---|
853 | File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc |
---|
854 | |
---|
855 | Defining Jump Instruction Patterns |
---|
856 | ================================== |
---|
857 | |
---|
858 | For most machines, GNU CC assumes that the machine has a condition |
---|
859 | code. A comparison insn sets the condition code, recording the results |
---|
860 | of both signed and unsigned comparison of the given operands. A |
---|
861 | separate branch insn tests the condition code and branches or not |
---|
862 | according its value. The branch insns come in distinct signed and |
---|
863 | unsigned flavors. Many common machines, such as the Vax, the 68000 and |
---|
864 | the 32000, work this way. |
---|
865 | |
---|
866 | Some machines have distinct signed and unsigned compare |
---|
867 | instructions, and only one set of conditional branch instructions. The |
---|
868 | easiest way to handle these machines is to treat them just like the |
---|
869 | others until the final stage where assembly code is written. At this |
---|
870 | time, when outputting code for the compare instruction, peek ahead at |
---|
871 | the following branch using `next_cc0_user (insn)'. (The variable |
---|
872 | `insn' refers to the insn being output, in the output-writing code in |
---|
873 | an instruction pattern.) If the RTL says that is an unsigned branch, |
---|
874 | output an unsigned compare; otherwise output a signed compare. When |
---|
875 | the branch itself is output, you can treat signed and unsigned branches |
---|
876 | identically. |
---|
877 | |
---|
878 | The reason you can do this is that GNU CC always generates a pair of |
---|
879 | consecutive RTL insns, possibly separated by `note' insns, one to set |
---|
880 | the condition code and one to test it, and keeps the pair inviolate |
---|
881 | until the end. |
---|
882 | |
---|
883 | To go with this technique, you must define the machine-description |
---|
884 | macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no |
---|
885 | compare instruction is superfluous. |
---|
886 | |
---|
887 | Some machines have compare-and-branch instructions and no condition |
---|
888 | code. A similar technique works for them. When it is time to "output" |
---|
889 | a compare instruction, record its operands in two static variables. |
---|
890 | When outputting the branch-on-condition-code instruction that follows, |
---|
891 | actually output a compare-and-branch instruction that uses the |
---|
892 | remembered operands. |
---|
893 | |
---|
894 | It also works to define patterns for compare-and-branch instructions. |
---|
895 | In optimizing compilation, the pair of compare and branch instructions |
---|
896 | will be combined according to these patterns. But this does not happen |
---|
897 | if optimization is not requested. So you must use one of the solutions |
---|
898 | above in addition to any special patterns you define. |
---|
899 | |
---|
900 | In many RISC machines, most instructions do not affect the condition |
---|
901 | code and there may not even be a separate condition code register. On |
---|
902 | these machines, the restriction that the definition and use of the |
---|
903 | condition code be adjacent insns is not necessary and can prevent |
---|
904 | important optimizations. For example, on the IBM RS/6000, there is a |
---|
905 | delay for taken branches unless the condition code register is set three |
---|
906 | instructions earlier than the conditional branch. The instruction |
---|
907 | scheduler cannot perform this optimization if it is not permitted to |
---|
908 | separate the definition and use of the condition code register. |
---|
909 | |
---|
910 | On these machines, do not use `(cc0)', but instead use a register to |
---|
911 | represent the condition code. If there is a specific condition code |
---|
912 | register in the machine, use a hard register. If the condition code or |
---|
913 | comparison result can be placed in any general register, or if there are |
---|
914 | multiple condition registers, use a pseudo register. |
---|
915 | |
---|
916 | On some machines, the type of branch instruction generated may |
---|
917 | depend on the way the condition code was produced; for example, on the |
---|
918 | 68k and Sparc, setting the condition code directly from an add or |
---|
919 | subtract instruction does not clear the overflow bit the way that a test |
---|
920 | instruction does, so a different branch instruction must be used for |
---|
921 | some conditional branches. For machines that use `(cc0)', the set and |
---|
922 | use of the condition code must be adjacent (separated only by `note' |
---|
923 | insns) allowing flags in `cc_status' to be used. (*Note Condition |
---|
924 | Code::.) Also, the comparison and branch insns can be located from |
---|
925 | each other by using the functions `prev_cc0_setter' and `next_cc0_user'. |
---|
926 | |
---|
927 | However, this is not true on machines that do not use `(cc0)'. On |
---|
928 | those machines, no assumptions can be made about the adjacency of the |
---|
929 | compare and branch insns and the above methods cannot be used. Instead, |
---|
930 | we use the machine mode of the condition code register to record |
---|
931 | different formats of the condition code register. |
---|
932 | |
---|
933 | Registers used to store the condition code value should have a mode |
---|
934 | that is in class `MODE_CC'. Normally, it will be `CCmode'. If |
---|
935 | additional modes are required (as for the add example mentioned above in |
---|
936 | the Sparc), define the macro `EXTRA_CC_MODES' to list the additional |
---|
937 | modes required (*note Condition Code::.). Also define `EXTRA_CC_NAMES' |
---|
938 | to list the names of those modes and `SELECT_CC_MODE' to choose a mode |
---|
939 | given an operand of a compare. |
---|
940 | |
---|
941 | If it is known during RTL generation that a different mode will be |
---|
942 | required (for example, if the machine has separate compare instructions |
---|
943 | for signed and unsigned quantities, like most IBM processors), they can |
---|
944 | be specified at that time. |
---|
945 | |
---|
946 | If the cases that require different modes would be made by |
---|
947 | instruction combination, the macro `SELECT_CC_MODE' determines which |
---|
948 | machine mode should be used for the comparison result. The patterns |
---|
949 | should be written using that mode. To support the case of the add on |
---|
950 | the Sparc discussed above, we have the pattern |
---|
951 | |
---|
952 | (define_insn "" |
---|
953 | [(set (reg:CC_NOOV 0) |
---|
954 | (compare:CC_NOOV |
---|
955 | (plus:SI (match_operand:SI 0 "register_operand" "%r") |
---|
956 | (match_operand:SI 1 "arith_operand" "rI")) |
---|
957 | (const_int 0)))] |
---|
958 | "" |
---|
959 | "...") |
---|
960 | |
---|
961 | The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for |
---|
962 | comparisons whose argument is a `plus'. |
---|
963 | |
---|
964 | |
---|
965 | File: gcc.info, Node: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc |
---|
966 | |
---|
967 | Canonicalization of Instructions |
---|
968 | ================================ |
---|
969 | |
---|
970 | There are often cases where multiple RTL expressions could represent |
---|
971 | an operation performed by a single machine instruction. This situation |
---|
972 | is most commonly encountered with logical, branch, and |
---|
973 | multiply-accumulate instructions. In such cases, the compiler attempts |
---|
974 | to convert these multiple RTL expressions into a single canonical form |
---|
975 | to reduce the number of insn patterns required. |
---|
976 | |
---|
977 | In addition to algebraic simplifications, following canonicalizations |
---|
978 | are performed: |
---|
979 | |
---|
980 | * For commutative and comparison operators, a constant is always |
---|
981 | made the second operand. If a machine only supports a constant as |
---|
982 | the second operand, only patterns that match a constant in the |
---|
983 | second operand need be supplied. |
---|
984 | |
---|
985 | For these operators, if only one operand is a `neg', `not', |
---|
986 | `mult', `plus', or `minus' expression, it will be the first |
---|
987 | operand. |
---|
988 | |
---|
989 | * For the `compare' operator, a constant is always the second operand |
---|
990 | on machines where `cc0' is used (*note Jump Patterns::.). On other |
---|
991 | machines, there are rare cases where the compiler might want to |
---|
992 | construct a `compare' with a constant as the first operand. |
---|
993 | However, these cases are not common enough for it to be worthwhile |
---|
994 | to provide a pattern matching a constant as the first operand |
---|
995 | unless the machine actually has such an instruction. |
---|
996 | |
---|
997 | An operand of `neg', `not', `mult', `plus', or `minus' is made the |
---|
998 | first operand under the same conditions as above. |
---|
999 | |
---|
1000 | * `(minus X (const_int N))' is converted to `(plus X (const_int |
---|
1001 | -N))'. |
---|
1002 | |
---|
1003 | * Within address computations (i.e., inside `mem'), a left shift is |
---|
1004 | converted into the appropriate multiplication by a power of two. |
---|
1005 | |
---|
1006 | * De`Morgan's Law is used to move bitwise negation inside a bitwise |
---|
1007 | logical-and or logical-or operation. If this results in only one |
---|
1008 | operand being a `not' expression, it will be the first one. |
---|
1009 | |
---|
1010 | A machine that has an instruction that performs a bitwise |
---|
1011 | logical-and of one operand with the bitwise negation of the other |
---|
1012 | should specify the pattern for that instruction as |
---|
1013 | |
---|
1014 | (define_insn "" |
---|
1015 | [(set (match_operand:M 0 ...) |
---|
1016 | (and:M (not:M (match_operand:M 1 ...)) |
---|
1017 | (match_operand:M 2 ...)))] |
---|
1018 | "..." |
---|
1019 | "...") |
---|
1020 | |
---|
1021 | Similarly, a pattern for a "NAND" instruction should be written |
---|
1022 | |
---|
1023 | (define_insn "" |
---|
1024 | [(set (match_operand:M 0 ...) |
---|
1025 | (ior:M (not:M (match_operand:M 1 ...)) |
---|
1026 | (not:M (match_operand:M 2 ...))))] |
---|
1027 | "..." |
---|
1028 | "...") |
---|
1029 | |
---|
1030 | In both cases, it is not necessary to include patterns for the many |
---|
1031 | logically equivalent RTL expressions. |
---|
1032 | |
---|
1033 | * The only possible RTL expressions involving both bitwise |
---|
1034 | exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M |
---|
1035 | (xor:M X Y))'. |
---|
1036 | |
---|
1037 | * The sum of three items, one of which is a constant, will only |
---|
1038 | appear in the form |
---|
1039 | |
---|
1040 | (plus:M (plus:M X Y) CONSTANT) |
---|
1041 | |
---|
1042 | * On machines that do not use `cc0', `(compare X (const_int 0))' |
---|
1043 | will be converted to X. |
---|
1044 | |
---|
1045 | * Equality comparisons of a group of bits (usually a single bit) |
---|
1046 | with zero will be written using `zero_extract' rather than the |
---|
1047 | equivalent `and' or `sign_extract' operations. |
---|
1048 | |
---|