1 | This is Info file gcc.info, produced by Makeinfo-1.55 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 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software |
---|
10 | Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc |
---|
34 | |
---|
35 | RTL Template |
---|
36 | ============ |
---|
37 | |
---|
38 | The RTL template is used to define which insns match the particular |
---|
39 | pattern and how to find their operands. For named patterns, the RTL |
---|
40 | template also says how to construct an insn from specified operands. |
---|
41 | |
---|
42 | Construction involves substituting specified operands into a copy of |
---|
43 | the template. Matching involves determining the values that serve as |
---|
44 | the operands in the insn being matched. Both of these activities are |
---|
45 | controlled by special expression types that direct matching and |
---|
46 | substitution of the operands. |
---|
47 | |
---|
48 | `(match_operand:M N PREDICATE CONSTRAINT)' |
---|
49 | This expression is a placeholder for operand number N of the insn. |
---|
50 | When constructing an insn, operand number N will be substituted |
---|
51 | at this point. When matching an insn, whatever appears at this |
---|
52 | position in the insn will be taken as operand number N; but it |
---|
53 | must satisfy PREDICATE or this instruction pattern will not match |
---|
54 | at all. |
---|
55 | |
---|
56 | Operand numbers must be chosen consecutively counting from zero in |
---|
57 | each instruction pattern. There may be only one `match_operand' |
---|
58 | expression in the pattern for each operand number. Usually |
---|
59 | operands are numbered in the order of appearance in `match_operand' |
---|
60 | expressions. |
---|
61 | |
---|
62 | PREDICATE is a string that is the name of a C function that |
---|
63 | accepts two arguments, an expression and a machine mode. During |
---|
64 | matching, the function will be called with the putative operand as |
---|
65 | the expression and M as the mode argument (if M is not specified, |
---|
66 | `VOIDmode' will be used, which normally causes PREDICATE to accept |
---|
67 | any mode). If it returns zero, this instruction pattern fails to |
---|
68 | match. PREDICATE may be an empty string; then it means no test is |
---|
69 | to be done on the operand, so anything which occurs in this |
---|
70 | position is valid. |
---|
71 | |
---|
72 | Most of the time, PREDICATE will reject modes other than M--but |
---|
73 | not always. For example, the predicate `address_operand' uses M |
---|
74 | as the mode of memory ref that the address should be valid for. |
---|
75 | Many predicates accept `const_int' nodes even though their mode is |
---|
76 | `VOIDmode'. |
---|
77 | |
---|
78 | CONSTRAINT controls reloading and the choice of the best register |
---|
79 | class to use for a value, as explained later (*note |
---|
80 | Constraints::.). |
---|
81 | |
---|
82 | People are often unclear on the difference between the constraint |
---|
83 | and the predicate. The predicate helps decide whether a given |
---|
84 | insn matches the pattern. The constraint plays no role in this |
---|
85 | decision; instead, it controls various decisions in the case of an |
---|
86 | insn which does match. |
---|
87 | |
---|
88 | On CISC machines, the most common PREDICATE is |
---|
89 | `"general_operand"'. This function checks that the putative |
---|
90 | operand is either a constant, a register or a memory reference, |
---|
91 | and that it is valid for mode M. |
---|
92 | |
---|
93 | For an operand that must be a register, PREDICATE should be |
---|
94 | `"register_operand"'. Using `"general_operand"' would be valid, |
---|
95 | since the reload pass would copy any non-register operands through |
---|
96 | registers, but this would make GNU CC do extra work, it would |
---|
97 | prevent invariant operands (such as constant) from being removed |
---|
98 | from loops, and it would prevent the register allocator from doing |
---|
99 | the best possible job. On RISC machines, it is usually most |
---|
100 | efficient to allow PREDICATE to accept only objects that the |
---|
101 | constraints allow. |
---|
102 | |
---|
103 | For an operand that must be a constant, you must be sure to either |
---|
104 | use `"immediate_operand"' for PREDICATE, or make the instruction |
---|
105 | pattern's extra condition require a constant, or both. You cannot |
---|
106 | expect the constraints to do this work! If the constraints allow |
---|
107 | only constants, but the predicate allows something else, the |
---|
108 | compiler will crash when that case arises. |
---|
109 | |
---|
110 | `(match_scratch:M N CONSTRAINT)' |
---|
111 | This expression is also a placeholder for operand number N and |
---|
112 | indicates that operand must be a `scratch' or `reg' expression. |
---|
113 | |
---|
114 | When matching patterns, this is equivalent to |
---|
115 | |
---|
116 | (match_operand:M N "scratch_operand" PRED) |
---|
117 | |
---|
118 | but, when generating RTL, it produces a (`scratch':M) expression. |
---|
119 | |
---|
120 | If the last few expressions in a `parallel' are `clobber' |
---|
121 | expressions whose operands are either a hard register or |
---|
122 | `match_scratch', the combiner can add or delete them when |
---|
123 | necessary. *Note Side Effects::. |
---|
124 | |
---|
125 | `(match_dup N)' |
---|
126 | This expression is also a placeholder for operand number N. It is |
---|
127 | used when the operand needs to appear more than once in the insn. |
---|
128 | |
---|
129 | In construction, `match_dup' acts just like `match_operand': the |
---|
130 | operand is substituted into the insn being constructed. But in |
---|
131 | matching, `match_dup' behaves differently. It assumes that operand |
---|
132 | number N has already been determined by a `match_operand' |
---|
133 | appearing earlier in the recognition template, and it matches only |
---|
134 | an identical-looking expression. |
---|
135 | |
---|
136 | `(match_operator:M N PREDICATE [OPERANDS...])' |
---|
137 | This pattern is a kind of placeholder for a variable RTL expression |
---|
138 | code. |
---|
139 | |
---|
140 | When constructing an insn, it stands for an RTL expression whose |
---|
141 | expression code is taken from that of operand N, and whose |
---|
142 | operands are constructed from the patterns OPERANDS. |
---|
143 | |
---|
144 | When matching an expression, it matches an expression if the |
---|
145 | function PREDICATE returns nonzero on that expression *and* the |
---|
146 | patterns OPERANDS match the operands of the expression. |
---|
147 | |
---|
148 | Suppose that the function `commutative_operator' is defined as |
---|
149 | follows, to match any expression whose operator is one of the |
---|
150 | commutative arithmetic operators of RTL and whose mode is MODE: |
---|
151 | |
---|
152 | int |
---|
153 | commutative_operator (x, mode) |
---|
154 | rtx x; |
---|
155 | enum machine_mode mode; |
---|
156 | { |
---|
157 | enum rtx_code code = GET_CODE (x); |
---|
158 | if (GET_MODE (x) != mode) |
---|
159 | return 0; |
---|
160 | return (GET_RTX_CLASS (code) == 'c' |
---|
161 | || code == EQ || code == NE); |
---|
162 | } |
---|
163 | |
---|
164 | Then the following pattern will match any RTL expression consisting |
---|
165 | of a commutative operator applied to two general operands: |
---|
166 | |
---|
167 | (match_operator:SI 3 "commutative_operator" |
---|
168 | [(match_operand:SI 1 "general_operand" "g") |
---|
169 | (match_operand:SI 2 "general_operand" "g")]) |
---|
170 | |
---|
171 | Here the vector `[OPERANDS...]' contains two patterns because the |
---|
172 | expressions to be matched all contain two operands. |
---|
173 | |
---|
174 | When this pattern does match, the two operands of the commutative |
---|
175 | operator are recorded as operands 1 and 2 of the insn. (This is |
---|
176 | done by the two instances of `match_operand'.) Operand 3 of the |
---|
177 | insn will be the entire commutative expression: use `GET_CODE |
---|
178 | (operands[3])' to see which commutative operator was used. |
---|
179 | |
---|
180 | The machine mode M of `match_operator' works like that of |
---|
181 | `match_operand': it is passed as the second argument to the |
---|
182 | predicate function, and that function is solely responsible for |
---|
183 | deciding whether the expression to be matched "has" that mode. |
---|
184 | |
---|
185 | When constructing an insn, argument 3 of the gen-function will |
---|
186 | specify the operation (i.e. the expression code) for the |
---|
187 | expression to be made. It should be an RTL expression, whose |
---|
188 | expression code is copied into a new expression whose operands are |
---|
189 | arguments 1 and 2 of the gen-function. The subexpressions of |
---|
190 | argument 3 are not used; only its expression code matters. |
---|
191 | |
---|
192 | When `match_operator' is used in a pattern for matching an insn, |
---|
193 | it usually best if the operand number of the `match_operator' is |
---|
194 | higher than that of the actual operands of the insn. This improves |
---|
195 | register allocation because the register allocator often looks at |
---|
196 | operands 1 and 2 of insns to see if it can do register tying. |
---|
197 | |
---|
198 | There is no way to specify constraints in `match_operator'. The |
---|
199 | operand of the insn which corresponds to the `match_operator' |
---|
200 | never has any constraints because it is never reloaded as a whole. |
---|
201 | However, if parts of its OPERANDS are matched by `match_operand' |
---|
202 | patterns, those parts may have constraints of their own. |
---|
203 | |
---|
204 | `(match_op_dup:M N[OPERANDS...])' |
---|
205 | Like `match_dup', except that it applies to operators instead of |
---|
206 | operands. When constructing an insn, operand number N will be |
---|
207 | substituted at this point. But in matching, `match_op_dup' behaves |
---|
208 | differently. It assumes that operand number N has already been |
---|
209 | determined by a `match_operator' appearing earlier in the |
---|
210 | recognition template, and it matches only an identical-looking |
---|
211 | expression. |
---|
212 | |
---|
213 | `(match_parallel N PREDICATE [SUBPAT...])' |
---|
214 | This pattern is a placeholder for an insn that consists of a |
---|
215 | `parallel' expression with a variable number of elements. This |
---|
216 | expression should only appear at the top level of an insn pattern. |
---|
217 | |
---|
218 | When constructing an insn, operand number N will be substituted at |
---|
219 | this point. When matching an insn, it matches if the body of the |
---|
220 | insn is a `parallel' expression with at least as many elements as |
---|
221 | the vector of SUBPAT expressions in the `match_parallel', if each |
---|
222 | SUBPAT matches the corresponding element of the `parallel', *and* |
---|
223 | the function PREDICATE returns nonzero on the `parallel' that is |
---|
224 | the body of the insn. It is the responsibility of the predicate |
---|
225 | to validate elements of the `parallel' beyond those listed in the |
---|
226 | `match_parallel'. |
---|
227 | |
---|
228 | A typical use of `match_parallel' is to match load and store |
---|
229 | multiple expressions, which can contain a variable number of |
---|
230 | elements in a `parallel'. For example, |
---|
231 | |
---|
232 | (define_insn "" |
---|
233 | [(match_parallel 0 "load_multiple_operation" |
---|
234 | [(set (match_operand:SI 1 "gpc_reg_operand" "=r") |
---|
235 | (match_operand:SI 2 "memory_operand" "m")) |
---|
236 | (use (reg:SI 179)) |
---|
237 | (clobber (reg:SI 179))])] |
---|
238 | "" |
---|
239 | "loadm 0,0,%1,%2") |
---|
240 | |
---|
241 | This example comes from `a29k.md'. The function |
---|
242 | `load_multiple_operations' is defined in `a29k.c' and checks that |
---|
243 | subsequent elements in the `parallel' are the same as the `set' in |
---|
244 | the pattern, except that they are referencing subsequent registers |
---|
245 | and memory locations. |
---|
246 | |
---|
247 | An insn that matches this pattern might look like: |
---|
248 | |
---|
249 | (parallel |
---|
250 | [(set (reg:SI 20) (mem:SI (reg:SI 100))) |
---|
251 | (use (reg:SI 179)) |
---|
252 | (clobber (reg:SI 179)) |
---|
253 | (set (reg:SI 21) |
---|
254 | (mem:SI (plus:SI (reg:SI 100) |
---|
255 | (const_int 4)))) |
---|
256 | (set (reg:SI 22) |
---|
257 | (mem:SI (plus:SI (reg:SI 100) |
---|
258 | (const_int 8))))]) |
---|
259 | |
---|
260 | `(match_par_dup N [SUBPAT...])' |
---|
261 | Like `match_op_dup', but for `match_parallel' instead of |
---|
262 | `match_operator'. |
---|
263 | |
---|
264 | `(address (match_operand:M N "address_operand" ""))' |
---|
265 | This complex of expressions is a placeholder for an operand number |
---|
266 | N in a "load address" instruction: an operand which specifies a |
---|
267 | memory location in the usual way, but for which the actual operand |
---|
268 | value used is the address of the location, not the contents of the |
---|
269 | location. |
---|
270 | |
---|
271 | `address' expressions never appear in RTL code, only in machine |
---|
272 | descriptions. And they are used only in machine descriptions that |
---|
273 | do not use the operand constraint feature. When operand |
---|
274 | constraints are in use, the letter `p' in the constraint serves |
---|
275 | this purpose. |
---|
276 | |
---|
277 | M is the machine mode of the *memory location being addressed*, |
---|
278 | not the machine mode of the address itself. That mode is always |
---|
279 | the same on a given target machine (it is `Pmode', which normally |
---|
280 | is `SImode'), so there is no point in mentioning it; thus, no |
---|
281 | machine mode is written in the `address' expression. If some day |
---|
282 | support is added for machines in which addresses of different |
---|
283 | kinds of objects appear differently or are used differently (such |
---|
284 | as the PDP-10), different formats would perhaps need different |
---|
285 | machine modes and these modes might be written in the `address' |
---|
286 | expression. |
---|
287 | |
---|
288 | |
---|
289 | File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc |
---|
290 | |
---|
291 | Output Templates and Operand Substitution |
---|
292 | ========================================= |
---|
293 | |
---|
294 | The "output template" is a string which specifies how to output the |
---|
295 | assembler code for an instruction pattern. Most of the template is a |
---|
296 | fixed string which is output literally. The character `%' is used to |
---|
297 | specify where to substitute an operand; it can also be used to identify |
---|
298 | places where different variants of the assembler require different |
---|
299 | syntax. |
---|
300 | |
---|
301 | In the simplest case, a `%' followed by a digit N says to output |
---|
302 | operand N at that point in the string. |
---|
303 | |
---|
304 | `%' followed by a letter and a digit says to output an operand in an |
---|
305 | alternate fashion. Four letters have standard, built-in meanings |
---|
306 | described below. The machine description macro `PRINT_OPERAND' can |
---|
307 | define additional letters with nonstandard meanings. |
---|
308 | |
---|
309 | `%cDIGIT' can be used to substitute an operand that is a constant |
---|
310 | value without the syntax that normally indicates an immediate operand. |
---|
311 | |
---|
312 | `%nDIGIT' is like `%cDIGIT' except that the value of the constant is |
---|
313 | negated before printing. |
---|
314 | |
---|
315 | `%aDIGIT' can be used to substitute an operand as if it were a |
---|
316 | memory reference, with the actual operand treated as the address. This |
---|
317 | may be useful when outputting a "load address" instruction, because |
---|
318 | often the assembler syntax for such an instruction requires you to |
---|
319 | write the operand as if it were a memory reference. |
---|
320 | |
---|
321 | `%lDIGIT' is used to substitute a `label_ref' into a jump |
---|
322 | instruction. |
---|
323 | |
---|
324 | `%=' outputs a number which is unique to each instruction in the |
---|
325 | entire compilation. This is useful for making local labels to be |
---|
326 | referred to more than once in a single template that generates multiple |
---|
327 | assembler instructions. |
---|
328 | |
---|
329 | `%' followed by a punctuation character specifies a substitution that |
---|
330 | does not use an operand. Only one case is standard: `%%' outputs a `%' |
---|
331 | into the assembler code. Other nonstandard cases can be defined in the |
---|
332 | `PRINT_OPERAND' macro. You must also define which punctuation |
---|
333 | characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. |
---|
334 | |
---|
335 | The template may generate multiple assembler instructions. Write |
---|
336 | the text for the instructions, with `\;' between them. |
---|
337 | |
---|
338 | When the RTL contains two operands which are required by constraint |
---|
339 | to match each other, the output template must refer only to the |
---|
340 | lower-numbered operand. Matching operands are not always identical, |
---|
341 | and the rest of the compiler arranges to put the proper RTL expression |
---|
342 | for printing into the lower-numbered operand. |
---|
343 | |
---|
344 | One use of nonstandard letters or punctuation following `%' is to |
---|
345 | distinguish between different assembler languages for the same machine; |
---|
346 | for example, Motorola syntax versus MIT syntax for the 68000. Motorola |
---|
347 | syntax requires periods in most opcode names, while MIT syntax does |
---|
348 | not. For example, the opcode `movel' in MIT syntax is `move.l' in |
---|
349 | Motorola syntax. The same file of patterns is used for both kinds of |
---|
350 | output syntax, but the character sequence `%.' is used in each place |
---|
351 | where Motorola syntax wants a period. The `PRINT_OPERAND' macro for |
---|
352 | Motorola syntax defines the sequence to output a period; the macro for |
---|
353 | MIT syntax defines it to do nothing. |
---|
354 | |
---|
355 | As a special case, a template consisting of the single character `#' |
---|
356 | instructs the compiler to first split the insn, and then output the |
---|
357 | resulting instructions separately. This helps eliminate redundancy in |
---|
358 | the output templates. If you have a `define_insn' that needs to emit |
---|
359 | multiple assembler instructions, and there is an matching `define_split' |
---|
360 | already defined, then you can simply use `#' as the output template |
---|
361 | instead of writing an output template that emits the multiple assembler |
---|
362 | instructions. |
---|
363 | |
---|
364 | If `ASSEMBLER_DIALECT' is defined, you can use |
---|
365 | `{option0|option1|option2}' constructs in the templates. These |
---|
366 | describe multiple variants of assembler language syntax. *Note |
---|
367 | Instruction Output::. |
---|
368 | |
---|
369 | |
---|
370 | File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc |
---|
371 | |
---|
372 | C Statements for Assembler Output |
---|
373 | ================================= |
---|
374 | |
---|
375 | Often a single fixed template string cannot produce correct and |
---|
376 | efficient assembler code for all the cases that are recognized by a |
---|
377 | single instruction pattern. For example, the opcodes may depend on the |
---|
378 | kinds of operands; or some unfortunate combinations of operands may |
---|
379 | require extra machine instructions. |
---|
380 | |
---|
381 | If the output control string starts with a `@', then it is actually |
---|
382 | a series of templates, each on a separate line. (Blank lines and |
---|
383 | leading spaces and tabs are ignored.) The templates correspond to the |
---|
384 | pattern's constraint alternatives (*note Multi-Alternative::.). For |
---|
385 | example, if a target machine has a two-address add instruction `addr' |
---|
386 | to add into a register and another `addm' to add a register to memory, |
---|
387 | you might write this pattern: |
---|
388 | |
---|
389 | (define_insn "addsi3" |
---|
390 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
391 | (plus:SI (match_operand:SI 1 "general_operand" "0,0") |
---|
392 | (match_operand:SI 2 "general_operand" "g,r")))] |
---|
393 | "" |
---|
394 | "@ |
---|
395 | addr %2,%0 |
---|
396 | addm %2,%0") |
---|
397 | |
---|
398 | If the output control string starts with a `*', then it is not an |
---|
399 | output template but rather a piece of C program that should compute a |
---|
400 | template. It should execute a `return' statement to return the |
---|
401 | template-string you want. Most such templates use C string literals, |
---|
402 | which require doublequote characters to delimit them. To include these |
---|
403 | doublequote characters in the string, prefix each one with `\'. |
---|
404 | |
---|
405 | The operands may be found in the array `operands', whose C data type |
---|
406 | is `rtx []'. |
---|
407 | |
---|
408 | It is very common to select different ways of generating assembler |
---|
409 | code based on whether an immediate operand is within a certain range. |
---|
410 | Be careful when doing this, because the result of `INTVAL' is an |
---|
411 | integer on the host machine. If the host machine has more bits in an |
---|
412 | `int' than the target machine has in the mode in which the constant |
---|
413 | will be used, then some of the bits you get from `INTVAL' will be |
---|
414 | superfluous. For proper results, you must carefully disregard the |
---|
415 | values of those bits. |
---|
416 | |
---|
417 | It is possible to output an assembler instruction and then go on to |
---|
418 | output or compute more of them, using the subroutine `output_asm_insn'. |
---|
419 | This receives two arguments: a template-string and a vector of |
---|
420 | operands. The vector may be `operands', or it may be another array of |
---|
421 | `rtx' that you declare locally and initialize yourself. |
---|
422 | |
---|
423 | When an insn pattern has multiple alternatives in its constraints, |
---|
424 | often the appearance of the assembler code is determined mostly by |
---|
425 | which alternative was matched. When this is so, the C code can test |
---|
426 | the variable `which_alternative', which is the ordinal number of the |
---|
427 | alternative that was actually satisfied (0 for the first, 1 for the |
---|
428 | second alternative, etc.). |
---|
429 | |
---|
430 | For example, suppose there are two opcodes for storing zero, `clrreg' |
---|
431 | for registers and `clrmem' for memory locations. Here is how a pattern |
---|
432 | could use `which_alternative' to choose between them: |
---|
433 | |
---|
434 | (define_insn "" |
---|
435 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
436 | (const_int 0))] |
---|
437 | "" |
---|
438 | "* |
---|
439 | return (which_alternative == 0 |
---|
440 | ? \"clrreg %0\" : \"clrmem %0\"); |
---|
441 | ") |
---|
442 | |
---|
443 | The example above, where the assembler code to generate was *solely* |
---|
444 | determined by the alternative, could also have been specified as |
---|
445 | follows, having the output control string start with a `@': |
---|
446 | |
---|
447 | (define_insn "" |
---|
448 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
449 | (const_int 0))] |
---|
450 | "" |
---|
451 | "@ |
---|
452 | clrreg %0 |
---|
453 | clrmem %0") |
---|
454 | |
---|
455 | |
---|
456 | File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc |
---|
457 | |
---|
458 | Operand Constraints |
---|
459 | =================== |
---|
460 | |
---|
461 | Each `match_operand' in an instruction pattern can specify a |
---|
462 | constraint for the type of operands allowed. Constraints can say |
---|
463 | whether an operand may be in a register, and which kinds of register; |
---|
464 | whether the operand can be a memory reference, and which kinds of |
---|
465 | address; whether the operand may be an immediate constant, and which |
---|
466 | possible values it may have. Constraints can also require two operands |
---|
467 | to match. |
---|
468 | |
---|
469 | * Menu: |
---|
470 | |
---|
471 | * Simple Constraints:: Basic use of constraints. |
---|
472 | * Multi-Alternative:: When an insn has two alternative constraint-patterns. |
---|
473 | * Class Preferences:: Constraints guide which hard register to put things in. |
---|
474 | * Modifiers:: More precise control over effects of constraints. |
---|
475 | * Machine Constraints:: Existing constraints for some particular machines. |
---|
476 | * No Constraints:: Describing a clean machine without constraints. |
---|
477 | |
---|
478 | |
---|
479 | File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints |
---|
480 | |
---|
481 | Simple Constraints |
---|
482 | ------------------ |
---|
483 | |
---|
484 | The simplest kind of constraint is a string full of letters, each of |
---|
485 | which describes one kind of operand that is permitted. Here are the |
---|
486 | letters that are allowed: |
---|
487 | |
---|
488 | `m' |
---|
489 | A memory operand is allowed, with any kind of address that the |
---|
490 | machine supports in general. |
---|
491 | |
---|
492 | `o' |
---|
493 | A memory operand is allowed, but only if the address is |
---|
494 | "offsettable". This means that adding a small integer (actually, |
---|
495 | the width in bytes of the operand, as determined by its machine |
---|
496 | mode) may be added to the address and the result is also a valid |
---|
497 | memory address. |
---|
498 | |
---|
499 | For example, an address which is constant is offsettable; so is an |
---|
500 | address that is the sum of a register and a constant (as long as a |
---|
501 | slightly larger constant is also within the range of |
---|
502 | address-offsets supported by the machine); but an autoincrement or |
---|
503 | autodecrement address is not offsettable. More complicated |
---|
504 | indirect/indexed addresses may or may not be offsettable depending |
---|
505 | on the other addressing modes that the machine supports. |
---|
506 | |
---|
507 | Note that in an output operand which can be matched by another |
---|
508 | operand, the constraint letter `o' is valid only when accompanied |
---|
509 | by both `<' (if the target machine has predecrement addressing) |
---|
510 | and `>' (if the target machine has preincrement addressing). |
---|
511 | |
---|
512 | `V' |
---|
513 | A memory operand that is not offsettable. In other words, |
---|
514 | anything that would fit the `m' constraint but not the `o' |
---|
515 | constraint. |
---|
516 | |
---|
517 | `<' |
---|
518 | A memory operand with autodecrement addressing (either |
---|
519 | predecrement or postdecrement) is allowed. |
---|
520 | |
---|
521 | `>' |
---|
522 | A memory operand with autoincrement addressing (either |
---|
523 | preincrement or postincrement) is allowed. |
---|
524 | |
---|
525 | `r' |
---|
526 | A register operand is allowed provided that it is in a general |
---|
527 | register. |
---|
528 | |
---|
529 | `d', `a', `f', ... |
---|
530 | Other letters can be defined in machine-dependent fashion to stand |
---|
531 | for particular classes of registers. `d', `a' and `f' are defined |
---|
532 | on the 68000/68020 to stand for data, address and floating point |
---|
533 | registers. |
---|
534 | |
---|
535 | `i' |
---|
536 | An immediate integer operand (one with constant value) is allowed. |
---|
537 | This includes symbolic constants whose values will be known only at |
---|
538 | assembly time. |
---|
539 | |
---|
540 | `n' |
---|
541 | An immediate integer operand with a known numeric value is allowed. |
---|
542 | Many systems cannot support assembly-time constants for operands |
---|
543 | less than a word wide. Constraints for these operands should use |
---|
544 | `n' rather than `i'. |
---|
545 | |
---|
546 | `I', `J', `K', ... `P' |
---|
547 | Other letters in the range `I' through `P' may be defined in a |
---|
548 | machine-dependent fashion to permit immediate integer operands with |
---|
549 | explicit integer values in specified ranges. For example, on the |
---|
550 | 68000, `I' is defined to stand for the range of values 1 to 8. |
---|
551 | This is the range permitted as a shift count in the shift |
---|
552 | instructions. |
---|
553 | |
---|
554 | `E' |
---|
555 | An immediate floating operand (expression code `const_double') is |
---|
556 | allowed, but only if the target floating point format is the same |
---|
557 | as that of the host machine (on which the compiler is running). |
---|
558 | |
---|
559 | `F' |
---|
560 | An immediate floating operand (expression code `const_double') is |
---|
561 | allowed. |
---|
562 | |
---|
563 | `G', `H' |
---|
564 | `G' and `H' may be defined in a machine-dependent fashion to |
---|
565 | permit immediate floating operands in particular ranges of values. |
---|
566 | |
---|
567 | `s' |
---|
568 | An immediate integer operand whose value is not an explicit |
---|
569 | integer is allowed. |
---|
570 | |
---|
571 | This might appear strange; if an insn allows a constant operand |
---|
572 | with a value not known at compile time, it certainly must allow |
---|
573 | any known value. So why use `s' instead of `i'? Sometimes it |
---|
574 | allows better code to be generated. |
---|
575 | |
---|
576 | For example, on the 68000 in a fullword instruction it is possible |
---|
577 | to use an immediate operand; but if the immediate value is between |
---|
578 | -128 and 127, better code results from loading the value into a |
---|
579 | register and using the register. This is because the load into |
---|
580 | the register can be done with a `moveq' instruction. We arrange |
---|
581 | for this to happen by defining the letter `K' to mean "any integer |
---|
582 | outside the range -128 to 127", and then specifying `Ks' in the |
---|
583 | operand constraints. |
---|
584 | |
---|
585 | `g' |
---|
586 | Any register, memory or immediate integer operand is allowed, |
---|
587 | except for registers that are not general registers. |
---|
588 | |
---|
589 | `X' |
---|
590 | Any operand whatsoever is allowed, even if it does not satisfy |
---|
591 | `general_operand'. This is normally used in the constraint of a |
---|
592 | `match_scratch' when certain alternatives will not actually |
---|
593 | require a scratch register. |
---|
594 | |
---|
595 | `0', `1', `2', ... `9' |
---|
596 | An operand that matches the specified operand number is allowed. |
---|
597 | If a digit is used together with letters within the same |
---|
598 | alternative, the digit should come last. |
---|
599 | |
---|
600 | This is called a "matching constraint" and what it really means is |
---|
601 | that the assembler has only a single operand that fills two roles |
---|
602 | considered separate in the RTL insn. For example, an add insn has |
---|
603 | two input operands and one output operand in the RTL, but on most |
---|
604 | CISC machines an add instruction really has only two operands, one |
---|
605 | of them an input-output operand: |
---|
606 | |
---|
607 | addl #35,r12 |
---|
608 | |
---|
609 | Matching constraints are used in these circumstances. More |
---|
610 | precisely, the two operands that match must include one input-only |
---|
611 | operand and one output-only operand. Moreover, the digit must be a |
---|
612 | smaller number than the number of the operand that uses it in the |
---|
613 | constraint. |
---|
614 | |
---|
615 | For operands to match in a particular case usually means that they |
---|
616 | are identical-looking RTL expressions. But in a few special cases |
---|
617 | specific kinds of dissimilarity are allowed. For example, `*x' as |
---|
618 | an input operand will match `*x++' as an output operand. For |
---|
619 | proper results in such cases, the output template should always |
---|
620 | use the output-operand's number when printing the operand. |
---|
621 | |
---|
622 | `p' |
---|
623 | An operand that is a valid memory address is allowed. This is for |
---|
624 | "load address" and "push address" instructions. |
---|
625 | |
---|
626 | `p' in the constraint must be accompanied by `address_operand' as |
---|
627 | the predicate in the `match_operand'. This predicate interprets |
---|
628 | the mode specified in the `match_operand' as the mode of the memory |
---|
629 | reference for which the address would be valid. |
---|
630 | |
---|
631 | `Q', `R', `S', ... `U' |
---|
632 | Letters in the range `Q' through `U' may be defined in a |
---|
633 | machine-dependent fashion to stand for arbitrary operand types. |
---|
634 | The machine description macro `EXTRA_CONSTRAINT' is passed the |
---|
635 | operand as its first argument and the constraint letter as its |
---|
636 | second operand. |
---|
637 | |
---|
638 | A typical use for this would be to distinguish certain types of |
---|
639 | memory references that affect other insn operands. |
---|
640 | |
---|
641 | Do not define these constraint letters to accept register |
---|
642 | references (`reg'); the reload pass does not expect this and would |
---|
643 | not handle it properly. |
---|
644 | |
---|
645 | In order to have valid assembler code, each operand must satisfy its |
---|
646 | constraint. But a failure to do so does not prevent the pattern from |
---|
647 | applying to an insn. Instead, it directs the compiler to modify the |
---|
648 | code so that the constraint will be satisfied. Usually this is done by |
---|
649 | copying an operand into a register. |
---|
650 | |
---|
651 | Contrast, therefore, the two instruction patterns that follow: |
---|
652 | |
---|
653 | (define_insn "" |
---|
654 | [(set (match_operand:SI 0 "general_operand" "=r") |
---|
655 | (plus:SI (match_dup 0) |
---|
656 | (match_operand:SI 1 "general_operand" "r")))] |
---|
657 | "" |
---|
658 | "...") |
---|
659 | |
---|
660 | which has two operands, one of which must appear in two places, and |
---|
661 | |
---|
662 | (define_insn "" |
---|
663 | [(set (match_operand:SI 0 "general_operand" "=r") |
---|
664 | (plus:SI (match_operand:SI 1 "general_operand" "0") |
---|
665 | (match_operand:SI 2 "general_operand" "r")))] |
---|
666 | "" |
---|
667 | "...") |
---|
668 | |
---|
669 | which has three operands, two of which are required by a constraint to |
---|
670 | be identical. If we are considering an insn of the form |
---|
671 | |
---|
672 | (insn N PREV NEXT |
---|
673 | (set (reg:SI 3) |
---|
674 | (plus:SI (reg:SI 6) (reg:SI 109))) |
---|
675 | ...) |
---|
676 | |
---|
677 | the first pattern would not apply at all, because this insn does not |
---|
678 | contain two identical subexpressions in the right place. The pattern |
---|
679 | would say, "That does not look like an add instruction; try other |
---|
680 | patterns." The second pattern would say, "Yes, that's an add |
---|
681 | instruction, but there is something wrong with it." It would direct |
---|
682 | the reload pass of the compiler to generate additional insns to make |
---|
683 | the constraint true. The results might look like this: |
---|
684 | |
---|
685 | (insn N2 PREV N |
---|
686 | (set (reg:SI 3) (reg:SI 6)) |
---|
687 | ...) |
---|
688 | |
---|
689 | (insn N N2 NEXT |
---|
690 | (set (reg:SI 3) |
---|
691 | (plus:SI (reg:SI 3) (reg:SI 109))) |
---|
692 | ...) |
---|
693 | |
---|
694 | It is up to you to make sure that each operand, in each pattern, has |
---|
695 | constraints that can handle any RTL expression that could be present for |
---|
696 | that operand. (When multiple alternatives are in use, each pattern |
---|
697 | must, for each possible combination of operand expressions, have at |
---|
698 | least one alternative which can handle that combination of operands.) |
---|
699 | The constraints don't need to *allow* any possible operand--when this is |
---|
700 | the case, they do not constrain--but they must at least point the way to |
---|
701 | reloading any possible operand so that it will fit. |
---|
702 | |
---|
703 | * If the constraint accepts whatever operands the predicate permits, |
---|
704 | there is no problem: reloading is never necessary for this operand. |
---|
705 | |
---|
706 | For example, an operand whose constraints permit everything except |
---|
707 | registers is safe provided its predicate rejects registers. |
---|
708 | |
---|
709 | An operand whose predicate accepts only constant values is safe |
---|
710 | provided its constraints include the letter `i'. If any possible |
---|
711 | constant value is accepted, then nothing less than `i' will do; if |
---|
712 | the predicate is more selective, then the constraints may also be |
---|
713 | more selective. |
---|
714 | |
---|
715 | * Any operand expression can be reloaded by copying it into a |
---|
716 | register. So if an operand's constraints allow some kind of |
---|
717 | register, it is certain to be safe. It need not permit all |
---|
718 | classes of registers; the compiler knows how to copy a register |
---|
719 | into another register of the proper class in order to make an |
---|
720 | instruction valid. |
---|
721 | |
---|
722 | * A nonoffsettable memory reference can be reloaded by copying the |
---|
723 | address into a register. So if the constraint uses the letter |
---|
724 | `o', all memory references are taken care of. |
---|
725 | |
---|
726 | * A constant operand can be reloaded by allocating space in memory to |
---|
727 | hold it as preinitialized data. Then the memory reference can be |
---|
728 | used in place of the constant. So if the constraint uses the |
---|
729 | letters `o' or `m', constant operands are not a problem. |
---|
730 | |
---|
731 | * If the constraint permits a constant and a pseudo register used in |
---|
732 | an insn was not allocated to a hard register and is equivalent to |
---|
733 | a constant, the register will be replaced with the constant. If |
---|
734 | the predicate does not permit a constant and the insn is |
---|
735 | re-recognized for some reason, the compiler will crash. Thus the |
---|
736 | predicate must always recognize any objects allowed by the |
---|
737 | constraint. |
---|
738 | |
---|
739 | If the operand's predicate can recognize registers, but the |
---|
740 | constraint does not permit them, it can make the compiler crash. When |
---|
741 | this operand happens to be a register, the reload pass will be stymied, |
---|
742 | because it does not know how to copy a register temporarily into memory. |
---|
743 | |
---|
744 | |
---|
745 | File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints |
---|
746 | |
---|
747 | Multiple Alternative Constraints |
---|
748 | -------------------------------- |
---|
749 | |
---|
750 | Sometimes a single instruction has multiple alternative sets of |
---|
751 | possible operands. For example, on the 68000, a logical-or instruction |
---|
752 | can combine register or an immediate value into memory, or it can |
---|
753 | combine any kind of operand into a register; but it cannot combine one |
---|
754 | memory location into another. |
---|
755 | |
---|
756 | These constraints are represented as multiple alternatives. An |
---|
757 | alternative can be described by a series of letters for each operand. |
---|
758 | The overall constraint for an operand is made from the letters for this |
---|
759 | operand from the first alternative, a comma, the letters for this |
---|
760 | operand from the second alternative, a comma, and so on until the last |
---|
761 | alternative. Here is how it is done for fullword logical-or on the |
---|
762 | 68000: |
---|
763 | |
---|
764 | (define_insn "iorsi3" |
---|
765 | [(set (match_operand:SI 0 "general_operand" "=m,d") |
---|
766 | (ior:SI (match_operand:SI 1 "general_operand" "%0,0") |
---|
767 | (match_operand:SI 2 "general_operand" "dKs,dmKs")))] |
---|
768 | ...) |
---|
769 | |
---|
770 | The first alternative has `m' (memory) for operand 0, `0' for |
---|
771 | operand 1 (meaning it must match operand 0), and `dKs' for operand 2. |
---|
772 | The second alternative has `d' (data register) for operand 0, `0' for |
---|
773 | operand 1, and `dmKs' for operand 2. The `=' and `%' in the |
---|
774 | constraints apply to all the alternatives; their meaning is explained |
---|
775 | in the next section (*note Class Preferences::.). |
---|
776 | |
---|
777 | If all the operands fit any one alternative, the instruction is |
---|
778 | valid. Otherwise, for each alternative, the compiler counts how many |
---|
779 | instructions must be added to copy the operands so that that |
---|
780 | alternative applies. The alternative requiring the least copying is |
---|
781 | chosen. If two alternatives need the same amount of copying, the one |
---|
782 | that comes first is chosen. These choices can be altered with the `?' |
---|
783 | and `!' characters: |
---|
784 | |
---|
785 | `?' |
---|
786 | Disparage slightly the alternative that the `?' appears in, as a |
---|
787 | choice when no alternative applies exactly. The compiler regards |
---|
788 | this alternative as one unit more costly for each `?' that appears |
---|
789 | in it. |
---|
790 | |
---|
791 | `!' |
---|
792 | Disparage severely the alternative that the `!' appears in. This |
---|
793 | alternative can still be used if it fits without reloading, but if |
---|
794 | reloading is needed, some other alternative will be used. |
---|
795 | |
---|
796 | When an insn pattern has multiple alternatives in its constraints, |
---|
797 | often the appearance of the assembler code is determined mostly by which |
---|
798 | alternative was matched. When this is so, the C code for writing the |
---|
799 | assembler code can use the variable `which_alternative', which is the |
---|
800 | ordinal number of the alternative that was actually satisfied (0 for |
---|
801 | the first, 1 for the second alternative, etc.). *Note Output |
---|
802 | Statement::. |
---|
803 | |
---|
804 | |
---|
805 | File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints |
---|
806 | |
---|
807 | Register Class Preferences |
---|
808 | -------------------------- |
---|
809 | |
---|
810 | The operand constraints have another function: they enable the |
---|
811 | compiler to decide which kind of hardware register a pseudo register is |
---|
812 | best allocated to. The compiler examines the constraints that apply to |
---|
813 | the insns that use the pseudo register, looking for the |
---|
814 | machine-dependent letters such as `d' and `a' that specify classes of |
---|
815 | registers. The pseudo register is put in whichever class gets the most |
---|
816 | "votes". The constraint letters `g' and `r' also vote: they vote in |
---|
817 | favor of a general register. The machine description says which |
---|
818 | registers are considered general. |
---|
819 | |
---|
820 | Of course, on some machines all registers are equivalent, and no |
---|
821 | register classes are defined. Then none of this complexity is relevant. |
---|
822 | |
---|
823 | |
---|
824 | File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints |
---|
825 | |
---|
826 | Constraint Modifier Characters |
---|
827 | ------------------------------ |
---|
828 | |
---|
829 | Here are constraint modifier characters. |
---|
830 | |
---|
831 | `=' |
---|
832 | Means that this operand is write-only for this instruction: the |
---|
833 | previous value is discarded and replaced by output data. |
---|
834 | |
---|
835 | `+' |
---|
836 | Means that this operand is both read and written by the |
---|
837 | instruction. |
---|
838 | |
---|
839 | When the compiler fixes up the operands to satisfy the constraints, |
---|
840 | it needs to know which operands are inputs to the instruction and |
---|
841 | which are outputs from it. `=' identifies an output; `+' |
---|
842 | identifies an operand that is both input and output; all other |
---|
843 | operands are assumed to be input only. |
---|
844 | |
---|
845 | `&' |
---|
846 | Means (in a particular alternative) that this operand is written |
---|
847 | before the instruction is finished using the input operands. |
---|
848 | Therefore, this operand may not lie in a register that is used as |
---|
849 | an input operand or as part of any memory address. |
---|
850 | |
---|
851 | `&' applies only to the alternative in which it is written. In |
---|
852 | constraints with multiple alternatives, sometimes one alternative |
---|
853 | requires `&' while others do not. See, for example, the `movdf' |
---|
854 | insn of the 68000. |
---|
855 | |
---|
856 | `&' does not obviate the need to write `='. |
---|
857 | |
---|
858 | `%' |
---|
859 | Declares the instruction to be commutative for this operand and the |
---|
860 | following operand. This means that the compiler may interchange |
---|
861 | the two operands if that is the cheapest way to make all operands |
---|
862 | fit the constraints. This is often used in patterns for addition |
---|
863 | instructions that really have only two operands: the result must |
---|
864 | go in one of the arguments. Here for example, is how the 68000 |
---|
865 | halfword-add instruction is defined: |
---|
866 | |
---|
867 | (define_insn "addhi3" |
---|
868 | [(set (match_operand:HI 0 "general_operand" "=m,r") |
---|
869 | (plus:HI (match_operand:HI 1 "general_operand" "%0,0") |
---|
870 | (match_operand:HI 2 "general_operand" "di,g")))] |
---|
871 | ...) |
---|
872 | |
---|
873 | `#' |
---|
874 | Says that all following characters, up to the next comma, are to be |
---|
875 | ignored as a constraint. They are significant only for choosing |
---|
876 | register preferences. |
---|
877 | |
---|
878 | `*' |
---|
879 | Says that the following character should be ignored when choosing |
---|
880 | register preferences. `*' has no effect on the meaning of the |
---|
881 | constraint as a constraint, and no effect on reloading. |
---|
882 | |
---|
883 | Here is an example: the 68000 has an instruction to sign-extend a |
---|
884 | halfword in a data register, and can also sign-extend a value by |
---|
885 | copying it into an address register. While either kind of |
---|
886 | register is acceptable, the constraints on an address-register |
---|
887 | destination are less strict, so it is best if register allocation |
---|
888 | makes an address register its goal. Therefore, `*' is used so |
---|
889 | that the `d' constraint letter (for data register) is ignored when |
---|
890 | computing register preferences. |
---|
891 | |
---|
892 | (define_insn "extendhisi2" |
---|
893 | [(set (match_operand:SI 0 "general_operand" "=*d,a") |
---|
894 | (sign_extend:SI |
---|
895 | (match_operand:HI 1 "general_operand" "0,g")))] |
---|
896 | ...) |
---|
897 | |
---|
898 | |
---|
899 | File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints |
---|
900 | |
---|
901 | Constraints for Particular Machines |
---|
902 | ----------------------------------- |
---|
903 | |
---|
904 | Whenever possible, you should use the general-purpose constraint |
---|
905 | letters in `asm' arguments, since they will convey meaning more readily |
---|
906 | to people reading your code. Failing that, use the constraint letters |
---|
907 | that usually have very similar meanings across architectures. The most |
---|
908 | commonly used constraints are `m' and `r' (for memory and |
---|
909 | general-purpose registers respectively; *note Simple Constraints::.), |
---|
910 | and `I', usually the letter indicating the most common |
---|
911 | immediate-constant format. |
---|
912 | |
---|
913 | For each machine architecture, the `config/MACHINE.h' file defines |
---|
914 | additional constraints. These constraints are used by the compiler |
---|
915 | itself for instruction generation, as well as for `asm' statements; |
---|
916 | therefore, some of the constraints are not particularly interesting for |
---|
917 | `asm'. The constraints are defined through these macros: |
---|
918 | |
---|
919 | `REG_CLASS_FROM_LETTER' |
---|
920 | Register class constraints (usually lower case). |
---|
921 | |
---|
922 | `CONST_OK_FOR_LETTER_P' |
---|
923 | Immediate constant constraints, for non-floating point constants of |
---|
924 | word size or smaller precision (usually upper case). |
---|
925 | |
---|
926 | `CONST_DOUBLE_OK_FOR_LETTER_P' |
---|
927 | Immediate constant constraints, for all floating point constants |
---|
928 | and for constants of greater than word size precision (usually |
---|
929 | upper case). |
---|
930 | |
---|
931 | `EXTRA_CONSTRAINT' |
---|
932 | Special cases of registers or memory. This macro is not required, |
---|
933 | and is only defined for some machines. |
---|
934 | |
---|
935 | Inspecting these macro definitions in the compiler source for your |
---|
936 | machine is the best way to be certain you have the right constraints. |
---|
937 | However, here is a summary of the machine-dependent constraints |
---|
938 | available on some particular machines. |
---|
939 | |
---|
940 | *ARM family--`arm.h'* |
---|
941 | `f' |
---|
942 | Floating-point register |
---|
943 | |
---|
944 | `F' |
---|
945 | One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, |
---|
946 | 4.0, 5.0 or 10.0 |
---|
947 | |
---|
948 | `G' |
---|
949 | Floating-point constant that would satisfy the constraint `F' |
---|
950 | if it were negated |
---|
951 | |
---|
952 | `I' |
---|
953 | Integer that is valid as an immediate operand in a data |
---|
954 | processing instruction. That is, an integer in the range 0 |
---|
955 | to 255 rotated by a multiple of 2 |
---|
956 | |
---|
957 | `J' |
---|
958 | Integer in the range -4095 to 4095 |
---|
959 | |
---|
960 | `K' |
---|
961 | Integer that satisfies constraint `I' when inverted (ones |
---|
962 | complement) |
---|
963 | |
---|
964 | `L' |
---|
965 | Integer that satisfies constraint `I' when negated (twos |
---|
966 | complement) |
---|
967 | |
---|
968 | `M' |
---|
969 | Integer in the range 0 to 32 |
---|
970 | |
---|
971 | `Q' |
---|
972 | A memory reference where the exact address is in a single |
---|
973 | register (``m'' is preferable for `asm' statements) |
---|
974 | |
---|
975 | `R' |
---|
976 | An item in the constant pool |
---|
977 | |
---|
978 | `S' |
---|
979 | A symbol in the text segment of the current file |
---|
980 | |
---|
981 | *AMD 29000 family--`a29k.h'* |
---|
982 | `l' |
---|
983 | Local register 0 |
---|
984 | |
---|
985 | `b' |
---|
986 | Byte Pointer (`BP') register |
---|
987 | |
---|
988 | `q' |
---|
989 | `Q' register |
---|
990 | |
---|
991 | `h' |
---|
992 | Special purpose register |
---|
993 | |
---|
994 | `A' |
---|
995 | First accumulator register |
---|
996 | |
---|
997 | `a' |
---|
998 | Other accumulator register |
---|
999 | |
---|
1000 | `f' |
---|
1001 | Floating point register |
---|
1002 | |
---|
1003 | `I' |
---|
1004 | Constant greater than 0, less than 0x100 |
---|
1005 | |
---|
1006 | `J' |
---|
1007 | Constant greater than 0, less than 0x10000 |
---|
1008 | |
---|
1009 | `K' |
---|
1010 | Constant whose high 24 bits are on (1) |
---|
1011 | |
---|
1012 | `L' |
---|
1013 | 16 bit constant whose high 8 bits are on (1) |
---|
1014 | |
---|
1015 | `M' |
---|
1016 | 32 bit constant whose high 16 bits are on (1) |
---|
1017 | |
---|
1018 | `N' |
---|
1019 | 32 bit negative constant that fits in 8 bits |
---|
1020 | |
---|
1021 | `O' |
---|
1022 | The constant 0x80000000 or, on the 29050, any 32 bit constant |
---|
1023 | whose low 16 bits are 0. |
---|
1024 | |
---|
1025 | `P' |
---|
1026 | 16 bit negative constant that fits in 8 bits |
---|
1027 | |
---|
1028 | `G' |
---|
1029 | `H' |
---|
1030 | A floating point constant (in `asm' statements, use the |
---|
1031 | machine independent `E' or `F' instead) |
---|
1032 | |
---|
1033 | *IBM RS6000--`rs6000.h'* |
---|
1034 | `b' |
---|
1035 | Address base register |
---|
1036 | |
---|
1037 | `f' |
---|
1038 | Floating point register |
---|
1039 | |
---|
1040 | `h' |
---|
1041 | `MQ', `CTR', or `LINK' register |
---|
1042 | |
---|
1043 | `q' |
---|
1044 | `MQ' register |
---|
1045 | |
---|
1046 | `c' |
---|
1047 | `CTR' register |
---|
1048 | |
---|
1049 | `l' |
---|
1050 | `LINK' register |
---|
1051 | |
---|
1052 | `x' |
---|
1053 | `CR' register (condition register) number 0 |
---|
1054 | |
---|
1055 | `y' |
---|
1056 | `CR' register (condition register) |
---|
1057 | |
---|
1058 | `I' |
---|
1059 | Signed 16 bit constant |
---|
1060 | |
---|
1061 | `J' |
---|
1062 | Constant whose low 16 bits are 0 |
---|
1063 | |
---|
1064 | `K' |
---|
1065 | Constant whose high 16 bits are 0 |
---|
1066 | |
---|
1067 | `L' |
---|
1068 | Constant suitable as a mask operand |
---|
1069 | |
---|
1070 | `M' |
---|
1071 | Constant larger than 31 |
---|
1072 | |
---|
1073 | `N' |
---|
1074 | Exact power of 2 |
---|
1075 | |
---|
1076 | `O' |
---|
1077 | Zero |
---|
1078 | |
---|
1079 | `P' |
---|
1080 | Constant whose negation is a signed 16 bit constant |
---|
1081 | |
---|
1082 | `G' |
---|
1083 | Floating point constant that can be loaded into a register |
---|
1084 | with one instruction per word |
---|
1085 | |
---|
1086 | `Q' |
---|
1087 | Memory operand that is an offset from a register (`m' is |
---|
1088 | preferable for `asm' statements) |
---|
1089 | |
---|
1090 | *Intel 386--`i386.h'* |
---|
1091 | `q' |
---|
1092 | `a', `b', `c', or `d' register |
---|
1093 | |
---|
1094 | `A' |
---|
1095 | `a', or `d' register (for 64-bit ints) |
---|
1096 | |
---|
1097 | `f' |
---|
1098 | Floating point register |
---|
1099 | |
---|
1100 | `t' |
---|
1101 | First (top of stack) floating point register |
---|
1102 | |
---|
1103 | `u' |
---|
1104 | Second floating point register |
---|
1105 | |
---|
1106 | `a' |
---|
1107 | `a' register |
---|
1108 | |
---|
1109 | `b' |
---|
1110 | `b' register |
---|
1111 | |
---|
1112 | `c' |
---|
1113 | `c' register |
---|
1114 | |
---|
1115 | `d' |
---|
1116 | `d' register |
---|
1117 | |
---|
1118 | `D' |
---|
1119 | `di' register |
---|
1120 | |
---|
1121 | `S' |
---|
1122 | `si' register |
---|
1123 | |
---|
1124 | `I' |
---|
1125 | Constant in range 0 to 31 (for 32 bit shifts) |
---|
1126 | |
---|
1127 | `J' |
---|
1128 | Constant in range 0 to 63 (for 64 bit shifts) |
---|
1129 | |
---|
1130 | `K' |
---|
1131 | `0xff' |
---|
1132 | |
---|
1133 | `L' |
---|
1134 | `0xffff' |
---|
1135 | |
---|
1136 | `M' |
---|
1137 | 0, 1, 2, or 3 (shifts for `lea' instruction) |
---|
1138 | |
---|
1139 | `N' |
---|
1140 | Constant in range 0 to 255 (for `out' instruction) |
---|
1141 | |
---|
1142 | `G' |
---|
1143 | Standard 80387 floating point constant |
---|
1144 | |
---|
1145 | *Intel 960--`i960.h'* |
---|
1146 | `f' |
---|
1147 | Floating point register (`fp0' to `fp3') |
---|
1148 | |
---|
1149 | `l' |
---|
1150 | Local register (`r0' to `r15') |
---|
1151 | |
---|
1152 | `b' |
---|
1153 | Global register (`g0' to `g15') |
---|
1154 | |
---|
1155 | `d' |
---|
1156 | Any local or global register |
---|
1157 | |
---|
1158 | `I' |
---|
1159 | Integers from 0 to 31 |
---|
1160 | |
---|
1161 | `J' |
---|
1162 | 0 |
---|
1163 | |
---|
1164 | `K' |
---|
1165 | Integers from -31 to 0 |
---|
1166 | |
---|
1167 | `G' |
---|
1168 | Floating point 0 |
---|
1169 | |
---|
1170 | `H' |
---|
1171 | Floating point 1 |
---|
1172 | |
---|
1173 | *MIPS--`mips.h'* |
---|
1174 | `d' |
---|
1175 | General-purpose integer register |
---|
1176 | |
---|
1177 | `f' |
---|
1178 | Floating-point register (if available) |
---|
1179 | |
---|
1180 | `h' |
---|
1181 | `Hi' register |
---|
1182 | |
---|
1183 | `l' |
---|
1184 | `Lo' register |
---|
1185 | |
---|
1186 | `x' |
---|
1187 | `Hi' or `Lo' register |
---|
1188 | |
---|
1189 | `y' |
---|
1190 | General-purpose integer register |
---|
1191 | |
---|
1192 | `z' |
---|
1193 | Floating-point status register |
---|
1194 | |
---|
1195 | `I' |
---|
1196 | Signed 16 bit constant (for arithmetic instructions) |
---|
1197 | |
---|
1198 | `J' |
---|
1199 | Zero |
---|
1200 | |
---|
1201 | `K' |
---|
1202 | Zero-extended 16-bit constant (for logic instructions) |
---|
1203 | |
---|
1204 | `L' |
---|
1205 | Constant with low 16 bits zero (can be loaded with `lui') |
---|
1206 | |
---|
1207 | `M' |
---|
1208 | 32 bit constant which requires two instructions to load (a |
---|
1209 | constant which is not `I', `K', or `L') |
---|
1210 | |
---|
1211 | `N' |
---|
1212 | Negative 16 bit constant |
---|
1213 | |
---|
1214 | `O' |
---|
1215 | Exact power of two |
---|
1216 | |
---|
1217 | `P' |
---|
1218 | Positive 16 bit constant |
---|
1219 | |
---|
1220 | `G' |
---|
1221 | Floating point zero |
---|
1222 | |
---|
1223 | `Q' |
---|
1224 | Memory reference that can be loaded with more than one |
---|
1225 | instruction (`m' is preferable for `asm' statements) |
---|
1226 | |
---|
1227 | `R' |
---|
1228 | Memory reference that can be loaded with one instruction (`m' |
---|
1229 | is preferable for `asm' statements) |
---|
1230 | |
---|
1231 | `S' |
---|
1232 | Memory reference in external OSF/rose PIC format (`m' is |
---|
1233 | preferable for `asm' statements) |
---|
1234 | |
---|
1235 | *Motorola 680x0--`m68k.h'* |
---|
1236 | `a' |
---|
1237 | Address register |
---|
1238 | |
---|
1239 | `d' |
---|
1240 | Data register |
---|
1241 | |
---|
1242 | `f' |
---|
1243 | 68881 floating-point register, if available |
---|
1244 | |
---|
1245 | `x' |
---|
1246 | Sun FPA (floating-point) register, if available |
---|
1247 | |
---|
1248 | `y' |
---|
1249 | First 16 Sun FPA registers, if available |
---|
1250 | |
---|
1251 | `I' |
---|
1252 | Integer in the range 1 to 8 |
---|
1253 | |
---|
1254 | `J' |
---|
1255 | 16 bit signed number |
---|
1256 | |
---|
1257 | `K' |
---|
1258 | Signed number whose magnitude is greater than 0x80 |
---|
1259 | |
---|
1260 | `L' |
---|
1261 | Integer in the range -8 to -1 |
---|
1262 | |
---|
1263 | `G' |
---|
1264 | Floating point constant that is not a 68881 constant |
---|
1265 | |
---|
1266 | `H' |
---|
1267 | Floating point constant that can be used by Sun FPA |
---|
1268 | |
---|
1269 | *SPARC--`sparc.h'* |
---|
1270 | `f' |
---|
1271 | Floating-point register |
---|
1272 | |
---|
1273 | `I' |
---|
1274 | Signed 13 bit constant |
---|
1275 | |
---|
1276 | `J' |
---|
1277 | Zero |
---|
1278 | |
---|
1279 | `K' |
---|
1280 | 32 bit constant with the low 12 bits clear (a constant that |
---|
1281 | can be loaded with the `sethi' instruction) |
---|
1282 | |
---|
1283 | `G' |
---|
1284 | Floating-point zero |
---|
1285 | |
---|
1286 | `H' |
---|
1287 | Signed 13 bit constant, sign-extended to 32 or 64 bits |
---|
1288 | |
---|
1289 | `Q' |
---|
1290 | Memory reference that can be loaded with one instruction |
---|
1291 | (`m' is more appropriate for `asm' statements) |
---|
1292 | |
---|
1293 | `S' |
---|
1294 | Constant, or memory address |
---|
1295 | |
---|
1296 | `T' |
---|
1297 | Memory address aligned to an 8-byte boundary |
---|
1298 | |
---|
1299 | `U' |
---|
1300 | Even register |
---|
1301 | |
---|
1302 | |
---|
1303 | File: gcc.info, Node: No Constraints, Prev: Machine Constraints, Up: Constraints |
---|
1304 | |
---|
1305 | Not Using Constraints |
---|
1306 | --------------------- |
---|
1307 | |
---|
1308 | Some machines are so clean that operand constraints are not |
---|
1309 | required. For example, on the Vax, an operand valid in one context is |
---|
1310 | valid in any other context. On such a machine, every operand |
---|
1311 | constraint would be `g', excepting only operands of "load address" |
---|
1312 | instructions which are written as if they referred to a memory |
---|
1313 | location's contents but actual refer to its address. They would have |
---|
1314 | constraint `p'. |
---|
1315 | |
---|
1316 | For such machines, instead of writing `g' and `p' for all the |
---|
1317 | constraints, you can choose to write a description with empty |
---|
1318 | constraints. Then you write `""' for the constraint in every |
---|
1319 | `match_operand'. Address operands are identified by writing an |
---|
1320 | `address' expression around the `match_operand', not by their |
---|
1321 | constraints. |
---|
1322 | |
---|
1323 | When the machine description has just empty constraints, certain |
---|
1324 | parts of compilation are skipped, making the compiler faster. However, |
---|
1325 | few machines actually do not need constraints; all machine descriptions |
---|
1326 | now in existence use constraints. |
---|
1327 | |
---|