![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-14 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-14 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
32:
33: C Statements for Assembler Output
34: =================================
35:
36: Often a single fixed template string cannot produce correct and
37: efficient assembler code for all the cases that are recognized by a
38: single instruction pattern. For example, the opcodes may depend on the
39: kinds of operands; or some unfortunate combinations of operands may
40: require extra machine instructions.
41:
42: If the output control string starts with a `@', then it is actually
43: a series of templates, each on a separate line. (Blank lines and
44: leading spaces and tabs are ignored.) The templates correspond to the
45: pattern's constraint alternatives (*note Multi-Alternative::.). For
46: example, if a target machine has a two-address add instruction `addr'
47: to add into a register and another `addm' to add a register to memory,
48: you might write this pattern:
49:
50: (define_insn "addsi3"
51: [(set (match_operand:SI 0 "general_operand" "=r,m")
52: (plus:SI (match_operand:SI 1 "general_operand" "0,0")
53: (match_operand:SI 2 "general_operand" "g,r")))]
54: ""
55: "@
56: addr %2,%0
57: addm %2,%0")
58:
59: If the output control string starts with a `*', then it is not an
60: output template but rather a piece of C program that should compute a
61: template. It should execute a `return' statement to return the
62: template-string you want. Most such templates use C string literals,
63: which require doublequote characters to delimit them. To include these
64: doublequote characters in the string, prefix each one with `\'.
65:
66: The operands may be found in the array `operands', whose C data type
67: is `rtx []'.
68:
69: It is very common to select different ways of generating assembler
70: code based on whether an immediate operand is within a certain range.
71: Be careful when doing this, because the result of `INTVAL' is an
72: integer on the host machine. If the host machine has more bits in an
73: `int' than the target machine has in the mode in which the constant
74: will be used, then some of the bits you get from `INTVAL' will be
75: superfluous. For proper results, you must carefully disregard the
76: values of those bits.
77:
78: It is possible to output an assembler instruction and then go on to
79: output or compute more of them, using the subroutine `output_asm_insn'.
80: This receives two arguments: a template-string and a vector of
81: operands. The vector may be `operands', or it may be another array of
82: `rtx' that you declare locally and initialize yourself.
83:
84: When an insn pattern has multiple alternatives in its constraints,
85: often the appearance of the assembler code is determined mostly by
86: which alternative was matched. When this is so, the C code can test
87: the variable `which_alternative', which is the ordinal number of the
88: alternative that was actually satisfied (0 for the first, 1 for the
89: second alternative, etc.).
90:
91: For example, suppose there are two opcodes for storing zero, `clrreg'
92: for registers and `clrmem' for memory locations. Here is how a pattern
93: could use `which_alternative' to choose between them:
94:
95: (define_insn ""
96: [(set (match_operand:SI 0 "general_operand" "=r,m")
97: (const_int 0))]
98: ""
99: "*
100: return (which_alternative == 0
101: ? \"clrreg %0\" : \"clrmem %0\");
102: ")
103:
104: The example above, where the assembler code to generate was *solely*
105: determined by the alternative, could also have been specified as
106: follows, having the output control string start with a `@':
107:
108: (define_insn ""
109: [(set (match_operand:SI 0 "general_operand" "=r,m")
110: (const_int 0))]
111: ""
112: "@
113: clrreg %0
114: clrmem %0")
115:
116:
117: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
118:
119: Operand Constraints
120: ===================
121:
122: Each `match_operand' in an instruction pattern can specify a
123: constraint for the type of operands allowed. Constraints can say
124: whether an operand may be in a register, and which kinds of register;
125: whether the operand can be a memory reference, and which kinds of
126: address; whether the operand may be an immediate constant, and which
127: possible values it may have. Constraints can also require two operands
128: to match.
129:
130: * Menu:
131:
132: * Simple Constraints:: Basic use of constraints.
133: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
134: * Class Preferences:: Constraints guide which hard register to put things in.
135: * Modifiers:: More precise control over effects of constraints.
136: * Machine Constraints:: Existing constraints for some particular machines.
137: * No Constraints:: Describing a clean machine without constraints.
138:
139:
140: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
141:
142: Simple Constraints
143: ------------------
144:
145: The simplest kind of constraint is a string full of letters, each of
146: which describes one kind of operand that is permitted. Here are the
147: letters that are allowed:
148:
149: `m'
150: A memory operand is allowed, with any kind of address that the
151: machine supports in general.
152:
153: `o'
154: A memory operand is allowed, but only if the address is
155: "offsettable". This means that adding a small integer (actually,
156: the width in bytes of the operand, as determined by its machine
157: mode) may be added to the address and the result is also a valid
158: memory address.
159:
160: For example, an address which is constant is offsettable; so is an
161: address that is the sum of a register and a constant (as long as a
162: slightly larger constant is also within the range of
163: address-offsets supported by the machine); but an autoincrement or
164: autodecrement address is not offsettable. More complicated
165: indirect/indexed addresses may or may not be offsettable depending
166: on the other addressing modes that the machine supports.
167:
168: Note that in an output operand which can be matched by another
169: operand, the constraint letter `o' is valid only when accompanied
170: by both `<' (if the target machine has predecrement addressing)
171: and `>' (if the target machine has preincrement addressing).
172:
173: `V'
174: A memory operand that is not offsettable. In other words,
175: anything that would fit the `m' constraint but not the `o'
176: constraint.
177:
178: `<'
179: A memory operand with autodecrement addressing (either
180: predecrement or postdecrement) is allowed.
181:
182: `>'
183: A memory operand with autoincrement addressing (either
184: preincrement or postincrement) is allowed.
185:
186: `r'
187: A register operand is allowed provided that it is in a general
188: register.
189:
190: `d', `a', `f', ...
191: Other letters can be defined in machine-dependent fashion to stand
192: for particular classes of registers. `d', `a' and `f' are defined
193: on the 68000/68020 to stand for data, address and floating point
194: registers.
195:
196: `i'
197: An immediate integer operand (one with constant value) is allowed.
198: This includes symbolic constants whose values will be known only at
199: assembly time.
200:
201: `n'
202: An immediate integer operand with a known numeric value is allowed.
203: Many systems cannot support assembly-time constants for operands
204: less than a word wide. Constraints for these operands should use
205: `n' rather than `i'.
206:
207: `I', `J', `K', ... `P'
208: Other letters in the range `I' through `P' may be defined in a
209: machine-dependent fashion to permit immediate integer operands with
210: explicit integer values in specified ranges. For example, on the
211: 68000, `I' is defined to stand for the range of values 1 to 8.
212: This is the range permitted as a shift count in the shift
213: instructions.
214:
215: `E'
216: An immediate floating operand (expression code `const_double') is
217: allowed, but only if the target floating point format is the same
218: as that of the host machine (on which the compiler is running).
219:
220: `F'
221: An immediate floating operand (expression code `const_double') is
222: allowed.
223:
224: `G', `H'
225: `G' and `H' may be defined in a machine-dependent fashion to
226: permit immediate floating operands in particular ranges of values.
227:
228: `s'
229: An immediate integer operand whose value is not an explicit
230: integer is allowed.
231:
232: This might appear strange; if an insn allows a constant operand
233: with a value not known at compile time, it certainly must allow
234: any known value. So why use `s' instead of `i'? Sometimes it
235: allows better code to be generated.
236:
237: For example, on the 68000 in a fullword instruction it is possible
238: to use an immediate operand; but if the immediate value is between
239: -128 and 127, better code results from loading the value into a
240: register and using the register. This is because the load into
241: the register can be done with a `moveq' instruction. We arrange
242: for this to happen by defining the letter `K' to mean "any integer
243: outside the range -128 to 127", and then specifying `Ks' in the
244: operand constraints.
245:
246: `g'
247: Any register, memory or immediate integer operand is allowed,
248: except for registers that are not general registers.
249:
250: `X'
251: Any operand whatsoever is allowed, even if it does not satisfy
252: `general_operand'. This is normally used in the constraint of a
253: `match_scratch' when certain alternatives will not actually
254: require a scratch register.
255:
256: `0', `1', `2', ... `9'
257: An operand that matches the specified operand number is allowed.
258: If a digit is used together with letters within the same
259: alternative, the digit should come last.
260:
261: This is called a "matching constraint" and what it really means is
262: that the assembler has only a single operand that fills two roles
263: considered separate in the RTL insn. For example, an add insn has
264: two input operands and one output operand in the RTL, but on most
265: CISC machines an add instruction really has only two operands, one
266: of them an input-output operand:
267:
268: addl #35,r12
269:
270: Matching constraints are used in these circumstances. More
271: precisely, the two operands that match must include one input-only
272: operand and one output-only operand. Moreover, the digit must be a
273: smaller number than the number of the operand that uses it in the
274: constraint.
275:
276: For operands to match in a particular case usually means that they
277: are identical-looking RTL expressions. But in a few special cases
278: specific kinds of dissimilarity are allowed. For example, `*x' as
279: an input operand will match `*x++' as an output operand. For
280: proper results in such cases, the output template should always
281: use the output-operand's number when printing the operand.
282:
283: `p'
284: An operand that is a valid memory address is allowed. This is for
285: "load address" and "push address" instructions.
286:
287: `p' in the constraint must be accompanied by `address_operand' as
288: the predicate in the `match_operand'. This predicate interprets
289: the mode specified in the `match_operand' as the mode of the memory
290: reference for which the address would be valid.
291:
292: `Q', `R', `S', ... `U'
293: Letters in the range `Q' through `U' may be defined in a
294: machine-dependent fashion to stand for arbitrary operand types.
295: The machine description macro `EXTRA_CONSTRAINT' is passed the
296: operand as its first argument and the constraint letter as its
297: second operand.
298:
299: A typical use for this would be to distinguish certain types of
300: memory references that affect other insn operands.
301:
302: Do not define these constraint letters to accept register
303: references (`reg'); the reload pass does not expect this and would
304: not handle it properly.
305:
306: In order to have valid assembler code, each operand must satisfy its
307: constraint. But a failure to do so does not prevent the pattern from
308: applying to an insn. Instead, it directs the compiler to modify the
309: code so that the constraint will be satisfied. Usually this is done by
310: copying an operand into a register.
311:
312: Contrast, therefore, the two instruction patterns that follow:
313:
314: (define_insn ""
315: [(set (match_operand:SI 0 "general_operand" "=r")
316: (plus:SI (match_dup 0)
317: (match_operand:SI 1 "general_operand" "r")))]
318: ""
319: "...")
320:
321: which has two operands, one of which must appear in two places, and
322:
323: (define_insn ""
324: [(set (match_operand:SI 0 "general_operand" "=r")
325: (plus:SI (match_operand:SI 1 "general_operand" "0")
326: (match_operand:SI 2 "general_operand" "r")))]
327: ""
328: "...")
329:
330: which has three operands, two of which are required by a constraint to
331: be identical. If we are considering an insn of the form
332:
333: (insn N PREV NEXT
334: (set (reg:SI 3)
335: (plus:SI (reg:SI 6) (reg:SI 109)))
336: ...)
337:
338: the first pattern would not apply at all, because this insn does not
339: contain two identical subexpressions in the right place. The pattern
340: would say, "That does not look like an add instruction; try other
341: patterns." The second pattern would say, "Yes, that's an add
342: instruction, but there is something wrong with it." It would direct
343: the reload pass of the compiler to generate additional insns to make
344: the constraint true. The results might look like this:
345:
346: (insn N2 PREV N
347: (set (reg:SI 3) (reg:SI 6))
348: ...)
349:
350: (insn N N2 NEXT
351: (set (reg:SI 3)
352: (plus:SI (reg:SI 3) (reg:SI 109)))
353: ...)
354:
355: It is up to you to make sure that each operand, in each pattern, has
356: constraints that can handle any RTL expression that could be present for
357: that operand. (When multiple alternatives are in use, each pattern
358: must, for each possible combination of operand expressions, have at
359: least one alternative which can handle that combination of operands.)
360: The constraints don't need to *allow* any possible operand--when this is
361: the case, they do not constrain--but they must at least point the way to
362: reloading any possible operand so that it will fit.
363:
364: * If the constraint accepts whatever operands the predicate permits,
365: there is no problem: reloading is never necessary for this operand.
366:
367: For example, an operand whose constraints permit everything except
368: registers is safe provided its predicate rejects registers.
369:
370: An operand whose predicate accepts only constant values is safe
371: provided its constraints include the letter `i'. If any possible
372: constant value is accepted, then nothing less than `i' will do; if
373: the predicate is more selective, then the constraints may also be
374: more selective.
375:
376: * Any operand expression can be reloaded by copying it into a
377: register. So if an operand's constraints allow some kind of
378: register, it is certain to be safe. It need not permit all
379: classes of registers; the compiler knows how to copy a register
380: into another register of the proper class in order to make an
381: instruction valid.
382:
383: * A nonoffsettable memory reference can be reloaded by copying the
384: address into a register. So if the constraint uses the letter
385: `o', all memory references are taken care of.
386:
387: * A constant operand can be reloaded by allocating space in memory to
388: hold it as preinitialized data. Then the memory reference can be
389: used in place of the constant. So if the constraint uses the
390: letters `o' or `m', constant operands are not a problem.
391:
392: * If the constraint permits a constant and a pseudo register used in
393: an insn was not allocated to a hard register and is equivalent to
394: a constant, the register will be replaced with the constant. If
395: the predicate does not permit a constant and the insn is
396: re-recognized for some reason, the compiler will crash. Thus the
397: predicate must always recognize any objects allowed by the
398: constraint.
399:
400: If the operand's predicate can recognize registers, but the
401: constraint does not permit them, it can make the compiler crash. When
402: this operand happens to be a register, the reload pass will be stymied,
403: because it does not know how to copy a register temporarily into memory.
404:
405:
406: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
407:
408: Multiple Alternative Constraints
409: --------------------------------
410:
411: Sometimes a single instruction has multiple alternative sets of
412: possible operands. For example, on the 68000, a logical-or instruction
413: can combine register or an immediate value into memory, or it can
414: combine any kind of operand into a register; but it cannot combine one
415: memory location into another.
416:
417: These constraints are represented as multiple alternatives. An
418: alternative can be described by a series of letters for each operand.
419: The overall constraint for an operand is made from the letters for this
420: operand from the first alternative, a comma, the letters for this
421: operand from the second alternative, a comma, and so on until the last
422: alternative. Here is how it is done for fullword logical-or on the
423: 68000:
424:
425: (define_insn "iorsi3"
426: [(set (match_operand:SI 0 "general_operand" "=m,d")
427: (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
428: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
429: ...)
430:
431: The first alternative has `m' (memory) for operand 0, `0' for
432: operand 1 (meaning it must match operand 0), and `dKs' for operand 2.
433: The second alternative has `d' (data register) for operand 0, `0' for
434: operand 1, and `dmKs' for operand 2. The `=' and `%' in the
435: constraints apply to all the alternatives; their meaning is explained
436: in the next section (*note Class Preferences::.).
437:
438: If all the operands fit any one alternative, the instruction is
439: valid. Otherwise, for each alternative, the compiler counts how many
440: instructions must be added to copy the operands so that that
441: alternative applies. The alternative requiring the least copying is
442: chosen. If two alternatives need the same amount of copying, the one
443: that comes first is chosen. These choices can be altered with the `?'
444: and `!' characters:
445:
446: `?'
447: Disparage slightly the alternative that the `?' appears in, as a
448: choice when no alternative applies exactly. The compiler regards
449: this alternative as one unit more costly for each `?' that appears
450: in it.
451:
452: `!'
453: Disparage severely the alternative that the `!' appears in. This
454: alternative can still be used if it fits without reloading, but if
455: reloading is needed, some other alternative will be used.
456:
457: When an insn pattern has multiple alternatives in its constraints,
458: often the appearance of the assembler code is determined mostly by which
459: alternative was matched. When this is so, the C code for writing the
460: assembler code can use the variable `which_alternative', which is the
461: ordinal number of the alternative that was actually satisfied (0 for
462: the first, 1 for the second alternative, etc.). *Note Output
463: Statement::.
464:
465:
466: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
467:
468: Register Class Preferences
469: --------------------------
470:
471: The operand constraints have another function: they enable the
472: compiler to decide which kind of hardware register a pseudo register is
473: best allocated to. The compiler examines the constraints that apply to
474: the insns that use the pseudo register, looking for the
475: machine-dependent letters such as `d' and `a' that specify classes of
476: registers. The pseudo register is put in whichever class gets the most
477: "votes". The constraint letters `g' and `r' also vote: they vote in
478: favor of a general register. The machine description says which
479: registers are considered general.
480:
481: Of course, on some machines all registers are equivalent, and no
482: register classes are defined. Then none of this complexity is relevant.
483:
484:
485: File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints
486:
487: Constraint Modifier Characters
488: ------------------------------
489:
490: `='
491: Means that this operand is write-only for this instruction: the
492: previous value is discarded and replaced by output data.
493:
494: `+'
495: Means that this operand is both read and written by the
496: instruction.
497:
498: When the compiler fixes up the operands to satisfy the constraints,
499: it needs to know which operands are inputs to the instruction and
500: which are outputs from it. `=' identifies an output; `+'
501: identifies an operand that is both input and output; all other
502: operands are assumed to be input only.
503:
504: `&'
505: Means (in a particular alternative) that this operand is written
506: before the instruction is finished using the input operands.
507: Therefore, this operand may not lie in a register that is used as
508: an input operand or as part of any memory address.
509:
510: `&' applies only to the alternative in which it is written. In
511: constraints with multiple alternatives, sometimes one alternative
512: requires `&' while others do not. See, for example, the `movdf'
513: insn of the 68000.
514:
515: `&' does not obviate the need to write `='.
516:
517: `%'
518: Declares the instruction to be commutative for this operand and the
519: following operand. This means that the compiler may interchange
520: the two operands if that is the cheapest way to make all operands
521: fit the constraints. This is often used in patterns for addition
522: instructions that really have only two operands: the result must
523: go in one of the arguments. Here for example, is how the 68000
524: halfword-add instruction is defined:
525:
526: (define_insn "addhi3"
527: [(set (match_operand:HI 0 "general_operand" "=m,r")
528: (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
529: (match_operand:HI 2 "general_operand" "di,g")))]
530: ...)
531:
532: `#'
533: Says that all following characters, up to the next comma, are to be
534: ignored as a constraint. They are significant only for choosing
535: register preferences.
536:
537: `*'
538: Says that the following character should be ignored when choosing
539: register preferences. `*' has no effect on the meaning of the
540: constraint as a constraint, and no effect on reloading.
541:
542: Here is an example: the 68000 has an instruction to sign-extend a
543: halfword in a data register, and can also sign-extend a value by
544: copying it into an address register. While either kind of
545: register is acceptable, the constraints on an address-register
546: destination are less strict, so it is best if register allocation
547: makes an address register its goal. Therefore, `*' is used so
548: that the `d' constraint letter (for data register) is ignored when
549: computing register preferences.
550:
551: (define_insn "extendhisi2"
552: [(set (match_operand:SI 0 "general_operand" "=*d,a")
553: (sign_extend:SI
554: (match_operand:HI 1 "general_operand" "0,g")))]
555: ...)
556:
557:
558: File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints
559:
560: Constraints for Particular Machines
561: -----------------------------------
562:
563: Whenever possible, you should use the general-purpose constraint
564: letters in `asm' arguments, since they will convey meaning more readily
565: to people reading your code. Failing that, use the constraint letters
566: that usually have very similar meanings across architectures. The most
567: commonly used constraints are `m' and `r' (for memory and
568: general-purpose registers respectively; *note Simple Constraints::.),
569: and `I', usually the letter indicating the most common
570: immediate-constant format.
571:
572: For each machine architecture, the `config/MACHINE.h' file defines
573: additional constraints. These constraints are used by the compiler
574: itself for instruction generation, as well as for `asm' statements;
575: therefore, some of the constraints are not particularly interesting for
576: `asm'. The constraints are defined through these macros:
577:
578: `REG_CLASS_FROM_LETTER'
579: Register class constraints (usually lower case).
580:
581: `CONST_OK_FOR_LETTER_P'
582: Immediate constant constraints, for non-floating point constants of
583: word size or smaller precision (usually upper case).
584:
585: `CONST_DOUBLE_OK_FOR_LETTER_P'
586: Immediate constant constraints, for all floating point constants
587: and for constants of greater than word size precision (usually
588: upper case).
589:
590: `EXTRA_CONSTRAINT'
591: Special cases of registers or memory. This macro is not required,
592: and is only defined for some machines.
593:
594: Inspecting these macro definitions in the compiler source for your
595: machine is the best way to be certain you have the right constraints.
596: However, here is a summary of the machine-dependent constraints
597: available on some particular machines.
598:
599: *AMD 29000 family--`a29k.h'*
600: `l'
601: Local register 0
602:
603: `b'
604: Byte Pointer (`BP') register
605:
606: `q'
607: `Q' register
608:
609: `h'
610: Special purpose register
611:
612: `A'
613: First accumulator register
614:
615: `a'
616: Other accumulator register
617:
618: `f'
619: Floating point register
620:
621: `I'
622: Constant greater than 0, less than 0x100
623:
624: `J'
625: Constant greater than 0, less than 0x10000
626:
627: `K'
628: Constant whose high 24 bits are on (1)
629:
630: `L'
631: 16 bit constant whose high 8 bits are on (1)
632:
633: `M'
634: 32 bit constant whose high 16 bits are on (1)
635:
636: `N'
637: 32 bit negative constant that fits in 8 bits
638:
639: `O'
640: The constant 0x80000000 or, on the 29050, any 32 bit constant
641: whose low 16 bits are 0.
642:
643: `P'
644: 16 bit negative constant that fits in 8 bits
645:
646: `G'
647: `H'
648: A floating point constant (in `asm' statements, use the
649: machine independent `E' or `F' instead)
650:
651: *IBM RS6000--`rs6000.h'*
652: `b'
653: Address base register
654:
655: `f'
656: Floating point register
657:
658: `h'
659: `MQ', `CTR', or `LINK' register
660:
661: `q'
662: `MQ' register
663:
664: `c'
665: `CTR' register
666:
667: `l'
668: `LINK' register
669:
670: `x'
671: `CR' register (condition register) number 0
672:
673: `y'
674: `CR' register (condition register)
675:
676: `I'
677: Signed 16 bit constant
678:
679: `J'
680: Constant whose low 16 bits are 0
681:
682: `K'
683: Constant whose high 16 bits are 0
684:
685: `L'
686: Constant suitable as a mask operand
687:
688: `M'
689: Constant larger than 31
690:
691: `N'
692: Exact power of 2
693:
694: `O'
695: Zero
696:
697: `P'
698: Constant whose negation is a signed 16 bit constant
699:
700: `G'
701: Floating point constant that can be loaded into a register
702: with one instruction per word
703:
704: `Q'
705: Memory operand that is an offset from a register (`m' is
706: preferable for `asm' statements)
707:
708: *Intel 386--`i386.h'*
709: `q'
710: `a', `b', `c', or `d' register
711:
712: `f'
713: Floating point register
714:
715: `t'
716: First (top of stack) floating point register
717:
718: `u'
719: Second floating point register
720:
721: `a'
722: `a' register
723:
724: `b'
725: `b' register
726:
727: `c'
728: `c' register
729:
730: `d'
731: `d' register
732:
733: `D'
734: `di' register
735:
736: `S'
737: `si' register
738:
739: `I'
740: Constant in range 0 to 31 (for 32 bit shifts)
741:
742: `J'
743: Constant in range 0 to 63 (for 64 bit shifts)
744:
745: `K'
746: `0xff'
747:
748: `L'
749: `0xffff'
750:
751: `M'
752: 0, 1, 2, or 3 (shifts for `lea' instruction)
753:
754: `G'
755: Standard 80387 floating point constant
756:
757: *Intel 960--`i960.h'*
758: `f'
759: Floating point register (`fp0' to `fp3')
760:
761: `l'
762: Local register (`r0' to `r15')
763:
764: `b'
765: Global register (`g0' to `g15')
766:
767: `d'
768: Any local or global register
769:
770: `I'
771: Integers from 0 to 31
772:
773: `J'
774: 0
775:
776: `K'
777: Integers from -31 to 0
778:
779: `G'
780: Floating point 0
781:
782: `H'
783: Floating point 1
784:
785: *MIPS--`mips.h'*
786: `d'
787: General-purpose integer register
788:
789: `f'
790: Floating-point register (if available)
791:
792: `h'
793: `Hi' register
794:
795: `l'
796: `Lo' register
797:
798: `x'
799: `Hi' or `Lo' register
800:
801: `y'
802: General-purpose integer register
803:
804: `z'
805: Floating-point status register
806:
807: `I'
808: Signed 16 bit constant (for arithmetic instructions)
809:
810: `J'
811: Zero
812:
813: `K'
814: Zero-extended 16-bit constant (for logic instructions)
815:
816: `L'
817: Constant with low 16 bits zero (can be loaded with `lui')
818:
819: `M'
820: 32 bit constant which requires two instructions to load (a
821: constant which is not `I', `K', or `L')
822:
823: `N'
824: Negative 16 bit constant
825:
826: `O'
827: Exact power of two
828:
829: `P'
830: Positive 16 bit constant
831:
832: `G'
833: Floating point zero
834:
835: `Q'
836: Memory reference that can be loaded with more than one
837: instruction (`m' is preferable for `asm' statements)
838:
839: `R'
840: Memory reference that can be loaded with one instruction (`m'
841: is preferable for `asm' statements)
842:
843: `S'
844: Memory reference in external OSF/rose PIC format (`m' is
845: preferable for `asm' statements)
846:
847: *Motorola 680x0--`m68k.h'*
848: `a'
849: Address register
850:
851: `d'
852: Data register
853:
854: `f'
855: 68881 floating-point register, if available
856:
857: `x'
858: Sun FPA (floating-point) register, if available
859:
860: `y'
861: First 16 Sun FPA registers, if available
862:
863: `I'
864: Integer in the range 1 to 8
865:
866: `J'
867: 16 bit signed number
868:
869: `K'
870: Signed number whose magnitude is greater than 0x80
871:
872: `L'
873: Integer in the range -8 to -1
874:
875: `G'
876: Floating point constant that is not a 68881 constant
877:
878: `H'
879: Floating point constant that can be used by Sun FPA
880:
881: *SPARC--`sparc.h'*
882: `f'
883: Floating-point register
884:
885: `I'
886: Signed 13 bit constant
887:
888: `J'
889: Zero
890:
891: `K'
892: 32 bit constant with the low 12 bits clear (a constant that
893: can be loaded with the `sethi' instruction)
894:
895: `G'
896: Floating-point zero
897:
898: `H'
899: Signed 13 bit constant, sign-extended to 32 or 64 bits
900:
901: `Q'
902: Memory reference that can be loaded with one instruction
903: (`m' is more appropriate for `asm' statements)
904:
905: `S'
906: Constant, or memory address
907:
908: `T'
909: Memory address aligned to an 8-byte boundary
910:
911: `U'
912: Even register
913:
914:
915: File: gcc.info, Node: No Constraints, Prev: Machine Constraints, Up: Constraints
916:
917: Not Using Constraints
918: ---------------------
919:
920: Some machines are so clean that operand constraints are not
921: required. For example, on the Vax, an operand valid in one context is
922: valid in any other context. On such a machine, every operand
923: constraint would be `g', excepting only operands of "load address"
924: instructions which are written as if they referred to a memory
925: location's contents but actual refer to its address. They would have
926: constraint `p'.
927:
928: For such machines, instead of writing `g' and `p' for all the
929: constraints, you can choose to write a description with empty
930: constraints. Then you write `""' for the constraint in every
931: `match_operand'. Address operands are identified by writing an
932: `address' expression around the `match_operand', not by their
933: constraints.
934:
935: When the machine description has just empty constraints, certain
936: parts of compilation are skipped, making the compiler faster. However,
937: few machines actually do not need constraints; all machine descriptions
938: now in existence use constraints.
939:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.