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