![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to internals-2 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file internals, produced by texinfo-format-buffer -*-Text-*-
2: from file internals.texinfo
3:
4:
5: This file documents the internals of the GNU compiler.
6:
7: Copyright (C) 1987 Richard M. Stallman.
8:
9: Permission is granted to make and distribute verbatim copies of
10: this manual provided the copyright notice and this permission notice
11: are preserved on all copies.
12:
13: Permission is granted to copy and distribute modified versions of this
14: manual under the conditions for verbatim copying, provided also that the
15: section entitled "GNU CC General Public License" is included exactly as
16: in the original, and provided that the entire resulting derived work is
17: distributed under the terms of a permission notice identical to this one.
18:
19: Permission is granted to copy and distribute translations of this manual
20: into another language, under the above conditions for modified versions,
21: except that the section entitled "GNU CC General Public License" may be
22: included in a translation approved by the author instead of in the original
23: English.
24:
25:
26:
27:
28:
29: File: internals Node: Comparisons, Prev: Arithmetic, Up: RTL, Next: Bit Fields
30:
31: Comparison Operations
32: =====================
33:
34: Comparison operators test a relation on two operands and are considered to
35: represent the value 1 if the relation holds, or zero if it does not. The
36: mode of the comparison is determined by the operands; they must both be
37: valid for a common machine mode. A comparison with both operands constant
38: would be invalid as the machine mode could not be deduced from it, but such
39: a comparison should never exist in rtl due to constant folding.
40:
41: Inequality comparisons come in two flavors, signed and unsigned. Thus,
42: there are distinct expression codes `GT' and `GTU' for signed and
43: unsigned greater-than. These can produce different results for the same
44: pair of integer values: for example, 1 is signed greater-than -1 but not
45: unsigned greater-than, because -1 when regarded as unsigned is actually
46: 0xffffffff which is greater than 1.
47:
48: The signed comparisons are also used for floating point values. Floating
49: point comparisons are distinguished by the machine modes of the operands.
50:
51: The comparison operators may be used to compare the condition codes
52: `(cc0)' against zero, as in `(eq (cc0) (const_int 0))'.
53: Such a construct actually refers to the result of the preceding
54: instruction in which the condition codes were set. The above
55: example stands for 1 if the condition codes were set to say
56: "zero" or "equal", 0 otherwise. Although the same comparison
57: operators are used for this as may be used in other contexts
58: on actual data, no confusion can result since the machine description
59: would never allow both kinds of uses in the same context.
60:
61: `(eq X Y)'
62: 1 if the values represented by X and Y are equal,
63: otherwise 0.
64:
65: `(ne X Y)'
66: 1 if the values represented by X and Y are not equal,
67: otherwise 0.
68:
69: `(gt X Y)'
70: 1 if the X is greater than Y. If they are fixed-point,
71: the comparison is done in a signed sense.
72:
73: `(gtu X Y)'
74: Like `gt' but does unsigned comparison, on fixed-point numbers only.
75:
76: `(lt X Y)'
77: `(ltu X Y)'
78: Like `gt' and `gtu' but test for "less than".
79:
80: `(ge X Y)'
81: `(geu X Y)'
82: Like `gt' and `gtu' but test for "greater than or equal".
83:
84: `(le X Y)'
85: `(leu X Y)'
86: Like `gt' and `gtu' but test for "less than or equal".
87:
88: `(if_then_else COND THEN ELSE)'
89: This is not a comparison operation but is listed here because it is
90: always used in conjunction with a comparison operation. To be
91: precise, COND is a comparison expression. This expression
92: represents a choice, according to COND, between the value
93: represented by THEN and the one represented by ELSE.
94:
95: On most machines, `if_then_else' expressions are valid only
96: to express conditional jumps.
97:
98:
99: File: internals Node: Bit Fields, Prev: Comparisons, Up: RTL, Next: Conversions
100:
101: Bit-fields
102: ==========
103:
104: Special expression codes exist to represent bit-field instructions.
105: These types of expressions are lvalues in rtl; they may appear
106: on the left side of a assignment, indicating insertion of a value
107: into the specified bit field.
108:
109: `(sign_extract:SI LOC SIZE POS)'
110: This represents a reference to a sign-extended bit-field contained or
111: starting in LOC (a memory or register reference). The bit field
112: is SIZE bits wide and starts at bit POS. The compilation
113: switch `BITS_BIG_ENDIAN' says which end of the memory unit
114: POS counts from.
115:
116: Which machine modes are valid for LOC depends on the machine,
117: but typically LOC should be a single byte when in memory
118: or a full word in a register.
119:
120: `(zero_extract:SI LOC POS SIZE)'
121: Like `sign_extract' but refers to an unsigned or zero-extended
122: bit field. The same sequence of bits are extracted, but they
123: are filled to an entire word with zeros instead of by sign-extension.
124:
125:
126: File: internals Node: Conversions, Prev: Bit Fields, Up: RTL, Next: RTL Declarations
127:
128: Conversions
129: ===========
130:
131: All conversions between machine modes must be represented by
132: explicit conversion operations. For example, an expression
133: which the sum of a byte and a full word cannot be written as
134: `(plus:SI (reg:QI 34) (reg:SI 80))' because the `plus'
135: operation requires two operands of the same machine mode.
136: Therefore, the byte-sized operand is enclosed in a conversion
137: operation, as in
138:
139: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
140:
141: The conversion operation is not a mere placeholder, because there
142: may be more than one way of converting from a given starting mode
143: to the desired final mode. The conversion operation code says how
144: to do it.
145:
146: `(sign_extend:M X)'
147: Represents the result of sign-extending the value X
148: to machine mode M. M must be a fixed-point mode
149: and X a fixed-point value of a mode narrower than M.
150:
151: `(zero_extend:M X)'
152: Represents the result of zero-extending the value X
153: to machine mode M. M must be a fixed-point mode
154: and X a fixed-point value of a mode narrower than M.
155:
156: `(float_extend:M X)'
157: Represents the result of extending the value X
158: to machine mode M. M must be a floating point mode
159: and X a floating point value of a mode narrower than M.
160:
161: `(truncate:M X)'
162: Represents the result of truncating the value X
163: to machine mode M. M must be a fixed-point mode
164: and X a fixed-point value of a mode wider than M.
165:
166: `(float_truncate:M X)'
167: Represents the result of truncating the value X
168: to machine mode M. M must be a floating point mode
169: and X a floating point value of a mode wider than M.
170:
171: `(float:M X)'
172: Represents the result of converting fixed point value X
173: to floating point mode M.
174:
175: `(fix:M X)'
176: Represents the result of converting floating point value X
177: to fixed point mode M. How rounding is done is not specified.
178:
179:
180:
181: File: internals Node: RTL Declarations, Prev: Conversions, Up: RTL, Next: Side Effects
182:
183: Declarations
184: ============
185:
186: Declaration expression codes do not represent arithmetic operations
187: but rather state assertions about their operands.
188:
189: `(volatile:M X)'
190: Represents the same value X does, but makes the assertion
191: that it should be treated as a volatile value. This forbids
192: coalescing multiple accesses or deleting them even if it would
193: appear to have no effect on the program. X must be a `mem'
194: expression with mode M.
195:
196: The first thing the reload pass does to an insn is to remove all
197: `volatile' expressions from it; each one is replaced by its
198: operand.
199:
200: Recognizers will never recognize anything with `volatile' in it.
201: This automatically prevents some optimizations on such things
202: (such as instruction combination). After the reload pass removes
203: all volatility information, the insns can be recognized.
204:
205: Cse removes `volatile' from destinations of `set''s, because
206: no optimizations reorder such `set's. This is not required for
207: correct code and is done to permit some optimization on the value to
208: be stored.
209:
210: `(unchanging:M X)'
211: Represents the same value X does, but makes the assertion
212: that its value is effectively constant during the execution
213: of the current function. This permits references to X
214: to be moved freely within the function. X must be a `reg'
215: expression with mode M.
216:
217: `(strict_low_part (subreg:M (reg:N R) 0))'
218: This expression code is used in only one context: operand 0 of a
219: `set' expression. In addition, the operand of this expression
220: must be a `subreg' expression.
221:
222: The presence of `strict_low_part' says that the part of the
223: register which is meaningful in mode N but is not part of
224: mode M is not to be altered. Normally, an assignment to such
225: a subreg is allowed to have undefined effects on the rest of the
226: register when M is less than a word.
227:
228:
229: File: internals Node: Side Effects, Prev: RTL Declarations, Up: RTL, Next: Incdec
230:
231: Side Effect Expressions
232: =======================
233:
234: The expression codes described so far represent values, not actions.
235: But machine instructions never produce values; they are meaningful
236: only for their side effects on the state of the machine. Special
237: expression codes are used to represent side effects.
238:
239: The body of an instruction is always one of these side effect codes;
240: the codes described above, which represent values, appear only as
241: the operands of these.
242:
243: `(set LVAL X)'
244: Represents the action of storing the value of X into the place
245: represented by LVAL. LVAL must be an expression
246: representing a place that can be stored in: `reg' (or
247: `subreg' or `strict_low_part'), `mem', `pc' or
248: `cc0'.
249:
250: If LVAL is a `reg', `subreg' or `mem', it has a
251: machine mode; then X must be valid for that mode.
252:
253: If LVAL is a `reg' whose machine mode is less than the full
254: width of the register, then it means that the part of the register
255: specified by the machine mode is given the specified value and the
256: rest of the register receives an undefined value. Likewise, if
257: LVAL is a `subreg' whose machine mode is narrower than
258: `SImode', the rest of the register can be changed in an undefined way.
259:
260: If LVAL is a `strict_low_part' of a `subreg', then the
261: part of the register specified by the machine mode of the
262: `subreg' is given the value X and the rest of the register
263: is not changed.
264:
265: If LVAL is `(cc0)', it has no machine mode, and X may
266: have any mode. This represents a "test" or "compare" instruction.
267:
268: If LVAL is `(pc)', we have a jump instruction, and the
269: possibilities for X are very limited. It may be a
270: `label_ref' expression (unconditional jump). It may be an
271: `if_then_else' (conditional jump), in which case either the
272: second or the third operand must be `(pc)' (for the case which
273: does not jump) and the other of the two must be a `label_ref'
274: (for the case which does jump). X may also be a `mem' or
275: `(plus:SI (pc) Y)', where Y may be a `reg' or a
276: `mem'; these unusual patterns are used to represent jumps through
277: branch tables.
278:
279: `(return)'
280: Represents a return from the current function, on machines where
281: this can be done with one instruction, such as Vaxen. On machines
282: where a multi-instruction "epilogue" must be executed in order
283: to return from the function, returning is done by jumping to a
284: label which precedes the epilogue, and the `return' expression
285: code is never used.
286:
287: `(call FUNCTION NARGS)'
288: Represents a function call. FUNCTION is a `mem' expression
289: whose address is the address of the function to be called. NARGS
290: is an expression representing the number of words of argument.
291:
292: Each machine has a standard machine mode which FUNCTION must
293: have. The machine descripion defines macro `FUNCTION_MODE' to
294: expand into the requisite mode name. The purpose of this mode is to
295: specify what kind of addressing is allowed, on machines where the
296: allowed kinds of addressing depend on the machine mode being
297: addressed.
298:
299: `(clobber X)'
300: Represents the storing or possible storing of an unpredictable,
301: undescribed value into X, which must be a `reg' or
302: `mem' expression.
303:
304: One place this is used is in string instructions that store standard
305: values into particular hard registers. It may not be worth the
306: trouble to describe the values that are stored, but it is essential
307: to inform the compiler that the registers will be altered, lest it
308: attempt to keep data in them across the string instruction.
309:
310: X may also be null---a null C pointer, no expression at all.
311: Such a `(clobber (null))' expression means that all memory
312: locations must be presumed clobbered.
313:
314: Note that the machine description classifies certain hard registers as
315: "call-clobbered". All function call instructions are assumed by
316: default to clobber these registers, so there is no need to use
317: `clobber' expressions to indicate this fact. Also, each function
318: call is assumed to have the potential to alter any memory location.
319:
320: `(use X)'
321: Represents the use of the value of X. It indicates that
322: the value in X at this point in the program is needed,
323: even though it may not be apparent whythis is so. Therefore, the
324: compiler will not attempt to delete instructions whose only
325: effect is to store a value in X. X must be a `reg'
326: expression.
327:
328: `(parallel [X0 X1 ...])'
329: Represents several side effects performed in parallel. The square
330: brackets stand for a vector; the operand of `parallel' is a
331: vector of expressions. X0, X1 and so on are individual
332: side effects---expressions of code `set', `call',
333: `return', `clobber' or `use'.
334:
335: "In parallel" means that first all the values used in
336: the individual side-effects are computed, and second all the actual
337: side-effects are performed. For example,
338:
339: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
340: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
341:
342: says unambiguously that the values of hard register 1 and the memory
343: location addressed by it are interchanged. In both places where
344: `(reg:SI 1)' appears as a memory address it refers to the value
345: in register 1 before the execution of the instruction.
346:
347: Three expression codes appear in place of a side effect, as the body
348: of an insn, though strictly speaking they do not describe side effects
349: as such:
350:
351: `(asm_input S)'
352: Represents literal assembler code as described by the string S.
353:
354: `(addr_vec:M [LR0 LR1 ...])'
355: Represents a table of jump addresses. LR0 etc. are
356: `label_ref' expressions. The mode M specifies how much
357: space is given to each address; normally M would be
358: `Pmode'.
359:
360: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
361: Represents a table of jump addresses expressed as offsets from
362: BASE. LR0 etc. are `label_ref' expressions and so is
363: BASE. The mode M specifies how much space is given to
364: each address-difference.
365:
366:
367: File: internals Node: Incdec, Prev: Side Effects, Up: RTL, Next: Insns
368:
369: Embedded Side-Effects on Addresses
370: ==================================
371:
372: Four special side-effect expression codes appear as memory addresses.
373:
374: `(pre_dec:M X)'
375: Represents the side effect of decrementing X by a standard
376: amount and represents also the value that X has after being
377: decremented. X must be a `reg' or `mem', but most
378: machines allow only a `reg'. M must be the machine mode
379: for pointers on the machine in use. The amount X is decrement
380: by is the length in bytes of the machine mode of the containing memory
381: reference of which this expression serves as the address. Here is an
382: example of its use:
383:
384: (mem:DF (pre_dec:SI (reg:SI 39)))
385:
386: This says to decrement pseudo register 39 by the length of a `DFmode'
387: value and use the result to address a `DFmode' value.
388:
389: `(pre_inc:M X)'
390: Similar, but specifies incrementing X instead of decrementing it.
391:
392: `(post_dec:M X)'
393: Represents the same side effect as `pre_decrement' but a different
394: value. The value represented here is the value X has before
395: being decremented.
396:
397: `(post_inc:M X)'
398: Similar, but specifies incrementing X instead of decrementing it.
399:
400: These embedded side effect expressions must be used with care. Instruction
401: patterns may not use them. Until the `flow' pass of the compiler,
402: they may occur only to represent pushes onto the stack. The `flow'
403: pass finds cases where registers are incremented or decremented in one
404: instruction and used as an address shortly before or after; these cases are
405: then transformed to use pre- or post-increment or -decrement.
406:
407: Explicit popping of the stack could be represented with these embedded
408: side effect operators, but that would not be safe; the instruction
409: combination pass could move the popping past pushes, thus changing
410: the meaning of the code.
411:
412: An instruction that can be represented with an embedded side effect
413: could also be represented using `parallel' containing an additional
414: `set' to describe how the address register is altered. This is not
415: done because machines that allow these operations at all typically
416: allow them wherever a memory address is called for. Describing them as
417: additional parallel stores would require doubling the number of entries
418: in the machine description.
419:
420:
421: File: internals Node: Insns, Prev: Incdec, Up: RTL, Next: Sharing
422:
423: Insns
424: =====
425:
426: The RTL representation of the code for a function is a doubly-linked
427: chain of objects called "insns". Insns are expressions with
428: special codes that are used for no other purpose. Some insns are
429: actual instructions; others represent dispatch tables for `switch'
430: statements; others represent labels to jump to or various sorts of
431: declaratory information.
432:
433: In addition to its own specific data, each insn must have a unique id number
434: that distinguishes it from all other insns in the current function, and
435: chain pointers to the preceding and following insns. These three fields
436: occupy the same position in every insn, independent of the expression code
437: of the insn. They could be accessed with `XEXP' and `XINT',
438: but instead three special macros are always used:
439:
440: `INSN_UID (I)'
441: Accesses the unique id of insn I.
442:
443: `PREV_INSN (I)'
444: Accesses the chain pointer to the insn preceding I.
445: If I is the first insn, this is a null pointer.
446:
447: `NEXT_INSN (I)'
448: Accesses the chain pointer to the insn following I.
449: If I is the last insn, this is a null pointer.
450:
451: The `NEXT_INSN' and `PREV_INSN' pointers must always
452: correspond: if I is not the first insn,
453:
454: NEXT_INSN (PREV_INSN (INSN)) == INSN
455:
456: is always true.
457:
458: Every insn has one of the following six expression codes:
459:
460: `insn'
461: The expression code `insn' is used for instructions that do not jump
462: and do not do function calls. Insns with code `insn' have four
463: additional fields beyond the three mandatory ones listed above.
464: These four are described in a table below.
465:
466: `jump_insn'
467: The expression code `jump_insn' is used for instructions that may jump
468: (or, more generally, may contain `label_ref' expressions).
469: `jump_insn' insns have the same extra fields as `insn' insns,
470: accessed in the same way.
471:
472: `call_insn'
473: The expression code `call_insn' is used for instructions that may do
474: function calls. It is important to distinguish these instructions because
475: they imply that certain registers and memory locations may be altered
476: unpredictably.
477:
478: `call_insn' insns have the same extra fields as `insn' insns,
479: accessed in the same way.
480:
481: `code_label'
482: A `code_label' insn represents a label that a jump insn can jump to.
483: It contains one special field of data in addition to the three standard ones.
484: It is used to hold the "label number", a number that identifies this
485: label uniquely among all the labels in the compilation (not just in the
486: current function). Ultimately, the label is represented in the assembler
487: output as an assembler label `LN' where N is the label number.
488:
489: `barrier'
490: Barriers are placed in the instruction stream after unconditional
491: jump instructions to indicate that the jumps are unconditional.
492: They contain no information beyond the three standard fields.
493:
494: `note'
495: `note' insns are used to represent additional debugging and
496: declaratory information. They contain two nonstandard fields, an
497: integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
498: string accessed with `NOTE_SOURCE_FILE'.
499:
500: If `NOTE_LINE_NUMBER' is positive, the note represents the
501: position of a source line and `NOTE_SOURCE_FILE' is the source file name
502: that the line came from. These notes control generation of line
503: number data in the assembler output.
504:
505: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
506: code with one of the following values (and `NOTE_SOURCE_FILE'
507: must contain a null pointer):
508:
509: `NOTE_INSN_DELETED'
510: Such a note is completely ignorable. Some passes of the compiler
511: delete insns by altering them into notes of this kind.
512:
513: `NOTE_INSN_BLOCK_BEG'
514: `NOTE_INSN_BLOCK_END'
515: These types of notes indicate the position of the beginning and end
516: of a level of scoping of variable names. They control the output
517: of debugging information.
518:
519: `NOTE_INSN_LOOP_BEG'
520: `NOTE_INSN_LOOP_END'
521: These types of notes indicate the position of the beginning and end
522: of a `while' or `for' loop. They enable the loop optimizer
523: to find loops quickly.
524:
525: Here is a table of the extra fields of `insn', `jump_insn'
526: and `call_insn' insns:
527:
528: `PATTERN (I)'
529: An expression for the side effect performed by this insn.
530:
531: `REG_NOTES (I)'
532: A list (chain of `expr_list' expressions) giving information
533: about the usage of registers in this insn. This list is set up by the
534: `flow' pass; it is a null pointer until then.
535:
536: `LOG_LINKS (I)'
537: A list (chain of `insn_list' expressions) of previous "related"
538: insns: insns which store into registers values that are used for the
539: first time in this insn. (An additional constraint is that neither a
540: jump nor a label may come between the related insns). This list is
541: set up by the `flow' pass; it is a null pointer until then.
542:
543: `INSN_CODE (I)'
544: An integer that says which pattern in the machine description matches
545: this insn, or -1 if the matching has not yet been attempted.
546:
547: Such matching is never attempted and this field is not used on an insn
548: whose pattern consists of a single `use', `clobber',
549: `asm', `addr_vec' or `addr_diff_vec' expression.
550:
551: The `LOG_LINKS' field of an insn is a chain of `insn_list'
552: expressions. Each of these has two operands: the first is an insn,
553: and the second is another `insn_list' expression (the next one in
554: the chain). The last `insn_list' in the chain has a null pointer
555: as second operand. The significant thing about the chain is which
556: insns apepar in it (as first operands of `insn_list'
557: expressions). Their order is not significant.
558:
559: The `REG_NOTES' field of an insn is a similar chain but of
560: `expr_list' expressions instead of `insn_list'. The first
561: operand is a `reg' rtx. Its presence in the list can have three
562: possible meanings, distinguished by a value that is stored in the
563: machine-mode field of the `expr_list' because that is a
564: conveniently available space, but that is not really a machine mode.
565: These values belong to the C type `enum reg_note' and there are
566: three of them:
567:
568: `REG_DEAD'
569: The `reg' listed dies in this insn; that is to say, altering
570: the value immediately after this insn would not affect the future
571: behavior of the program.
572:
573: `REG_INC'
574: The `reg' listed is incremented (or decremented; at this level
575: there is no distinction) by an embedded side effect inside this insn.
576:
577: `REG_CONST'
578: The `reg' listed has a value that could safely be replaced
579: everywhere by the value that this insn copies into it. ("Safety"
580: here refers to the data flow of the program; such replacement may
581: require reloading into registers for some of the insns in which
582: the `reg' is replaced.)
583:
584: `REG_WAS_0'
585: The `reg' listed contained zero before this insn. You can rely
586: on this note if it is present; its absence implies nothing.
587:
588: (The only difference between the expression codes `insn_list' and
589: `expr_list' is that the first operand of an `insn_list' is
590: assumed to be an insn and is printed in debugging dumps as the insn's
591: unique id; the first operand of an `expr_list' is printed in the
592: ordinary way as an expression.)
593:
594:
595: File: internals Node: Sharing, Prev: Insns, Up: RTL
596:
597: Structure Sharing Assumptions
598: =============================
599:
600: The compiler assumes that certain kinds of RTL expressions are unique;
601: there do not exist two distinct objects representing the same value.
602: In other cases, it makes an opposite assumption: that no RTL expression
603: object of a certain kind appears in more than one place in the
604: containing structure.
605:
606: These assumptions refer to a single function; except for the RTL
607: objects that describe global variables and external functions,
608: no RTL objects are common to two functions.
609:
610: * Each pseudo-register has only a single `reg' object to represent it,
611: and therefore only a single machine mode.
612:
613: * For any symbolic label, there is only one `symbol_ref' object
614: referring to it.
615:
616: * There is only one `const_int' expression with value zero,
617: and only one with value one.
618:
619: * There is only one `pc' expression.
620:
621: * There is only one `cc0' expression.
622:
623: * There is only one `const_double' expression with mode
624: `SFmode' and value zero, and only one with mode `DFmode' and
625: value zero.
626:
627: * No `label_ref' appears in more than one place in the RTL structure;
628: in other words, it is safe to do a tree-walk of all the insns in the function
629: and assume that each time a `label_ref' is seen it is distinct from all
630: other `label_refs' seen.
631:
632: * Aside from the cases listed above, the only kind of expression
633: object that may appear in more than one place is the `mem'
634: object that describes a stack slot or a static variable.
635:
636:
637: File: internals Node: Machine Desc, Prev: RTL, Up: Top, Next: Machine Macros
638:
639: Machine Descriptions
640: ********************
641:
642: A machine description has two parts: a file of instruction patterns
643: (`.md' file) and a C header file of macro definitions.
644:
645: The `.md' file for a target machine contains a pattern for each
646: instruction that the target machine supports (or at least each instruction
647: that is worth telling the compiler about). It may also contain comments.
648: A semicolon causes the rest of the line to be a comment, unless the semicolon
649: is inside a quoted string.
650:
651: See the next chapter for information on the C header file.
652:
653: * Menu:
654:
655: * Patterns:: How to write instruction patterns.
656: * Example:: Example of an instruction pattern.
657: * Constraints:: When not all operands are general operands.
658: * Standard Names:: Names mark patterns to use for code generation.
659: * Dependent Patterns:: Having one pattern may make you need another.
660:
661:
662: File: internals Node: Patterns, Prev: Machine Desc, Up: Machine Desc, Next: Example
663:
664: Instruction Patterns
665: ====================
666:
667: Each instruction pattern contains an incomplete RTL expression, with pieces
668: to be filled in later, operand constraints that restrict how the pieces can
669: be filled in, and an output pattern or C code to generate the assembler
670: output, all wrapped up in a `define_insn' expression.
671:
672: Sometimes an insn can match more than one instruction pattern. Then the
673: pattern that appears first in the machine description is the one used.
674: Therefore, more specific patterns should usually go first in the
675: description.
676:
677: The `define_insn' expression contains four operands:
678:
679: 1. An optional name. The presence of a name indicate that this instruction
680: pattern can perform a certain standard job for the RTL-generation
681: pass of the compiler. This pass knows certain names and will use
682: the instruction patterns with those names, if the names are defined
683: in the machine description.
684:
685: The absence of a name is indicated by writing an empty string
686: where the name should go. Nameless instruction patterns are never
687: used for generating RTL code, but they may permit several simpler insns
688: to be combined later on.
689:
690: Names that are not thus known and used in RTL-generation have no
691: effect; they are equivalent to no name at all.
692:
693: 2. The recognition template. This is a vector of incomplete RTL
694: expressions which show what the instruction should look like. It is
695: incomplete because it may contain `match_operand' and
696: `match_dup' expressions that stand for operands of the
697: instruction.
698:
699: If the vector has only one element, that element is what the
700: instruction should look like. If the vector has multiple elements,
701: then the instruction looks like a `parallel' expression
702: containing that many elements as described.
703:
704: 3. A condition. This is a string which contains a C expression that is
705: the final test to decide whether an insn body matches this pattern.
706:
707: For a named pattern, the condition (if present) may not depend on
708: the data in the insn being matched, but only the target-machine-type
709: flags. The compiler needs to test these conditions during
710: initialization in order to learn exactly which named instructions are
711: available in a particular run.
712:
713: For nameless patterns, the condition is applied only when matching an
714: individual insn, and only after the insn has matched the pattern's
715: recognition template. The insn's operands may be found in the vector
716: `operands'.
717:
718: 4. A string that says how to output matching insns as assembler code. In
719: the simpler case, the string is an output template, much like a
720: `printf' control string. `%' in the string specifies where
721: to insert the operands of the instruction; the `%' is followed by
722: a single-digit operand number.
723:
724: `%cDIGIT' can be used to subtitute an operand that is a
725: constant value without the syntax that normally indicates an immediate
726: operand.
727:
728: `%aDIGIT' can be used to substitute an operand as if it
729: were a memory reference, with the actual operand treated as the address.
730: This may be useful when outputting a "load address" instruction,
731: because often the assembler syntax for such an instruction requires
732: you to write the operand as if it were a memory reference.
733:
734: The template may generate multiple assembler instructions.
735: Write the text for the instructions, with `\;' between them.
736:
737: If the output control string starts with a `*', then it is not an
738: output template but rather a piece of C program that should compute a
739: template. It should execute a `return' statement to return the
740: template-string you want. Most such templates use C string literals,
741: which require doublequote characters to delimit them. To include
742: these doublequote characters in the string, prefix each one with
743: `\'.
744:
745: The operands may be found in the array `operands', whose C
746: data type is `rtx []'.
747:
748: It is possible to output an assembler instruction and then go on to
749: output or compute more of them, using the subroutine
750: `output_asm_insn'. This receives two arguments: a
751: template-string and a vector of operands. The vector may be
752: `operands', or it may be another array of `rtx' that you
753: declare locally and initialize yourself.
754:
755: The recognition template is used also, for named patterns, for
756: constructing insns. Construction involves substituting specified
757: operands into a copy of the template. Matching involves determining
758: the values that serve as the operands in the insn being matched. Both
759: of these activities are controlled by two special expression types
760: that direct matching and substitution of the operands.
761:
762: `(match_operand:M N TESTFN CONSTRAINT)'
763: This expression is a placeholder for operand number N of
764: the insn. When constructing an insn, operand number N
765: will be substituted at this point. When matching an insn, whatever
766: appears at this position in the insn will be taken as operand
767: number N; but it must satisfy TESTFN or this instruction
768: pattern will not match at all.
769:
770: Operand numbers must be chosen consecutively counting from zero in
771: each instruction pattern. There may be only one `match_operand'
772: expression in the pattern for each expression number, and they must
773: appear in order of increasing expression number.
774:
775: TESTFN is a string that is the name of a C function that accepts
776: two arguments, a machine mode and an expression. During matching,
777: the function will be called with M as the mode argument
778: and the putative operand as the other argument. If it returns zero,
779: this instruction pattern fails to match. TESTFN may be
780: an empty string; then it means no test is to be done on the operand.
781:
782: Most often, TESTFN is `"general_operand"'. It checks
783: that the putative operand is either a constant, a register or a
784: memory reference, and that it is valid for mode M.
785:
786: CONSTRAINT is explained later.
787:
788: `(match_dup N)'
789: This expression is also a placeholder for operand number N.
790: It is used when the operand needs to appear more than once in the
791: insn.
792:
793: In construction, `match_dup' behaves exactly like
794: MATCH_OPERAND: the operand is substituted into the insn being
795: constructed. But in matching, `match_dup' behaves differently.
796: It assumes that operand number N has already been determined by
797: a `match_operand' apparing earlier in the recognition template,
798: and it matches only an identical-looking expression.
799:
800: `(address (match_operand:M N "address_operand" ""))'
801: This complex of expressions is a placeholder for an operand number
802: N in a "load address" instruction: an operand which specifies
803: a memory location in the usual way, but for which the actual operand
804: value used is the address of the location, not the contents of the
805: location.
806:
807: `address' expressions never appear in RTL code, only in machine
808: descriptions. And they are used only in machine descriptions that do
809: not use the operand constraint feature. When operand constraints are
810: in use, the letter `p' in the constraint serves this purpose.
811:
812: M is the machine mode of the *memory location being
813: addressed*, not the machine mode of the address itself. That mode is
814: always the same on a given target machine (it is `Pmode', which
815: normally is `SImode'), so there is no point in mentioning it;
816: thus, no machine mode is written in the `address' expression. If
817: some day support is added for machines in which addresses of different
818: kinds of objects appear differently or are used differently (such as
819: the PDP-10), different formats would perhaps need different machine
820: modes and these modes might be written in the `address'
821: expression.
822:
823:
824: File: internals Node: Example, Prev: Patterns, Up: Machine Desc, Next: Constraints
825:
826: Example of `define_insn'
827: ========================
828:
829: Here is an actual example of an instruction pattern, for the 68000/68020.
830:
831: (define_insn "tstsi"
832: [(set (cc0)
833: (match_operand:SI 0 "general_operand" "rm"))]
834: ""
835: "*
836: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
837: return \"tstl %0\";
838: return \"cmpl #0,%0\"; }")
839:
840: This is an instruction that sets the condition codes based on the value of
841: a general operand. It has no condition, so any insn whose RTL description
842: has the form shown may be handled according to this pattern. The name
843: `tstsi' means "test a `SImode' value" and tells the RTL generation
844: pass that, when it is necessary to test such a value, an insn to do so
845: can be constructed using this pattern.
846:
847: The output control string is a piece of C code which chooses which
848: output template to return based on the kind of operand and the specific
849: type of CPU for which code is being generated.
850:
851: `"rm"' is an operand constraint. Its meaning is explained below.
852:
853:
854: File: internals Node: Constraints, Prev: Example, Up: Machine Desc, Next: Standard Names
855:
856: Operand Constraints
857: ===================
858:
859: Each `match_operand' in an instruction pattern can specify a
860: constraint for the type of operands allowed. Constraints can say whether
861: an operand may be in a register, and which kinds of register; whether the
862: operand can be a memory reference, and which kinds of address; whether the
863: operand may be an immediate constant, and which possible values it may
864: have. Constraints can also require two operands to match.
865:
866: * Menu:
867:
868: * Simple Constraints:: Basic use of constraints.
869: * Multi-alternative:: When an insn has two alternative constraint-patterns.
870: * Class Preferences:: Constraints guide which hard register to put things in.
871: * Modifiers:: More precise control over effects of constraints.
872: * No Constraints:: Describing a clean machine without constraints.
873:
874:
875: File: internals Node: Simple Constraints, Prev: Constraints, Up: Constraints, Next: Multi-Alternative
876:
877: Simple Constraints
878: ------------------
879:
880: The simplest kind of constraint is a string full of letters, each of
881: which describes one kind of operand that is permitted. Here are
882: the letters that are allowed:
883:
884: `m'
885: A memory operand is allowed, with any kind of address that the machine
886: supports in general.
887:
888: `o'
889: A memory operand is allowed, but only if the address is "offsetable".
890: This means that adding a small integer (actually, the width in bytes of the
891: operand, as determined by its machine mode) may be added to the address
892: and the result is also a valid memory address. For example, an address
893: which is constant is offsetable; so is an address that is the sum of
894: a register and a constant (as long as a slightly larger constant is also
895: within the range of address-offsets supported by the machine); but an
896: autoincrement or autodecrement address is not offsetable. More complicated
897: indirect/indexed addresses may or may not be offsetable depending on the
898: other addressing modes that the machine supports.
899:
900: `<'
901: A memory operand with autodecrement addressing (either predecrement or
902: postdecrement) is allowed.
903:
904: `>'
905: A memory operand with autoincrement addressing (either preincrement or
906: postincrement) is allowed.
907:
908: `r'
909: A register operand is allowed provided that it is in a general register.
910:
911: `d'
912: `a'
913: `f'
914: `...'
915: Other letters can be defined in machine-dependent fashion to stand for
916: particular classes of registers. `d', `a' and `f' are
917: defined on the 68000/68020 to stand for data, address and floating point
918: registers.
919:
920: `i'
921: An immediate integer operand (one with constant value) is allowed.
922:
923: `I'
924: `J'
925: `K'
926: `...'
927: Other letters in the range `I' through `M' may be defined in a
928: machine-dependent fashion to permit immediate integer operands with
929: explicit integer values in specified ranges. For example, on the 68000,
930: `I' is defined to stand for the range of values 1 to 8. This is the
931: range permitted as a shift count in the shift instructions.
932:
933: `F'
934: An immediate floating operand (expression code `const_double') is
935: allowed.
936:
937: `G'
938: `H'
939: `G' and `H' may be defined in a machine-dependent fashion to
940: permit immediate floating operands in particular ranges of values.
941:
942: `s'
943: An immediate integer operand whose value is not an explicit integer is
944: allowed. This might appear strange; if an insn allows a constant operand
945: with a value not known at compile time, it certainly must allow any known
946: value. So why use `s' instead of `i'? Sometimes it allows
947: better code to be generated. For example, on the 68000 in a fullword
948: instruction it is possible to use an immediate operand; but if the
949: immediate value is between -32 and 31, better code results from loading the
950: value into a register and using the register. This is because the load
951: into the register can be done with a `moveq' instruction. We arrange
952: for this to happen by defining the letter `K' to mean "any integer
953: outside the range -32 to 31", and then specifying `Ks' in the operand
954: constraints.
955:
956: `g'
957: Any register, memory or immediate integer operand is allowed, except for
958: registers that are not general registers.
959:
960: `N, a digit'
961: An operand identical to operand number N is allowed.
962: If a digit is used together with letters, the digit should come last.
963:
964: `p'
965: An operand that is a valid memory address is allowed. This is
966: for "load address" and "push address" instructions.
967:
968: If `p' is used in the constraint, the test-function in the
969: `match_operand' must be `address_operand'.
970:
971: In order to have valid assembler code, each operand must satisfy
972: its constraint. But a failure to do so does not prevent the pattern
973: from applying to an insn. Instead, it directs the compiler to modify
974: the code such that the constraint will be satisfied. Usually this is
975: done by copying an operand into a register.
976:
977: Contrast, therefore, the two instruction patterns that follow:
978:
979: (define_insn ""
980: [(set (match_operand:SI 0 "general_operand" "r")
981: (plus:SI (match_dup 0)
982: (match_operand:SI 1 "general_operand" "r")))]
983: ""
984: "...")
985:
986: which has two operands, one of which must appear in two places, and
987:
988: (define_insn ""
989: [(set (match_operand:SI 0 "general_operand" "r")
990: (plus:SI (match_operand:SI 1 "general_operand" "0")
991: (match_operand:SI 2 "general_operand" "r")))]
992: ""
993: "...")
994:
995: which has three operands, two of which are required by a constraint to be
996: identical. If we are considering an insn of the form
997:
998: (insn N PREV NEXT
999: (set (reg:SI 3)
1000: (plus:SI (reg:SI 6) (reg:SI 109)))
1001: ...)
1002:
1003: the first pattern would not apply at all, because this insn does not
1004: contain two identical subexpressions in the right place. The pattern would
1005: say, "That does not look like an add instruction; try other patterns."
1006: The second pattern would say, "Yes, that's an add instruction, but there
1007: is something wrong with it." It would direct the reload pass of the
1008: compiler to generate additional insns to make the constraint true. The
1009: results might look like this:
1010:
1011: (insn N2 PREV N
1012: (set (reg:SI 3) (reg:SI 6))
1013: ...)
1014:
1015: (insn N N2 NEXT
1016: (set (reg:SI 3)
1017: (plus:SI (reg:SI 3) (reg:SI 109)))
1018: ...)
1019:
1020: Because insns that don't fit the constraints are fixed up by loading
1021: operands into registers, every instruction pattern's constraints must
1022: permit the case where all the operands are in registers. It need not
1023: permit all classes of registers; the compiler knows how to copy registers
1024: into other registers of the proper class in order to make an instruction
1025: valid. But if no registers are permitted, the compiler will be stymied: it
1026: does not know how to save a register in memory in order to make an
1027: instruction valid. Instruction patterns that reject registers can be
1028: made valid by attaching a condition-expression that refuses to match
1029: an insn at all if the crucial operand is a register.
1030:
1031:
1032: File: internals Node: Multi-Alternative, Prev: Simple Constraints, Up: Constraints, Next: Class Preferences
1033:
1034: Multiple Alternative Constraints
1035: --------------------------------
1036:
1037: Sometimes a single instruction has multiple alternative sets of possible
1038: operands. For example, on the 68000, a logical-or instruction can combine
1039: register or an immediate value into memory, or it can combine any kind of
1040: operand into a register; but it cannot combine one memory location into
1041: another.
1042:
1043: These constraints are represented as multiple alternatives. An alternative
1044: can be described by a series of letters for each operand. The overall
1045: constraint for an operand is made from the letters for this operand
1046: from the first alternative, a comma, the letters for this operand from
1047: the second alternative, a comma, and so on until the last alternative.
1048: Here is how it is done for fullword logical-or on the 68000:
1049:
1050: (define_insn "iorsi3"
1051: [(set (match_operand:SI 0 "general_operand" "=%m,d")
1052: (ior:SI (match_operand:SI 1 "general_operand" "0,0")
1053: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
1054: ...)
1055:
1056: The first alternative has `m' (memory) for operand 0, `0' for
1057: operand 1 (meaning it must match operand 0), and `dKs' for operand 2.
1058: The second alternative has `d' (data register) for operand 0, `0'
1059: for operand 1, and `dmKs' for operand 2. The `=' and `%' in
1060: the constraint for operand 0 are not part of any alternative; their meaning
1061: is explained in the next section.
1062:
1063: If all the operands fit any one alternative, the instruction is valid.
1064: Otherwise, for each alternative, the compiler counts how many instructions
1065: must be added to copy the operands so that that alternative applies.
1066: The alternative requiring the least copying is chosen. If two alternatives
1067: need the same amount of copying, the one that comes first is chosen.
1068: These choices can be altered with the `?' and `!' characters:
1069:
1070: `?'
1071: Disparage slightly the alternative that the `?' appears in,
1072: as a choice when no alternative applies exactly. The compiler regards
1073: this alternative as one unit more costly for each `?' that appears
1074: in it.
1075:
1076: `!'
1077: Disparage severely the alternative that the `!' appears in.
1078: When operands must be copied into registers, the compiler will
1079: never choose this alternative as the one to strive for.
1080:
1081:
1082: File: internals Node: Class Preferences, Prev: Multi-Alternative, Up: Constraints, Next: Modifiers
1083:
1084: Register Class Preferences
1085: --------------------------
1086:
1087: The operand constraints have another function: they enable the compiler
1088: to decide which kind of hardware register a pseudo register is best
1089: allocated to. The compiler examines the constraints that apply to the
1090: insns that use the pseudo register, looking for the machine-dependent
1091: letters such as `d' and `a' that specify classes of registers.
1092: The pseudo register is put in whichever class gets the most "votes".
1093: The constraint letters `g' and `r' also vote: they vote in
1094: favor of a general register. The machine description says which registers
1095: are considered general.
1096:
1097: Of course, on some machines all registers are equivalent, and no register
1098: classes are defined. Then none of this complexity is relevant.
1099:
1100:
1101: File: internals Node: Modifiers, Prev: Class Preferences, Up: Constraints, Next: No Constraints
1102:
1103: Constraint Modifier Characters
1104: ------------------------------
1105:
1106: `='
1107: Means that this operand is written by the instruction, but its previous
1108: value is not used.
1109:
1110: `+'
1111: Means that this operand is both read and written by the instruction.
1112:
1113: When the compiler fixes up the operands to satisfy the constraints,
1114: it needs to know which operands are inputs to the instruction and
1115: which are outputs from it. `=' identifies an output; `+'
1116: identifies an operand that is both input and output; all other operands
1117: are assumed to be input only.
1118:
1119: `%'
1120: Declares the instruction to be commutative for operands 1 and 2.
1121: This means that the compiler may interchange operands 1 and 2
1122: if that will make the operands fit their constraints.
1123:
1124: `#'
1125: Says that all following characters, up to the next comma, are to be ignored
1126: as a constraint. They are significant only for choosing register preferences.
1127:
1128: `*'
1129: Says that the following character should be ignored when choosing
1130: register preferences. `*' has no effect on the meaning of
1131: the constraint as a constraint.
1132:
1133:
1134: File: internals Node: No Constraints, Prev: Modifiers, Up: Constraints
1135:
1136: Not Using Constraints
1137: ---------------------
1138:
1139: Some machines are so clean that operand constraints are not required. For
1140: example, on the Vax, an operand valid in one context is valid in any other
1141: context. On such a machine, every operand constraint would be `"g"',
1142: excepting only operands of "load address" instructions which are
1143: written as if they referred to a memory location's contents but actual
1144: refer to its address. They would have constraint `"p"'.
1145:
1146: For such machines, instead of writing `"g"' and `"p"' for all
1147: the constraints, you can choose to write a description with empty constraints.
1148: Then you write `""' for the constraint in every `match_operand'.
1149: Address operands are identified by writing an `address' expression
1150: around the `match_operand', not by their constraints.
1151:
1152: When the machine description has just empty constraints, certain parts
1153: of compilation are skipped, making the compiler faster.
1154:
1155:
1156: File: internals Node: Standard Names, Prev: Constraints, Up: Machine Desc, Next: Dependent Patterns
1157:
1158: Standard Insn Names
1159: ===================
1160:
1161: Here is a table of the instruction names that are meaningful in the RTL
1162: generation pass of the compiler. Giving one of these names to an
1163: instruction pattern tells the RTL generation pass that it can use the
1164: pattern in to accomplish a certain task.
1165:
1166: `movM'
1167: Here M is a two-letter machine mode name, in lower case. This
1168: instruction pattern moves data with that machine mode from operand 1 to
1169: operand 0. For example, `movsi' moves full-word data.
1170:
1171: If operand 0 is a `subreg' with mode M of a register whose
1172: natural mode is wider than M, the effect of this instruction is
1173: to store the specified value in the part of the register that corresponds
1174: to mode M. The effect on the rest of the register is undefined.
1175:
1176: `movstrictM'
1177: Like `movM' except that if operand 0 is a `subreg'
1178: with mode M of a register whose natural mode is wider,
1179: the `movstrictM' instruction is guaranteed not to alter
1180: any of the register except the part which belongs to mode M.
1181:
1182: `addM3'
1183: Add operand 2 and operand 1, storing the result in operand 0. All operands
1184: must have mode M. This can be used even on two-address machines, by
1185: means of constraints requiring operands 1 and 0 to be the same location.
1186:
1187: `subM3'
1188: `mulM3'
1189: `umulM3'
1190: `divM3'
1191: `udivM3'
1192: `modM3'
1193: `umodM3'
1194: `andM3'
1195: `iorM3'
1196: `xorM3'
1197: Similar, for other arithmetic operations.
1198:
1199: `andcbM3'
1200: Bitwise logical-and operand 1 with the complement of operand 2
1201: and store the result in operand 0.
1202:
1203: `mulhisi3'
1204: Multiply operands 1 and 2, which have mode `HImode', and store
1205: a `SImode' product in operand 0.
1206:
1207: `mulqihi3'
1208: `mulsidi3'
1209: Similar widening-multiplication instructions of other widths.
1210:
1211: `umulqihi3'
1212: `umulhisi3'
1213: `umulsidi3'
1214: Similar widening-multiplication instructions that do unsigned
1215: multiplication.
1216:
1217: `divmodM4'
1218: Signed division that produces both a quotient and a remainder.
1219: Operand 1 is divided by operand 2 to produce a quotient stored
1220: in operand 0 and a remainder stored in operand 3.
1221:
1222: `udivmodM4'
1223: Similar, but does unsigned division.
1224:
1225: `divmodMN4'
1226: Like `divmodM4' except that only the dividend has mode
1227: M; the divisor, quotient and remainder have mode N.
1228: For example, the Vax has a `divmoddisi4' instruction
1229: (but it is omitted from the machine description, because it
1230: is so slow that it is faster to compute remainders by the
1231: circumlocution that the compiler will use if this instruction is
1232: not available).
1233:
1234: `ashlM3'
1235: Arithmetic-shift operand 1 left by a number of bits specified by
1236: operand 2, and store the result in operand 0. Operand 2 has
1237: mode `SImode', not mode M.
1238:
1239: `ashrM3'
1240: `lshlM3'
1241: `lshrM3'
1242: `rotlM3'
1243: `rotrM3'
1244: Other shift and rotate instructions.
1245:
1246: `negM2'
1247: Negate operand 1 and store the result in operand 0.
1248:
1249: `absM2'
1250: Store the absolute value of operand 1 into operand 0.
1251:
1252: `sqrtM2'
1253: Store the square root of operand 1 into operand 0.
1254:
1255: `one_cmplM2'
1256: Store the bitwise-complement of operand 1 into operand 0.
1257:
1258: `cmpM'
1259: Compare operand 0 and operand 1, and set the condition codes.
1260:
1261: `tstM'
1262: Compare operand 0 against zero, and set the condition codes.
1263:
1264: `movstrM'
1265: Block move instruction. The addresses of the destination and source
1266: strings are the first two operands, and both are in mode `Pmode'.
1267: The number of bytes to move is the third operand, in mode M.
1268:
1269: `cmpstrM'
1270: Block compare instruction, with operands like `movstrM'
1271: except that the two memory blocks are compared byte by byte
1272: in lexicographic order. The effect of the instruction is to set
1273: the condition codes.
1274:
1275: `floatMN2'
1276: Convert operand 1 (valid for floating point mode M) to fixed
1277: point mode N and store in operand 0 (which has mode N).
1278:
1279: `fixMN2'
1280: Convert operand 1 (valid for fixed point mode M) to floating
1281: point mode N and store in operand 0 (which has mode N).
1282:
1283: `truncMN'
1284: Truncate operand 1 (valid for mode M) to mode N and
1285: store in operand 0 (which has mode N). Both modes must be fixed
1286: point or both floating point.
1287:
1288: `extendMN'
1289: Sign-extend operand 1 (valid for mode M) to mode N and
1290: store in operand 0 (which has mode N). Both modes must be fixed
1291: point or both floating point.
1292:
1293: `zero_extendMN'
1294: Zero-extend operand 1 (valid for mode M) to mode N and
1295: store in operand 0 (which has mode N). Both modes must be fixed
1296: point.
1297:
1298: `extv'
1299: Extract a bit-field from operand 1 (a register or memory operand),
1300: where operand 2 specifies the width in bits and operand 3 the starting
1301: bit, and store it in operand 0. Operand 0 must have `Simode'.
1302: Operand 1 may have mode `QImode' or `SImode'; often
1303: `SImode' is allowed only for registers. Operands 2 and 3 must be
1304: valid for `SImode'.
1305:
1306: The RTL generation pass generates this instruction only with constants
1307: for operands 2 and 3.
1308:
1309: The bit-field value is sign-extended to a full word integer
1310: before it is stored in operand 0.
1311:
1312: `extzv'
1313: Like `extv' except that the bit-field value is zero-extended.
1314:
1315: `insv'
1316: Store operand 3 (which must be valid for `SImode') into a
1317: bit-field in operand 0, where operand 1 specifies the width in bits
1318: and operand 2 the starting bit. Operand 0 may have mode `QImode'
1319: or `SImode'; often `SImode' is allowed only for registers.
1320: Operands 1 and 2 must be valid for `SImode'.
1321:
1322: The RTL generation pass generates this instruction only with constants
1323: for operands 1 and 2.
1324:
1325: `sCONDM'
1326: Store zero or -1 in the operand (with mode M) according to the
1327: condition codes. Value stored is -1 iff the condition COND is
1328: true. COND is the name of a comparison operation rtx code, such
1329: as `eq', `lt' or `leu'.
1330:
1331: `bCOND'
1332: Conditional branch instruction. Operand 0 is a `label_ref'
1333: that refers to the label to jump to. Jump if the condition codes
1334: meet condition COND.
1335:
1336: `call'
1337: Subroutine call instruction. Operand 1 is the number of arguments
1338: and operand 0 is the function to call. Operand 1 should be a `mem'
1339: rtx whose address is the address of the function.
1340:
1341: `return'
1342: Subroutine return instruction. This instruction pattern name should be
1343: defined only if a single instruction can do all the work of returning
1344: from a function.
1345:
1346: `tablejump'
1347: `caseM'
1348:
1349:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.