![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / cmd / gcc|
Return to internals-4 CVS log | Up to [Research Unix] / researchv10dc / cmd / gcc |
1.1 root 1:
2:
3: File: internals, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
4:
5: Side Effect Expressions
6: =======================
7:
8: The expression codes described so far represent values, not actions. But
9: machine instructions never produce values; they are meaningful only for
10: their side effects on the state of the machine. Special expression codes
11: are used to represent side effects.
12:
13: The body of an instruction is always one of these side effect codes; the
14: codes described above, which represent values, appear only as the operands
15: of these.
16:
17: `(set LVAL X)'
18: Represents the action of storing the value of X into the place
19: represented by LVAL. LVAL must be an expression representing a place
20: that can be stored in: `reg' (or `subreg' or `strict_low_part'),
21: `mem', `pc' or `cc0'.
22:
23: If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then X
24: must be valid for that mode.
25:
26: If LVAL is a `reg' whose machine mode is less than the full width of
27: the register, then it means that the part of the register specified by
28: the machine mode is given the specified value and the rest of the
29: register receives an undefined value. Likewise, if LVAL is a `subreg'
30: whose machine mode is narrower than `SImode', the rest of the register
31: can be changed in an undefined way.
32:
33: If LVAL is a `strict_low_part' of a `subreg', then the part of the
34: register specified by the machine mode of the `subreg' is given the
35: value X and the rest of the register is not changed.
36:
37: If LVAL is `(cc0)', it has no machine mode, and X may have any mode.
38: This represents a ``test'' or ``compare'' instruction.
39:
40: If LVAL is `(pc)', we have a jump instruction, and the possibilities
41: for X are very limited. It may be a `label_ref' expression
42: (unconditional jump). It may be an `if_then_else' (conditional jump),
43: in which case either the second or the third operand must be `(pc)'
44: (for the case which does not jump) and the other of the two must be a
45: `label_ref' (for the case which does jump). X may also be a `mem' or
46: `(plus:SI (pc) Y)', where Y may be a `reg' or a `mem'; these unusual
47: patterns are used to represent jumps through branch tables.
48:
49: `(return)'
50: Represents a return from the current function, on machines where this
51: can be done with one instruction, such as Vaxes. On machines where a
52: multi-instruction ``epilogue'' must be executed in order to return
53: from the function, returning is done by jumping to a label which
54: precedes the epilogue, and the `return' expression code is never used.
55:
56: `(call FUNCTION NARGS)'
57: Represents a function call. FUNCTION is a `mem' expression whose
58: address is the address of the function to be called. NARGS is an
59: expression representing the number of words of argument.
60:
61: Each machine has a standard machine mode which FUNCTION must have.
62: The machine description defines macro `FUNCTION_MODE' to expand into
63: the requisite mode name. The purpose of this mode is to specify what
64: kind of addressing is allowed, on machines where the allowed kinds of
65: addressing depend on the machine mode being addressed.
66:
67: `(clobber X)'
68: Represents the storing or possible storing of an unpredictable,
69: undescribed value into X, which must be a `reg' or `mem' expression.
70:
71: One place this is used is in string instructions that store standard
72: values into particular hard registers. It may not be worth the
73: trouble to describe the values that are stored, but it is essential to
74: inform the compiler that the registers will be altered, lest it
75: attempt to keep data in them across the string instruction.
76:
77: X may also be null---a null C pointer, no expression at all. Such a
78: `(clobber (null))' expression means that all memory locations must be
79: presumed clobbered.
80:
81: Note that the machine description classifies certain hard registers as
82: ``call-clobbered''. All function call instructions are assumed by
83: default to clobber these registers, so there is no need to use
84: `clobber' expressions to indicate this fact. Also, each function call
85: is assumed to have the potential to alter any memory location.
86:
87: `(use X)'
88: Represents the use of the value of X. It indicates that the value in
89: X at this point in the program is needed, even though it may not be
90: apparent why this is so. Therefore, the compiler will not attempt to
91: delete instructions whose only effect is to store a value in X. X
92: must be a `reg' expression.
93:
94: `(parallel [X0 X1 ...])'
95: Represents several side effects performed in parallel. The square
96: brackets stand for a vector; the operand of `parallel' is a vector of
97: expressions. X0, X1 and so on are individual side
98: effects---expressions of code `set', `call', `return', `clobber' or
99: `use'.
100:
101: ``In parallel'' means that first all the values used in the individual
102: side-effects are computed, and second all the actual side-effects are
103: performed. For example,
104:
105: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
106: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
107:
108: says unambiguously that the values of hard register 1 and the memory
109: location addressed by it are interchanged. In both places where
110: `(reg:SI 1)' appears as a memory address it refers to the value in
111: register 1 *before* the execution of the instruction.
112:
113: `(sequence [INSNS ...])'
114: Represents a sequence of insns. Each of the INSNS that appears in the
115: vector is suitable for appearing in the chain of insns, so it must be
116: an `insn', `jump_insn', `call_insn', `code_label', `barrier' or `note'.
117:
118: A `sequence' RTX never appears in an actual insn. It represents the
119: sequence of insns that result from a `define_expand' *before* those
120: insns are passed to `emit_insn' to insert them in the chain of insns.
121: When actually inserted, the individual sub-insns are separated out and
122: the `sequence' is forgotten.
123:
124: Three expression codes appear in place of a side effect, as the body of an
125: insn, though strictly speaking they do not describe side effects as such:
126:
127: `(asm_input S)'
128: Represents literal assembler code as described by the string S.
129:
130: `(addr_vec:M [LR0 LR1 ...])'
131: Represents a table of jump addresses. The vector elements LR0, etc.,
132: are `label_ref' expressions. The mode M specifies how much space is
133: given to each address; normally M would be `Pmode'.
134:
135: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
136: Represents a table of jump addresses expressed as offsets from BASE.
137: The vector elements LR0, etc., are `label_ref' expressions and so is
138: BASE. The mode M specifies how much space is given to each
139: address-difference.
140:
141:
142: File: internals, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
143:
144: Embedded Side-Effects on Addresses
145: ==================================
146:
147: Four special side-effect expression codes appear as memory addresses.
148:
149: `(pre_dec:M X)'
150: Represents the side effect of decrementing X by a standard amount and
151: represents also the value that X has after being decremented. X must
152: be a `reg' or `mem', but most machines allow only a `reg'. M must be
153: the machine mode for pointers on the machine in use. The amount X is
154: decremented by is the length in bytes of the machine mode of the
155: containing memory reference of which this expression serves as the
156: address. Here is an example of its use:
157:
158: (mem:DF (pre_dec:SI (reg:SI 39)))
159:
160: This says to decrement pseudo register 39 by the length of a `DFmode'
161: value and use the result to address a `DFmode' value.
162:
163: `(pre_inc:M X)'
164: Similar, but specifies incrementing X instead of decrementing it.
165:
166: `(post_dec:M X)'
167: Represents the same side effect as `pre_decrement' but a different
168: value. The value represented here is the value X has before being
169: decremented.
170:
171: `(post_inc:M X)'
172: Similar, but specifies incrementing X instead of decrementing it.
173:
174: These embedded side effect expressions must be used with care. Instruction
175: patterns may not use them. Until the `flow' pass of the compiler, they may
176: occur only to represent pushes onto the stack. The `flow' pass finds cases
177: where registers are incremented or decremented in one instruction and used
178: as an address shortly before or after; these cases are then transformed to
179: use pre- or post-increment or -decrement.
180:
181: Explicit popping of the stack could be represented with these embedded side
182: effect operators, but that would not be safe; the instruction combination
183: pass could move the popping past pushes, thus changing the meaning of the
184: code.
185:
186: An instruction that can be represented with an embedded side effect could
187: also be represented using `parallel' containing an additional `set' to
188: describe how the address register is altered. This is not done because
189: machines that allow these operations at all typically allow them wherever a
190: memory address is called for. Describing them as additional parallel
191: stores would require doubling the number of entries in the machine
192: description.
193:
194:
195: File: internals, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL
196:
197: Assembler Instructions as Expressions
198: =====================================
199:
200: The RTX code `asm_operands' represents a value produced by a user-specified
201: assembler instruction. It is used to represent an `asm' statement with
202: arguments. An `asm' statement with a single output operand, like this:
203:
204: asm ("foo %1,%2,%0" : "a" (outputvar) : "g" (x + y), "di" (*z));
205:
206: is represented using a single `asm_operands' RTX which represents the value
207: that is stored in `outputvar':
208:
209: (set RTX-FOR-OUTPUTVAR
210: (asm_operands "foo %1,%2,%0" "a" 0
211: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
212: [(asm_input:M1 "g")
213: (asm_input:M2 "di")]))
214:
215: Here the operands of the `asm_operands' RTX are the assembler template
216: string, the output-operand's constraint, the index-number of the output
217: operand among the output operands specified, a vector of input operand
218: RTX's, and a vector of input-operand modes and constraints. The mode M1 is
219: the mode of the sum `x+y'; M2 is that of `*z'.
220:
221: When an `asm' statement has multiple output values, its insn has several
222: such `set' RTX's inside of a `parallel'. Each `set' contains a
223: `asm_operands'; all of these share the same assembler template and vectors,
224: but each contains the constraint for the respective output operand. They
225: are also distinguished by the output-operand index number, which is 0, 1,
226: ... for successive output operands.
227:
228:
229: File: internals, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
230:
231: Insns
232: =====
233:
234: The RTL representation of the code for a function is a doubly-linked chain
235: of objects called "insns". Insns are expressions with special codes that
236: are used for no other purpose. Some insns are actual instructions; others
237: represent dispatch tables for `switch' statements; others represent labels
238: to jump to or various sorts of declarative information.
239:
240: In addition to its own specific data, each insn must have a unique
241: id-number that distinguishes it from all other insns in the current
242: function, and chain pointers to the preceding and following insns. These
243: three fields occupy the same position in every insn, independent of the
244: expression code of the insn. They could be accessed with `XEXP' and
245: `XINT', but instead three special macros are always used:
246:
247: `INSN_UID (I)'
248: Accesses the unique id of insn I.
249:
250: `PREV_INSN (I)'
251: Accesses the chain pointer to the insn preceding I. If I is the first
252: insn, this is a null pointer.
253:
254: `NEXT_INSN (I)'
255: Accesses the chain pointer to the insn following I. If I is the last
256: insn, this is a null pointer.
257:
258: The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if I is
259: not the first insn,
260:
261: NEXT_INSN (PREV_INSN (INSN)) == INSN
262:
263: is always true.
264:
265: Every insn has one of the following six expression codes:
266:
267: `insn'
268: The expression code `insn' is used for instructions that do not jump
269: and do not do function calls. Insns with code `insn' have four
270: additional fields beyond the three mandatory ones listed above. These
271: four are described in a table below.
272:
273: `jump_insn'
274: The expression code `jump_insn' is used for instructions that may jump
275: (or, more generally, may contain `label_ref' expressions).
276: `jump_insn' insns have the same extra fields as `insn' insns, accessed
277: in the same way.
278:
279: `call_insn'
280: The expression code `call_insn' is used for instructions that may do
281: function calls. It is important to distinguish these instructions
282: because they imply that certain registers and memory locations may be
283: altered unpredictably.
284:
285: `call_insn' insns have the same extra fields as `insn' insns, accessed
286: in the same way.
287:
288: `code_label'
289: A `code_label' insn represents a label that a jump insn can jump to.
290: It contains one special field of data in addition to the three
291: standard ones. It is used to hold the "label number", a number that
292: identifies this label uniquely among all the labels in the compilation
293: (not just in the current function). Ultimately, the label is
294: represented in the assembler output as an assembler label `LN' where N
295: is the label number.
296:
297: `barrier'
298: Barriers are placed in the instruction stream after unconditional jump
299: instructions to indicate that the jumps are unconditional. They
300: contain no information beyond the three standard fields.
301:
302: `note'
303: `note' insns are used to represent additional debugging and
304: declarative information. They contain two nonstandard fields, an
305: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
306: string accessed with `NOTE_SOURCE_FILE'.
307:
308: If `NOTE_LINE_NUMBER' is positive, the note represents the position of
309: a source line and `NOTE_SOURCE_FILE' is the source file name that the
310: line came from. These notes control generation of line number data in
311: the assembler output.
312:
313: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a code
314: with one of the following values (and `NOTE_SOURCE_FILE' must contain
315: a null pointer):
316:
317: `NOTE_INSN_DELETED'
318: Such a note is completely ignorable. Some passes of the compiler
319: delete insns by altering them into notes of this kind.
320:
321: `NOTE_INSN_BLOCK_BEG'
322: `NOTE_INSN_BLOCK_END'
323: These types of notes indicate the position of the beginning and
324: end of a level of scoping of variable names. They control the
325: output of debugging information.
326:
327: `NOTE_INSN_LOOP_BEG'
328: `NOTE_INSN_LOOP_END'
329: These types of notes indicate the position of the beginning and
330: end of a `while' or `for' loop. They enable the loop optimizer
331: to find loops quickly.
332:
333: Here is a table of the extra fields of `insn', `jump_insn' and `call_insn'
334: insns:
335:
336: `PATTERN (I)'
337: An expression for the side effect performed by this insn.
338:
339: `REG_NOTES (I)'
340: A list (chain of `expr_list' expressions) giving information about the
341: usage of registers in this insn. This list is set up by the flow
342: analysis pass; it is a null pointer until then.
343:
344: `LOG_LINKS (I)'
345: A list (chain of `insn_list' expressions) of previous ``related''
346: insns: insns which store into registers values that are used for the
347: first time in this insn. (An additional constraint is that neither a
348: jump nor a label may come between the related insns). This list is
349: set up by the flow analysis pass; it is a null pointer until then.
350:
351: `INSN_CODE (I)'
352: An integer that says which pattern in the machine description matches
353: this insn, or -1 if the matching has not yet been attempted.
354:
355: Such matching is never attempted and this field is not used on an insn
356: whose pattern consists of a single `use', `clobber', `asm', `addr_vec'
357: or `addr_diff_vec' expression.
358:
359: The `LOG_LINKS' field of an insn is a chain of `insn_list' expressions.
360: Each of these has two operands: the first is an insn, and the second is
361: another `insn_list' expression (the next one in the chain). The last
362: `insn_list' in the chain has a null pointer as second operand. The
363: significant thing about the chain is which insns appear in it (as first
364: operands of `insn_list' expressions). Their order is not significant.
365:
366: The `REG_NOTES' field of an insn is a similar chain but of `expr_list'
367: expressions instead of `insn_list'. There are four kinds of register
368: notes, which are distinguished by the machine mode of the `expr_list',
369: which a register note is really understood as being an `enum reg_note'.
370: The first operand OP of the `expr_list' is data whose meaning depends on
371: the kind of note. Here are the four kinds:
372:
373: `REG_DEAD'
374: The register OP dies in this insn; that is to say, altering the value
375: immediately after this insn would not affect the future behavior of
376: the program.
377:
378: `REG_INC'
379: The register OP is incremented (or decremented; at this level there is
380: no distinction) by an embedded side effect inside this insn. This
381: means it appears in a `POST_INC', `PRE_INC', `POST_DEC' or `PRE_DEC'
382: RTX.
383:
384: `REG_EQUIV'
385: The register that is set by this insn will be equal to OP at run time,
386: and could validly be replaced in all its occurrences by OP.
387: (``Validly'' here refers to the data flow of the program; simple
388: replacement may make some insns invalid.)
389:
390: The value which the insn explicitly copies into the register may look
391: different from OP, but they will be equal at run time.
392:
393: For example, when a constant is loaded into a register that is never
394: assigned any other value, this kind of note is used.
395:
396: When a parameter is copied into a pseudo-register at entry to a
397: function, a note of this kind records that the register is equivalent
398: to the stack slot where the parameter was passed. Although in this
399: case the register may be set by other insns, it is still valid to
400: replace the register by the stack slot throughout the function.
401:
402: `REG_EQUAL'
403: The register that is set by this insn will be equal to OP at run time
404: at the end of this insn (but not necessarily elsewhere in the function).
405:
406: The RTX OP is typically an arithmetic expression. For example, when a
407: sequence of insns such as a library call is used to perform an
408: arithmetic operation, this kind of note is attached to the insn that
409: produces or copies the final value. It tells the CSE pass how to
410: think of that value.
411:
412: `REG_RETVAL'
413: This insn copies the value of a library call, and OP is the first insn
414: that was generated to set up the arguments for the library call.
415:
416: Flow analysis uses this note to delete all of a library call whose
417: result is dead.
418:
419: `REG_WAS_0'
420: The register OP contained zero before this insn. You can rely on this
421: note if it is present; its absence implies nothing.
422:
423: (The only difference between the expression codes `insn_list' and
424: `expr_list' is that the first operand of an `insn_list' is assumed to be an
425: insn and is printed in debugging dumps as the insn's unique id; the first
426: operand of an `expr_list' is printed in the ordinary way as an expression.)
427:
428:
429: File: internals, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
430:
431: RTL Representation of Function-Call Insns
432: =========================================
433:
434: Insns that call subroutines have the RTL expression code `call_insn'.
435: These insns must satisfy special rules, and their bodies must use a special
436: RTL expression code, `call'.
437:
438: A `call' expression has two operands, as follows:
439:
440: (call NBYTES (mem:FM ADDR))
441:
442: Here NBYTES is an operand that represents the number of bytes of argument
443: data being passed to the subroutine, FM is a machine mode (which must equal
444: as the definition of the `FUNCTION_MODE' macro in the machine description)
445: and ADDR represents the address of the subroutine.
446:
447: For a subroutine that returns no value, the `call' RTX as shown above is
448: the entire body of the insn.
449:
450: For a subroutine that returns a value whose mode is not `BLKmode', the
451: value is returned in a hard register. If this register's number is R, then
452: the body of the call insn looks like this:
453:
454: (set (reg:M R)
455: (call NBYTES (mem:FM ADDR)))
456:
457: This RTL expression makes it clear (to the optimizer passes) that the
458: appropriate register receives a useful value in this insn.
459:
460: Immediately after RTL generation, if the value of the subroutine is
461: actually used, this call insn is always followed closely by an insn which
462: refers to the register R. This remains true through all the optimizer
463: passes until cross jumping occurs.
464:
465: The following insn has one of two forms. Either it copies the value into a
466: pseudo-register, like this:
467:
468: (set (reg:M P) (reg:M R))
469:
470: or (in the case where the calling function will simply return whatever
471: value the call produced, and no operation is needed to do this):
472:
473: (use (reg:M R))
474:
475: Between the call insn and this following insn there may intervene only a
476: stack-adjustment insn (and perhaps some `note' insns).
477:
478: When a subroutine returns a `BLKmode' value, it is handled by passing to
479: the subroutine the address of a place to store the value. So the call insn
480: itself does not ``return'' any value, and it has the same RTL form as a
481: call that returns nothing.
482:
483:
484: File: internals, Node: Sharing, Prev: Calls, Up: RTL
485:
486: Structure Sharing Assumptions
487: =============================
488:
489: The compiler assumes that certain kinds of RTL expressions are unique;
490: there do not exist two distinct objects representing the same value. In
491: other cases, it makes an opposite assumption: that no RTL expression object
492: of a certain kind appears in more than one place in the containing structure.
493:
494: These assumptions refer to a single function; except for the RTL objects
495: that describe global variables and external functions, no RTL objects are
496: common to two functions.
497:
498: * Each pseudo-register has only a single `reg' object to represent it,
499: and therefore only a single machine mode.
500:
501: * For any symbolic label, there is only one `symbol_ref' object
502: referring to it.
503:
504: * There is only one `const_int' expression with value zero, and only one
505: with value one.
506:
507: * There is only one `pc' expression.
508:
509: * There is only one `cc0' expression.
510:
511: * There is only one `const_double' expression with mode `SFmode' and
512: value zero, and only one with mode `DFmode' and value zero.
513:
514: * No `label_ref' appears in more than one place in the RTL structure; in
515: other words, it is safe to do a tree-walk of all the insns in the
516: function and assume that each time a `label_ref' is seen it is
517: distinct from all others that are seen.
518:
519: * Only one `mem' object is normally created for each static variable or
520: stack slot, so these objects are frequently shared in all the places
521: they appear. However, separate but equal objects for these variables
522: are occasionally made.
523:
524: * No RTL object appears in more than one place in the RTL structure
525: except as described above. Many passes of the compiler rely on this
526: by assuming that they can modify RTL objects in place without unwanted
527: side-effects on other insns.
528:
529: * During initial RTL generation, shared structure is freely introduced.
530: After all the RTL for a function has been generated, all shared
531: structure is copied by `unshare_all_rtl' in `emit-rtl.c', after which
532: the above rules are guaranteed to be followed.
533:
534: * During the combiner pass, shared structure with an insn can exist
535: temporarily. However, the shared structure is copied before the
536: combiner is finished with the insn. This is done by
537: `copy_substitutions' in `combine.c'.
538:
539:
540: File: internals, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top
541:
542: Machine Descriptions
543: ********************
544:
545: A machine description has two parts: a file of instruction patterns (`.md'
546: file) and a C header file of macro definitions.
547:
548: The `.md' file for a target machine contains a pattern for each instruction
549: that the target machine supports (or at least each instruction that is
550: worth telling the compiler about). It may also contain comments. A
551: semicolon causes the rest of the line to be a comment, unless the semicolon
552: is inside a quoted string.
553:
554: See the next chapter for information on the C header file.
555:
556: * Menu:
557:
558: * Patterns:: How to write instruction patterns.
559: * Example:: An explained example of a `define_insn' pattern.
560: * RTL Template:: The RTL template defines what insns match a pattern.
561: * Output Template:: The output template says how to make assembler code
562: from such an insn.
563: * Output Statement:: For more generality, write C code to output
564: the assembler code.
565: * Constraints:: When not all operands are general operands.
566: * Standard Names:: Names mark patterns to use for code generation.
567: * Pattern Ordering:: When the order of patterns makes a difference.
568: * Dependent Patterns:: Having one pattern may make you need another.
569: * Jump Patterns:: Special considerations for patterns for jump insns.
570: * Peephole Definitions::Defining machine-specific peephole optimizations.
571: * Expander Definitions::Generating a sequence of several RTL insns
572: for a standard operation.
573:
574:
575:
576: File: internals, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc
577:
578: Everything about Instruction Patterns
579: =====================================
580:
581: Each instruction pattern contains an incomplete RTL expression, with pieces
582: to be filled in later, operand constraints that restrict how the pieces can
583: be filled in, and an output pattern or C code to generate the assembler
584: output, all wrapped up in a `define_insn' expression.
585:
586: A `define_insn' is an RTL expression containing four operands:
587:
588: 1. An optional name. The presence of a name indicate that this instruction
589: pattern can perform a certain standard job for the RTL-generation pass
590: of the compiler. This pass knows certain names and will use the
591: instruction patterns with those names, if the names are defined in the
592: machine description.
593:
594: The absence of a name is indicated by writing an empty string where
595: the name should go. Nameless instruction patterns are never used for
596: generating RTL code, but they may permit several simpler insns to be
597: combined later on.
598:
599: Names that are not thus known and used in RTL-generation have no
600: effect; they are equivalent to no name at all.
601:
602: 2. The "RTL template" (*Note RTL Template::.) is a vector of incomplete RTL
603: expressions which show what the instruction should look like. It is
604: incomplete because it may contain `match_operand' and `match_dup'
605: expressions that stand for operands of the instruction.
606:
607: If the vector has only one element, that element is what the
608: instruction should look like. If the vector has multiple elements,
609: then the instruction looks like a `parallel' expression containing
610: that many elements as described.
611:
612: 3. A condition. This is a string which contains a C expression that is the
613: final test to decide whether an insn body matches this pattern.
614:
615: For a named pattern, the condition (if present) may not depend on the
616: data in the insn being matched, but only the target-machine-type
617: flags. The compiler needs to test these conditions during
618: initialization in order to learn exactly which named instructions are
619: available in a particular run.
620:
621: For nameless patterns, the condition is applied only when matching an
622: individual insn, and only after the insn has matched the pattern's
623: recognition template. The insn's operands may be found in the vector
624: `operands'.
625:
626: 4. The "output template": a string that says how to output matching insns
627: as assembler code. `%' in this string specifies where to substitute
628: the value of an operand. *note Output Template::.
629:
630: When simple substitution isn't general enough, you can specify a piece
631: of C code to compute the output. *note Output Statement::.
632:
633:
634: File: internals, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
635:
636: Example of `define_insn'
637: ========================
638:
639: Here is an actual example of an instruction pattern, for the 68000/68020.
640:
641: (define_insn "tstsi"
642: [(set (cc0)
643: (match_operand:SI 0 "general_operand" "rm"))]
644: ""
645: "*
646: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
647: return \"tstl %0\";
648: return \"cmpl #0,%0\"; }")
649:
650: This is an instruction that sets the condition codes based on the value of
651: a general operand. It has no condition, so any insn whose RTL description
652: has the form shown may be handled according to this pattern. The name
653: `tstsi' means ``test a `SImode' value'' and tells the RTL generation pass
654: that, when it is necessary to test such a value, an insn to do so can be
655: constructed using this pattern.
656:
657: The output control string is a piece of C code which chooses which output
658: template to return based on the kind of operand and the specific type of
659: CPU for which code is being generated.
660:
661: `"rm"' is an operand constraint. Its meaning is explained below.
662:
663:
664: File: internals, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
665:
666: RTL Template for Generating and Recognizing Insns
667: =================================================
668:
669: The RTL template is used to define which insns match the particular pattern
670: and how to find their operands. For named patterns, the RTL template also
671: says how to construct an insn from specified operands.
672:
673: Construction involves substituting specified operands into a copy of the
674: template. Matching involves determining the values that serve as the
675: operands in the insn being matched. Both of these activities are
676: controlled by special expression types that direct matching and
677: substitution of the operands.
678:
679: `(match_operand:M N TESTFN CONSTRAINT)'
680: This expression is a placeholder for operand number N of the insn.
681: When constructing an insn, operand number N will be substituted at
682: this point. When matching an insn, whatever appears at this position
683: in the insn will be taken as operand number N; but it must satisfy
684: TESTFN or this instruction pattern will not match at all.
685:
686: Operand numbers must be chosen consecutively counting from zero in
687: each instruction pattern. There may be only one `match_operand'
688: expression in the pattern for each expression number, and they must
689: appear in order of increasing expression number.
690:
691: TESTFN is a string that is the name of a C function that accepts two
692: arguments, a machine mode and an expression. During matching, the
693: function will be called with M as the mode argument and the putative
694: operand as the other argument. If it returns zero, this instruction
695: pattern fails to match. TESTFN may be an empty string; then it means
696: no test is to be done on the operand.
697:
698: Most often, TESTFN is `"general_operand"'. It checks that the
699: putative operand is either a constant, a register or a memory
700: reference, and that it is valid for mode M.
701:
702: For an operand that must be a register, TESTFN should be
703: `"register_operand"'. This prevents GNU CC from creating insns that
704: have memory references in these operands, insns which would only have
705: to be taken apart in the reload pass.
706:
707: For an operand that must be a constant, either TESTFN should be
708: `"immediate_operand"', or the instruction pattern's extra condition
709: should check for constants, or both.
710:
711: CONSTRAINT is explained later (*Note Constraints::.).
712:
713: `(match_dup N)'
714: This expression is also a placeholder for operand number N. It is
715: used when the operand needs to appear more than once in the insn.
716:
717: In construction, `match_dup' behaves exactly like `match_operand': the
718: operand is substituted into the insn being constructed. But in
719: matching, `match_dup' behaves differently. It assumes that operand
720: number N has already been determined by a `match_operand' appearing
721: earlier in the recognition template, and it matches only an
722: identical-looking expression.
723:
724: `(address (match_operand:M N "address_operand" ""))'
725: This complex of expressions is a placeholder for an operand number N
726: in a ``load address'' instruction: an operand which specifies a memory
727: location in the usual way, but for which the actual operand value used
728: is the address of the location, not the contents of the location.
729:
730: `address' expressions never appear in RTL code, only in machine
731: descriptions. And they are used only in machine descriptions that do
732: not use the operand constraint feature. When operand constraints are
733: in use, the letter `p' in the constraint serves this purpose.
734:
735: M is the machine mode of the *memory location being addressed*, not
736: the machine mode of the address itself. That mode is always the same
737: on a given target machine (it is `Pmode', which normally is `SImode'),
738: so there is no point in mentioning it; thus, no machine mode is
739: written in the `address' expression. If some day support is added for
740: machines in which addresses of different kinds of objects appear
741: differently or are used differently (such as the PDP-10), different
742: formats would perhaps need different machine modes and these modes
743: might be written in the `address' expression.
744:
745:
746: File: internals, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
747:
748: Output Templates and Operand Substitution
749: =========================================
750:
751: The "output template" is a string which specifies how to output the
752: assembler code for an instruction pattern. Most of the template is a fixed
753: string which is output literally. The character `%' is used to specify
754: where to substitute an operand; it can also be used to identify places
755: different variants of the assembler require different syntax.
756:
757: In the simplest case, a `%' followed by a digit N says to output operand N
758: at that point in the string.
759:
760: `%' followed by a letter and a digit says to output an operand in an
761: alternate fashion. Four letters have standard, built-in meanings described
762: below. The machine description macro `PRINT_OPERAND' can define additional
763: letters with nonstandard meanings.
764:
765: `%cDIGIT' can be used to substitute an operand that is a constant value
766: without the syntax that normally indicates an immediate operand.
767:
768: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
769: negated before printing.
770:
771: `%aDIGIT' can be used to substitute an operand as if it were a memory
772: reference, with the actual operand treated as the address. This may be
773: useful when outputting a ``load address'' instruction, because often the
774: assembler syntax for such an instruction requires you to write the operand
775: as if it were a memory reference.
776:
777: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
778:
779: `%' followed by a punctuation character specifies a substitution that does
780: not use an operand. Only one case is standard: `%%' outputs a `%' into the
781: assembler code. Other nonstandard cases can be defined in the
782: `PRINT_OPERAND' macro.
783:
784: The template may generate multiple assembler instructions. Write the text
785: for the instructions, with `\;' between them.
786:
787: When the RTL contains two operand which are required by constraint to match
788: each other, the output template must refer only to the lower-numbered
789: operand. Matching operands are not always identical, and the rest of the
790: compiler arranges to put the proper RTL expression for printing into the
791: lower-numbered operand.
792:
793: One use of nonstandard letters or punctuation following `%' is to
794: distinguish between different assembler languages for the same machine; for
795: example, Motorola syntax versus MIT syntax for the 68000. Motorola syntax
796: requires periods in most opcode names, while MIT syntax does not. For
797: example, the opcode `movel' in MIT syntax is `move.l' in Motorola syntax.
798: The same file of patterns is used for both kinds of output syntax, but the
799: character sequence `%.' is used in each place where Motorola syntax wants a
800: period. The `PRINT_OPERAND' macro for Motorola syntax defines the sequence
801: to output a period; the macro for MIT syntax defines it to do nothing.
802:
803:
804: File: internals, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
805:
806: C Statements for Generating Assembler Output
807: ============================================
808:
809: Often a single fixed template string cannot produce correct and efficient
810: assembler code for all the cases that are recognized by a single
811: instruction pattern. For example, the opcodes may depend on the kinds of
812: operands; or some unfortunate combinations of operands may require extra
813: machine instructions.
814:
815: If the output control string starts with a `*', then it is not an output
816: template but rather a piece of C program that should compute a template.
817: It should execute a `return' statement to return the template-string you
818: want. Most such templates use C string literals, which require doublequote
819: characters to delimit them. To include these doublequote characters in the
820: string, prefix each one with `\'.
821:
822: The operands may be found in the array `operands', whose C data type is
823: `rtx []'.
824:
825: It is possible to output an assembler instruction and then go on to output
826: or compute more of them, using the subroutine `output_asm_insn'. This
827: receives two arguments: a template-string and a vector of operands. The
828: vector may be `operands', or it may be another array of `rtx' that you
829: declare locally and initialize yourself.
830:
831: When an insn pattern has multiple alternatives in its constraints, often
832: the appearance of the assembler code determined mostly by which alternative
833: was matched. When this is so, the C code can test the variable
834: `which_alternative', which is the ordinal number of the alternative that
835: was actually satisfied (0 for the first, 1 for the second alternative, etc.).
836:
837: For example, suppose there are two opcodes for storing zero, `clrreg' for
838: registers and `clrmem' for memory locations. Here is how a pattern could
839: use `which_alternative' to choose between them:
840:
841: (define_insn ""
842: [(set (match_operand:SI 0 "general_operand" "r,m")
843: (const_int 0))]
844: ""
845: "*
846: return (which_alternative == 0
847: ? \"clrreg %0\" : \"clrmem %0\");
848: ")
849:
850:
851: File: internals, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
852:
853: Operand Constraints
854: ===================
855:
856: Each `match_operand' in an instruction pattern can specify a constraint for
857: the type of operands allowed. Constraints can say whether an operand may
858: be in a register, and which kinds of register; whether the operand can be a
859: memory reference, and which kinds of address; whether the operand may be an
860: immediate constant, and which possible values it may have. Constraints can
861: also require two operands to match.
862:
863: * Menu:
864:
865: * Simple Constraints:: Basic use of constraints.
866: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
867: * Class Preferences:: Constraints guide which hard register to put things in.
868: * Modifiers:: More precise control over effects of constraints.
869: * No Constraints:: Describing a clean machine without constraints.
870:
871:
872:
873: File: internals, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints
874:
875: Simple Constraints
876: ------------------
877:
878: The simplest kind of constraint is a string full of letters, each of which
879: describes one kind of operand that is permitted. Here are the letters that
880: are allowed:
881:
882: `m'
883: A memory operand is allowed, with any kind of address that the machine
884: supports in general.
885:
886: `o'
887: A memory operand is allowed, but only if the address is "offsetable".
888: This means that adding a small integer (actually, the width in bytes
889: of the operand, as determined by its machine mode) may be added to the
890: address and the result is also a valid memory address.
891:
892: For example, an address which is constant is offsetable; so is an
893: address that is the sum of a register and a constant (as long as a
894: slightly larger constant is also within the range of address-offsets
895: supported by the machine); but an autoincrement or autodecrement
896: address is not offsetable. More complicated indirect/indexed
897: addresses may or may not be offsetable depending on the other
898: addressing modes that the machine supports.
899:
900: Note that in an output operand which can be matched by another
901: operand, the constraint letter `o' is valid only when accompanied by
902: both `<' (if the target machine has predecrement addressing) and `>'
903: (if the target machine has preincrement addressing).
904:
905: `<'
906: A memory operand with autodecrement addressing (either predecrement or
907: postdecrement) is allowed.
908:
909: `>'
910: A memory operand with autoincrement addressing (either preincrement or
911: postincrement) is allowed.
912:
913: `r'
914: A register operand is allowed provided that it is in a general register.
915:
916: `d', `a', `f', ...
917: Other letters can be defined in machine-dependent fashion to stand for
918: particular classes of registers. `d', `a' and `f' are defined on the
919: 68000/68020 to stand for data, address and floating point registers.
920:
921: `i'
922: An immediate integer operand (one with constant value) is allowed.
923: This includes symbolic constants whose values will be known only at
924: assembly time.
925:
926: `n'
927: An immediate integer operand with a known numeric value is allowed.
928: Many systems cannot support assembly-time constants for operands less
929: than a word wide. Constraints for these operands should use `n'
930: rather than `i'.
931:
932: `I', `J', `K', ...
933: Other letters in the range `I' through `M' may be defined in a
934: machine-dependent fashion to permit immediate integer operands with
935: explicit integer values in specified ranges. For example, on the
936: 68000, `I' is defined to stand for the range of values 1 to 8. This
937: is the range permitted as a shift count in the shift instructions.
938:
939: `F'
940: An immediate floating operand (expression code `const_double') is
941: allowed.
942:
943: `G', `H'
944: `G' and `H' may be defined in a machine-dependent fashion to permit
945: immediate floating operands in particular ranges of values.
946:
947: `s'
948: An immediate integer operand whose value is not an explicit integer is
949: allowed.
950:
951: This might appear strange; if an insn allows a constant operand with a
952: value not known at compile time, it certainly must allow any known
953: value. So why use `s' instead of `i'? Sometimes it allows better
954: code to be generated.
955:
956: For example, on the 68000 in a fullword instruction it is possible to
957: use an immediate operand; but if the immediate value is between -32
958: and 31, better code results from loading the value into a register and
959: using the register. This is because the load into the register can be
960: done with a `moveq' instruction. We arrange for this to happen by
961: defining the letter `K' to mean ``any integer outside the range -32 to
962: 31'', and then specifying `Ks' in the operand constraints.
963:
964: `g'
965: Any register, memory or immediate integer operand is allowed, except
966: for registers that are not general registers.
967:
968: `N' (a digit)
969: An operand that matches operand number N is allowed. If a digit is
970: used together with letters, the digit should come last.
971:
972: This is called a "matching constraint" and what it really means is
973: that the assembler has only a single operand that fills two roles
974: considered separate in the RTL insn. For example, an add insn has two
975: input operands and one output operand in the RTL, but on most machines
976: an add instruction really has only two operands, one of them an
977: input-output operand.
978:
979: Matching constraints work only in circumstances like that add insn.
980: More precisely, the matching constraint must appear in an input-only
981: operand and the operand that it matches must be an output-only operand
982: with a lower number.
983:
984: For operands to match in a particular case usually means that they are
985: identical-looking RTL expressions. But in a few special cases
986: specific kinds of dissimilarity are allowed. For example, `*x' as an
987: input operand will match `*x++' as an output operand. For proper
988: results in such cases, the output template should always use the
989: output-operand's number when printing the operand.
990:
991: `p'
992: An operand that is a valid memory address is allowed. This is for
993: ``load address'' and ``push address'' instructions.
994:
995: If `p' is used in the constraint, the test-function in the
996: `match_operand' must be `address_operand'.
997:
998: In order to have valid assembler code, each operand must satisfy its
999: constraint. But a failure to do so does not prevent the pattern from
1000: applying to an insn. Instead, it directs the compiler to modify the code
1001: so that the constraint will be satisfied. Usually this is done by copying
1002: an operand into a register.
1003:
1004: Contrast, therefore, the two instruction patterns that follow:
1005:
1006: (define_insn ""
1007: [(set (match_operand:SI 0 "general_operand" "r")
1008: (plus:SI (match_dup 0)
1009: (match_operand:SI 1 "general_operand" "r")))]
1010: ""
1011: "...")
1012:
1013: which has two operands, one of which must appear in two places, and
1014:
1015: (define_insn ""
1016: [(set (match_operand:SI 0 "general_operand" "r")
1017: (plus:SI (match_operand:SI 1 "general_operand" "0")
1018: (match_operand:SI 2 "general_operand" "r")))]
1019: ""
1020: "...")
1021:
1022: which has three operands, two of which are required by a constraint to be
1023: identical. If we are considering an insn of the form
1024:
1025: (insn N PREV NEXT
1026: (set (reg:SI 3)
1027: (plus:SI (reg:SI 6) (reg:SI 109)))
1028: ...)
1029:
1030: the first pattern would not apply at all, because this insn does not
1031: contain two identical subexpressions in the right place. The pattern would
1032: say, ``That does not look like an add instruction; try other patterns.''
1033: The second pattern would say, ``Yes, that's an add instruction, but there
1034: is something wrong with it.'' It would direct the reload pass of the
1035: compiler to generate additional insns to make the constraint true. The
1036: results might look like this:
1037:
1038: (insn N2 PREV N
1039: (set (reg:SI 3) (reg:SI 6))
1040: ...)
1041:
1042: (insn N N2 NEXT
1043: (set (reg:SI 3)
1044: (plus:SI (reg:SI 3) (reg:SI 109)))
1045: ...)
1046:
1047: Because insns that don't fit the constraints are fixed up by loading
1048: operands into registers, every instruction pattern's constraints must
1049: permit the case where all the operands are in registers. It need not
1050: permit all classes of registers; the compiler knows how to copy registers
1051: into other registers of the proper class in order to make an instruction
1052: valid. But if no registers are permitted, the compiler will be stymied: it
1053: does not know how to save a register in memory in order to make an
1054: instruction valid. Instruction patterns that reject registers can be made
1055: valid by attaching a condition-expression that refuses to match an insn at
1056: all if the crucial operand is a register.
1057:
1058:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.