![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.4 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: 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
1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect
! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
! 16: original, and provided that the entire resulting derived work is
! 17: distributed under the terms of a permission notice identical to this
! 18: one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.4 ! root 22: versions, except that the sections entitled "GNU General Public
! 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
! 24: permission notice may be included in translations approved by the
! 25: Free Software Foundation instead of in the original English.
! 26:
! 27:
! 28:
! 29: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
! 30:
! 31: Output Templates and Operand Substitution
! 32: =========================================
! 33:
! 34: The "output template" is a string which specifies how to output the
! 35: assembler code for an instruction pattern. Most of the template is a
! 36: fixed string which is output literally. The character `%' is used to
! 37: specify where to substitute an operand; it can also be used to
! 38: identify places where different variants of the assembler require
! 39: different syntax.
! 40:
! 41: In the simplest case, a `%' followed by a digit N says to output
! 42: operand N at that point in the string.
! 43:
! 44: `%' followed by a letter and a digit says to output an operand in an
! 45: alternate fashion. Four letters have standard, built-in meanings
! 46: described below. The machine description macro `PRINT_OPERAND' can
! 47: define additional letters with nonstandard meanings.
! 48:
! 49: `%cDIGIT' can be used to substitute an operand that is a constant
! 50: value without the syntax that normally indicates an immediate operand.
! 51:
! 52: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
! 53: negated before printing.
! 54:
! 55: `%aDIGIT' can be used to substitute an operand as if it were a memory
! 56: reference, with the actual operand treated as the address. This may
! 57: be useful when outputting a "load address" instruction, because often
! 58: the assembler syntax for such an instruction requires you to write
! 59: the operand as if it were a memory reference.
! 60:
! 61: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
! 62:
! 63: `%' followed by a punctuation character specifies a substitution that
! 64: does not use an operand. Only one case is standard: `%%' outputs a
! 65: `%' into the assembler code. Other nonstandard cases can be defined
! 66: in the `PRINT_OPERAND' macro. You must also define which punctuation
! 67: characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
! 68:
! 69: The template may generate multiple assembler instructions. Write the
! 70: text for the instructions, with `\;' between them.
! 71:
! 72: When the RTL contains two operands which are required by constraint
! 73: to match each other, the output template must refer only to the
! 74: lower-numbered operand. Matching operands are not always identical,
! 75: and the rest of the compiler arranges to put the proper RTL
! 76: expression for printing into the lower-numbered operand.
! 77:
! 78: One use of nonstandard letters or punctuation following `%' is to
! 79: distinguish between different assembler languages for the same
! 80: machine; for example, Motorola syntax versus MIT syntax for the
! 81: 68000. Motorola syntax requires periods in most opcode names, while
! 82: MIT syntax does not. For example, the opcode `movel' in MIT syntax
! 83: is `move.l' in Motorola syntax. The same file of patterns is used
! 84: for both kinds of output syntax, but the character sequence `%.' is
! 85: used in each place where Motorola syntax wants a period. The
! 86: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to
! 87: output a period; the macro for MIT syntax defines it to do nothing.
1.1.1.2 root 88:
1.1.1.3 root 89:
90:
91: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
92:
93: C Statements for Generating Assembler Output
94: ============================================
95:
96: Often a single fixed template string cannot produce correct and
97: efficient assembler code for all the cases that are recognized by a
98: single instruction pattern. For example, the opcodes may depend on
99: the kinds of operands; or some unfortunate combinations of operands
100: may require extra machine instructions.
101:
102: If the output control string starts with a `*', then it is not an
103: output template but rather a piece of C program that should compute a
104: template. It should execute a `return' statement to return the
105: template-string you want. Most such templates use C string literals,
106: which require doublequote characters to delimit them. To include
107: these doublequote characters in the string, prefix each one with `\'.
108:
109: The operands may be found in the array `operands', whose C data type
110: is `rtx []'.
111:
112: It is possible to output an assembler instruction and then go on to
113: output or compute more of them, using the subroutine
114: `output_asm_insn'. This receives two arguments: a template-string
115: and a vector of operands. The vector may be `operands', or it may be
116: another array of `rtx' that you declare locally and initialize
117: yourself.
118:
119: When an insn pattern has multiple alternatives in its constraints,
120: often the appearance of the assembler code is determined mostly by
121: which alternative was matched. When this is so, the C code can test
122: the variable `which_alternative', which is the ordinal number of the
123: alternative that was actually satisfied (0 for the first, 1 for the
124: second alternative, etc.).
125:
126: For example, suppose there are two opcodes for storing zero, `clrreg'
127: for registers and `clrmem' for memory locations. Here is how a
128: pattern could use `which_alternative' to choose between them:
129:
130: (define_insn ""
131: [(set (match_operand:SI 0 "general_operand" "r,m")
132: (const_int 0))]
133: ""
134: "*
135: return (which_alternative == 0
136: ? \"clrreg %0\" : \"clrmem %0\");
137: ")
138:
139:
140:
141: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
142:
143: Operand Constraints
144: ===================
145:
146: Each `match_operand' in an instruction pattern can specify a
147: constraint for the type of operands allowed. Constraints can say
148: whether an operand may be in a register, and which kinds of register;
149: whether the operand can be a memory reference, and which kinds of
150: address; whether the operand may be an immediate constant, and which
151: possible values it may have. Constraints can also require two
152: operands to match.
153:
154: * Menu:
155:
156: * Simple Constraints:: Basic use of constraints.
157: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
158: * Class Preferences:: Constraints guide which hard register to put things in.
159: * Modifiers:: More precise control over effects of constraints.
160: * No Constraints:: Describing a clean machine without constraints.
161:
162:
163:
164: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints
165:
166: Simple Constraints
167: ------------------
168:
169: The simplest kind of constraint is a string full of letters, each of
170: which describes one kind of operand that is permitted. Here are the
171: letters that are allowed:
172:
173: `m'
174: A memory operand is allowed, with any kind of address that the
175: machine supports in general.
176:
177: `o'
178: A memory operand is allowed, but only if the address is
179: "offsettable". This means that adding a small integer
180: (actually, the width in bytes of the operand, as determined by
181: its machine mode) may be added to the address and the result is
182: also a valid memory address.
183:
184: For example, an address which is constant is offsettable; so is
185: an address that is the sum of a register and a constant (as long
186: as a slightly larger constant is also within the range of
187: address-offsets supported by the machine); but an autoincrement
188: or autodecrement address is not offsettable. More complicated
189: indirect/indexed addresses may or may not be offsettable
190: depending on the other addressing modes that the machine supports.
191:
192: Note that in an output operand which can be matched by another
193: operand, the constraint letter `o' is valid only when
194: accompanied by both `<' (if the target machine has predecrement
195: addressing) and `>' (if the target machine has preincrement
196: addressing).
197:
198: When the constraint letter `o' is used, the reload pass may
199: generate instructions which copy a nonoffsettable address into
200: an index register. The idea is that the register can be used as
201: a replacement offsettable address. But this method requires
202: that there be patterns to copy any kind of address into a
203: register. Auto-increment and auto-decrement addresses are an
204: exception; there need not be an instruction that can copy such
205: an address into a register, because reload handles these cases
206: specially.
207:
1.1.1.4 ! root 208: Most older machine designs have "load address" instructions
1.1.1.3 root 209: which do just what is needed here. Some RISC machines do not
210: advertise such instructions, but the possible addresses on these
211: machines are very limited, so it is easy to fake them.
212:
213: `<'
214: A memory operand with autodecrement addressing (either
215: predecrement or postdecrement) is allowed.
216:
217: `>'
218: A memory operand with autoincrement addressing (either
219: preincrement or postincrement) is allowed.
220:
221: `r'
222: A register operand is allowed provided that it is in a general
223: register.
224:
225: `d', `a', `f', ...
226: Other letters can be defined in machine-dependent fashion to
227: stand for particular classes of registers. `d', `a' and `f' are
228: defined on the 68000/68020 to stand for data, address and
229: floating point registers.
230:
231: `i'
232: An immediate integer operand (one with constant value) is allowed.
233: This includes symbolic constants whose values will be known only
234: at assembly time.
235:
236: `n'
237: An immediate integer operand with a known numeric value is
238: allowed. Many systems cannot support assembly-time constants
239: for operands less than a word wide. Constraints for these
240: operands should use `n' rather than `i'.
241:
242: `I', `J', `K', ...
243: Other letters in the range `I' through `M' may be defined in a
244: machine-dependent fashion to permit immediate integer operands
245: with explicit integer values in specified ranges. For example,
246: on the 68000, `I' is defined to stand for the range of values 1
247: to 8. This is the range permitted as a shift count in the shift
248: instructions.
249:
250: `F'
251: An immediate floating operand (expression code `const_double')
252: is allowed.
253:
254: `G', `H'
255: `G' and `H' may be defined in a machine-dependent fashion to
256: permit immediate floating operands in particular ranges of values.
257:
258: `s'
259: An immediate integer operand whose value is not an explicit
260: integer is allowed.
261:
262: This might appear strange; if an insn allows a constant operand
263: with a value not known at compile time, it certainly must allow
264: any known value. So why use `s' instead of `i'? Sometimes it
265: allows better code to be generated.
266:
267: For example, on the 68000 in a fullword instruction it is
268: possible to use an immediate operand; but if the immediate value
269: is between -128 and 127, better code results from loading the
270: value into a register and using the register. This is because
271: the load into the register can be done with a `moveq'
272: instruction. We arrange for this to happen by defining the
1.1.1.4 ! root 273: letter `K' to mean "any integer outside the range -128 to 127",
! 274: and then specifying `Ks' in the operand constraints.
1.1.1.3 root 275:
276: `g'
277: Any register, memory or immediate integer operand is allowed,
278: except for registers that are not general registers.
279:
280: `N' (a digit)
281: An operand that matches operand number N is allowed. If a digit
282: is used together with letters, the digit should come last.
283:
284: This is called a "matching constraint" and what it really means
285: is that the assembler has only a single operand that fills two
286: roles considered separate in the RTL insn. For example, an add
287: insn has two input operands and one output operand in the RTL,
288: but on most machines an add instruction really has only two
289: operands, one of them an input-output operand.
290:
291: Matching constraints work only in circumstances like that add
292: insn. More precisely, the matching constraint must appear in an
293: input-only operand and the operand that it matches must be an
294: output-only operand with a lower number. Thus, operand N must
295: have `=' in its constraint.
296:
297: For operands to match in a particular case usually means that
298: they are identical-looking RTL expressions. But in a few
299: special cases specific kinds of dissimilarity are allowed. For
300: example, `*x' as an input operand will match `*x++' as an output
301: operand. For proper results in such cases, the output template
302: should always use the output-operand's number when printing the
303: operand.
304:
305: `p'
306: An operand that is a valid memory address is allowed. This is
1.1.1.4 ! root 307: for "load address" and "push address" instructions.
1.1.1.3 root 308:
309: `p' in the constraint must be accompanies by `address_operand'
310: as the predicate in the `match_operand'.
311:
312: In order to have valid assembler code, each operand must satisfy its
313: constraint. But a failure to do so does not prevent the pattern from
314: applying to an insn. Instead, it directs the compiler to modify the
315: code so that the constraint will be satisfied. Usually this is done
316: by copying an operand into a register.
317:
318: Contrast, therefore, the two instruction patterns that follow:
319:
320: (define_insn ""
321: [(set (match_operand:SI 0 "general_operand" "r")
322: (plus:SI (match_dup 0)
323: (match_operand:SI 1 "general_operand" "r")))]
324: ""
325: "...")
326:
327: which has two operands, one of which must appear in two places, and
328:
329: (define_insn ""
330: [(set (match_operand:SI 0 "general_operand" "r")
331: (plus:SI (match_operand:SI 1 "general_operand" "0")
332: (match_operand:SI 2 "general_operand" "r")))]
333: ""
334: "...")
335:
336: which has three operands, two of which are required by a constraint
337: to be identical. If we are considering an insn of the form
338:
339: (insn N PREV NEXT
340: (set (reg:SI 3)
341: (plus:SI (reg:SI 6) (reg:SI 109)))
342: ...)
343:
344: the first pattern would not apply at all, because this insn does not
345: contain two identical subexpressions in the right place. The pattern
1.1.1.4 ! root 346: would say, "That does not look like an add instruction; try other
! 347: patterns." The second pattern would say, "Yes, that's an add
! 348: instruction, but there is something wrong with it." It would direct
1.1.1.3 root 349: the reload pass of the compiler to generate additional insns to make
350: the constraint true. The results might look like this:
351:
352: (insn N2 PREV N
353: (set (reg:SI 3) (reg:SI 6))
354: ...)
355:
356: (insn N N2 NEXT
357: (set (reg:SI 3)
358: (plus:SI (reg:SI 3) (reg:SI 109)))
359: ...)
360:
361: It is up to you to make sure that each operand, in each pattern, has
362: constraints that can handle any RTL expression that could be present
363: for that operand. (When multiple alternatives are in use, each
364: pattern must, for each possible combination of operand expressions,
365: have at least one alternative which can handle that combination of
366: operands.) The constraints don't need to *allow* any possible
367: operand--when this is the case, they do not constrain--but they must
368: at least point the way to reloading any possible operand so that it
369: will fit.
370:
371: * If the constraint accepts whatever operands the predicate
372: permits, there is no problem: reloading is never necessary for
373: this operand.
374:
375: For example, an operand whose constraints permit everything
376: except registers is safe provided its predicate rejects registers.
377:
378: An operand whose predicate accepts only constant values is safe
379: provided its constraints include the letter `i'. If any
380: possible constant value is accepted, then nothing less than `i'
381: will do; if the predicate is more selective, then the
382: constraints may also be more selective.
383:
384: * Any operand expression can be reloaded by copying it into a
385: register. So if an operand's constraints allow some kind of
386: register, it is certain to be safe. It need not permit all
387: classes of registers; the compiler knows how to copy a register
388: into another register of the proper class in order to make an
389: instruction valid.
390:
391: * A nonoffsettable memory reference can be reloaded by copying the
392: address into a register. So if the constraint uses the letter
393: `o', all memory references are taken care of.
394:
395: * A constant operand can be reloaded by allocating space in memory
396: to hold it as preinitialized data. Then the memory reference
397: can be used in place of the constant. So if the constraint uses
398: the letters `o' or `m', constant operands are not a problem.
399:
400: If the operand's predicate can recognize registers, but the
401: constraint does not permit them, it can make the compiler crash.
402: When this operand happens to be a register, the reload pass will be
403: stymied, because it does not know how to copy a register temporarily
404: into memory.
405:
406:
407:
408: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
409:
410: Multiple Alternative Constraints
411: --------------------------------
412:
413: Sometimes a single instruction has multiple alternative sets of
414: possible operands. For example, on the 68000, a logical-or
415: instruction can combine register or an immediate value into memory,
416: or it can combine any kind of operand into a register; but it cannot
417: combine one memory location into another.
418:
419: These constraints are represented as multiple alternatives. An
420: alternative can be described by a series of letters for each operand.
421: The overall constraint for an operand is made from the letters for
422: this operand from the first alternative, a comma, the letters for
423: this operand from the second alternative, a comma, and so on until
424: the last alternative. Here is how it is done for fullword logical-or
425: on the 68000:
426:
427: (define_insn "iorsi3"
428: [(set (match_operand:SI 0 "general_operand" "=m,d")
429: (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
430: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
431: ...)
432:
433: The first alternative has `m' (memory) for operand 0, `0' for operand
434: 1 (meaning it must match operand 0), and `dKs' for operand 2. The
435: second alternative has `d' (data register) for operand 0, `0' for
436: operand 1, and `dmKs' for operand 2. The `=' and `%' in the
437: constraints apply to all the alternatives; their meaning is explained
438: in the next section.
439:
440: If all the operands fit any one alternative, the instruction is valid.
441: Otherwise, for each alternative, the compiler counts how many
442: instructions must be added to copy the operands so that that
443: alternative applies. The alternative requiring the least copying is
444: chosen. If two alternatives need the same amount of copying, the one
445: that comes first is chosen. These choices can be altered with the
446: `?' and `!' characters:
447:
448: `?'
449: Disparage slightly the alternative that the `?' appears in, as a
450: choice when no alternative applies exactly. The compiler
451: regards this alternative as one unit more costly for each `?'
452: that appears in it.
453:
454: `!'
455: Disparage severely the alternative that the `!' appears in.
456: When operands must be copied into registers, the compiler will
457: never choose this alternative as the one to strive for.
458:
459: When an insn pattern has multiple alternatives in its constraints,
460: often the appearance of the assembler code is determined mostly by
461: which alternative was matched. When this is so, the C code for
462: writing the assembler code can use the variable `which_alternative',
463: which is the ordinal number of the alternative that was actually
464: satisfied (0 for the first, 1 for the second alternative, etc.). For
465: example:
466:
467: (define_insn ""
468: [(set (match_operand:SI 0 "general_operand" "r,m")
469: (const_int 0))]
470: ""
471: "*
472: return (which_alternative == 0
473: ? \"clrreg %0\" : \"clrmem %0\");
474: ")
475:
476:
477:
478: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
479:
480: Register Class Preferences
481: --------------------------
482:
483: The operand constraints have another function: they enable the
484: compiler to decide which kind of hardware register a pseudo register
485: is best allocated to. The compiler examines the constraints that
486: apply to the insns that use the pseudo register, looking for the
487: machine-dependent letters such as `d' and `a' that specify classes of
488: registers. The pseudo register is put in whichever class gets the
1.1.1.4 ! root 489: most "votes". The constraint letters `g' and `r' also vote: they
1.1.1.3 root 490: vote in favor of a general register. The machine description says
491: which registers are considered general.
492:
493: Of course, on some machines all registers are equivalent, and no
494: register classes are defined. Then none of this complexity is
495: relevant.
496:
497:
498:
499: File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints
500:
501: Constraint Modifier Characters
502: ------------------------------
503:
504: `='
505: Means that this operand is write-only for this instruction: the
506: previous value is discarded and replaced by output data.
507:
508: `+'
509: Means that this operand is both read and written by the
510: instruction.
511:
512: When the compiler fixes up the operands to satisfy the
513: constraints, it needs to know which operands are inputs to the
514: instruction and which are outputs from it. `=' identifies an
515: output; `+' identifies an operand that is both input and output;
516: all other operands are assumed to be input only.
517:
518: `&'
519: Means (in a particular alternative) that this operand is written
520: before the instruction is finished using the input operands.
521: Therefore, this operand may not lie in a register that is used
522: as an input operand or as part of any memory address.
523:
524: `&' applies only to the alternative in which it is written. In
525: constraints with multiple alternatives, sometimes one
526: alternative requires `&' while others do not. See, for example,
527: the `movdf' insn of the 68000.
528:
529: `&' does not obviate the need to write `='.
530:
531: `%'
532: Declares the instruction to be commutative for this operand and
533: the following operand. This means that the compiler may
534: interchange the two operands if that is the cheapest way to make
535: all operands fit the constraints. This is often used in
536: patterns for addition instructions that really have only two
537: operands: the result must go in one of the arguments. Here for
538: example, is how the 68000 halfword-add instruction is defined:
539:
540: (define_insn "addhi3"
541: [(set (match_operand:HI 0 "general_operand" "=m,r")
542: (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
543: (match_operand:HI 2 "general_operand" "di,g")))]
544: ...)
545:
546: Note that in previous versions of GNU CC the `%' constraint
547: modifier always applied to operands 1 and 2 regardless of which
548: operand it was written in. The usual custom was to write it in
549: operand 0. Now it must be in operand 1 if the operands to be
550: exchanged are 1 and 2.
551:
552: `#'
553: Says that all following characters, up to the next comma, are to
554: be ignored as a constraint. They are significant only for
555: choosing register preferences.
556:
557: `*'
558: Says that the following character should be ignored when
559: choosing register preferences. `*' has no effect on the meaning
560: of the constraint as a constraint.
561:
562: Here is an example: the 68000 has an instruction to sign-extend
563: a halfword in a data register, and can also sign-extend a value
564: by copying it into an address register. While either kind of
565: register is acceptable, the constraints on an address-register
566: destination are less strict, so it is best if register
567: allocation makes an address register its goal. Therefore, `*'
568: is used so that the `d' constraint letter (for data register) is
569: ignored when computing register preferences.
570:
571: (define_insn "extendhisi2"
572: [(set (match_operand:SI 0 "general_operand" "=*d,a")
573: (sign_extend:SI
574: (match_operand:HI 1 "general_operand" "0,g")))]
575: ...)
576:
577:
578:
579: File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints
580:
581: Not Using Constraints
582: ---------------------
583:
584: Some machines are so clean that operand constraints are not required.
585: For example, on the Vax, an operand valid in one context is valid in
586: any other context. On such a machine, every operand constraint would
1.1.1.4 ! root 587: be `g', excepting only operands of "load address" instructions which
! 588: are written as if they referred to a memory location's contents but
! 589: actual refer to its address. They would have constraint `p'.
1.1.1.3 root 590:
591: For such machines, instead of writing `g' and `p' for all the
592: constraints, you can choose to write a description with empty
593: constraints. Then you write `""' for the constraint in every
594: `match_operand'. Address operands are identified by writing an
595: `address' expression around the `match_operand', not by their
596: constraints.
597:
598: When the machine description has just empty constraints, certain
599: parts of compilation are skipped, making the compiler faster.
600: However, few machines actually do not need constraints; all machine
601: descriptions now in existence use constraints.
602:
603:
604:
605: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
606:
607: Standard Names for Patterns Used in Generation
608: ==============================================
609:
610: Here is a table of the instruction names that are meaningful in the
611: RTL generation pass of the compiler. Giving one of these names to an
612: instruction pattern tells the RTL generation pass that it can use the
613: pattern in to accomplish a certain task.
614:
615: `movM'
616: Here M stands for a two-letter machine mode name, in lower case.
617: This instruction pattern moves data with that machine mode from
618: operand 1 to operand 0. For example, `movsi' moves full-word
619: data.
620:
621: If operand 0 is a `subreg' with mode M of a register whose own
622: mode is wider than M, the effect of this instruction is to store
623: the specified value in the part of the register that corresponds
624: to mode M. The effect on the rest of the register is undefined.
625:
626: This class of patterns is special in several ways. First of
627: all, each of these names *must* be defined, because there is no
628: other way to copy a datum from one place to another.
629:
630: Second, these patterns are not used solely in the RTL generation
631: pass. Even the reload pass can generate move insns to copy
632: values from stack slots into temporary registers. When it does
633: so, one of the operands is a hard register and the other is an
634: operand that can need to be reloaded into a register.
635:
636: Therefore, when given such a pair of operands, the pattern must
637: generate RTL which needs no reloading and needs no temporary
638: registers--no registers other than the operands. For example,
639: if you support the pattern with a `define_expand', then in such
640: a case the `define_expand' mustn't call `force_reg' or any other
641: such function which might generate new pseudo registers.
642:
643: This requirement exists even for subword modes on a RISC machine
644: where fetching those modes from memory normally requires several
645: insns and some temporary registers. Look in `spur.md' to see
646: how the requirement can be satisfied.
647:
648: The variety of operands that have reloads depends on the rest of
649: the machine description, but typically on a RISC machine these
650: can only be pseudo registers that did not get hard registers,
651: while on other machines explicit memory references will get
652: optional reloads.
653:
654: The constraints on a `moveM' must allow any hard register to be
655: moved to any other hard register (provided that
656: `HARD_REGNO_MODE_OK' permits mode M in both registers).
657:
658: It is obligatory to support floating point `moveM' instructions
1.1.1.2 root 659: into and out of any registers that can hold fixed point values,
660: because unions and structures (which have modes `SImode' or
661: `DImode') can be in those registers and they may have floating
662: point members.
663:
1.1.1.3 root 664: There may also be a need to support fixed point `moveM'
1.1.1.2 root 665: instructions in and out of floating point registers.
666: Unfortunately, I have forgotten why this was so, and I don't
667: know whether it is still true. If `HARD_REGNO_MODE_OK' rejects
668: fixed point values in floating point registers, then the
1.1.1.3 root 669: constraints of the fixed point `moveM' instructions must be
1.1.1.2 root 670: designed to avoid ever trying to reload into a floating point
671: register.
672:
1.1.1.3 root 673: `movstrictM'
674: Like `movM' except that if operand 0 is a `subreg' with mode M
675: of a register whose natural mode is wider, the `movstrictM'
676: instruction is guaranteed not to alter any of the register
677: except the part which belongs to mode M.
678:
679: `addM3'
680: Add operand 2 and operand 1, storing the result in operand 0.
681: All operands must have mode M. This can be used even on
682: two-address machines, by means of constraints requiring operands
683: 1 and 0 to be the same location.
684:
685: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3'
686: Similar, for other arithmetic operations.
687:
688: There are special considerations for register classes for
689: logical-and instructions, affecting also the macro
690: `PREFERRED_RELOAD_CLASS'. They apply not only to the patterns
691: with these standard names, but to any patterns that will match
692: such an instruction. *Note Register Classes::.
693:
694: `mulhisi3'
695: Multiply operands 1 and 2, which have mode `HImode', and store a
696: `SImode' product in operand 0.
697:
698: `mulqihi3', `mulsidi3'
699: Similar widening-multiplication instructions of other widths.
700:
701: `umulqihi3', `umulhisi3', `umulsidi3'
702: Similar widening-multiplication instructions that do unsigned
703: multiplication.
704:
705: `divmodM4'
706: Signed division that produces both a quotient and a remainder.
707: Operand 1 is divided by operand 2 to produce a quotient stored
708: in operand 0 and a remainder stored in operand 3.
709:
710: `udivmodM4'
711: Similar, but does unsigned division.
712:
713: `ashlM3'
714: Arithmetic-shift operand 1 left by a number of bits specified by
715: operand 2, and store the result in operand 0. Operand 2 has
716: mode `SImode', not mode M.
717:
718: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
719: Other shift and rotate instructions.
720:
721: Logical and arithmetic left shift are the same. Machines that
722: do not allow negative shift counts often have only one
723: instruction for shifting left. On such machines, you should
724: define a pattern named `ashlM3' and leave `lshlM3' undefined.
725:
726: There are special considerations for register classes for shift
727: instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'.
728: They apply not only to the patterns with these standard names,
729: but to any patterns that will match such an instruction. *Note
730: Register Classes::.
731:
732: `negM2'
733: Negate operand 1 and store the result in operand 0.
734:
735: `absM2'
736: Store the absolute value of operand 1 into operand 0.
737:
738: `sqrtM2'
739: Store the square root of operand 1 into operand 0.
740:
741: `ffsM2'
742: Store into operand 0 one plus the index of the least significant
743: 1-bit of operand 1. If operand 1 is zero, store zero. M is the
744: mode of operand 0; operand 1's mode is specified by the
745: instruction pattern, and the compiler will convert the operand
746: to that mode before generating the instruction.
747:
748: `one_cmplM2'
749: Store the bitwise-complement of operand 1 into operand 0.
750:
751: `cmpM'
752: Compare operand 0 and operand 1, and set the condition codes.
753: The RTL pattern should look like this:
754:
755: (set (cc0) (compare (match_operand:M 0 ...)
756: (match_operand:M 1 ...)))
757:
758: Each such definition in the machine description, for integer
759: mode M, must have a corresponding `tstM' pattern, because
760: optimization can simplify the compare into a test when operand 1
761: is zero.
762:
763: `tstM'
764: Compare operand 0 against zero, and set the condition codes.
765: The RTL pattern should look like this:
766:
767: (set (cc0) (match_operand:M 0 ...))
768:
769: `movstrM'
770: Block move instruction. The addresses of the destination and
771: source strings are the first two operands, and both are in mode
772: `Pmode'. The number of bytes to move is the third operand, in
773: mode M. The fourth operand is the known shared alignment of the
774: source and destination, in the form of a `const_int' rtx.
775:
776: `cmpstrM'
777: Block compare instruction, with operands like `movstrM' except
778: that the two memory blocks are compared byte by byte in
779: lexicographic order. The effect of the instruction is to set
780: the condition codes.
781:
782: `floatMN2'
783: Convert signed integer operand 1 (valid for fixed point mode M)
784: to floating point mode N and store in operand 0 (which has mode
785: N).
786:
787: `floatunsMN2'
788: Convert unsigned integer operand 1 (valid for fixed point mode
789: M) to floating point mode N and store in operand 0 (which has
790: mode N).
791:
792: `fixMN2'
793: Convert operand 1 (valid for floating point mode M) to fixed
794: point mode N as a signed number and store in operand 0 (which
795: has mode N). This instruction's result is defined only when the
796: value of operand 1 is an integer.
797:
798: `fixunsMN2'
799: Convert operand 1 (valid for floating point mode M) to fixed
800: point mode N as an unsigned number and store in operand 0 (which
801: has mode N). This instruction's result is defined only when the
802: value of operand 1 is an integer.
803:
804: `ftruncM2'
805: Convert operand 1 (valid for floating point mode M) to an
806: integer value, still represented in floating point mode M, and
807: store it in operand 0 (valid for floating point mode M).
808:
809: `fix_truncMN2'
810: Like `fixMN2' but works for any floating point value of mode M
811: by converting the value to an integer.
812:
813: `fixuns_truncMN2'
814: Like `fixunsMN2' but works for any floating point value of mode
815: M by converting the value to an integer.
816:
817: `truncMN'
818: Truncate operand 1 (valid for mode M) to mode N and store in
819: operand 0 (which has mode N). Both modes must be fixed point or
820: both floating point.
821:
822: `extendMN'
823: Sign-extend operand 1 (valid for mode M) to mode N and store in
824: operand 0 (which has mode N). Both modes must be fixed point or
825: both floating point.
826:
827: `zero_extendMN'
828: Zero-extend operand 1 (valid for mode M) to mode N and store in
829: operand 0 (which has mode N). Both modes must be fixed point.
830:
831: `extv'
832: Extract a bit-field from operand 1 (a register or memory
833: operand), where operand 2 specifies the width in bits and
834: operand 3 the starting bit, and store it in operand 0. Operand
1.1.1.4 ! root 835: 0 must have `SImode'. Operand 1 may have mode `QImode' or
1.1.1.3 root 836: `SImode'; often `SImode' is allowed only for registers.
837: Operands 2 and 3 must be valid for `SImode'.
838:
839: The RTL generation pass generates this instruction only with
840: constants for operands 2 and 3.
841:
842: The bit-field value is sign-extended to a full word integer
843: before it is stored in operand 0.
844:
845: `extzv'
846: Like `extv' except that the bit-field value is zero-extended.
847:
848: `insv'
849: Store operand 3 (which must be valid for `SImode') into a
850: bit-field in operand 0, where operand 1 specifies the width in
851: bits and operand 2 the starting bit. Operand 0 may have mode
852: `QImode' or `SImode'; often `SImode' is allowed only for
853: registers. Operands 1 and 2 must be valid for `SImode'.
854:
855: The RTL generation pass generates this instruction only with
856: constants for operands 1 and 2.
857:
858: `sCOND'
859: Store zero or nonzero in the operand according to the condition
860: codes. Value stored is nonzero iff the condition COND is true.
861: COND is the name of a comparison operation expression code, such
862: as `eq', `lt' or `leu'.
863:
864: You specify the mode that the operand must have when you write
865: the `match_operand' expression. The compiler automatically sees
866: which mode you have used and supplies an operand of that mode.
867:
868: The value stored for a true condition must have 1 as its low
869: bit, or else must be negative. Otherwise the instruction is not
870: suitable and must be omitted from the machine description. You
871: must tell the compiler exactly which value is stored by defining
872: the macro `STORE_FLAG_VALUE'.
873:
874: `bCOND'
875: Conditional branch instruction. Operand 0 is a `label_ref' that
876: refers to the label to jump to. Jump if the condition codes
877: meet condition COND.
878:
879: `call'
880: Subroutine call instruction returning no value. Operand 0 is
881: the function to call; operand 1 is the number of bytes of
882: arguments pushed (in mode `SImode', except it is normally a
883: `const_int'); operand 2 is the number of registers used as
884: operands.
885:
886: On most machines, operand 2 is not actually stored into the RTL
887: pattern. It is supplied for the sake of some RISC machines
888: which need to put this information into the assembler code; they
889: can put it in the RTL instead of operand 1.
890:
891: Operand 0 should be a `mem' RTX whose address is the address of
892: the function.
893:
894: `call_value'
895: Subroutine call instruction returning a value. Operand 0 is the
896: hard register in which the value is returned. There are three
897: more operands, the same as the three operands of the `call'
898: instruction (but with numbers increased by one).
899:
900: Subroutines that return `BLKmode' objects use the `call' insn.
901:
902: `return'
903: Subroutine return instruction. This instruction pattern name
904: should be defined only if a single instruction can do all the
905: work of returning from a function.
906:
907: `nop'
908: No-op instruction. This instruction pattern name should always
909: be defined to output a no-op in assembler code. `(const_int 0)'
910: will do as an RTL pattern.
911:
912: `casesi'
913: Instruction to jump through a dispatch table, including bounds
914: checking. This instruction takes five operands:
915:
916: 1. The index to dispatch on, which has mode `SImode'.
917:
918: 2. The lower bound for indices in the table, an integer
919: constant.
920:
921: 3. The total range of indices in the table--the largest index
922: minus the smallest one (both inclusive).
923:
924: 4. A label to jump to if the index has a value outside the
925: bounds. (If the machine-description macro
926: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds
927: index drops through to the code following the jump table
928: instead of jumping to this label. In that case, this label
929: is not actually used by the `casesi' instruction, but it is
930: always provided as an operand.)
931:
932: 5. A label that precedes the table itself.
933:
934: The table is a `addr_vec' or `addr_diff_vec' inside of a
935: `jump_insn'. The number of elements in the table is one plus
936: the difference between the upper bound and the lower bound.
937:
938: `tablejump'
939: Instruction to jump to a variable address. This is a low-level
940: capability which can be used to implement a dispatch table when
941: there is no `casesi' pattern.
942:
943: This pattern requires two operands: the address or offset, and a
944: label which should immediately precede the jump table. If the
945: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first
1.1.1.4 ! root 946: operand is an offset that counts from the address of the table;
! 947: otherwise, it is an absolute address to jump to.
1.1.1.3 root 948:
949: The `tablejump' insn is always the last insn before the jump
950: table it uses. Its assembler code normally has no need to use
951: the second operand, but you should incorporate it in the RTL
952: pattern so that the jump optimizer will not delete the table as
953: unreachable code.
954:
955:
956:
957: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
958:
959: When the Order of Patterns Matters
960: ==================================
961:
962: Sometimes an insn can match more than one instruction pattern. Then
963: the pattern that appears first in the machine description is the one
964: used. Therefore, more specific patterns (patterns that will match
965: fewer things) and faster instructions (those that will produce better
966: code when they do match) should usually go first in the description.
967:
968: In some cases the effect of ordering the patterns can be used to hide
969: a pattern when it is not valid. For example, the 68000 has an
970: instruction for converting a fullword to floating point and another
971: for converting a byte to floating point. An instruction converting
972: an integer to floating point could match either one. We put the
973: pattern to convert the fullword first to make sure that one will be
974: used rather than the other. (Otherwise a large integer might be
975: generated as a single-byte immediate quantity, which would not work.)
976: Instead of using this pattern ordering it would be possible to make
977: the pattern for convert-a-byte smart enough to deal properly with any
978: constant value.
979:
980:
981:
982: File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
983:
984: Interdependence of Patterns
985: ===========================
986:
987: Every machine description must have a named pattern for each of the
988: conditional branch names `bCOND'. The recognition template must
989: always have the form
990:
991: (set (pc)
992: (if_then_else (COND (cc0) (const_int 0))
993: (label_ref (match_operand 0 "" ""))
994: (pc)))
995:
996: In addition, every machine description must have an anonymous pattern
997: for each of the possible reverse-conditional branches. These
998: patterns look like
999:
1000: (set (pc)
1001: (if_then_else (COND (cc0) (const_int 0))
1002: (pc)
1003: (label_ref (match_operand 0 "" ""))))
1004:
1005: They are necessary because jump optimization can turn
1006: direct-conditional branches into reverse-conditional branches.
1007:
1008: The compiler does more with RTL than just create it from patterns and
1009: recognize the patterns: it can perform arithmetic expression codes
1010: when constant values for their operands can be determined. As a
1011: result, sometimes having one pattern can require other patterns. For
1012: example, the Vax has no `and' instruction, but it has `and not'
1013: instructions. Here is the definition of one of them:
1014:
1015: (define_insn "andcbsi2"
1016: [(set (match_operand:SI 0 "general_operand" "")
1017: (and:SI (match_dup 0)
1018: (not:SI (match_operand:SI
1019: 1 "general_operand" ""))))]
1020: ""
1021: "bicl2 %1,%0")
1022:
1023: If operand 1 is an explicit integer constant, an instruction
1024: constructed using that pattern can be simplified into an `and' like
1025: this:
1026:
1027: (set (reg:SI 41)
1028: (and:SI (reg:SI 41)
1029: (const_int 0xffff7fff)))
1030:
1031: (where the integer constant is the one's complement of what appeared
1032: in the original instruction).
1033:
1034: To avoid a fatal error, the compiler must have a pattern that
1035: recognizes such an instruction. Here is what is used:
1036:
1037: (define_insn ""
1038: [(set (match_operand:SI 0 "general_operand" "")
1039: (and:SI (match_dup 0)
1040: (match_operand:SI 1 "general_operand" "")))]
1041: "GET_CODE (operands[1]) == CONST_INT"
1042: "*
1043: { operands[1]
1044: = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1]));
1045: return \"bicl2 %1,%0\";
1046: }")
1047:
1048: Whereas a pattern to match a general `and' instruction is impossible
1049: to support on the Vax, this pattern is possible because it matches
1050: only a constant second argument: a special case that can be output as
1051: an `and not' instruction.
1052:
1.1.1.4 ! root 1053: A "compare" instruction whose RTL looks like this:
1.1.1.3 root 1054:
1055: (set (cc0) (compare OPERAND (const_int 0)))
1056:
1.1.1.4 ! root 1057: may be simplified by optimization into a "test" like this:
1.1.1.3 root 1058:
1059: (set (cc0) OPERAND)
1060:
1.1.1.4 ! root 1061: So in the machine description, each "compare" pattern for an integer
! 1062: mode must have a corresponding "test" pattern that will match the
! 1063: result of such simplification.
1.1.1.3 root 1064:
1065: In some cases machines support instructions identical except for the
1066: machine mode of one or more operands. For example, there may be
1.1.1.4 ! root 1067: "sign-extend halfword" and "sign-extend byte" instructions whose
1.1.1.3 root 1068: patterns are
1069:
1070: (set (match_operand:SI 0 ...)
1071: (extend:SI (match_operand:HI 1 ...)))
1072:
1073: (set (match_operand:SI 0 ...)
1074: (extend:SI (match_operand:QI 1 ...)))
1075:
1076: Constant integers do not specify a machine mode, so an instruction to
1077: extend a constant value could match either pattern. The pattern it
1078: actually will match is the one that appears first in the file. For
1079: correct results, this must be the one for the widest possible mode
1080: (`HImode', here). If the pattern matches the `QImode' instruction,
1081: the results will be incorrect if the constant value does not actually
1082: fit that mode.
1083:
1084: Such instructions to extend constants are rarely generated because
1085: they are optimized away, but they do occasionally happen in
1086: nonoptimized compilations.
1087:
1088: When an instruction has the constraint letter `o', the reload pass
1089: may generate instructions which copy a nonoffsettable address into an
1090: index register. The idea is that the register can be used as a
1091: replacement offsettable address. In order for these generated
1092: instructions to work, there must be patterns to copy any kind of
1093: valid address into a register.
1094:
1.1.1.4 ! root 1095: Most older machine designs have "load address" instructions which do
! 1096: just what is needed here. Some RISC machines do not advertise such
! 1097: instructions, but the possible addresses on these machines are very
! 1098: limited, so it is easy to fake them.
1.1.1.3 root 1099:
1100: Auto-increment and auto-decrement addresses are an exception; there
1101: need not be an instruction that can copy such an address into a
1102: register, because reload handles these cases in a different manner.
1103:
1104:
1105:
1106: File: gcc.info, Node: Jump Patterns, Next: Peephole Definitions, Prev: Dependent Patterns, Up: Machine Desc
1107:
1108: Defining Jump Instruction Patterns
1109: ==================================
1110:
1111: GNU CC assumes that the machine has a condition code. A comparison
1112: insn sets the condition code, recording the results of both signed
1113: and unsigned comparison of the given operands. A separate branch
1114: insn tests the condition code and branches or not according its
1115: value. The branch insns come in distinct signed and unsigned
1116: flavors. Many common machines, such as the Vax, the 68000 and the
1117: 32000, work this way.
1118:
1119: Some machines have distinct signed and unsigned compare instructions,
1120: and only one set of conditional branch instructions. The easiest way
1121: to handle these machines is to treat them just like the others until
1122: the final stage where assembly code is written. At this time, when
1123: outputting code for the compare instruction, peek ahead at the
1124: following branch using `NEXT_INSN (insn)'. (The variable `insn'
1125: refers to the insn being output, in the output-writing code in an
1126: instruction pattern.) If the RTL says that is an unsigned branch,
1127: output an unsigned compare; otherwise output a signed compare. When
1128: the branch itself is output, you can treat signed and unsigned
1129: branches identically.
1130:
1131: The reason you can do this is that GNU CC always generates a pair of
1132: consecutive RTL insns, one to set the condition code and one to test
1133: it, and keeps the pair inviolate until the end.
1134:
1135: To go with this technique, you must define the machine-description
1136: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
1137: compare instruction is superfluous.
1138:
1139: Some machines have compare-and-branch instructions and no condition
1140: code. A similar technique works for them. When it is time to
1.1.1.4 ! root 1141: "output" a compare instruction, record its operands in two static
1.1.1.3 root 1142: variables. When outputting the branch-on-condition-code instruction
1143: that follows, actually output a compare-and-branch instruction that
1144: uses the remembered operands.
1145:
1146: It also works to define patterns for compare-and-branch instructions.
1147: In optimizing compilation, the pair of compare and branch
1148: instructions will be combined according to these patterns. But this
1149: does not happen if optimization is not requested. So you must use
1150: one of the solutions above in addition to any special patterns you
1151: define.
1.1 root 1152:
1153:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.