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