![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rtl.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to rtl.texi CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 root 1: @c Copyright (C) 1988, 1989, 1992, 1994 Free Software Foundation, Inc.
1.1 root 2: @c This is part of the GCC manual.
3: @c For copying conditions, see the file gcc.texi.
4:
1.1.1.3 root 5: @node RTL
1.1 root 6: @chapter RTL Representation
7: @cindex RTL representation
8: @cindex representation of RTL
9: @cindex Register Transfer Language (RTL)
10:
11: Most of the work of the compiler is done on an intermediate representation
12: called register transfer language. In this language, the instructions to be
13: output are described, pretty much one by one, in an algebraic form that
14: describes what the instruction does.
15:
16: RTL is inspired by Lisp lists. It has both an internal form, made up of
17: structures that point at other structures, and a textual form that is used
18: in the machine description and in printed debugging dumps. The textual
19: form uses nested parentheses to indicate the pointers in the internal form.
20:
21: @menu
22: * RTL Objects:: Expressions vs vectors vs strings vs integers.
23: * Accessors:: Macros to access expression operands or vector elts.
24: * Flags:: Other flags in an RTL expression.
25: * Machine Modes:: Describing the size and format of a datum.
26: * Constants:: Expressions with constant values.
27: * Regs and Memory:: Expressions representing register contents or memory.
28: * Arithmetic:: Expressions representing arithmetic on other expressions.
29: * Comparisons:: Expressions representing comparison of expressions.
1.1.1.5 root 30: * Bit Fields:: Expressions representing bitfields in memory or reg.
1.1 root 31: * Conversions:: Extending, truncating, floating or fixing.
32: * RTL Declarations:: Declaring volatility, constancy, etc.
33: * Side Effects:: Expressions for storing in registers, etc.
34: * Incdec:: Embedded side-effects for autoincrement addressing.
35: * Assembler:: Representing @code{asm} with operands.
36: * Insns:: Expression types for entire insns.
37: * Calls:: RTL representation of function call insns.
38: * Sharing:: Some expressions are unique; others *must* be copied.
1.1.1.5 root 39: * Reading RTL:: Reading textual RTL from a file.
1.1 root 40: @end menu
41:
42: @node RTL Objects, Accessors, RTL, RTL
43: @section RTL Object Types
44: @cindex RTL object types
45:
46: @cindex RTL integers
47: @cindex RTL strings
48: @cindex RTL vectors
49: @cindex RTL expression
50: @cindex RTX (See RTL)
1.1.1.4 root 51: RTL uses five kinds of objects: expressions, integers, wide integers,
52: strings and vectors. Expressions are the most important ones. An RTL
53: expression (``RTX'', for short) is a C structure, but it is usually
54: referred to with a pointer; a type that is given the typedef name
55: @code{rtx}.
1.1 root 56:
57: An integer is simply an @code{int}; their written form uses decimal digits.
1.1.1.4 root 58: A wide integer is an integral object whose type is @code{HOST_WIDE_INT}
1.1.1.5 root 59: (@pxref{Config}); their written form uses decimal digits.
1.1 root 60:
61: A string is a sequence of characters. In core it is represented as a
62: @code{char *} in usual C fashion, and it is written in C syntax as well.
63: However, strings in RTL may never be null. If you write an empty string in
64: a machine description, it is represented in core as a null pointer rather
65: than as a pointer to a null character. In certain contexts, these null
66: pointers instead of strings are valid. Within RTL code, strings are most
67: commonly found inside @code{symbol_ref} expressions, but they appear in
68: other contexts in the RTL expressions that make up machine descriptions.
69:
70: A vector contains an arbitrary number of pointers to expressions. The
71: number of elements in the vector is explicitly present in the vector.
72: The written form of a vector consists of square brackets
73: (@samp{[@dots{}]}) surrounding the elements, in sequence and with
74: whitespace separating them. Vectors of length zero are not created;
75: null pointers are used instead.
76:
77: @cindex expression codes
78: @cindex codes, RTL expression
79: @findex GET_CODE
80: @findex PUT_CODE
81: Expressions are classified by @dfn{expression codes} (also called RTX
82: codes). The expression code is a name defined in @file{rtl.def}, which is
83: also (in upper case) a C enumeration constant. The possible expression
84: codes and their meanings are machine-independent. The code of an RTX can
85: be extracted with the macro @code{GET_CODE (@var{x})} and altered with
86: @code{PUT_CODE (@var{x}, @var{newcode})}.
87:
88: The expression code determines how many operands the expression contains,
89: and what kinds of objects they are. In RTL, unlike Lisp, you cannot tell
90: by looking at an operand what kind of object it is. Instead, you must know
91: from its context---from the expression code of the containing expression.
92: For example, in an expression of code @code{subreg}, the first operand is
93: to be regarded as an expression and the second operand as an integer. In
94: an expression of code @code{plus}, there are two operands, both of which
95: are to be regarded as expressions. In a @code{symbol_ref} expression,
96: there is one operand, which is to be regarded as a string.
97:
98: Expressions are written as parentheses containing the name of the
99: expression type, its flags and machine mode if any, and then the operands
100: of the expression (separated by spaces).
101:
102: Expression code names in the @samp{md} file are written in lower case,
103: but when they appear in C code they are written in upper case. In this
104: manual, they are shown as follows: @code{const_int}.
105:
106: @cindex (nil)
107: @cindex nil
108: In a few contexts a null pointer is valid where an expression is normally
109: wanted. The written form of this is @code{(nil)}.
110:
111: @node Accessors, Flags, RTL Objects, RTL
112: @section Access to Operands
113: @cindex accessors
114: @cindex access to operands
115: @cindex operand access
116:
117: @cindex RTL format
1.1.1.4 root 118: For each expression type @file{rtl.def} specifies the number of
119: contained objects and their kinds, with four possibilities: @samp{e} for
120: expression (actually a pointer to an expression), @samp{i} for integer,
121: @samp{w} for wide integer, @samp{s} for string, and @samp{E} for vector
122: of expressions. The sequence of letters for an expression code is
123: called its @dfn{format}. Thus, the format of @code{subreg} is
124: @samp{ei}.@refill
1.1 root 125:
126: @cindex RTL format characters
127: A few other format characters are used occasionally:
128:
129: @table @code
130: @item u
131: @samp{u} is equivalent to @samp{e} except that it is printed differently
132: in debugging dumps. It is used for pointers to insns.
133:
134: @item n
135: @samp{n} is equivalent to @samp{i} except that it is printed differently
136: in debugging dumps. It is used for the line number or code number of a
137: @code{note} insn.
138:
139: @item S
140: @samp{S} indicates a string which is optional. In the RTL objects in
141: core, @samp{S} is equivalent to @samp{s}, but when the object is read,
142: from an @samp{md} file, the string value of this operand may be omitted.
143: An omitted string is taken to be the null string.
144:
145: @item V
146: @samp{V} indicates a vector which is optional. In the RTL objects in
147: core, @samp{V} is equivalent to @samp{E}, but when the object is read
148: from an @samp{md} file, the vector value of this operand may be omitted.
149: An omitted vector is effectively the same as a vector of no elements.
150:
151: @item 0
152: @samp{0} means a slot whose contents do not fit any normal category.
153: @samp{0} slots are not printed at all in dumps, and are often used in
154: special ways by small parts of the compiler.
155: @end table
156:
157: There are macros to get the number of operands, the format, and the
158: class of an expression code:
159:
160: @table @code
161: @findex GET_RTX_LENGTH
162: @item GET_RTX_LENGTH (@var{code})
163: Number of operands of an RTX of code @var{code}.
164:
165: @findex GET_RTX_FORMAT
166: @item GET_RTX_FORMAT (@var{code})
167: The format of an RTX of code @var{code}, as a C string.
168:
169: @findex GET_RTX_CLASS
170: @cindex classes of RTX codes
171: @item GET_RTX_CLASS (@var{code})
172: A single character representing the type of RTX operation that code
173: @var{code} performs.
174:
175: The following classes are defined:
176:
177: @table @code
178: @item o
179: An RTX code that represents an actual object, such as @code{reg} or
180: @code{mem}. @code{subreg} is not in this class.
181:
182: @item <
183: An RTX code for a comparison. The codes in this class are
184: @code{NE}, @code{EQ}, @code{LE}, @code{LT}, @code{GE}, @code{GT},
185: @code{LEU}, @code{LTU}, @code{GEU}, @code{GTU}.@refill
186:
187: @item 1
188: An RTX code for a unary arithmetic operation, such as @code{neg}.
189:
190: @item c
191: An RTX code for a commutative binary operation, other than @code{NE}
192: and @code{EQ} (which have class @samp{<}).
193:
194: @item 2
195: An RTX code for a noncommutative binary operation, such as @code{MINUS}.
196:
197: @item b
1.1.1.5 root 198: An RTX code for a bitfield operation, either @code{ZERO_EXTRACT} or
199: @code{SIGN_EXTRACT}.
1.1 root 200:
201: @item 3
202: An RTX code for other three input operations, such as @code{IF_THEN_ELSE}.
203:
204: @item i
205: An RTX code for a machine insn (@code{INSN}, @code{JUMP_INSN}, and
206: @code{CALL_INSN}).@refill
207:
208: @item m
209: An RTX code for something that matches in insns, such as @code{MATCH_DUP}.
210:
211: @item x
212: All other RTX codes.
213: @end table
214: @end table
215:
216: @findex XEXP
217: @findex XINT
1.1.1.4 root 218: @findex XWINT
1.1 root 219: @findex XSTR
220: Operands of expressions are accessed using the macros @code{XEXP},
1.1.1.4 root 221: @code{XINT}, @code{XWINT} and @code{XSTR}. Each of these macros takes
222: two arguments: an expression-pointer (RTX) and an operand number
223: (counting from zero). Thus,@refill
1.1 root 224:
225: @example
226: XEXP (@var{x}, 2)
227: @end example
228:
229: @noindent
230: accesses operand 2 of expression @var{x}, as an expression.
231:
232: @example
233: XINT (@var{x}, 2)
234: @end example
235:
236: @noindent
237: accesses the same operand as an integer. @code{XSTR}, used in the same
238: fashion, would access it as a string.
239:
240: Any operand can be accessed as an integer, as an expression or as a string.
241: You must choose the correct method of access for the kind of value actually
242: stored in the operand. You would do this based on the expression code of
243: the containing expression. That is also how you would know how many
244: operands there are.
245:
246: For example, if @var{x} is a @code{subreg} expression, you know that it has
247: two operands which can be correctly accessed as @code{XEXP (@var{x}, 0)}
248: and @code{XINT (@var{x}, 1)}. If you did @code{XINT (@var{x}, 0)}, you
249: would get the address of the expression operand but cast as an integer;
250: that might occasionally be useful, but it would be cleaner to write
251: @code{(int) XEXP (@var{x}, 0)}. @code{XEXP (@var{x}, 1)} would also
252: compile without error, and would return the second, integer operand cast as
253: an expression pointer, which would probably result in a crash when
254: accessed. Nothing stops you from writing @code{XEXP (@var{x}, 28)} either,
255: but this will access memory past the end of the expression with
256: unpredictable results.@refill
257:
258: Access to operands which are vectors is more complicated. You can use the
259: macro @code{XVEC} to get the vector-pointer itself, or the macros
260: @code{XVECEXP} and @code{XVECLEN} to access the elements and length of a
261: vector.
262:
263: @table @code
264: @findex XVEC
265: @item XVEC (@var{exp}, @var{idx})
266: Access the vector-pointer which is operand number @var{idx} in @var{exp}.
267:
268: @findex XVECLEN
269: @item XVECLEN (@var{exp}, @var{idx})
270: Access the length (number of elements) in the vector which is
271: in operand number @var{idx} in @var{exp}. This value is an @code{int}.
272:
273: @findex XVECEXP
274: @item XVECEXP (@var{exp}, @var{idx}, @var{eltnum})
275: Access element number @var{eltnum} in the vector which is
276: in operand number @var{idx} in @var{exp}. This value is an RTX.
277:
278: It is up to you to make sure that @var{eltnum} is not negative
279: and is less than @code{XVECLEN (@var{exp}, @var{idx})}.
280: @end table
281:
282: All the macros defined in this section expand into lvalues and therefore
283: can be used to assign the operands, lengths and vector elements as well as
284: to access them.
285:
286: @node Flags, Machine Modes, Accessors, RTL
287: @section Flags in an RTL Expression
288: @cindex flags in RTL expression
289:
1.1.1.5 root 290: RTL expressions contain several flags (one-bit bitfields) that are used
1.1 root 291: in certain types of expression. Most often they are accessed with the
292: following macros:
293:
294: @table @code
295: @findex MEM_VOLATILE_P
296: @cindex @code{mem} and @samp{/v}
297: @cindex @code{volatil}, in @code{mem}
298: @cindex @samp{/v} in RTL dump
299: @item MEM_VOLATILE_P (@var{x})
300: In @code{mem} expressions, nonzero for volatile memory references.
301: Stored in the @code{volatil} field and printed as @samp{/v}.
302:
303: @findex MEM_IN_STRUCT_P
304: @cindex @code{mem} and @samp{/s}
305: @cindex @code{in_struct}, in @code{mem}
306: @cindex @samp{/s} in RTL dump
307: @item MEM_IN_STRUCT_P (@var{x})
308: In @code{mem} expressions, nonzero for reference to an entire
309: structure, union or array, or to a component of one. Zero for
310: references to a scalar variable or through a pointer to a scalar.
311: Stored in the @code{in_struct} field and printed as @samp{/s}.
312:
313: @findex REG_LOOP_TEST_P
314: @cindex @code{reg} and @samp{/s}
315: @cindex @code{in_struct}, in @code{reg}
316: @item REG_LOOP_TEST_P
317: In @code{reg} expressions, nonzero if this register's entire life is
318: contained in the exit test code for some loop. Stored in the
319: @code{in_struct} field and printed as @samp{/s}.
320:
321: @findex REG_USERVAR_P
322: @cindex @code{reg} and @samp{/v}
323: @cindex @code{volatil}, in @code{reg}
324: @item REG_USERVAR_P (@var{x})
325: In a @code{reg}, nonzero if it corresponds to a variable present in
326: the user's source code. Zero for temporaries generated internally by
327: the compiler. Stored in the @code{volatil} field and printed as
328: @samp{/v}.
329:
330: @cindex @samp{/i} in RTL dump
331: @findex REG_FUNCTION_VALUE_P
332: @cindex @code{reg} and @samp{/i}
333: @cindex @code{integrated}, in @code{reg}
334: @item REG_FUNCTION_VALUE_P (@var{x})
335: Nonzero in a @code{reg} if it is the place in which this function's
336: value is going to be returned. (This happens only in a hard
337: register.) Stored in the @code{integrated} field and printed as
338: @samp{/i}.
339:
340: The same hard register may be used also for collecting the values of
341: functions called by this one, but @code{REG_FUNCTION_VALUE_P} is zero
342: in this kind of use.
343:
1.1.1.4 root 344: @findex SUBREG_PROMOTED_VAR_P
345: @cindex @code{subreg} and @samp{/s}
346: @cindex @code{in_struct}, in @code{subreg}
347: @item SUBREG_PROMOTED_VAR_P
348: Nonzero in a @code{subreg} if it was made when accessing an object that
349: was promoted to a wider mode in accord with the @code{PROMOTED_MODE} machine
350: description macro (@pxref{Storage Layout}). In this case, the mode of
351: the @code{subreg} is the declared mode of the object and the mode of
352: @code{SUBREG_REG} is the mode of the register that holds the object.
353: Promoted variables are always either sign- or zero-extended to the wider
354: mode on every assignment. Stored in the @code{in_struct} field and
355: printed as @samp{/s}.
356:
357: @findex SUBREG_PROMOTED_UNSIGNED_P
358: @cindex @code{subreg} and @samp{/u}
359: @cindex @code{unchanging}, in @code{subreg}
360: @item SUBREG_PROMOTED_UNSIGNED_P
361: Nonzero in a @code{subreg} that has @code{SUBREG_PROMOTED_VAR_P} nonzero
362: if the object being referenced is kept zero-extended and zero if it
363: is kept sign-extended. Stored in the @code{unchanging} field and
364: printed as @samp{/u}.
365:
1.1 root 366: @findex RTX_UNCHANGING_P
367: @cindex @code{reg} and @samp{/u}
368: @cindex @code{mem} and @samp{/u}
369: @cindex @code{unchanging}, in @code{reg} and @code{mem}
370: @cindex @samp{/u} in RTL dump
371: @item RTX_UNCHANGING_P (@var{x})
372: Nonzero in a @code{reg} or @code{mem} if the value is not changed.
373: (This flag is not set for memory references via pointers to constants.
374: Such pointers only guarantee that the object will not be changed
375: explicitly by the current function. The object might be changed by
376: other functions or by aliasing.) Stored in the
377: @code{unchanging} field and printed as @samp{/u}.
378:
379: @findex RTX_INTEGRATED_P
380: @cindex @code{integrated}, in @code{insn}
381: @item RTX_INTEGRATED_P (@var{insn})
382: Nonzero in an insn if it resulted from an in-line function call.
383: Stored in the @code{integrated} field and printed as @samp{/i}. This
384: may be deleted; nothing currently depends on it.
385:
386: @findex SYMBOL_REF_USED
387: @cindex @code{used}, in @code{symbol_ref}
388: @item SYMBOL_REF_USED (@var{x})
389: In a @code{symbol_ref}, indicates that @var{x} has been used. This is
390: normally only used to ensure that @var{x} is only declared external
391: once. Stored in the @code{used} field.
392:
393: @findex SYMBOL_REF_FLAG
394: @cindex @code{symbol_ref} and @samp{/v}
395: @cindex @code{volatil}, in @code{symbol_ref}
396: @item SYMBOL_REF_FLAG (@var{x})
397: In a @code{symbol_ref}, this is used as a flag for machine-specific purposes.
398: Stored in the @code{volatil} field and printed as @samp{/v}.
399:
400: @findex LABEL_OUTSIDE_LOOP_P
401: @cindex @code{label_ref} and @samp{/s}
402: @cindex @code{in_struct}, in @code{label_ref}
403: @item LABEL_OUTSIDE_LOOP_P
404: In @code{label_ref} expressions, nonzero if this is a reference to a
405: label that is outside the innermost loop containing the reference to the
406: label. Stored in the @code{in_struct} field and printed as @samp{/s}.
407:
408: @findex INSN_DELETED_P
409: @cindex @code{volatil}, in @code{insn}
410: @item INSN_DELETED_P (@var{insn})
411: In an insn, nonzero if the insn has been deleted. Stored in the
412: @code{volatil} field and printed as @samp{/v}.
413:
414: @findex INSN_ANNULLED_BRANCH_P
415: @cindex @code{insn} and @samp{/u}
416: @cindex @code{unchanging}, in @code{insn}
417: @item INSN_ANNULLED_BRANCH_P (@var{insn})
418: In an @code{insn} in the delay slot of a branch insn, indicates that an
419: annulling branch should be used. See the discussion under
420: @code{sequence} below. Stored in the @code{unchanging} field and printed
421: as @samp{/u}.
422:
423: @findex INSN_FROM_TARGET_P
424: @cindex @code{insn} and @samp{/s}
425: @cindex @code{in_struct}, in @code{insn}
426: @cindex @samp{/s} in RTL dump
427: @item INSN_FROM_TARGET_P (@var{insn})
428: In an @code{insn} in a delay slot of a branch, indicates that the insn
429: is from the target of the branch. If the branch insn has
430: @code{INSN_ANNULLED_BRANCH_P} set, this insn should only be executed if
431: the branch is taken. For annulled branches with this bit clear, the
432: insn should be executed only if the branch is not taken. Stored in the
433: @code{in_struct} field and printed as @samp{/s}.
434:
435: @findex CONSTANT_POOL_ADDRESS_P
436: @cindex @code{symbol_ref} and @samp{/u}
437: @cindex @code{unchanging}, in @code{symbol_ref}
438: @item CONSTANT_POOL_ADDRESS_P (@var{x})
439: Nonzero in a @code{symbol_ref} if it refers to part of the current
440: function's ``constants pool''. These are addresses close to the
441: beginning of the function, and GNU CC assumes they can be addressed
442: directly (perhaps with the help of base registers). Stored in the
443: @code{unchanging} field and printed as @samp{/u}.
444:
445: @findex CONST_CALL_P
446: @cindex @code{call_insn} and @samp{/u}
447: @cindex @code{unchanging}, in @code{call_insn}
448: @item CONST_CALL_P (@var{x})
449: In a @code{call_insn}, indicates that the insn represents a call to a const
450: function. Stored in the @code{unchanging} field and printed as @samp{/u}.
451:
452: @findex LABEL_PRESERVE_P
453: @cindex @code{code_label} and @samp{/i}
454: @cindex @code{in_struct}, in @code{code_label}
455: @item LABEL_PRESERVE_P (@var{x})
456: In a @code{code_label}, indicates that the label can never be deleted.
1.1.1.4 root 457: Labels referenced by a non-local goto will have this bit set. Stored
1.1 root 458: in the @code{in_struct} field and printed as @samp{/s}.
459:
460: @findex SCHED_GROUP_P
461: @cindex @code{insn} and @samp{/i}
462: @cindex @code{in_struct}, in @code{insn}
463: @item SCHED_GROUP_P (@var{insn})
464: During instruction scheduling, in an insn, indicates that the previous insn
465: must be scheduled together with this insn. This is used to ensure that
466: certain groups of instructions will not be split up by the instruction
467: scheduling pass, for example, @code{use} insns before a @code{call_insn} may
468: not be separated from the @code{call_insn}. Stored in the @code{in_struct}
469: field and printed as @samp{/s}.
470: @end table
471:
472: These are the fields which the above macros refer to:
473:
474: @table @code
475: @findex used
476: @item used
477: Normally, this flag is used only momentarily, at the end of RTL
478: generation for a function, to count the number of times an expression
479: appears in insns. Expressions that appear more than once are copied,
480: according to the rules for shared structure (@pxref{Sharing}).
481:
482: In a @code{symbol_ref}, it indicates that an external declaration for
483: the symbol has already been written.
484:
485: In a @code{reg}, it is used by the leaf register renumbering code to ensure
486: that each register is only renumbered once.
487:
488: @findex volatil
489: @item volatil
1.1.1.4 root 490: This flag is used in @code{mem}, @code{symbol_ref} and @code{reg}
1.1 root 491: expressions and in insns. In RTL dump files, it is printed as
492: @samp{/v}.
493:
494: @cindex volatile memory references
495: In a @code{mem} expression, it is 1 if the memory reference is volatile.
496: Volatile memory references may not be deleted, reordered or combined.
497:
498: In a @code{symbol_ref} expression, it is used for machine-specific
499: purposes.
500:
501: In a @code{reg} expression, it is 1 if the value is a user-level variable.
502: 0 indicates an internal compiler temporary.
503:
504: In an insn, 1 means the insn has been deleted.
505:
506: @findex in_struct
507: @item in_struct
508: In @code{mem} expressions, it is 1 if the memory datum referred to is
509: all or part of a structure or array; 0 if it is (or might be) a scalar
510: variable. A reference through a C pointer has 0 because the pointer
511: might point to a scalar variable. This information allows the compiler
512: to determine something about possible cases of aliasing.
513:
514: In an insn in the delay slot of a branch, 1 means that this insn is from
515: the target of the branch.
516:
517: During instruction scheduling, in an insn, 1 means that this insn must be
518: scheduled as part of a group together with the previous insn.
519:
520: In @code{reg} expressions, it is 1 if the register has its entire life
1.1.1.5 root 521: contained within the test expression of some loop.
1.1 root 522:
1.1.1.4 root 523: In @code{subreg} expressions, 1 means that the @code{subreg} is accessing
524: an object that has had its mode promoted from a wider mode.
525:
1.1 root 526: In @code{label_ref} expressions, 1 means that the referenced label is
527: outside the innermost loop containing the insn in which the @code{label_ref}
528: was found.
529:
530: In @code{code_label} expressions, it is 1 if the label may never be deleted.
531: This is used for labels which are the target of non-local gotos.
532:
533: In an RTL dump, this flag is represented as @samp{/s}.
534:
535: @findex unchanging
536: @item unchanging
537: In @code{reg} and @code{mem} expressions, 1 means
538: that the value of the expression never changes.
539:
1.1.1.4 root 540: In @code{subreg} expressions, it is 1 if the @code{subreg} references an
541: unsigned object whose mode has been promoted to a wider mode.
542:
1.1 root 543: In an insn, 1 means that this is an annulling branch.
544:
545: In a @code{symbol_ref} expression, 1 means that this symbol addresses
546: something in the per-function constants pool.
547:
548: In a @code{call_insn}, 1 means that this instruction is a call to a
549: const function.
550:
551: In an RTL dump, this flag is represented as @samp{/u}.
552:
553: @findex integrated
554: @item integrated
555: In some kinds of expressions, including insns, this flag means the
556: rtl was produced by procedure integration.
557:
558: In a @code{reg} expression, this flag indicates the register
559: containing the value to be returned by the current function. On
560: machines that pass parameters in registers, the same register number
561: may be used for parameters as well, but this flag is not set on such
562: uses.
563: @end table
564:
565: @node Machine Modes, Constants, Flags, RTL
566: @section Machine Modes
567: @cindex machine modes
568:
569: @findex enum machine_mode
570: A machine mode describes a size of data object and the representation used
571: for it. In the C code, machine modes are represented by an enumeration
572: type, @code{enum machine_mode}, defined in @file{machmode.def}. Each RTL
573: expression has room for a machine mode and so do certain kinds of tree
574: expressions (declarations and types, to be precise).
575:
576: In debugging dumps and machine descriptions, the machine mode of an RTL
577: expression is written after the expression code with a colon to separate
578: them. The letters @samp{mode} which appear at the end of each machine mode
579: name are omitted. For example, @code{(reg:SI 38)} is a @code{reg}
580: expression with machine mode @code{SImode}. If the mode is
581: @code{VOIDmode}, it is not written at all.
582:
583: Here is a table of machine modes. The term ``byte'' below refers to an
584: object of @code{BITS_PER_UNIT} bits (@pxref{Storage Layout}).
585:
586: @table @code
587: @findex QImode
588: @item QImode
589: ``Quarter-Integer'' mode represents a single byte treated as an integer.
590:
591: @findex HImode
592: @item HImode
593: ``Half-Integer'' mode represents a two-byte integer.
594:
595: @findex PSImode
596: @item PSImode
597: ``Partial Single Integer'' mode represents an integer which occupies
598: four bytes but which doesn't really use all four. On some machines,
599: this is the right mode to use for pointers.
600:
601: @findex SImode
602: @item SImode
603: ``Single Integer'' mode represents a four-byte integer.
604:
605: @findex PDImode
606: @item PDImode
607: ``Partial Double Integer'' mode represents an integer which occupies
608: eight bytes but which doesn't really use all eight. On some machines,
609: this is the right mode to use for certain pointers.
610:
611: @findex DImode
612: @item DImode
613: ``Double Integer'' mode represents an eight-byte integer.
614:
615: @findex TImode
616: @item TImode
617: ``Tetra Integer'' (?) mode represents a sixteen-byte integer.
618:
619: @findex SFmode
620: @item SFmode
621: ``Single Floating'' mode represents a single-precision (four byte) floating
622: point number.
623:
624: @findex DFmode
625: @item DFmode
626: ``Double Floating'' mode represents a double-precision (eight byte) floating
627: point number.
628:
629: @findex XFmode
630: @item XFmode
631: ``Extended Floating'' mode represents a triple-precision (twelve byte)
632: floating point number. This mode is used for IEEE extended floating
1.1.1.8 ! root 633: point. On some systems not all bits within these bytes will actually
! 634: be used.
1.1 root 635:
636: @findex TFmode
637: @item TFmode
638: ``Tetra Floating'' mode represents a quadruple-precision (sixteen byte)
639: floating point number.
640:
641: @findex CCmode
642: @item CCmode
643: ``Condition Code'' mode represents the value of a condition code, which
644: is a machine-specific set of bits used to represent the result of a
645: comparison operation. Other machine-specific modes may also be used for
646: the condition code. These modes are not used on machines that use
647: @code{cc0} (see @pxref{Condition Code}).
648:
649: @findex BLKmode
650: @item BLKmode
651: ``Block'' mode represents values that are aggregates to which none of
652: the other modes apply. In RTL, only memory references can have this mode,
653: and only if they appear in string-move or vector instructions. On machines
654: which have no such instructions, @code{BLKmode} will not appear in RTL.
655:
656: @findex VOIDmode
657: @item VOIDmode
658: Void mode means the absence of a mode or an unspecified mode.
659: For example, RTL expressions of code @code{const_int} have mode
660: @code{VOIDmode} because they can be taken to have whatever mode the context
661: requires. In debugging dumps of RTL, @code{VOIDmode} is expressed by
662: the absence of any mode.
663:
664: @findex SCmode
665: @findex DCmode
666: @findex XCmode
667: @findex TCmode
668: @item SCmode, DCmode, XCmode, TCmode
1.1.1.6 root 669: These modes stand for a complex number represented as a pair of floating
670: point values. The floating point values are in @code{SFmode},
671: @code{DFmode}, @code{XFmode}, and @code{TFmode}, respectively.
672:
673: @findex CQImode
674: @findex CHImode
675: @findex CSImode
676: @findex CDImode
677: @findex CTImode
678: @findex COImode
679: @item CQImode, CHImode, CSImode, CDImode, CTImode, COImode
680: These modes stand for a complex number represented as a pair of integer
681: values. The integer values are in @code{QImode}, @code{HImode},
682: @code{SImode}, @code{DImode}, @code{TImode}, and @code{OImode},
683: respectively.
1.1 root 684: @end table
685:
686: The machine description defines @code{Pmode} as a C macro which expands
687: into the machine mode used for addresses. Normally this is the mode
688: whose size is @code{BITS_PER_WORD}, @code{SImode} on 32-bit machines.
689:
690: The only modes which a machine description @i{must} support are
691: @code{QImode}, and the modes corresponding to @code{BITS_PER_WORD},
692: @code{FLOAT_TYPE_SIZE} and @code{DOUBLE_TYPE_SIZE}.
693: The compiler will attempt to use @code{DImode} for 8-byte structures and
694: unions, but this can be prevented by overriding the definition of
695: @code{MAX_FIXED_MODE_SIZE}. Alternatively, you can have the compiler
696: use @code{TImode} for 16-byte structures and unions. Likewise, you can
697: arrange for the C type @code{short int} to avoid using @code{HImode}.
698:
699: @cindex mode classes
700: Very few explicit references to machine modes remain in the compiler and
701: these few references will soon be removed. Instead, the machine modes
702: are divided into mode classes. These are represented by the enumeration
703: type @code{enum mode_class} defined in @file{machmode.h}. The possible
704: mode classes are:
705:
706: @table @code
707: @findex MODE_INT
708: @item MODE_INT
709: Integer modes. By default these are @code{QImode}, @code{HImode},
710: @code{SImode}, @code{DImode}, and @code{TImode}.
711:
712: @findex MODE_PARTIAL_INT
713: @item MODE_PARTIAL_INT
714: The ``partial integer'' modes, @code{PSImode} and @code{PDImode}.
715:
716: @findex MODE_FLOAT
717: @item MODE_FLOAT
718: floating point modes. By default these are @code{SFmode}, @code{DFmode},
719: @code{XFmode} and @code{TFmode}.
720:
721: @findex MODE_COMPLEX_INT
722: @item MODE_COMPLEX_INT
723: Complex integer modes. (These are not currently implemented).
724:
725: @findex MODE_COMPLEX_FLOAT
726: @item MODE_COMPLEX_FLOAT
727: Complex floating point modes. By default these are @code{SCmode},
728: @code{DCmode}, @code{XCmode}, and @code{TCmode}.
729:
730: @findex MODE_FUNCTION
731: @item MODE_FUNCTION
732: Algol or Pascal function variables including a static chain.
733: (These are not currently implemented).
734:
735: @findex MODE_CC
736: @item MODE_CC
737: Modes representing condition code values. These are @code{CCmode} plus
738: any modes listed in the @code{EXTRA_CC_MODES} macro. @xref{Jump Patterns},
739: also see @ref{Condition Code}.
740:
741: @findex MODE_RANDOM
742: @item MODE_RANDOM
743: This is a catchall mode class for modes which don't fit into the above
744: classes. Currently @code{VOIDmode} and @code{BLKmode} are in
745: @code{MODE_RANDOM}.
746: @end table
747:
748: Here are some C macros that relate to machine modes:
749:
750: @table @code
751: @findex GET_MODE
752: @item GET_MODE (@var{x})
753: Returns the machine mode of the RTX @var{x}.
754:
755: @findex PUT_MODE
756: @item PUT_MODE (@var{x}, @var{newmode})
757: Alters the machine mode of the RTX @var{x} to be @var{newmode}.
758:
759: @findex NUM_MACHINE_MODES
760: @item NUM_MACHINE_MODES
761: Stands for the number of machine modes available on the target
762: machine. This is one greater than the largest numeric value of any
763: machine mode.
764:
765: @findex GET_MODE_NAME
766: @item GET_MODE_NAME (@var{m})
767: Returns the name of mode @var{m} as a string.
768:
769: @findex GET_MODE_CLASS
770: @item GET_MODE_CLASS (@var{m})
771: Returns the mode class of mode @var{m}.
772:
773: @findex GET_MODE_WIDER_MODE
774: @item GET_MODE_WIDER_MODE (@var{m})
1.1.1.5 root 775: Returns the next wider natural mode. For example, the expression
776: @code{GET_MODE_WIDER_MODE (QImode)} returns @code{HImode}.
1.1 root 777:
778: @findex GET_MODE_SIZE
779: @item GET_MODE_SIZE (@var{m})
780: Returns the size in bytes of a datum of mode @var{m}.
781:
782: @findex GET_MODE_BITSIZE
783: @item GET_MODE_BITSIZE (@var{m})
784: Returns the size in bits of a datum of mode @var{m}.
785:
786: @findex GET_MODE_MASK
787: @item GET_MODE_MASK (@var{m})
788: Returns a bitmask containing 1 for all bits in a word that fit within
789: mode @var{m}. This macro can only be used for modes whose bitsize is
790: less than or equal to @code{HOST_BITS_PER_INT}.
791:
792: @findex GET_MODE_ALIGNMENT
793: @item GET_MODE_ALIGNMENT (@var{m)})
794: Return the required alignment, in bits, for an object of mode @var{m}.
795:
796: @findex GET_MODE_UNIT_SIZE
797: @item GET_MODE_UNIT_SIZE (@var{m})
798: Returns the size in bytes of the subunits of a datum of mode @var{m}.
799: This is the same as @code{GET_MODE_SIZE} except in the case of complex
800: modes. For them, the unit size is the size of the real or imaginary
801: part.
802:
803: @findex GET_MODE_NUNITS
804: @item GET_MODE_NUNITS (@var{m})
805: Returns the number of units contained in a mode, i.e.,
806: @code{GET_MODE_SIZE} divided by @code{GET_MODE_UNIT_SIZE}.
807:
808: @findex GET_CLASS_NARROWEST_MODE
809: @item GET_CLASS_NARROWEST_MODE (@var{c})
810: Returns the narrowest mode in mode class @var{c}.
811: @end table
812:
813: @findex byte_mode
814: @findex word_mode
1.1.1.5 root 815: The global variables @code{byte_mode} and @code{word_mode} contain modes
816: whose classes are @code{MODE_INT} and whose bitsizes are either
1.1 root 817: @code{BITS_PER_UNIT} or @code{BITS_PER_WORD}, respectively. On 32-bit
818: machines, these are @code{QImode} and @code{SImode}, respectively.
819:
820: @node Constants, Regs and Memory, Machine Modes, RTL
821: @section Constant Expression Types
822: @cindex RTL constants
823: @cindex RTL constant expression types
824:
825: The simplest RTL expressions are those that represent constant values.
826:
827: @table @code
828: @findex const_int
829: @item (const_int @var{i})
830: This type of expression represents the integer value @var{i}. @var{i}
831: is customarily accessed with the macro @code{INTVAL} as in
1.1.1.4 root 832: @code{INTVAL (@var{exp})}, which is equivalent to @code{XWINT (@var{exp}, 0)}.
1.1 root 833:
834: @findex const0_rtx
835: @findex const1_rtx
836: @findex const2_rtx
837: @findex constm1_rtx
838: There is only one expression object for the integer value zero; it is
839: the value of the variable @code{const0_rtx}. Likewise, the only
840: expression for integer value one is found in @code{const1_rtx}, the only
841: expression for integer value two is found in @code{const2_rtx}, and the
842: only expression for integer value negative one is found in
843: @code{constm1_rtx}. Any attempt to create an expression of code
844: @code{const_int} and value zero, one, two or negative one will return
845: @code{const0_rtx}, @code{const1_rtx}, @code{const2_rtx} or
846: @code{constm1_rtx} as appropriate.@refill
847:
848: @findex const_true_rtx
849: Similarly, there is only one object for the integer whose value is
850: @code{STORE_FLAG_VALUE}. It is found in @code{const_true_rtx}. If
851: @code{STORE_FLAG_VALUE} is one, @code{const_true_rtx} and
852: @code{const1_rtx} will point to the same object. If
853: @code{STORE_FLAG_VALUE} is -1, @code{const_true_rtx} and
854: @code{constm1_rtx} will point to the same object.@refill
855:
856: @findex const_double
857: @item (const_double:@var{m} @var{addr} @var{i0} @var{i1} @dots{})
858: Represents either a floating-point constant of mode @var{m} or an
1.1.1.5 root 859: integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT}
1.1 root 860: bits but small enough to fit within twice that number of bits (GNU CC
861: does not provide a mechanism to represent even larger constants). In
862: the latter case, @var{m} will be @code{VOIDmode}.
863:
864: @findex CONST_DOUBLE_MEM
865: @findex CONST_DOUBLE_CHAIN
866: @var{addr} is used to contain the @code{mem} expression that corresponds
867: to the location in memory that at which the constant can be found. If
868: it has not been allocated a memory location, but is on the chain of all
869: @code{const_double} expressions in this compilation (maintained using an
870: undisplayed field), @var{addr} contains @code{const0_rtx}. If it is not
871: on the chain, @var{addr} contains @code{cc0_rtx}. @var{addr} is
872: customarily accessed with the macro @code{CONST_DOUBLE_MEM} and the
873: chain field via @code{CONST_DOUBLE_CHAIN}.@refill
874:
875: @findex CONST_DOUBLE_LOW
1.1.1.2 root 876: If @var{m} is @code{VOIDmode}, the bits of the value are stored in
1.1 root 877: @var{i0} and @var{i1}. @var{i0} is customarily accessed with the macro
878: @code{CONST_DOUBLE_LOW} and @var{i1} with @code{CONST_DOUBLE_HIGH}.
879:
1.1.1.5 root 880: If the constant is floating point (regardless of its precision), then
881: the number of integers used to store the value depends on the size of
882: @code{REAL_VALUE_TYPE} (@pxref{Cross-compilation}). The integers
883: represent a floating point number, but not precisely in the target
884: machine's or host machine's floating point format. To convert them to
885: the precise bit pattern used by the target machine, use the macro
886: @code{REAL_VALUE_TO_TARGET_DOUBLE} and friends (@pxref{Data Output}).
1.1 root 887:
888: @findex CONST0_RTX
889: @findex CONST1_RTX
890: @findex CONST2_RTX
891: The macro @code{CONST0_RTX (@var{mode})} refers to an expression with
1.1.1.5 root 892: value 0 in mode @var{mode}. If mode @var{mode} is of mode class
1.1 root 893: @code{MODE_INT}, it returns @code{const0_rtx}. Otherwise, it returns a
894: @code{CONST_DOUBLE} expression in mode @var{mode}. Similarly, the macro
895: @code{CONST1_RTX (@var{mode})} refers to an expression with value 1 in
896: mode @var{mode} and similarly for @code{CONST2_RTX}.
897:
898: @findex const_string
899: @item (const_string @var{str})
900: Represents a constant string with value @var{str}. Currently this is
901: used only for insn attributes (@pxref{Insn Attributes}) since constant
902: strings in C are placed in memory.
903:
904: @findex symbol_ref
1.1.1.2 root 905: @item (symbol_ref:@var{mode} @var{symbol})
1.1 root 906: Represents the value of an assembler label for data. @var{symbol} is
907: a string that describes the name of the assembler label. If it starts
908: with a @samp{*}, the label is the rest of @var{symbol} not including
909: the @samp{*}. Otherwise, the label is @var{symbol}, usually prefixed
910: with @samp{_}.
911:
1.1.1.2 root 912: The @code{symbol_ref} contains a mode, which is usually @code{Pmode}.
913: Usually that is the only mode for which a symbol is directly valid.
914:
1.1 root 915: @findex label_ref
916: @item (label_ref @var{label})
917: Represents the value of an assembler label for code. It contains one
918: operand, an expression, which must be a @code{code_label} that appears
919: in the instruction sequence to identify the place where the label
920: should go.
921:
922: The reason for using a distinct expression type for code label
923: references is so that jump optimization can distinguish them.
924:
925: @item (const:@var{m} @var{exp})
926: Represents a constant that is the result of an assembly-time
927: arithmetic computation. The operand, @var{exp}, is an expression that
928: contains only constants (@code{const_int}, @code{symbol_ref} and
929: @code{label_ref} expressions) combined with @code{plus} and
930: @code{minus}. However, not all combinations are valid, since the
931: assembler cannot do arbitrary arithmetic on relocatable symbols.
932:
933: @var{m} should be @code{Pmode}.
934:
935: @findex high
936: @item (high:@var{m} @var{exp})
937: Represents the high-order bits of @var{exp}, usually a
938: @code{symbol_ref}. The number of bits is machine-dependent and is
939: normally the number of bits specified in an instruction that initializes
940: the high order bits of a register. It is used with @code{lo_sum} to
941: represent the typical two-instruction sequence used in RISC machines to
942: reference a global memory location.
943:
944: @var{m} should be @code{Pmode}.
945: @end table
946:
947: @node Regs and Memory, Arithmetic, Constants, RTL
948: @section Registers and Memory
949: @cindex RTL register expressions
950: @cindex RTL memory expressions
951:
952: Here are the RTL expression types for describing access to machine
953: registers and to main memory.
954:
955: @table @code
956: @findex reg
957: @cindex hard registers
958: @cindex pseudo registers
959: @item (reg:@var{m} @var{n})
1.1.1.5 root 960: For small values of the integer @var{n} (those that are less than
1.1 root 961: @code{FIRST_PSEUDO_REGISTER}), this stands for a reference to machine
962: register number @var{n}: a @dfn{hard register}. For larger values of
963: @var{n}, it stands for a temporary value or @dfn{pseudo register}.
964: The compiler's strategy is to generate code assuming an unlimited
965: number of such pseudo registers, and later convert them into hard
966: registers or into memory references.
967:
968: @var{m} is the machine mode of the reference. It is necessary because
969: machines can generally refer to each register in more than one mode.
970: For example, a register may contain a full word but there may be
971: instructions to refer to it as a half word or as a single byte, as
972: well as instructions to refer to it as a floating point number of
973: various precisions.
974:
975: Even for a register that the machine can access in only one mode,
976: the mode must always be specified.
977:
978: The symbol @code{FIRST_PSEUDO_REGISTER} is defined by the machine
979: description, since the number of hard registers on the machine is an
980: invariant characteristic of the machine. Note, however, that not
981: all of the machine registers must be general registers. All the
982: machine registers that can be used for storage of data are given
983: hard register numbers, even those that can be used only in certain
984: instructions or can hold only certain types of data.
985:
986: A hard register may be accessed in various modes throughout one
987: function, but each pseudo register is given a natural mode
988: and is accessed only in that mode. When it is necessary to describe
989: an access to a pseudo register using a nonnatural mode, a @code{subreg}
990: expression is used.
991:
992: A @code{reg} expression with a machine mode that specifies more than
993: one word of data may actually stand for several consecutive registers.
994: If in addition the register number specifies a hardware register, then
995: it actually represents several consecutive hardware registers starting
996: with the specified one.
997:
998: Each pseudo register number used in a function's RTL code is
999: represented by a unique @code{reg} expression.
1000:
1001: @findex FIRST_VIRTUAL_REGISTER
1002: @findex LAST_VIRTUAL_REGISTER
1003: Some pseudo register numbers, those within the range of
1004: @code{FIRST_VIRTUAL_REGISTER} to @code{LAST_VIRTUAL_REGISTER} only
1005: appear during the RTL generation phase and are eliminated before the
1006: optimization phases. These represent locations in the stack frame that
1007: cannot be determined until RTL generation for the function has been
1008: completed. The following virtual register numbers are defined:
1009:
1010: @table @code
1011: @findex VIRTUAL_INCOMING_ARGS_REGNUM
1012: @item VIRTUAL_INCOMING_ARGS_REGNUM
1013: This points to the first word of the incoming arguments passed on the
1014: stack. Normally these arguments are placed there by the caller, but the
1015: callee may have pushed some arguments that were previously passed in
1016: registers.
1017:
1018: @cindex @code{FIRST_PARM_OFFSET} and virtual registers
1019: @cindex @code{ARG_POINTER_REGNUM} and virtual registers
1020: When RTL generation is complete, this virtual register is replaced
1021: by the sum of the register given by @code{ARG_POINTER_REGNUM} and the
1022: value of @code{FIRST_PARM_OFFSET}.
1023:
1024: @findex VIRTUAL_STACK_VARS_REGNUM
1025: @cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
1026: @item VIRTUAL_STACK_VARS_REGNUM
1.1.1.6 root 1027: If @code{FRAME_GROWS_DOWNWARD} is defined, this points to immediately
1.1 root 1028: above the first variable on the stack. Otherwise, it points to the
1029: first variable on the stack.
1030:
1031: @cindex @code{STARTING_FRAME_OFFSET} and virtual registers
1032: @cindex @code{FRAME_POINTER_REGNUM} and virtual registers
1.1.1.5 root 1033: @code{VIRTUAL_STACK_VARS_REGNUM} is replaced with the sum of the
1034: register given by @code{FRAME_POINTER_REGNUM} and the value
1035: @code{STARTING_FRAME_OFFSET}.
1.1 root 1036:
1037: @findex VIRTUAL_STACK_DYNAMIC_REGNUM
1038: @item VIRTUAL_STACK_DYNAMIC_REGNUM
1039: This points to the location of dynamically allocated memory on the stack
1040: immediately after the stack pointer has been adjusted by the amount of
1041: memory desired.
1042:
1043: @cindex @code{STACK_DYNAMIC_OFFSET} and virtual registers
1044: @cindex @code{STACK_POINTER_REGNUM} and virtual registers
1.1.1.5 root 1045: This virtual register is replaced by the sum of the register given by
1.1 root 1046: @code{STACK_POINTER_REGNUM} and the value @code{STACK_DYNAMIC_OFFSET}.
1047:
1048: @findex VIRTUAL_OUTGOING_ARGS_REGNUM
1049: @item VIRTUAL_OUTGOING_ARGS_REGNUM
1050: This points to the location in the stack at which outgoing arguments
1051: should be written when the stack is pre-pushed (arguments pushed using
1052: push insns should always use @code{STACK_POINTER_REGNUM}).
1053:
1054: @cindex @code{STACK_POINTER_OFFSET} and virtual registers
1.1.1.5 root 1055: This virtual register is replaced by the sum of the register given by
1.1 root 1056: @code{STACK_POINTER_REGNUM} and the value @code{STACK_POINTER_OFFSET}.
1057: @end table
1058:
1059: @findex subreg
1060: @item (subreg:@var{m} @var{reg} @var{wordnum})
1061: @code{subreg} expressions are used to refer to a register in a machine
1062: mode other than its natural one, or to refer to one register of
1063: a multi-word @code{reg} that actually refers to several registers.
1064:
1065: Each pseudo-register has a natural mode. If it is necessary to
1066: operate on it in a different mode---for example, to perform a fullword
1067: move instruction on a pseudo-register that contains a single
1068: byte---the pseudo-register must be enclosed in a @code{subreg}. In
1069: such a case, @var{wordnum} is zero.
1070:
1071: Usually @var{m} is at least as narrow as the mode of @var{reg}, in which
1072: case it is restricting consideration to only the bits of @var{reg} that
1.1.1.6 root 1073: are in @var{m}.
1074:
1075: Sometimes @var{m} is wider than the mode of @var{reg}. These
1076: @code{subreg} expressions are often called @dfn{paradoxical}. They are
1077: used in cases where we want to refer to an object in a wider mode but do
1078: not care what value the additional bits have. The reload pass ensures
1079: that paradoxical references are only made to hard registers.
1.1 root 1080:
1081: The other use of @code{subreg} is to extract the individual registers of
1082: a multi-register value. Machine modes such as @code{DImode} and
1083: @code{TImode} can indicate values longer than a word, values which
1084: usually require two or more consecutive registers. To access one of the
1085: registers, use a @code{subreg} with mode @code{SImode} and a
1086: @var{wordnum} that says which register.
1087:
1.1.1.6 root 1088: Storing in a non-paradoxical @code{subreg} has undefined results for
1089: bits belonging to the same word as the @code{subreg}. This laxity makes
1090: it easier to generate efficient code for such instructions. To
1091: represent an instruction that preserves all the bits outside of those in
1092: the @code{subreg}, use @code{strict_low_part} around the @code{subreg}.
1093:
1.1 root 1094: @cindex @code{WORDS_BIG_ENDIAN}, effect on @code{subreg}
1095: The compilation parameter @code{WORDS_BIG_ENDIAN}, if set to 1, says
1096: that word number zero is the most significant part; otherwise, it is
1097: the least significant part.
1098:
1099: @cindex combiner pass
1100: @cindex reload pass
1101: @cindex @code{subreg}, special reload handling
1102: Between the combiner pass and the reload pass, it is possible to have a
1103: paradoxical @code{subreg} which contains a @code{mem} instead of a
1104: @code{reg} as its first operand. After the reload pass, it is also
1105: possible to have a non-paradoxical @code{subreg} which contains a
1106: @code{mem}; this usually occurs when the @code{mem} is a stack slot
1107: which replaced a pseudo register.
1108:
1109: Note that it is not valid to access a @code{DFmode} value in @code{SFmode}
1110: using a @code{subreg}. On some machines the most significant part of a
1111: @code{DFmode} value does not have the same format as a single-precision
1112: floating value.
1113:
1114: It is also not valid to access a single word of a multi-word value in a
1115: hard register when less registers can hold the value than would be
1116: expected from its size. For example, some 32-bit machines have
1117: floating-point registers that can hold an entire @code{DFmode} value.
1118: If register 10 were such a register @code{(subreg:SI (reg:DF 10) 1)}
1119: would be invalid because there is no way to convert that reference to
1120: a single machine register. The reload pass prevents @code{subreg}
1121: expressions such as these from being formed.
1122:
1123: @findex SUBREG_REG
1124: @findex SUBREG_WORD
1125: The first operand of a @code{subreg} expression is customarily accessed
1126: with the @code{SUBREG_REG} macro and the second operand is customarily
1127: accessed with the @code{SUBREG_WORD} macro.
1128:
1129: @findex scratch
1130: @cindex scratch operands
1131: @item (scratch:@var{m})
1132: This represents a scratch register that will be required for the
1133: execution of a single instruction and not used subsequently. It is
1134: converted into a @code{reg} by either the local register allocator or
1135: the reload pass.
1136:
1137: @code{scratch} is usually present inside a @code{clobber} operation
1138: (@pxref{Side Effects}).
1139:
1140: @findex cc0
1141: @cindex condition code register
1142: @item (cc0)
1143: This refers to the machine's condition code register. It has no
1144: operands and may not have a machine mode. There are two ways to use it:
1145:
1146: @itemize @bullet
1147: @item
1148: To stand for a complete set of condition code flags. This is best on
1149: most machines, where each comparison sets the entire series of flags.
1150:
1151: With this technique, @code{(cc0)} may be validly used in only two
1152: contexts: as the destination of an assignment (in test and compare
1153: instructions) and in comparison operators comparing against zero
1154: (@code{const_int} with value zero; that is to say, @code{const0_rtx}).
1155:
1156: @item
1157: To stand for a single flag that is the result of a single condition.
1158: This is useful on machines that have only a single flag bit, and in
1159: which comparison instructions must specify the condition to test.
1160:
1161: With this technique, @code{(cc0)} may be validly used in only two
1162: contexts: as the destination of an assignment (in test and compare
1163: instructions) where the source is a comparison operator, and as the
1164: first operand of @code{if_then_else} (in a conditional branch).
1165: @end itemize
1166:
1167: @findex cc0_rtx
1168: There is only one expression object of code @code{cc0}; it is the
1169: value of the variable @code{cc0_rtx}. Any attempt to create an
1170: expression of code @code{cc0} will return @code{cc0_rtx}.
1171:
1172: Instructions can set the condition code implicitly. On many machines,
1173: nearly all instructions set the condition code based on the value that
1174: they compute or store. It is not necessary to record these actions
1175: explicitly in the RTL because the machine description includes a
1176: prescription for recognizing the instructions that do so (by means of
1177: the macro @code{NOTICE_UPDATE_CC}). @xref{Condition Code}. Only
1178: instructions whose sole purpose is to set the condition code, and
1179: instructions that use the condition code, need mention @code{(cc0)}.
1180:
1181: On some machines, the condition code register is given a register number
1182: and a @code{reg} is used instead of @code{(cc0)}. This is usually the
1183: preferable approach if only a small subset of instructions modify the
1184: condition code. Other machines store condition codes in general
1185: registers; in such cases a pseudo register should be used.
1186:
1187: Some machines, such as the Sparc and RS/6000, have two sets of
1188: arithmetic instructions, one that sets and one that does not set the
1189: condition code. This is best handled by normally generating the
1190: instruction that does not set the condition code, and making a pattern
1191: that both performs the arithmetic and sets the condition code register
1192: (which would not be @code{(cc0)} in this case). For examples, search
1193: for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
1194:
1195: @findex pc
1196: @item (pc)
1197: @cindex program counter
1198: This represents the machine's program counter. It has no operands and
1199: may not have a machine mode. @code{(pc)} may be validly used only in
1200: certain specific contexts in jump instructions.
1201:
1202: @findex pc_rtx
1203: There is only one expression object of code @code{pc}; it is the value
1204: of the variable @code{pc_rtx}. Any attempt to create an expression of
1205: code @code{pc} will return @code{pc_rtx}.
1206:
1207: All instructions that do not jump alter the program counter implicitly
1208: by incrementing it, but there is no need to mention this in the RTL.
1209:
1210: @findex mem
1211: @item (mem:@var{m} @var{addr})
1212: This RTX represents a reference to main memory at an address
1213: represented by the expression @var{addr}. @var{m} specifies how large
1214: a unit of memory is accessed.
1215: @end table
1216:
1217: @node Arithmetic, Comparisons, Regs and Memory, RTL
1218: @section RTL Expressions for Arithmetic
1219: @cindex arithmetic, in RTL
1220: @cindex math, in RTL
1221: @cindex RTL expressions for arithmetic
1222:
1223: Unless otherwise specified, all the operands of arithmetic expressions
1224: must be valid for mode @var{m}. An operand is valid for mode @var{m}
1225: if it has mode @var{m}, or if it is a @code{const_int} or
1226: @code{const_double} and @var{m} is a mode of class @code{MODE_INT}.
1227:
1228: For commutative binary operations, constants should be placed in the
1229: second operand.
1230:
1231: @table @code
1232: @findex plus
1233: @cindex RTL addition
1234: @cindex RTL sum
1235: @item (plus:@var{m} @var{x} @var{y})
1236: Represents the sum of the values represented by @var{x} and @var{y}
1237: carried out in machine mode @var{m}.
1238:
1239: @findex lo_sum
1240: @item (lo_sum:@var{m} @var{x} @var{y})
1241: Like @code{plus}, except that it represents that sum of @var{x} and the
1242: low-order bits of @var{y}. The number of low order bits is
1243: machine-dependent but is normally the number of bits in a @code{Pmode}
1244: item minus the number of bits set by the @code{high} code
1245: (@pxref{Constants}).
1246:
1247: @var{m} should be @code{Pmode}.
1248:
1249: @findex minus
1250: @cindex RTL subtraction
1251: @cindex RTL difference
1252: @item (minus:@var{m} @var{x} @var{y})
1253: Like @code{plus} but represents subtraction.
1254:
1255: @findex compare
1256: @cindex RTL comparison
1257: @item (compare:@var{m} @var{x} @var{y})
1258: Represents the result of subtracting @var{y} from @var{x} for purposes
1259: of comparison. The result is computed without overflow, as if with
1260: infinite precision.
1261:
1262: Of course, machines can't really subtract with infinite precision.
1263: However, they can pretend to do so when only the sign of the
1264: result will be used, which is the case when the result is stored
1265: in the condition code. And that is the only way this kind of expression
1266: may validly be used: as a value to be stored in the condition codes.
1267:
1268: The mode @var{m} is not related to the modes of @var{x} and @var{y},
1269: but instead is the mode of the condition code value. If @code{(cc0)}
1270: is used, it is @code{VOIDmode}. Otherwise it is some mode in class
1271: @code{MODE_CC}, often @code{CCmode}. @xref{Condition Code}.
1272:
1273: Normally, @var{x} and @var{y} must have the same mode. Otherwise,
1274: @code{compare} is valid only if the mode of @var{x} is in class
1275: @code{MODE_INT} and @var{y} is a @code{const_int} or
1276: @code{const_double} with mode @code{VOIDmode}. The mode of @var{x}
1277: determines what mode the comparison is to be done in; thus it must not
1278: be @code{VOIDmode}.
1279:
1280: If one of the operands is a constant, it should be placed in the
1281: second operand and the comparison code adjusted as appropriate.
1282:
1283: A @code{compare} specifying two @code{VOIDmode} constants is not valid
1284: since there is no way to know in what mode the comparison is to be
1285: performed; the comparison must either be folded during the compilation
1286: or the first operand must be loaded into a register while its mode is
1287: still known.
1288:
1289: @findex neg
1290: @item (neg:@var{m} @var{x})
1291: Represents the negation (subtraction from zero) of the value represented
1292: by @var{x}, carried out in mode @var{m}.
1293:
1294: @findex mult
1295: @cindex multiplication
1296: @cindex product
1297: @item (mult:@var{m} @var{x} @var{y})
1298: Represents the signed product of the values represented by @var{x} and
1299: @var{y} carried out in machine mode @var{m}.
1300:
1301: Some machines support a multiplication that generates a product wider
1302: than the operands. Write the pattern for this as
1303:
1304: @example
1305: (mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y}))
1306: @end example
1307:
1308: where @var{m} is wider than the modes of @var{x} and @var{y}, which need
1309: not be the same.
1310:
1311: Write patterns for unsigned widening multiplication similarly using
1312: @code{zero_extend}.
1313:
1314: @findex div
1315: @cindex division
1316: @cindex signed division
1317: @cindex quotient
1318: @item (div:@var{m} @var{x} @var{y})
1319: Represents the quotient in signed division of @var{x} by @var{y},
1320: carried out in machine mode @var{m}. If @var{m} is a floating point
1321: mode, it represents the exact quotient; otherwise, the integerized
1322: quotient.
1323:
1324: Some machines have division instructions in which the operands and
1325: quotient widths are not all the same; you should represent
1326: such instructions using @code{truncate} and @code{sign_extend} as in,
1327:
1328: @example
1329: (truncate:@var{m1} (div:@var{m2} @var{x} (sign_extend:@var{m2} @var{y})))
1330: @end example
1331:
1332: @findex udiv
1333: @cindex unsigned division
1334: @cindex division
1335: @item (udiv:@var{m} @var{x} @var{y})
1336: Like @code{div} but represents unsigned division.
1337:
1338: @findex mod
1339: @findex umod
1340: @cindex remainder
1341: @cindex division
1342: @item (mod:@var{m} @var{x} @var{y})
1343: @itemx (umod:@var{m} @var{x} @var{y})
1344: Like @code{div} and @code{udiv} but represent the remainder instead of
1345: the quotient.
1346:
1347: @findex smin
1348: @findex smax
1349: @cindex signed minimum
1350: @cindex signed maximum
1351: @item (smin:@var{m} @var{x} @var{y})
1352: @itemx (smax:@var{m} @var{x} @var{y})
1353: Represents the smaller (for @code{smin}) or larger (for @code{smax}) of
1354: @var{x} and @var{y}, interpreted as signed integers in mode @var{m}.
1355:
1356: @findex umin
1357: @findex umax
1358: @cindex unsigned minimum and maximum
1359: @item (umin:@var{m} @var{x} @var{y})
1360: @itemx (umax:@var{m} @var{x} @var{y})
1361: Like @code{smin} and @code{smax}, but the values are interpreted as unsigned
1362: integers.
1363:
1364: @findex not
1365: @cindex complement, bitwise
1366: @cindex bitwise complement
1367: @item (not:@var{m} @var{x})
1368: Represents the bitwise complement of the value represented by @var{x},
1369: carried out in mode @var{m}, which must be a fixed-point machine mode.
1370:
1371: @findex and
1372: @cindex logical-and, bitwise
1373: @cindex bitwise logical-and
1374: @item (and:@var{m} @var{x} @var{y})
1375: Represents the bitwise logical-and of the values represented by
1376: @var{x} and @var{y}, carried out in machine mode @var{m}, which must be
1377: a fixed-point machine mode.
1378:
1379: @findex ior
1380: @cindex inclusive-or, bitwise
1381: @cindex bitwise inclusive-or
1382: @item (ior:@var{m} @var{x} @var{y})
1383: Represents the bitwise inclusive-or of the values represented by @var{x}
1384: and @var{y}, carried out in machine mode @var{m}, which must be a
1385: fixed-point mode.
1386:
1387: @findex xor
1388: @cindex exclusive-or, bitwise
1389: @cindex bitwise exclusive-or
1390: @item (xor:@var{m} @var{x} @var{y})
1391: Represents the bitwise exclusive-or of the values represented by @var{x}
1392: and @var{y}, carried out in machine mode @var{m}, which must be a
1393: fixed-point mode.
1394:
1395: @findex ashift
1396: @cindex left shift
1397: @cindex shift
1398: @cindex arithmetic shift
1399: @item (ashift:@var{m} @var{x} @var{c})
1400: Represents the result of arithmetically shifting @var{x} left by @var{c}
1401: places. @var{x} have mode @var{m}, a fixed-point machine mode. @var{c}
1402: be a fixed-point mode or be a constant with mode @code{VOIDmode}; which
1403: mode is determined by the mode called for in the machine description
1404: entry for the left-shift instruction. For example, on the Vax, the mode
1405: of @var{c} is @code{QImode} regardless of @var{m}.
1406:
1407: @findex lshiftrt
1408: @cindex right shift
1409: @findex ashiftrt
1410: @item (lshiftrt:@var{m} @var{x} @var{c})
1411: @itemx (ashiftrt:@var{m} @var{x} @var{c})
1.1.1.7 root 1412: Like @code{ashift} but for right shift. Unlike the case for left shift,
1413: these two operations are distinct.
1.1 root 1414:
1415: @findex rotate
1416: @cindex rotate
1417: @cindex left rotate
1418: @findex rotatert
1419: @cindex right rotate
1420: @item (rotate:@var{m} @var{x} @var{c})
1421: @itemx (rotatert:@var{m} @var{x} @var{c})
1422: Similar but represent left and right rotate. If @var{c} is a constant,
1423: use @code{rotate}.
1424:
1425: @findex abs
1426: @cindex absolute value
1427: @item (abs:@var{m} @var{x})
1428: Represents the absolute value of @var{x}, computed in mode @var{m}.
1429:
1430: @findex sqrt
1431: @cindex square root
1432: @item (sqrt:@var{m} @var{x})
1433: Represents the square root of @var{x}, computed in mode @var{m}.
1434: Most often @var{m} will be a floating point mode.
1435:
1436: @findex ffs
1437: @item (ffs:@var{m} @var{x})
1438: Represents one plus the index of the least significant 1-bit in
1439: @var{x}, represented as an integer of mode @var{m}. (The value is
1440: zero if @var{x} is zero.) The mode of @var{x} need not be @var{m};
1441: depending on the target machine, various mode combinations may be
1442: valid.
1443: @end table
1444:
1445: @node Comparisons, Bit Fields, Arithmetic, RTL
1446: @section Comparison Operations
1447: @cindex RTL comparison operations
1448:
1449: Comparison operators test a relation on two operands and are considered
1450: to represent a machine-dependent nonzero value described by, but not
1451: necessarily equal to, @code{STORE_FLAG_VALUE} (@pxref{Misc})
1452: if the relation holds, or zero if it does not. The mode of the
1453: comparison operation is independent of the mode of the data being
1454: compared. If the comparison operation is being tested (e.g., the first
1455: operand of an @code{if_then_else}), the mode must be @code{VOIDmode}.
1456: If the comparison operation is producing data to be stored in some
1457: variable, the mode must be in class @code{MODE_INT}. All comparison
1458: operations producing data must use the same mode, which is
1459: machine-specific.
1460:
1461: @cindex condition codes
1462: There are two ways that comparison operations may be used. The
1463: comparison operators may be used to compare the condition codes
1464: @code{(cc0)} against zero, as in @code{(eq (cc0) (const_int 0))}. Such
1465: a construct actually refers to the result of the preceding instruction
1466: in which the condition codes were set. The instructing setting the
1467: condition code must be adjacent to the instruction using the condition
1468: code; only @code{note} insns may separate them.
1469:
1470: Alternatively, a comparison operation may directly compare two data
1471: objects. The mode of the comparison is determined by the operands; they
1472: must both be valid for a common machine mode. A comparison with both
1473: operands constant would be invalid as the machine mode could not be
1474: deduced from it, but such a comparison should never exist in RTL due to
1475: constant folding.
1476:
1477: In the example above, if @code{(cc0)} were last set to
1478: @code{(compare @var{x} @var{y})}, the comparison operation is
1479: identical to @code{(eq @var{x} @var{y})}. Usually only one style
1480: of comparisons is supported on a particular machine, but the combine
1481: pass will try to merge the operations to produce the @code{eq} shown
1482: in case it exists in the context of the particular insn involved.
1483:
1484: Inequality comparisons come in two flavors, signed and unsigned. Thus,
1485: there are distinct expression codes @code{gt} and @code{gtu} for signed and
1486: unsigned greater-than. These can produce different results for the same
1487: pair of integer values: for example, 1 is signed greater-than -1 but not
1488: unsigned greater-than, because -1 when regarded as unsigned is actually
1489: @code{0xffffffff} which is greater than 1.
1490:
1491: The signed comparisons are also used for floating point values. Floating
1492: point comparisons are distinguished by the machine modes of the operands.
1493:
1494: @table @code
1495: @findex eq
1496: @cindex equal
1497: @item (eq:@var{m} @var{x} @var{y})
1498: 1 if the values represented by @var{x} and @var{y} are equal,
1499: otherwise 0.
1500:
1501: @findex ne
1502: @cindex not equal
1503: @item (ne:@var{m} @var{x} @var{y})
1504: 1 if the values represented by @var{x} and @var{y} are not equal,
1505: otherwise 0.
1506:
1507: @findex gt
1508: @cindex greater than
1509: @item (gt:@var{m} @var{x} @var{y})
1510: 1 if the @var{x} is greater than @var{y}. If they are fixed-point,
1511: the comparison is done in a signed sense.
1512:
1513: @findex gtu
1514: @cindex greater than
1515: @cindex unsigned greater than
1516: @item (gtu:@var{m} @var{x} @var{y})
1517: Like @code{gt} but does unsigned comparison, on fixed-point numbers only.
1518:
1519: @findex lt
1520: @cindex less than
1521: @findex ltu
1522: @cindex unsigned less than
1523: @item (lt:@var{m} @var{x} @var{y})
1524: @itemx (ltu:@var{m} @var{x} @var{y})
1525: Like @code{gt} and @code{gtu} but test for ``less than''.
1526:
1527: @findex ge
1528: @cindex greater than
1529: @findex geu
1530: @cindex unsigned greater than
1531: @item (ge:@var{m} @var{x} @var{y})
1532: @itemx (geu:@var{m} @var{x} @var{y})
1533: Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
1534:
1535: @findex le
1536: @cindex less than or equal
1537: @findex leu
1538: @cindex unsigned less than
1539: @item (le:@var{m} @var{x} @var{y})
1540: @itemx (leu:@var{m} @var{x} @var{y})
1541: Like @code{gt} and @code{gtu} but test for ``less than or equal''.
1542:
1543: @findex if_then_else
1544: @item (if_then_else @var{cond} @var{then} @var{else})
1545: This is not a comparison operation but is listed here because it is
1546: always used in conjunction with a comparison operation. To be
1547: precise, @var{cond} is a comparison expression. This expression
1548: represents a choice, according to @var{cond}, between the value
1549: represented by @var{then} and the one represented by @var{else}.
1550:
1551: On most machines, @code{if_then_else} expressions are valid only
1552: to express conditional jumps.
1553:
1554: @findex cond
1555: @item (cond [@var{test1} @var{value1} @var{test2} @var{value2} @dots{}] @var{default})
1556: Similar to @code{if_then_else}, but more general. Each of @var{test1},
1557: @var{test2}, @dots{} is performed in turn. The result of this expression is
1558: the @var{value} corresponding to the first non-zero test, or @var{default} if
1559: none of the tests are non-zero expressions.
1560:
1561: This is currently not valid for instruction patterns and is supported only
1562: for insn attributes. @xref{Insn Attributes}.
1563: @end table
1564:
1565: @node Bit Fields, Conversions, Comparisons, RTL
1566: @section Bit Fields
1567: @cindex bit fields
1568:
1.1.1.5 root 1569: Special expression codes exist to represent bitfield instructions.
1.1 root 1570: These types of expressions are lvalues in RTL; they may appear
1571: on the left side of an assignment, indicating insertion of a value
1572: into the specified bit field.
1573:
1574: @table @code
1575: @findex sign_extract
1576: @cindex @code{BITS_BIG_ENDIAN}, effect on @code{sign_extract}
1577: @item (sign_extract:@var{m} @var{loc} @var{size} @var{pos})
1578: This represents a reference to a sign-extended bit field contained or
1579: starting in @var{loc} (a memory or register reference). The bit field
1580: is @var{size} bits wide and starts at bit @var{pos}. The compilation
1581: option @code{BITS_BIG_ENDIAN} says which end of the memory unit
1582: @var{pos} counts from.
1583:
1584: If @var{loc} is in memory, its mode must be a single-byte integer mode.
1585: If @var{loc} is in a register, the mode to use is specified by the
1586: operand of the @code{insv} or @code{extv} pattern
1587: (@pxref{Standard Names}) and is usually a full-word integer mode.
1588:
1589: The mode of @var{pos} is machine-specific and is also specified
1590: in the @code{insv} or @code{extv} pattern.
1591:
1592: The mode @var{m} is the same as the mode that would be used for
1593: @var{loc} if it were a register.
1594:
1595: @findex zero_extract
1596: @item (zero_extract:@var{m} @var{loc} @var{size} @var{pos})
1597: Like @code{sign_extract} but refers to an unsigned or zero-extended
1598: bit field. The same sequence of bits are extracted, but they
1599: are filled to an entire word with zeros instead of by sign-extension.
1600: @end table
1601:
1602: @node Conversions, RTL Declarations, Bit Fields, RTL
1603: @section Conversions
1604: @cindex conversions
1605: @cindex machine mode conversions
1606:
1607: All conversions between machine modes must be represented by
1608: explicit conversion operations. For example, an expression
1609: which is the sum of a byte and a full word cannot be written as
1610: @code{(plus:SI (reg:QI 34) (reg:SI 80))} because the @code{plus}
1611: operation requires two operands of the same machine mode.
1612: Therefore, the byte-sized operand is enclosed in a conversion
1613: operation, as in
1614:
1615: @example
1616: (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
1617: @end example
1618:
1619: The conversion operation is not a mere placeholder, because there
1620: may be more than one way of converting from a given starting mode
1621: to the desired final mode. The conversion operation code says how
1622: to do it.
1623:
1624: For all conversion operations, @var{x} must not be @code{VOIDmode}
1625: because the mode in which to do the conversion would not be known.
1626: The conversion must either be done at compile-time or @var{x}
1627: must be placed into a register.
1628:
1629: @table @code
1630: @findex sign_extend
1631: @item (sign_extend:@var{m} @var{x})
1632: Represents the result of sign-extending the value @var{x}
1633: to machine mode @var{m}. @var{m} must be a fixed-point mode
1634: and @var{x} a fixed-point value of a mode narrower than @var{m}.
1635:
1636: @findex zero_extend
1637: @item (zero_extend:@var{m} @var{x})
1638: Represents the result of zero-extending the value @var{x}
1639: to machine mode @var{m}. @var{m} must be a fixed-point mode
1640: and @var{x} a fixed-point value of a mode narrower than @var{m}.
1641:
1642: @findex float_extend
1643: @item (float_extend:@var{m} @var{x})
1644: Represents the result of extending the value @var{x}
1645: to machine mode @var{m}. @var{m} must be a floating point mode
1646: and @var{x} a floating point value of a mode narrower than @var{m}.
1647:
1648: @findex truncate
1649: @item (truncate:@var{m} @var{x})
1650: Represents the result of truncating the value @var{x}
1651: to machine mode @var{m}. @var{m} must be a fixed-point mode
1652: and @var{x} a fixed-point value of a mode wider than @var{m}.
1653:
1654: @findex float_truncate
1655: @item (float_truncate:@var{m} @var{x})
1656: Represents the result of truncating the value @var{x}
1657: to machine mode @var{m}. @var{m} must be a floating point mode
1658: and @var{x} a floating point value of a mode wider than @var{m}.
1659:
1660: @findex float
1661: @item (float:@var{m} @var{x})
1662: Represents the result of converting fixed point value @var{x},
1663: regarded as signed, to floating point mode @var{m}.
1664:
1665: @findex unsigned_float
1666: @item (unsigned_float:@var{m} @var{x})
1667: Represents the result of converting fixed point value @var{x},
1668: regarded as unsigned, to floating point mode @var{m}.
1669:
1670: @findex fix
1671: @item (fix:@var{m} @var{x})
1672: When @var{m} is a fixed point mode, represents the result of
1673: converting floating point value @var{x} to mode @var{m}, regarded as
1674: signed. How rounding is done is not specified, so this operation may
1675: be used validly in compiling C code only for integer-valued operands.
1676:
1677: @findex unsigned_fix
1678: @item (unsigned_fix:@var{m} @var{x})
1679: Represents the result of converting floating point value @var{x} to
1680: fixed point mode @var{m}, regarded as unsigned. How rounding is done
1681: is not specified.
1682:
1683: @findex fix
1684: @item (fix:@var{m} @var{x})
1685: When @var{m} is a floating point mode, represents the result of
1686: converting floating point value @var{x} (valid for mode @var{m}) to an
1687: integer, still represented in floating point mode @var{m}, by rounding
1688: towards zero.
1689: @end table
1690:
1691: @node RTL Declarations, Side Effects, Conversions, RTL
1692: @section Declarations
1693: @cindex RTL declarations
1694: @cindex declarations, RTL
1695:
1696: Declaration expression codes do not represent arithmetic operations
1697: but rather state assertions about their operands.
1698:
1699: @table @code
1700: @findex strict_low_part
1701: @cindex @code{subreg}, in @code{strict_low_part}
1702: @item (strict_low_part (subreg:@var{m} (reg:@var{n} @var{r}) 0))
1.1.1.4 root 1703: This expression code is used in only one context: as the destination operand of a
1.1 root 1704: @code{set} expression. In addition, the operand of this expression
1705: must be a non-paradoxical @code{subreg} expression.
1706:
1707: The presence of @code{strict_low_part} says that the part of the
1708: register which is meaningful in mode @var{n}, but is not part of
1709: mode @var{m}, is not to be altered. Normally, an assignment to such
1710: a subreg is allowed to have undefined effects on the rest of the
1711: register when @var{m} is less than a word.
1712: @end table
1713:
1714: @node Side Effects, Incdec, RTL Declarations, RTL
1715: @section Side Effect Expressions
1716: @cindex RTL side effect expressions
1717:
1718: The expression codes described so far represent values, not actions.
1719: But machine instructions never produce values; they are meaningful
1720: only for their side effects on the state of the machine. Special
1721: expression codes are used to represent side effects.
1722:
1723: The body of an instruction is always one of these side effect codes;
1724: the codes described above, which represent values, appear only as
1725: the operands of these.
1726:
1727: @table @code
1728: @findex set
1729: @item (set @var{lval} @var{x})
1730: Represents the action of storing the value of @var{x} into the place
1731: represented by @var{lval}. @var{lval} must be an expression
1732: representing a place that can be stored in: @code{reg} (or
1733: @code{subreg} or @code{strict_low_part}), @code{mem}, @code{pc} or
1734: @code{cc0}.@refill
1735:
1736: If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
1737: machine mode; then @var{x} must be valid for that mode.@refill
1738:
1739: If @var{lval} is a @code{reg} whose machine mode is less than the full
1740: width of the register, then it means that the part of the register
1741: specified by the machine mode is given the specified value and the
1742: rest of the register receives an undefined value. Likewise, if
1743: @var{lval} is a @code{subreg} whose machine mode is narrower than
1744: the mode of the register, the rest of the register can be changed in
1745: an undefined way.
1746:
1747: If @var{lval} is a @code{strict_low_part} of a @code{subreg}, then the
1748: part of the register specified by the machine mode of the
1749: @code{subreg} is given the value @var{x} and the rest of the register
1750: is not changed.@refill
1751:
1752: If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
1753: be either a @code{compare} expression or a value that may have any mode.
1754: The latter case represents a ``test'' instruction. The expression
1755: @code{(set (cc0) (reg:@var{m} @var{n}))} is equivalent to
1756: @code{(set (cc0) (compare (reg:@var{m} @var{n}) (const_int 0)))}.
1757: Use the former expression to save space during the compilation.
1758:
1759: @cindex jump instructions and @code{set}
1760: @cindex @code{if_then_else} usage
1761: If @var{lval} is @code{(pc)}, we have a jump instruction, and the
1762: possibilities for @var{x} are very limited. It may be a
1763: @code{label_ref} expression (unconditional jump). It may be an
1764: @code{if_then_else} (conditional jump), in which case either the
1765: second or the third operand must be @code{(pc)} (for the case which
1766: does not jump) and the other of the two must be a @code{label_ref}
1767: (for the case which does jump). @var{x} may also be a @code{mem} or
1768: @code{(plus:SI (pc) @var{y})}, where @var{y} may be a @code{reg} or a
1769: @code{mem}; these unusual patterns are used to represent jumps through
1770: branch tables.@refill
1771:
1772: If @var{lval} is neither @code{(cc0)} nor @code{(pc)}, the mode of
1773: @var{lval} must not be @code{VOIDmode} and the mode of @var{x} must be
1774: valid for the mode of @var{lval}.
1775:
1776: @findex SET_DEST
1777: @findex SET_SRC
1778: @var{lval} is customarily accessed with the @code{SET_DEST} macro and
1779: @var{x} with the @code{SET_SRC} macro.
1780:
1781: @findex return
1782: @item (return)
1783: As the sole expression in a pattern, represents a return from the
1784: current function, on machines where this can be done with one
1785: instruction, such as Vaxes. On machines where a multi-instruction
1786: ``epilogue'' must be executed in order to return from the function,
1787: returning is done by jumping to a label which precedes the epilogue, and
1788: the @code{return} expression code is never used.
1789:
1790: Inside an @code{if_then_else} expression, represents the value to be
1791: placed in @code{pc} to return to the caller.
1792:
1793: Note that an insn pattern of @code{(return)} is logically equivalent to
1794: @code{(set (pc) (return))}, but the latter form is never used.
1795:
1796: @findex call
1797: @item (call @var{function} @var{nargs})
1798: Represents a function call. @var{function} is a @code{mem} expression
1799: whose address is the address of the function to be called.
1800: @var{nargs} is an expression which can be used for two purposes: on
1801: some machines it represents the number of bytes of stack argument; on
1802: others, it represents the number of argument registers.
1803:
1804: Each machine has a standard machine mode which @var{function} must
1805: have. The machine description defines macro @code{FUNCTION_MODE} to
1806: expand into the requisite mode name. The purpose of this mode is to
1807: specify what kind of addressing is allowed, on machines where the
1808: allowed kinds of addressing depend on the machine mode being
1809: addressed.
1810:
1811: @findex clobber
1812: @item (clobber @var{x})
1813: Represents the storing or possible storing of an unpredictable,
1814: undescribed value into @var{x}, which must be a @code{reg},
1815: @code{scratch} or @code{mem} expression.
1816:
1817: One place this is used is in string instructions that store standard
1818: values into particular hard registers. It may not be worth the
1819: trouble to describe the values that are stored, but it is essential to
1820: inform the compiler that the registers will be altered, lest it
1821: attempt to keep data in them across the string instruction.
1822:
1823: If @var{x} is @code{(mem:BLK (const_int 0))}, it means that all memory
1824: locations must be presumed clobbered.
1825:
1826: Note that the machine description classifies certain hard registers as
1827: ``call-clobbered''. All function call instructions are assumed by
1828: default to clobber these registers, so there is no need to use
1829: @code{clobber} expressions to indicate this fact. Also, each function
1830: call is assumed to have the potential to alter any memory location,
1831: unless the function is declared @code{const}.
1832:
1833: If the last group of expressions in a @code{parallel} are each a
1834: @code{clobber} expression whose arguments are @code{reg} or
1835: @code{match_scratch} (@pxref{RTL Template}) expressions, the combiner
1836: phase can add the appropriate @code{clobber} expressions to an insn it
1837: has constructed when doing so will cause a pattern to be matched.
1838:
1839: This feature can be used, for example, on a machine that whose multiply
1840: and add instructions don't use an MQ register but which has an
1841: add-accumulate instruction that does clobber the MQ register. Similarly,
1842: a combined instruction might require a temporary register while the
1843: constituent instructions might not.
1844:
1845: When a @code{clobber} expression for a register appears inside a
1846: @code{parallel} with other side effects, the register allocator
1847: guarantees that the register is unoccupied both before and after that
1848: insn. However, the reload phase may allocate a register used for one of
1849: the inputs unless the @samp{&} constraint is specified for the selected
1850: alternative (@pxref{Modifiers}). You can clobber either a specific hard
1851: register, a pseudo register, or a @code{scratch} expression; in the
1852: latter two cases, GNU CC will allocate a hard register that is available
1853: there for use as a temporary.
1854:
1855: For instructions that require a temporary register, you should use
1856: @code{scratch} instead of a pseudo-register because this will allow the
1857: combiner phase to add the @code{clobber} when required. You do this by
1858: coding (@code{clobber} (@code{match_scratch} @dots{})). If you do
1859: clobber a pseudo register, use one which appears nowhere else---generate
1860: a new one each time. Otherwise, you may confuse CSE.
1861:
1862: There is one other known use for clobbering a pseudo register in a
1863: @code{parallel}: when one of the input operands of the insn is also
1864: clobbered by the insn. In this case, using the same pseudo register in
1865: the clobber and elsewhere in the insn produces the expected results.
1866:
1867: @findex use
1868: @item (use @var{x})
1869: Represents the use of the value of @var{x}. It indicates that the
1870: value in @var{x} at this point in the program is needed, even though
1871: it may not be apparent why this is so. Therefore, the compiler will
1872: not attempt to delete previous instructions whose only effect is to
1873: store a value in @var{x}. @var{x} must be a @code{reg} expression.
1874:
1875: During the delayed branch scheduling phase, @var{x} may be an insn.
1876: This indicates that @var{x} previously was located at this place in the
1877: code and its data dependencies need to be taken into account. These
1878: @code{use} insns will be deleted before the delayed branch scheduling
1879: phase exits.
1880:
1881: @findex parallel
1882: @item (parallel [@var{x0} @var{x1} @dots{}])
1883: Represents several side effects performed in parallel. The square
1884: brackets stand for a vector; the operand of @code{parallel} is a
1885: vector of expressions. @var{x0}, @var{x1} and so on are individual
1886: side effect expressions---expressions of code @code{set}, @code{call},
1887: @code{return}, @code{clobber} or @code{use}.@refill
1888:
1889: ``In parallel'' means that first all the values used in the individual
1890: side-effects are computed, and second all the actual side-effects are
1891: performed. For example,
1892:
1893: @example
1894: (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
1895: (set (mem:SI (reg:SI 1)) (reg:SI 1))])
1896: @end example
1897:
1898: @noindent
1899: says unambiguously that the values of hard register 1 and the memory
1900: location addressed by it are interchanged. In both places where
1901: @code{(reg:SI 1)} appears as a memory address it refers to the value
1902: in register 1 @emph{before} the execution of the insn.
1903:
1904: It follows that it is @emph{incorrect} to use @code{parallel} and
1905: expect the result of one @code{set} to be available for the next one.
1906: For example, people sometimes attempt to represent a jump-if-zero
1907: instruction this way:
1908:
1909: @example
1910: (parallel [(set (cc0) (reg:SI 34))
1911: (set (pc) (if_then_else
1912: (eq (cc0) (const_int 0))
1913: (label_ref @dots{})
1914: (pc)))])
1915: @end example
1916:
1917: @noindent
1918: But this is incorrect, because it says that the jump condition depends
1919: on the condition code value @emph{before} this instruction, not on the
1920: new value that is set by this instruction.
1921:
1922: @cindex peephole optimization, RTL representation
1923: Peephole optimization, which takes place together with final assembly
1924: code output, can produce insns whose patterns consist of a @code{parallel}
1925: whose elements are the operands needed to output the resulting
1926: assembler code---often @code{reg}, @code{mem} or constant expressions.
1927: This would not be well-formed RTL at any other stage in compilation,
1928: but it is ok then because no further optimization remains to be done.
1929: However, the definition of the macro @code{NOTICE_UPDATE_CC}, if
1930: any, must deal with such insns if you define any peephole optimizations.
1931:
1932: @findex sequence
1933: @item (sequence [@var{insns} @dots{}])
1934: Represents a sequence of insns. Each of the @var{insns} that appears
1935: in the vector is suitable for appearing in the chain of insns, so it
1936: must be an @code{insn}, @code{jump_insn}, @code{call_insn},
1937: @code{code_label}, @code{barrier} or @code{note}.
1938:
1939: A @code{sequence} RTX is never placed in an actual insn during RTL
1940: generation. It represents the sequence of insns that result from a
1941: @code{define_expand} @emph{before} those insns are passed to
1942: @code{emit_insn} to insert them in the chain of insns. When actually
1943: inserted, the individual sub-insns are separated out and the
1944: @code{sequence} is forgotten.
1945:
1946: After delay-slot scheduling is completed, an insn and all the insns that
1947: reside in its delay slots are grouped together into a @code{sequence}.
1948: The insn requiring the delay slot is the first insn in the vector;
1949: subsequent insns are to be placed in the delay slot.
1950:
1951: @code{INSN_ANNULLED_BRANCH_P} is set on an insn in a delay slot to
1952: indicate that a branch insn should be used that will conditionally annul
1953: the effect of the insns in the delay slots. In such a case,
1954: @code{INSN_FROM_TARGET_P} indicates that the insn is from the target of
1955: the branch and should be executed only if the branch is taken; otherwise
1956: the insn should be executed only if the branch is not taken.
1957: @xref{Delay Slots}.
1958: @end table
1959:
1960: These expression codes appear in place of a side effect, as the body of
1961: an insn, though strictly speaking they do not always describe side
1962: effects as such:
1963:
1964: @table @code
1965: @findex asm_input
1966: @item (asm_input @var{s})
1967: Represents literal assembler code as described by the string @var{s}.
1968:
1969: @findex unspec
1970: @findex unspec_volatile
1971: @item (unspec [@var{operands} @dots{}] @var{index})
1.1.1.2 root 1972: @itemx (unspec_volatile [@var{operands} @dots{}] @var{index})
1.1 root 1973: Represents a machine-specific operation on @var{operands}. @var{index}
1.1.1.2 root 1974: selects between multiple machine-specific operations.
1.1 root 1975: @code{unspec_volatile} is used for volatile operations and operations
1976: that may trap; @code{unspec} is used for other operations.
1977:
1.1.1.2 root 1978: These codes may appear inside a @code{pattern} of an
1.1 root 1979: insn, inside a @code{parallel}, or inside an expression.
1980:
1981: @findex addr_vec
1982: @item (addr_vec:@var{m} [@var{lr0} @var{lr1} @dots{}])
1983: Represents a table of jump addresses. The vector elements @var{lr0},
1984: etc., are @code{label_ref} expressions. The mode @var{m} specifies
1985: how much space is given to each address; normally @var{m} would be
1986: @code{Pmode}.
1987:
1988: @findex addr_diff_vec
1989: @item (addr_diff_vec:@var{m} @var{base} [@var{lr0} @var{lr1} @dots{}])
1990: Represents a table of jump addresses expressed as offsets from
1991: @var{base}. The vector elements @var{lr0}, etc., are @code{label_ref}
1992: expressions and so is @var{base}. The mode @var{m} specifies how much
1993: space is given to each address-difference.@refill
1994: @end table
1995:
1996: @node Incdec, Assembler, Side Effects, RTL
1997: @section Embedded Side-Effects on Addresses
1998: @cindex RTL preincrement
1999: @cindex RTL postincrement
2000: @cindex RTL predecrement
2001: @cindex RTL postdecrement
2002:
2003: Four special side-effect expression codes appear as memory addresses.
2004:
2005: @table @code
2006: @findex pre_dec
2007: @item (pre_dec:@var{m} @var{x})
2008: Represents the side effect of decrementing @var{x} by a standard
2009: amount and represents also the value that @var{x} has after being
2010: decremented. @var{x} must be a @code{reg} or @code{mem}, but most
2011: machines allow only a @code{reg}. @var{m} must be the machine mode
2012: for pointers on the machine in use. The amount @var{x} is decremented
2013: by is the length in bytes of the machine mode of the containing memory
2014: reference of which this expression serves as the address. Here is an
2015: example of its use:@refill
2016:
2017: @example
2018: (mem:DF (pre_dec:SI (reg:SI 39)))
2019: @end example
2020:
2021: @noindent
2022: This says to decrement pseudo register 39 by the length of a @code{DFmode}
2023: value and use the result to address a @code{DFmode} value.
2024:
2025: @findex pre_inc
2026: @item (pre_inc:@var{m} @var{x})
2027: Similar, but specifies incrementing @var{x} instead of decrementing it.
2028:
2029: @findex post_dec
2030: @item (post_dec:@var{m} @var{x})
2031: Represents the same side effect as @code{pre_dec} but a different
2032: value. The value represented here is the value @var{x} has @i{before}
2033: being decremented.
2034:
2035: @findex post_inc
2036: @item (post_inc:@var{m} @var{x})
2037: Similar, but specifies incrementing @var{x} instead of decrementing it.
2038: @end table
2039:
2040: These embedded side effect expressions must be used with care. Instruction
2041: patterns may not use them. Until the @samp{flow} pass of the compiler,
2042: they may occur only to represent pushes onto the stack. The @samp{flow}
2043: pass finds cases where registers are incremented or decremented in one
2044: instruction and used as an address shortly before or after; these cases are
2045: then transformed to use pre- or post-increment or -decrement.
2046:
2047: If a register used as the operand of these expressions is used in
2048: another address in an insn, the original value of the register is used.
2049: Uses of the register outside of an address are not permitted within the
2050: same insn as a use in an embedded side effect expression because such
2051: insns behave differently on different machines and hence must be treated
2052: as ambiguous and disallowed.
2053:
2054: An instruction that can be represented with an embedded side effect
2055: could also be represented using @code{parallel} containing an additional
2056: @code{set} to describe how the address register is altered. This is not
2057: done because machines that allow these operations at all typically
2058: allow them wherever a memory address is called for. Describing them as
2059: additional parallel stores would require doubling the number of entries
2060: in the machine description.
2061:
1.1.1.5 root 2062: @node Assembler, Insns, Incdec, RTL
1.1 root 2063: @section Assembler Instructions as Expressions
2064: @cindex assembler instructions in RTL
2065:
2066: @cindex @code{asm_operands}, usage
2067: The RTX code @code{asm_operands} represents a value produced by a
2068: user-specified assembler instruction. It is used to represent
2069: an @code{asm} statement with arguments. An @code{asm} statement with
2070: a single output operand, like this:
2071:
1.1.1.5 root 2072: @smallexample
1.1 root 2073: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
1.1.1.5 root 2074: @end smallexample
1.1 root 2075:
2076: @noindent
2077: is represented using a single @code{asm_operands} RTX which represents
2078: the value that is stored in @code{outputvar}:
2079:
1.1.1.5 root 2080: @smallexample
1.1 root 2081: (set @var{rtx-for-outputvar}
2082: (asm_operands "foo %1,%2,%0" "a" 0
2083: [@var{rtx-for-addition-result} @var{rtx-for-*z}]
2084: [(asm_input:@var{m1} "g")
2085: (asm_input:@var{m2} "di")]))
1.1.1.5 root 2086: @end smallexample
1.1 root 2087:
2088: @noindent
2089: Here the operands of the @code{asm_operands} RTX are the assembler
2090: template string, the output-operand's constraint, the index-number of the
2091: output operand among the output operands specified, a vector of input
2092: operand RTX's, and a vector of input-operand modes and constraints. The
2093: mode @var{m1} is the mode of the sum @code{x+y}; @var{m2} is that of
2094: @code{*z}.
2095:
2096: When an @code{asm} statement has multiple output values, its insn has
2097: several such @code{set} RTX's inside of a @code{parallel}. Each @code{set}
2098: contains a @code{asm_operands}; all of these share the same assembler
2099: template and vectors, but each contains the constraint for the respective
2100: output operand. They are also distinguished by the output-operand index
2101: number, which is 0, 1, @dots{} for successive output operands.
2102:
2103: @node Insns, Calls, Assembler, RTL
2104: @section Insns
2105: @cindex insns
2106:
2107: The RTL representation of the code for a function is a doubly-linked
2108: chain of objects called @dfn{insns}. Insns are expressions with
2109: special codes that are used for no other purpose. Some insns are
2110: actual instructions; others represent dispatch tables for @code{switch}
2111: statements; others represent labels to jump to or various sorts of
2112: declarative information.
2113:
2114: In addition to its own specific data, each insn must have a unique
2115: id-number that distinguishes it from all other insns in the current
2116: function (after delayed branch scheduling, copies of an insn with the
2117: same id-number may be present in multiple places in a function, but
2118: these copies will always be identical and will only appear inside a
2119: @code{sequence}), and chain pointers to the preceding and following
2120: insns. These three fields occupy the same position in every insn,
2121: independent of the expression code of the insn. They could be accessed
2122: with @code{XEXP} and @code{XINT}, but instead three special macros are
2123: always used:
2124:
2125: @table @code
2126: @findex INSN_UID
2127: @item INSN_UID (@var{i})
2128: Accesses the unique id of insn @var{i}.
2129:
2130: @findex PREV_INSN
2131: @item PREV_INSN (@var{i})
2132: Accesses the chain pointer to the insn preceding @var{i}.
2133: If @var{i} is the first insn, this is a null pointer.
2134:
2135: @findex NEXT_INSN
2136: @item NEXT_INSN (@var{i})
2137: Accesses the chain pointer to the insn following @var{i}.
2138: If @var{i} is the last insn, this is a null pointer.
2139: @end table
2140:
2141: @findex get_insns
2142: @findex get_last_insn
2143: The first insn in the chain is obtained by calling @code{get_insns}; the
2144: last insn is the result of calling @code{get_last_insn}. Within the
2145: chain delimited by these insns, the @code{NEXT_INSN} and
2146: @code{PREV_INSN} pointers must always correspond: if @var{insn} is not
2147: the first insn,
2148:
2149: @example
2150: NEXT_INSN (PREV_INSN (@var{insn})) == @var{insn}
2151: @end example
2152:
2153: @noindent
2154: is always true and if @var{insn} is not the last insn,
2155:
2156: @example
2157: PREV_INSN (NEXT_INSN (@var{insn})) == @var{insn}
2158: @end example
2159:
2160: @noindent
2161: is always true.
2162:
2163: After delay slot scheduling, some of the insns in the chain might be
2164: @code{sequence} expressions, which contain a vector of insns. The value
2165: of @code{NEXT_INSN} in all but the last of these insns is the next insn
2166: in the vector; the value of @code{NEXT_INSN} of the last insn in the vector
2167: is the same as the value of @code{NEXT_INSN} for the @code{sequence} in
2168: which it is contained. Similar rules apply for @code{PREV_INSN}.
2169:
2170: This means that the above invariants are not necessarily true for insns
2171: inside @code{sequence} expressions. Specifically, if @var{insn} is the
2172: first insn in a @code{sequence}, @code{NEXT_INSN (PREV_INSN (@var{insn}))}
2173: is the insn containing the @code{sequence} expression, as is the value
2174: of @code{PREV_INSN (NEXT_INSN (@var{insn}))} is @var{insn} is the last
2175: insn in the @code{sequence} expression. You can use these expressions
2176: to find the containing @code{sequence} expression.@refill
2177:
2178: Every insn has one of the following six expression codes:
2179:
2180: @table @code
2181: @findex insn
2182: @item insn
2183: The expression code @code{insn} is used for instructions that do not jump
2184: and do not do function calls. @code{sequence} expressions are always
2185: contained in insns with code @code{insn} even if one of those insns
2186: should jump or do function calls.
2187:
2188: Insns with code @code{insn} have four additional fields beyond the three
2189: mandatory ones listed above. These four are described in a table below.
2190:
2191: @findex jump_insn
2192: @item jump_insn
2193: The expression code @code{jump_insn} is used for instructions that may
2194: jump (or, more generally, may contain @code{label_ref} expressions). If
2195: there is an instruction to return from the current function, it is
2196: recorded as a @code{jump_insn}.
2197:
2198: @findex JUMP_LABEL
2199: @code{jump_insn} insns have the same extra fields as @code{insn} insns,
1.1.1.7 root 2200: accessed in the same way and in addition contain a field
1.1 root 2201: @code{JUMP_LABEL} which is defined once jump optimization has completed.
2202:
2203: For simple conditional and unconditional jumps, this field contains the
2204: @code{code_label} to which this insn will (possibly conditionally)
2205: branch. In a more complex jump, @code{JUMP_LABEL} records one of the
2206: labels that the insn refers to; the only way to find the others
2207: is to scan the entire body of the insn.
2208:
2209: Return insns count as jumps, but since they do not refer to any labels,
2210: they have zero in the @code{JUMP_LABEL} field.
2211:
2212: @findex call_insn
2213: @item call_insn
2214: The expression code @code{call_insn} is used for instructions that may do
2215: function calls. It is important to distinguish these instructions because
2216: they imply that certain registers and memory locations may be altered
2217: unpredictably.
2218:
1.1.1.7 root 2219: @findex CALL_INSN_FUNCTION_USAGE
1.1 root 2220: @code{call_insn} insns have the same extra fields as @code{insn} insns,
1.1.1.7 root 2221: accessed in the same way and in addition contain a field
2222: @code{CALL_INSN_FUNCTION_USAGE}, which contains a list (chain of
2223: @code{expr_list} expressions) containing @code{use} and @code{clobber}
2224: expressions that denote hard registers used or clobbered by the called
2225: function. A register specified in a @code{clobber} in this list is
2226: modified @emph{after} the execution of the @code{call_insn}, while a
2227: register in a @code{clobber} in the body of the @code{call_insn} is
2228: clobbered before the insn completes execution. @code{clobber}
2229: expressions in this list augment registers specified in
2230: @code{CALL_USED_REGISTERS} (@pxref{Register Basics}).
1.1 root 2231:
2232: @findex code_label
2233: @findex CODE_LABEL_NUMBER
2234: @item code_label
2235: A @code{code_label} insn represents a label that a jump insn can jump
2236: to. It contains two special fields of data in addition to the three
2237: standard ones. @code{CODE_LABEL_NUMBER} is used to hold the @dfn{label
2238: number}, a number that identifies this label uniquely among all the
2239: labels in the compilation (not just in the current function).
2240: Ultimately, the label is represented in the assembler output as an
2241: assembler label, usually of the form @samp{L@var{n}} where @var{n} is
2242: the label number.
2243:
2244: When a @code{code_label} appears in an RTL expression, it normally
2245: appears within a @code{label_ref} which represents the address of
2246: the label, as a number.
2247:
2248: @findex LABEL_NUSES
2249: The field @code{LABEL_NUSES} is only defined once the jump optimization
2250: phase is completed and contains the number of times this label is
2251: referenced in the current function.
2252:
2253: @findex barrier
2254: @item barrier
2255: Barriers are placed in the instruction stream when control cannot flow
2256: past them. They are placed after unconditional jump instructions to
2257: indicate that the jumps are unconditional and after calls to
2258: @code{volatile} functions, which do not return (e.g., @code{exit}).
2259: They contain no information beyond the three standard fields.
2260:
2261: @findex note
2262: @findex NOTE_LINE_NUMBER
2263: @findex NOTE_SOURCE_FILE
2264: @item note
2265: @code{note} insns are used to represent additional debugging and
2266: declarative information. They contain two nonstandard fields, an
2267: integer which is accessed with the macro @code{NOTE_LINE_NUMBER} and a
2268: string accessed with @code{NOTE_SOURCE_FILE}.
2269:
2270: If @code{NOTE_LINE_NUMBER} is positive, the note represents the
2271: position of a source line and @code{NOTE_SOURCE_FILE} is the source file name
2272: that the line came from. These notes control generation of line
2273: number data in the assembler output.
2274:
2275: Otherwise, @code{NOTE_LINE_NUMBER} is not really a line number but a
2276: code with one of the following values (and @code{NOTE_SOURCE_FILE}
2277: must contain a null pointer):
2278:
2279: @table @code
2280: @findex NOTE_INSN_DELETED
2281: @item NOTE_INSN_DELETED
2282: Such a note is completely ignorable. Some passes of the compiler
2283: delete insns by altering them into notes of this kind.
2284:
2285: @findex NOTE_INSN_BLOCK_BEG
2286: @findex NOTE_INSN_BLOCK_END
2287: @item NOTE_INSN_BLOCK_BEG
2288: @itemx NOTE_INSN_BLOCK_END
2289: These types of notes indicate the position of the beginning and end
2290: of a level of scoping of variable names. They control the output
2291: of debugging information.
2292:
2293: @findex NOTE_INSN_LOOP_BEG
2294: @findex NOTE_INSN_LOOP_END
2295: @item NOTE_INSN_LOOP_BEG
2296: @itemx NOTE_INSN_LOOP_END
2297: These types of notes indicate the position of the beginning and end
2298: of a @code{while} or @code{for} loop. They enable the loop optimizer
2299: to find loops quickly.
2300:
2301: @findex NOTE_INSN_LOOP_CONT
2302: @item NOTE_INSN_LOOP_CONT
2303: Appears at the place in a loop that @code{continue} statements jump to.
2304:
2305: @findex NOTE_INSN_LOOP_VTOP
2306: @item NOTE_INSN_LOOP_VTOP
2307: This note indicates the place in a loop where the exit test begins for
2308: those loops in which the exit test has been duplicated. This position
2309: becomes another virtual start of the loop when considering loop
2310: invariants.
2311:
2312: @findex NOTE_INSN_FUNCTION_END
2313: @item NOTE_INSN_FUNCTION_END
2314: Appears near the end of the function body, just before the label that
2315: @code{return} statements jump to (on machine where a single instruction
2316: does not suffice for returning). This note may be deleted by jump
2317: optimization.
2318:
2319: @findex NOTE_INSN_SETJMP
2320: @item NOTE_INSN_SETJMP
2321: Appears following each call to @code{setjmp} or a related function.
2322: @end table
2323:
2324: These codes are printed symbolically when they appear in debugging dumps.
2325: @end table
2326:
2327: @cindex @code{HImode}, in @code{insn}
2328: @cindex @code{QImode}, in @code{insn}
2329: The machine mode of an insn is normally @code{VOIDmode}, but some
2330: phases use the mode for various purposes; for example, the reload pass
2331: sets it to @code{HImode} if the insn needs reloading but not register
2332: elimination and @code{QImode} if both are required. The common
2333: subexpression elimination pass sets the mode of an insn to @code{QImode}
2334: when it is the first insn in a block that has already been processed.
2335:
2336: Here is a table of the extra fields of @code{insn}, @code{jump_insn}
2337: and @code{call_insn} insns:
2338:
2339: @table @code
2340: @findex PATTERN
2341: @item PATTERN (@var{i})
2342: An expression for the side effect performed by this insn. This must be
2343: one of the following codes: @code{set}, @code{call}, @code{use},
2344: @code{clobber}, @code{return}, @code{asm_input}, @code{asm_output},
2345: @code{addr_vec}, @code{addr_diff_vec}, @code{trap_if}, @code{unspec},
1.1.1.4 root 2346: @code{unspec_volatile}, @code{parallel}, or @code{sequence}. If it is a @code{parallel},
1.1 root 2347: each element of the @code{parallel} must be one these codes, except that
2348: @code{parallel} expressions cannot be nested and @code{addr_vec} and
2349: @code{addr_diff_vec} are not permitted inside a @code{parallel} expression.
2350:
2351: @findex INSN_CODE
2352: @item INSN_CODE (@var{i})
2353: An integer that says which pattern in the machine description matches
2354: this insn, or -1 if the matching has not yet been attempted.
2355:
2356: Such matching is never attempted and this field remains -1 on an insn
2357: whose pattern consists of a single @code{use}, @code{clobber},
2358: @code{asm_input}, @code{addr_vec} or @code{addr_diff_vec} expression.
2359:
2360: @findex asm_noperands
2361: Matching is also never attempted on insns that result from an @code{asm}
2362: statement. These contain at least one @code{asm_operands} expression.
2363: The function @code{asm_noperands} returns a non-negative value for
2364: such insns.
2365:
2366: In the debugging output, this field is printed as a number followed by
2367: a symbolic representation that locates the pattern in the @file{md}
2368: file as some small positive or negative offset from a named pattern.
2369:
2370: @findex LOG_LINKS
2371: @item LOG_LINKS (@var{i})
2372: A list (chain of @code{insn_list} expressions) giving information about
2373: dependencies between instructions within a basic block. Neither a jump
2374: nor a label may come between the related insns.
2375:
2376: @findex REG_NOTES
2377: @item REG_NOTES (@var{i})
2378: A list (chain of @code{expr_list} and @code{insn_list} expressions)
2379: giving miscellaneous information about the insn. It is often information
2380: pertaining to the registers used in this insn.
2381: @end table
2382:
2383: The @code{LOG_LINKS} field of an insn is a chain of @code{insn_list}
2384: expressions. Each of these has two operands: the first is an insn,
2385: and the second is another @code{insn_list} expression (the next one in
2386: the chain). The last @code{insn_list} in the chain has a null pointer
2387: as second operand. The significant thing about the chain is which
2388: insns appear in it (as first operands of @code{insn_list}
2389: expressions). Their order is not significant.
2390:
2391: This list is originally set up by the flow analysis pass; it is a null
2392: pointer until then. Flow only adds links for those data dependencies
2393: which can be used for instruction combination. For each insn, the flow
2394: analysis pass adds a link to insns which store into registers values
2395: that are used for the first time in this insn. The instruction
2396: scheduling pass adds extra links so that every dependence will be
2397: represented. Links represent data dependencies, antidependencies and
2398: output dependencies; the machine mode of the link distinguishes these
2399: three types: antidependencies have mode @code{REG_DEP_ANTI}, output
2400: dependencies have mode @code{REG_DEP_OUTPUT}, and data dependencies have
2401: mode @code{VOIDmode}.
2402:
2403: The @code{REG_NOTES} field of an insn is a chain similar to the
2404: @code{LOG_LINKS} field but it includes @code{expr_list} expressions in
2405: addition to @code{insn_list} expressions. There are several kinds
2406: of register notes, which are distinguished by the machine mode, which
2407: in a register note is really understood as being an @code{enum reg_note}.
2408: The first operand @var{op} of the note is data whose meaning depends on
2409: the kind of note.
2410:
2411: @findex REG_NOTE_KIND
2412: @findex PUT_REG_NOTE_KIND
1.1.1.4 root 2413: The macro @code{REG_NOTE_KIND (@var{x})} returns the kind of
1.1 root 2414: register note. Its counterpart, the macro @code{PUT_REG_NOTE_KIND
2415: (@var{x}, @var{newkind})} sets the register note type of @var{x} to be
2416: @var{newkind}.
2417:
2418: Register notes are of three classes: They may say something about an
2419: input to an insn, they may say something about an output of an insn, or
2420: they may create a linkage between two insns. There are also a set
2421: of values that are only used in @code{LOG_LINKS}.
2422:
2423: These register notes annotate inputs to an insn:
2424:
2425: @table @code
2426: @findex REG_DEAD
2427: @item REG_DEAD
2428: The value in @var{op} dies in this insn; that is to say, altering the
2429: value immediately after this insn would not affect the future behavior
2430: of the program.
2431:
2432: This does not necessarily mean that the register @var{op} has no useful
2433: value after this insn since it may also be an output of the insn. In
2434: such a case, however, a @code{REG_DEAD} note would be redundant and is
2435: usually not present until after the reload pass, but no code relies on
2436: this fact.
2437:
2438: @findex REG_INC
2439: @item REG_INC
2440: The register @var{op} is incremented (or decremented; at this level
2441: there is no distinction) by an embedded side effect inside this insn.
2442: This means it appears in a @code{post_inc}, @code{pre_inc},
2443: @code{post_dec} or @code{pre_dec} expression.
2444:
2445: @findex REG_NONNEG
2446: @item REG_NONNEG
2447: The register @var{op} is known to have a nonnegative value when this
2448: insn is reached. This is used so that decrement and branch until zero
2449: instructions, such as the m68k dbra, can be matched.
2450:
2451: The @code{REG_NONNEG} note is added to insns only if the machine
1.1.1.5 root 2452: description has a @samp{decrement_and_branch_until_zero} pattern.
1.1 root 2453:
2454: @findex REG_NO_CONFLICT
2455: @item REG_NO_CONFLICT
2456: This insn does not cause a conflict between @var{op} and the item
2457: being set by this insn even though it might appear that it does.
2458: In other words, if the destination register and @var{op} could
2459: otherwise be assigned the same register, this insn does not
2460: prevent that assignment.
2461:
2462: Insns with this note are usually part of a block that begins with a
2463: @code{clobber} insn specifying a multi-word pseudo register (which will
2464: be the output of the block), a group of insns that each set one word of
2465: the value and have the @code{REG_NO_CONFLICT} note attached, and a final
2466: insn that copies the output to itself with an attached @code{REG_EQUAL}
2467: note giving the expression being computed. This block is encapsulated
2468: with @code{REG_LIBCALL} and @code{REG_RETVAL} notes on the first and
2469: last insns, respectively.
2470:
2471: @findex REG_LABEL
2472: @item REG_LABEL
2473: This insn uses @var{op}, a @code{code_label}, but is not a
2474: @code{jump_insn}. The presence of this note allows jump optimization to
2475: be aware that @var{op} is, in fact, being used.
2476: @end table
2477:
2478: The following notes describe attributes of outputs of an insn:
2479:
2480: @table @code
2481: @findex REG_EQUIV
2482: @findex REG_EQUAL
2483: @item REG_EQUIV
2484: @itemx REG_EQUAL
2485: This note is only valid on an insn that sets only one register and
2486: indicates that that register will be equal to @var{op} at run time; the
2487: scope of this equivalence differs between the two types of notes. The
2488: value which the insn explicitly copies into the register may look
2489: different from @var{op}, but they will be equal at run time. If the
2490: output of the single @code{set} is a @code{strict_low_part} expression,
2491: the note refers to the register that is contained in @code{SUBREG_REG}
2492: of the @code{subreg} expression.
2493:
2494: For @code{REG_EQUIV}, the register is equivalent to @var{op} throughout
2495: the entire function, and could validly be replaced in all its
2496: occurrences by @var{op}. (``Validly'' here refers to the data flow of
2497: the program; simple replacement may make some insns invalid.) For
2498: example, when a constant is loaded into a register that is never
2499: assigned any other value, this kind of note is used.
2500:
2501: When a parameter is copied into a pseudo-register at entry to a function,
2502: a note of this kind records that the register is equivalent to the stack
2503: slot where the parameter was passed. Although in this case the register
2504: may be set by other insns, it is still valid to replace the register
2505: by the stack slot throughout the function.
2506:
2507: In the case of @code{REG_EQUAL}, the register that is set by this insn
2508: will be equal to @var{op} at run time at the end of this insn but not
2509: necessarily elsewhere in the function. In this case, @var{op}
2510: is typically an arithmetic expression. For example, when a sequence of
2511: insns such as a library call is used to perform an arithmetic operation,
2512: this kind of note is attached to the insn that produces or copies the
2513: final value.
2514:
2515: These two notes are used in different ways by the compiler passes.
2516: @code{REG_EQUAL} is used by passes prior to register allocation (such as
2517: common subexpression elimination and loop optimization) to tell them how
2518: to think of that value. @code{REG_EQUIV} notes are used by register
2519: allocation to indicate that there is an available substitute expression
2520: (either a constant or a @code{mem} expression for the location of a
2521: parameter on the stack) that may be used in place of a register if
2522: insufficient registers are available.
2523:
2524: Except for stack homes for parameters, which are indicated by a
2525: @code{REG_EQUIV} note and are not useful to the early optimization
2526: passes and pseudo registers that are equivalent to a memory location
2527: throughout there entire life, which is not detected until later in
2528: the compilation, all equivalences are initially indicated by an attached
2529: @code{REG_EQUAL} note. In the early stages of register allocation, a
2530: @code{REG_EQUAL} note is changed into a @code{REG_EQUIV} note if
2531: @var{op} is a constant and the insn represents the only set of its
2532: destination register.
2533:
2534: Thus, compiler passes prior to register allocation need only check for
2535: @code{REG_EQUAL} notes and passes subsequent to register allocation
2536: need only check for @code{REG_EQUIV} notes.
2537:
2538: @findex REG_UNUSED
2539: @item REG_UNUSED
2540: The register @var{op} being set by this insn will not be used in a
2541: subsequent insn. This differs from a @code{REG_DEAD} note, which
2542: indicates that the value in an input will not be used subsequently.
2543: These two notes are independent; both may be present for the same
2544: register.
2545:
2546: @findex REG_WAS_0
2547: @item REG_WAS_0
2548: The single output of this insn contained zero before this insn.
2549: @var{op} is the insn that set it to zero. You can rely on this note if
2550: it is present and @var{op} has not been deleted or turned into a @code{note};
2551: its absence implies nothing.
2552: @end table
2553:
2554: These notes describe linkages between insns. They occur in pairs: one
2555: insn has one of a pair of notes that points to a second insn, which has
2556: the inverse note pointing back to the first insn.
2557:
2558: @table @code
2559: @findex REG_RETVAL
2560: @item REG_RETVAL
2561: This insn copies the value of a multi-insn sequence (for example, a
2562: library call), and @var{op} is the first insn of the sequence (for a
2563: library call, the first insn that was generated to set up the arguments
2564: for the library call).
2565:
2566: Loop optimization uses this note to treat such a sequence as a single
2567: operation for code motion purposes and flow analysis uses this note to
2568: delete such sequences whose results are dead.
2569:
2570: A @code{REG_EQUAL} note will also usually be attached to this insn to
2571: provide the expression being computed by the sequence.
2572:
2573: @findex REG_LIBCALL
2574: @item REG_LIBCALL
2575: This is the inverse of @code{REG_RETVAL}: it is placed on the first
2576: insn of a multi-insn sequence, and it points to the last one.
2577:
2578: @findex REG_CC_SETTER
2579: @findex REG_CC_USER
2580: @item REG_CC_SETTER
2581: @itemx REG_CC_USER
2582: On machines that use @code{cc0}, the insns which set and use @code{cc0}
2583: set and use @code{cc0} are adjacent. However, when branch delay slot
2584: filling is done, this may no longer be true. In this case a
2585: @code{REG_CC_USER} note will be placed on the insn setting @code{cc0} to
2586: point to the insn using @code{cc0} and a @code{REG_CC_SETTER} note will
2587: be placed on the insn using @code{cc0} to point to the insn setting
2588: @code{cc0}.@refill
2589: @end table
2590:
2591: These values are only used in the @code{LOG_LINKS} field, and indicate
2592: the type of dependency that each link represents. Links which indicate
2593: a data dependence (a read after write dependence) do not use any code,
2594: they simply have mode @code{VOIDmode}, and are printed without any
2595: descriptive text.
2596:
2597: @table @code
2598: @findex REG_DEP_ANTI
2599: @item REG_DEP_ANTI
2600: This indicates an anti dependence (a write after read dependence).
2601:
2602: @findex REG_DEP_OUTPUT
2603: @item REG_DEP_OUTPUT
2604: This indicates an output dependence (a write after write dependence).
2605: @end table
2606:
2607: For convenience, the machine mode in an @code{insn_list} or
2608: @code{expr_list} is printed using these symbolic codes in debugging dumps.
2609:
2610: @findex insn_list
2611: @findex expr_list
2612: The only difference between the expression codes @code{insn_list} and
2613: @code{expr_list} is that the first operand of an @code{insn_list} is
2614: assumed to be an insn and is printed in debugging dumps as the insn's
2615: unique id; the first operand of an @code{expr_list} is printed in the
2616: ordinary way as an expression.
2617:
2618: @node Calls, Sharing, Insns, RTL
2619: @section RTL Representation of Function-Call Insns
2620: @cindex calling functions in RTL
2621: @cindex RTL function-call insns
2622: @cindex function-call insns
2623:
2624: Insns that call subroutines have the RTL expression code @code{call_insn}.
2625: These insns must satisfy special rules, and their bodies must use a special
2626: RTL expression code, @code{call}.
2627:
2628: @cindex @code{call} usage
2629: A @code{call} expression has two operands, as follows:
2630:
2631: @example
2632: (call (mem:@var{fm} @var{addr}) @var{nbytes})
2633: @end example
2634:
2635: @noindent
2636: Here @var{nbytes} is an operand that represents the number of bytes of
2637: argument data being passed to the subroutine, @var{fm} is a machine mode
2638: (which must equal as the definition of the @code{FUNCTION_MODE} macro in
2639: the machine description) and @var{addr} represents the address of the
2640: subroutine.
2641:
2642: For a subroutine that returns no value, the @code{call} expression as
2643: shown above is the entire body of the insn, except that the insn might
2644: also contain @code{use} or @code{clobber} expressions.
2645:
2646: @cindex @code{BLKmode}, and function return values
2647: For a subroutine that returns a value whose mode is not @code{BLKmode},
2648: the value is returned in a hard register. If this register's number is
2649: @var{r}, then the body of the call insn looks like this:
2650:
2651: @example
2652: (set (reg:@var{m} @var{r})
2653: (call (mem:@var{fm} @var{addr}) @var{nbytes}))
2654: @end example
2655:
2656: @noindent
2657: This RTL expression makes it clear (to the optimizer passes) that the
2658: appropriate register receives a useful value in this insn.
2659:
2660: When a subroutine returns a @code{BLKmode} value, it is handled by
2661: passing to the subroutine the address of a place to store the value.
2662: So the call insn itself does not ``return'' any value, and it has the
2663: same RTL form as a call that returns nothing.
2664:
2665: On some machines, the call instruction itself clobbers some register,
2666: for example to contain the return address. @code{call_insn} insns
2667: on these machines should have a body which is a @code{parallel}
2668: that contains both the @code{call} expression and @code{clobber}
2669: expressions that indicate which registers are destroyed. Similarly,
2670: if the call instruction requires some register other than the stack
2671: pointer that is not explicitly mentioned it its RTL, a @code{use}
2672: subexpression should mention that register.
2673:
2674: Functions that are called are assumed to modify all registers listed in
2675: the configuration macro @code{CALL_USED_REGISTERS} (@pxref{Register
2676: Basics}) and, with the exception of @code{const} functions and library
2677: calls, to modify all of memory.
2678:
2679: Insns containing just @code{use} expressions directly precede the
2680: @code{call_insn} insn to indicate which registers contain inputs to the
2681: function. Similarly, if registers other than those in
2682: @code{CALL_USED_REGISTERS} are clobbered by the called function, insns
2683: containing a single @code{clobber} follow immediately after the call to
2684: indicate which registers.
2685:
1.1.1.5 root 2686: @node Sharing
1.1 root 2687: @section Structure Sharing Assumptions
2688: @cindex sharing of RTL components
2689: @cindex RTL structure sharing assumptions
2690:
2691: The compiler assumes that certain kinds of RTL expressions are unique;
2692: there do not exist two distinct objects representing the same value.
2693: In other cases, it makes an opposite assumption: that no RTL expression
2694: object of a certain kind appears in more than one place in the
2695: containing structure.
2696:
2697: These assumptions refer to a single function; except for the RTL
2698: objects that describe global variables and external functions,
2699: and a few standard objects such as small integer constants,
2700: no RTL objects are common to two functions.
2701:
2702: @itemize @bullet
2703: @cindex @code{reg}, RTL sharing
2704: @item
2705: Each pseudo-register has only a single @code{reg} object to represent it,
2706: and therefore only a single machine mode.
2707:
2708: @cindex symbolic label
2709: @cindex @code{symbol_ref}, RTL sharing
2710: @item
2711: For any symbolic label, there is only one @code{symbol_ref} object
2712: referring to it.
2713:
2714: @cindex @code{const_int}, RTL sharing
2715: @item
2716: There is only one @code{const_int} expression with value 0, only
2717: one with value 1, and only one with value @minus{}1.
2718: Some other integer values are also stored uniquely.
2719:
2720: @cindex @code{pc}, RTL sharing
2721: @item
2722: There is only one @code{pc} expression.
2723:
2724: @cindex @code{cc0}, RTL sharing
2725: @item
2726: There is only one @code{cc0} expression.
2727:
2728: @cindex @code{const_double}, RTL sharing
2729: @item
2730: There is only one @code{const_double} expression with value 0 for
2731: each floating point mode. Likewise for values 1 and 2.
2732:
2733: @cindex @code{label_ref}, RTL sharing
2734: @cindex @code{scratch}, RTL sharing
2735: @item
2736: No @code{label_ref} or @code{scratch} appears in more than one place in
2737: the RTL structure; in other words, it is safe to do a tree-walk of all
2738: the insns in the function and assume that each time a @code{label_ref}
2739: or @code{scratch} is seen it is distinct from all others that are seen.
2740:
2741: @cindex @code{mem}, RTL sharing
2742: @item
2743: Only one @code{mem} object is normally created for each static
2744: variable or stack slot, so these objects are frequently shared in all
2745: the places they appear. However, separate but equal objects for these
2746: variables are occasionally made.
2747:
2748: @cindex @code{asm_operands}, RTL sharing
2749: @item
2750: When a single @code{asm} statement has multiple output operands, a
2751: distinct @code{asm_operands} expression is made for each output operand.
2752: However, these all share the vector which contains the sequence of input
2753: operands. This sharing is used later on to test whether two
2754: @code{asm_operands} expressions come from the same statement, so all
2755: optimizations must carefully preserve the sharing if they copy the
2756: vector at all.
2757:
2758: @item
2759: No RTL object appears in more than one place in the RTL structure
2760: except as described above. Many passes of the compiler rely on this
2761: by assuming that they can modify RTL objects in place without unwanted
2762: side-effects on other insns.
2763:
2764: @findex unshare_all_rtl
2765: @item
2766: During initial RTL generation, shared structure is freely introduced.
2767: After all the RTL for a function has been generated, all shared
2768: structure is copied by @code{unshare_all_rtl} in @file{emit-rtl.c},
2769: after which the above rules are guaranteed to be followed.
2770:
2771: @findex copy_rtx_if_shared
2772: @item
2773: During the combiner pass, shared structure within an insn can exist
2774: temporarily. However, the shared structure is copied before the
2775: combiner is finished with the insn. This is done by calling
2776: @code{copy_rtx_if_shared}, which is a subroutine of
2777: @code{unshare_all_rtl}.
2778: @end itemize
1.1.1.5 root 2779:
2780: @node Reading RTL
2781: @section Reading RTL
2782:
2783: To read an RTL object from a file, call @code{read_rtx}. It takes one
2784: argument, a stdio stream, and returns a single RTL object.
2785:
1.1.1.8 ! root 2786: Reading RTL from a file is very slow. This is not currently a
! 2787: problem since reading RTL occurs only as part of building the
1.1.1.5 root 2788: compiler.
2789:
2790: People frequently have the idea of using RTL stored as text in a file as
2791: an interface between a language front end and the bulk of GNU CC. This
2792: idea is not feasible.
2793:
2794: GNU CC was designed to use RTL internally only. Correct RTL for a given
2795: program is very dependent on the particular target machine. And the RTL
2796: does not contain all the information about the program.
2797:
2798: The proper way to interface GNU CC to a new language front end is with
2799: the ``tree'' data structure. There is no manual for this data
2800: structure, but it is described in the files @file{tree.h} and
2801: @file{tree.def}.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.