You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
470 lines
24 KiB
HTML
470 lines
24 KiB
HTML
4 years ago
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Copyright (C) 1988-2018 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being "Funding Free Software", the Front-Cover
|
||
|
|
Texts being (a) (see below), and with the Back-Cover Texts being (b)
|
||
|
|
(see below). A copy of the license is included in the section entitled
|
||
|
|
"GNU Free Documentation License".
|
||
|
|
|
||
|
|
(a) The FSF's Front-Cover Text is:
|
||
|
|
|
||
|
|
A GNU Manual
|
||
|
|
|
||
|
|
(b) The FSF's Back-Cover Text is:
|
||
|
|
|
||
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
||
|
|
software. Copies published by the Free Software Foundation raise
|
||
|
|
funds for GNU development. -->
|
||
|
|
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Side Effects (GNU Compiler Collection (GCC) Internals)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Side Effects (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="keywords" content="Side Effects (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="resource-type" content="document">
|
||
|
|
<meta name="distribution" content="global">
|
||
|
|
<meta name="Generator" content="makeinfo">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<link href="index.html#Top" rel="start" title="Top">
|
||
|
|
<link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
|
||
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
||
|
|
<link href="RTL.html#RTL" rel="up" title="RTL">
|
||
|
|
<link href="Incdec.html#Incdec" rel="next" title="Incdec">
|
||
|
|
<link href="RTL-Declarations.html#RTL-Declarations" rel="prev" title="RTL Declarations">
|
||
|
|
<style type="text/css">
|
||
|
|
<!--
|
||
|
|
a.summary-letter {text-decoration: none}
|
||
|
|
blockquote.indentedblock {margin-right: 0em}
|
||
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
div.smalllisp {margin-left: 3.2em}
|
||
|
|
kbd {font-style: oblique}
|
||
|
|
pre.display {font-family: inherit}
|
||
|
|
pre.format {font-family: inherit}
|
||
|
|
pre.menu-comment {font-family: serif}
|
||
|
|
pre.menu-preformatted {font-family: serif}
|
||
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smallexample {font-size: smaller}
|
||
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smalllisp {font-size: smaller}
|
||
|
|
span.nolinebreak {white-space: nowrap}
|
||
|
|
span.roman {font-family: initial; font-weight: normal}
|
||
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en">
|
||
|
|
<a name="Side-Effects"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Incdec.html#Incdec" accesskey="n" rel="next">Incdec</a>, Previous: <a href="RTL-Declarations.html#RTL-Declarations" accesskey="p" rel="prev">RTL Declarations</a>, Up: <a href="RTL.html#RTL" accesskey="u" rel="up">RTL</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
<hr>
|
||
|
|
<a name="Side-Effect-Expressions"></a>
|
||
|
|
<h3 class="section">14.15 Side Effect Expressions</h3>
|
||
|
|
<a name="index-RTL-side-effect-expressions"></a>
|
||
|
|
|
||
|
|
<p>The expression codes described so far represent values, not actions.
|
||
|
|
But machine instructions never produce values; they are meaningful
|
||
|
|
only for their side effects on the state of the machine. Special
|
||
|
|
expression codes are used to represent side effects.
|
||
|
|
</p>
|
||
|
|
<p>The body of an instruction is always one of these side effect codes;
|
||
|
|
the codes described above, which represent values, appear only as
|
||
|
|
the operands of these.
|
||
|
|
</p>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dd><a name="index-set"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(set <var>lval</var> <var>x</var>)</code></dt>
|
||
|
|
<dd><p>Represents the action of storing the value of <var>x</var> into the place
|
||
|
|
represented by <var>lval</var>. <var>lval</var> must be an expression
|
||
|
|
representing a place that can be stored in: <code>reg</code> (or <code>subreg</code>,
|
||
|
|
<code>strict_low_part</code> or <code>zero_extract</code>), <code>mem</code>, <code>pc</code>,
|
||
|
|
<code>parallel</code>, or <code>cc0</code>.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is a <code>reg</code>, <code>subreg</code> or <code>mem</code>, it has a
|
||
|
|
machine mode; then <var>x</var> must be valid for that mode.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is a <code>reg</code> whose machine mode is less than the full
|
||
|
|
width of the register, then it means that the part of the register
|
||
|
|
specified by the machine mode is given the specified value and the
|
||
|
|
rest of the register receives an undefined value. Likewise, if
|
||
|
|
<var>lval</var> is a <code>subreg</code> whose machine mode is narrower than
|
||
|
|
the mode of the register, the rest of the register can be changed in
|
||
|
|
an undefined way.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is a <code>strict_low_part</code> of a subreg, then the part
|
||
|
|
of the register specified by the machine mode of the <code>subreg</code> is
|
||
|
|
given the value <var>x</var> and the rest of the register is not changed.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is a <code>zero_extract</code>, then the referenced part of
|
||
|
|
the bit-field (a memory or register reference) specified by the
|
||
|
|
<code>zero_extract</code> is given the value <var>x</var> and the rest of the
|
||
|
|
bit-field is not changed. Note that <code>sign_extract</code> can not
|
||
|
|
appear in <var>lval</var>.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is <code>(cc0)</code>, it has no machine mode, and <var>x</var> may
|
||
|
|
be either a <code>compare</code> expression or a value that may have any mode.
|
||
|
|
The latter case represents a “test” instruction. The expression
|
||
|
|
<code>(set (cc0) (reg:<var>m</var> <var>n</var>))</code> is equivalent to
|
||
|
|
<code>(set (cc0) (compare (reg:<var>m</var> <var>n</var>) (const_int 0)))</code>.
|
||
|
|
Use the former expression to save space during the compilation.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is a <code>parallel</code>, it is used to represent the case of
|
||
|
|
a function returning a structure in multiple registers. Each element
|
||
|
|
of the <code>parallel</code> is an <code>expr_list</code> whose first operand is a
|
||
|
|
<code>reg</code> and whose second operand is a <code>const_int</code> representing the
|
||
|
|
offset (in bytes) into the structure at which the data in that register
|
||
|
|
corresponds. The first element may be null to indicate that the structure
|
||
|
|
is also passed partly in memory.
|
||
|
|
</p>
|
||
|
|
<a name="index-jump-instructions-and-set"></a>
|
||
|
|
<a name="index-if_005fthen_005felse-usage"></a>
|
||
|
|
<p>If <var>lval</var> is <code>(pc)</code>, we have a jump instruction, and the
|
||
|
|
possibilities for <var>x</var> are very limited. It may be a
|
||
|
|
<code>label_ref</code> expression (unconditional jump). It may be an
|
||
|
|
<code>if_then_else</code> (conditional jump), in which case either the
|
||
|
|
second or the third operand must be <code>(pc)</code> (for the case which
|
||
|
|
does not jump) and the other of the two must be a <code>label_ref</code>
|
||
|
|
(for the case which does jump). <var>x</var> may also be a <code>mem</code> or
|
||
|
|
<code>(plus:SI (pc) <var>y</var>)</code>, where <var>y</var> may be a <code>reg</code> or a
|
||
|
|
<code>mem</code>; these unusual patterns are used to represent jumps through
|
||
|
|
branch tables.
|
||
|
|
</p>
|
||
|
|
<p>If <var>lval</var> is neither <code>(cc0)</code> nor <code>(pc)</code>, the mode of
|
||
|
|
<var>lval</var> must not be <code>VOIDmode</code> and the mode of <var>x</var> must be
|
||
|
|
valid for the mode of <var>lval</var>.
|
||
|
|
</p>
|
||
|
|
<a name="index-SET_005fDEST"></a>
|
||
|
|
<a name="index-SET_005fSRC"></a>
|
||
|
|
<p><var>lval</var> is customarily accessed with the <code>SET_DEST</code> macro and
|
||
|
|
<var>x</var> with the <code>SET_SRC</code> macro.
|
||
|
|
</p>
|
||
|
|
<a name="index-return"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(return)</code></dt>
|
||
|
|
<dd><p>As the sole expression in a pattern, represents a return from the
|
||
|
|
current function, on machines where this can be done with one
|
||
|
|
instruction, such as VAXen. On machines where a multi-instruction
|
||
|
|
“epilogue” must be executed in order to return from the function,
|
||
|
|
returning is done by jumping to a label which precedes the epilogue, and
|
||
|
|
the <code>return</code> expression code is never used.
|
||
|
|
</p>
|
||
|
|
<p>Inside an <code>if_then_else</code> expression, represents the value to be
|
||
|
|
placed in <code>pc</code> to return to the caller.
|
||
|
|
</p>
|
||
|
|
<p>Note that an insn pattern of <code>(return)</code> is logically equivalent to
|
||
|
|
<code>(set (pc) (return))</code>, but the latter form is never used.
|
||
|
|
</p>
|
||
|
|
<a name="index-simple_005freturn"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(simple_return)</code></dt>
|
||
|
|
<dd><p>Like <code>(return)</code>, but truly represents only a function return, while
|
||
|
|
<code>(return)</code> may represent an insn that also performs other functions
|
||
|
|
of the function epilogue. Like <code>(return)</code>, this may also occur in
|
||
|
|
conditional jumps.
|
||
|
|
</p>
|
||
|
|
<a name="index-call-1"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(call <var>function</var> <var>nargs</var>)</code></dt>
|
||
|
|
<dd><p>Represents a function call. <var>function</var> is a <code>mem</code> expression
|
||
|
|
whose address is the address of the function to be called.
|
||
|
|
<var>nargs</var> is an expression which can be used for two purposes: on
|
||
|
|
some machines it represents the number of bytes of stack argument; on
|
||
|
|
others, it represents the number of argument registers.
|
||
|
|
</p>
|
||
|
|
<p>Each machine has a standard machine mode which <var>function</var> must
|
||
|
|
have. The machine description defines macro <code>FUNCTION_MODE</code> to
|
||
|
|
expand into the requisite mode name. The purpose of this mode is to
|
||
|
|
specify what kind of addressing is allowed, on machines where the
|
||
|
|
allowed kinds of addressing depend on the machine mode being
|
||
|
|
addressed.
|
||
|
|
</p>
|
||
|
|
<a name="index-clobber"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(clobber <var>x</var>)</code></dt>
|
||
|
|
<dd><p>Represents the storing or possible storing of an unpredictable,
|
||
|
|
undescribed value into <var>x</var>, which must be a <code>reg</code>,
|
||
|
|
<code>scratch</code>, <code>parallel</code> or <code>mem</code> expression.
|
||
|
|
</p>
|
||
|
|
<p>One place this is used is in string instructions that store standard
|
||
|
|
values into particular hard registers. It may not be worth the
|
||
|
|
trouble to describe the values that are stored, but it is essential to
|
||
|
|
inform the compiler that the registers will be altered, lest it
|
||
|
|
attempt to keep data in them across the string instruction.
|
||
|
|
</p>
|
||
|
|
<p>If <var>x</var> is <code>(mem:BLK (const_int 0))</code> or
|
||
|
|
<code>(mem:BLK (scratch))</code>, it means that all memory
|
||
|
|
locations must be presumed clobbered. If <var>x</var> is a <code>parallel</code>,
|
||
|
|
it has the same meaning as a <code>parallel</code> in a <code>set</code> expression.
|
||
|
|
</p>
|
||
|
|
<p>Note that the machine description classifies certain hard registers as
|
||
|
|
“call-clobbered”. All function call instructions are assumed by
|
||
|
|
default to clobber these registers, so there is no need to use
|
||
|
|
<code>clobber</code> expressions to indicate this fact. Also, each function
|
||
|
|
call is assumed to have the potential to alter any memory location,
|
||
|
|
unless the function is declared <code>const</code>.
|
||
|
|
</p>
|
||
|
|
<p>If the last group of expressions in a <code>parallel</code> are each a
|
||
|
|
<code>clobber</code> expression whose arguments are <code>reg</code> or
|
||
|
|
<code>match_scratch</code> (see <a href="RTL-Template.html#RTL-Template">RTL Template</a>) expressions, the combiner
|
||
|
|
phase can add the appropriate <code>clobber</code> expressions to an insn it
|
||
|
|
has constructed when doing so will cause a pattern to be matched.
|
||
|
|
</p>
|
||
|
|
<p>This feature can be used, for example, on a machine that whose multiply
|
||
|
|
and add instructions don’t use an MQ register but which has an
|
||
|
|
add-accumulate instruction that does clobber the MQ register. Similarly,
|
||
|
|
a combined instruction might require a temporary register while the
|
||
|
|
constituent instructions might not.
|
||
|
|
</p>
|
||
|
|
<p>When a <code>clobber</code> expression for a register appears inside a
|
||
|
|
<code>parallel</code> with other side effects, the register allocator
|
||
|
|
guarantees that the register is unoccupied both before and after that
|
||
|
|
insn if it is a hard register clobber. For pseudo-register clobber,
|
||
|
|
the register allocator and the reload pass do not assign the same hard
|
||
|
|
register to the clobber and the input operands if there is an insn
|
||
|
|
alternative containing the ‘<samp>&</samp>’ constraint (see <a href="Modifiers.html#Modifiers">Modifiers</a>) for
|
||
|
|
the clobber and the hard register is in register classes of the
|
||
|
|
clobber in the alternative. You can clobber either a specific hard
|
||
|
|
register, a pseudo register, or a <code>scratch</code> expression; in the
|
||
|
|
latter two cases, GCC will allocate a hard register that is available
|
||
|
|
there for use as a temporary.
|
||
|
|
</p>
|
||
|
|
<p>For instructions that require a temporary register, you should use
|
||
|
|
<code>scratch</code> instead of a pseudo-register because this will allow the
|
||
|
|
combiner phase to add the <code>clobber</code> when required. You do this by
|
||
|
|
coding (<code>clobber</code> (<code>match_scratch</code> …)). If you do
|
||
|
|
clobber a pseudo register, use one which appears nowhere else—generate
|
||
|
|
a new one each time. Otherwise, you may confuse CSE.
|
||
|
|
</p>
|
||
|
|
<p>There is one other known use for clobbering a pseudo register in a
|
||
|
|
<code>parallel</code>: when one of the input operands of the insn is also
|
||
|
|
clobbered by the insn. In this case, using the same pseudo register in
|
||
|
|
the clobber and elsewhere in the insn produces the expected results.
|
||
|
|
</p>
|
||
|
|
<a name="index-use"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(use <var>x</var>)</code></dt>
|
||
|
|
<dd><p>Represents the use of the value of <var>x</var>. It indicates that the
|
||
|
|
value in <var>x</var> at this point in the program is needed, even though
|
||
|
|
it may not be apparent why this is so. Therefore, the compiler will
|
||
|
|
not attempt to delete previous instructions whose only effect is to
|
||
|
|
store a value in <var>x</var>. <var>x</var> must be a <code>reg</code> expression.
|
||
|
|
</p>
|
||
|
|
<p>In some situations, it may be tempting to add a <code>use</code> of a
|
||
|
|
register in a <code>parallel</code> to describe a situation where the value
|
||
|
|
of a special register will modify the behavior of the instruction.
|
||
|
|
A hypothetical example might be a pattern for an addition that can
|
||
|
|
either wrap around or use saturating addition depending on the value
|
||
|
|
of a special control register:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
|
||
|
|
(reg:SI 4)] 0))
|
||
|
|
(use (reg:SI 1))])
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
|
||
|
|
<p>This will not work, several of the optimizers only look at expressions
|
||
|
|
locally; it is very likely that if you have multiple insns with
|
||
|
|
identical inputs to the <code>unspec</code>, they will be optimized away even
|
||
|
|
if register 1 changes in between.
|
||
|
|
</p>
|
||
|
|
<p>This means that <code>use</code> can <em>only</em> be used to describe
|
||
|
|
that the register is live. You should think twice before adding
|
||
|
|
<code>use</code> statements, more often you will want to use <code>unspec</code>
|
||
|
|
instead. The <code>use</code> RTX is most commonly useful to describe that
|
||
|
|
a fixed register is implicitly used in an insn. It is also safe to use
|
||
|
|
in patterns where the compiler knows for other reasons that the result
|
||
|
|
of the whole pattern is variable, such as ‘<samp>movmem<var>m</var></samp>’ or
|
||
|
|
‘<samp>call</samp>’ patterns.
|
||
|
|
</p>
|
||
|
|
<p>During the reload phase, an insn that has a <code>use</code> as pattern
|
||
|
|
can carry a reg_equal note. These <code>use</code> insns will be deleted
|
||
|
|
before the reload phase exits.
|
||
|
|
</p>
|
||
|
|
<p>During the delayed branch scheduling phase, <var>x</var> may be an insn.
|
||
|
|
This indicates that <var>x</var> previously was located at this place in the
|
||
|
|
code and its data dependencies need to be taken into account. These
|
||
|
|
<code>use</code> insns will be deleted before the delayed branch scheduling
|
||
|
|
phase exits.
|
||
|
|
</p>
|
||
|
|
<a name="index-parallel"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(parallel [<var>x0</var> <var>x1</var> …])</code></dt>
|
||
|
|
<dd><p>Represents several side effects performed in parallel. The square
|
||
|
|
brackets stand for a vector; the operand of <code>parallel</code> is a
|
||
|
|
vector of expressions. <var>x0</var>, <var>x1</var> and so on are individual
|
||
|
|
side effect expressions—expressions of code <code>set</code>, <code>call</code>,
|
||
|
|
<code>return</code>, <code>simple_return</code>, <code>clobber</code> or <code>use</code>.
|
||
|
|
</p>
|
||
|
|
<p>“In parallel” means that first all the values used in the individual
|
||
|
|
side-effects are computed, and second all the actual side-effects are
|
||
|
|
performed. For example,
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
|
||
|
|
(set (mem:SI (reg:SI 1)) (reg:SI 1))])
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>says unambiguously that the values of hard register 1 and the memory
|
||
|
|
location addressed by it are interchanged. In both places where
|
||
|
|
<code>(reg:SI 1)</code> appears as a memory address it refers to the value
|
||
|
|
in register 1 <em>before</em> the execution of the insn.
|
||
|
|
</p>
|
||
|
|
<p>It follows that it is <em>incorrect</em> to use <code>parallel</code> and
|
||
|
|
expect the result of one <code>set</code> to be available for the next one.
|
||
|
|
For example, people sometimes attempt to represent a jump-if-zero
|
||
|
|
instruction this way:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(parallel [(set (cc0) (reg:SI 34))
|
||
|
|
(set (pc) (if_then_else
|
||
|
|
(eq (cc0) (const_int 0))
|
||
|
|
(label_ref …)
|
||
|
|
(pc)))])
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>But this is incorrect, because it says that the jump condition depends
|
||
|
|
on the condition code value <em>before</em> this instruction, not on the
|
||
|
|
new value that is set by this instruction.
|
||
|
|
</p>
|
||
|
|
<a name="index-peephole-optimization_002c-RTL-representation"></a>
|
||
|
|
<p>Peephole optimization, which takes place together with final assembly
|
||
|
|
code output, can produce insns whose patterns consist of a <code>parallel</code>
|
||
|
|
whose elements are the operands needed to output the resulting
|
||
|
|
assembler code—often <code>reg</code>, <code>mem</code> or constant expressions.
|
||
|
|
This would not be well-formed RTL at any other stage in compilation,
|
||
|
|
but it is OK then because no further optimization remains to be done.
|
||
|
|
However, the definition of the macro <code>NOTICE_UPDATE_CC</code>, if
|
||
|
|
any, must deal with such insns if you define any peephole optimizations.
|
||
|
|
</p>
|
||
|
|
<a name="index-cond_005fexec"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(cond_exec [<var>cond</var> <var>expr</var>])</code></dt>
|
||
|
|
<dd><p>Represents a conditionally executed expression. The <var>expr</var> is
|
||
|
|
executed only if the <var>cond</var> is nonzero. The <var>cond</var> expression
|
||
|
|
must not have side-effects, but the <var>expr</var> may very well have
|
||
|
|
side-effects.
|
||
|
|
</p>
|
||
|
|
<a name="index-sequence"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(sequence [<var>insns</var> …])</code></dt>
|
||
|
|
<dd><p>Represents a sequence of insns. If a <code>sequence</code> appears in the
|
||
|
|
chain of insns, then each of the <var>insns</var> that appears in the sequence
|
||
|
|
must be suitable for appearing in the chain of insns, i.e. must satisfy
|
||
|
|
the <code>INSN_P</code> predicate.
|
||
|
|
</p>
|
||
|
|
<p>After delay-slot scheduling is completed, an insn and all the insns that
|
||
|
|
reside in its delay slots are grouped together into a <code>sequence</code>.
|
||
|
|
The insn requiring the delay slot is the first insn in the vector;
|
||
|
|
subsequent insns are to be placed in the delay slot.
|
||
|
|
</p>
|
||
|
|
<p><code>INSN_ANNULLED_BRANCH_P</code> is set on an insn in a delay slot to
|
||
|
|
indicate that a branch insn should be used that will conditionally annul
|
||
|
|
the effect of the insns in the delay slots. In such a case,
|
||
|
|
<code>INSN_FROM_TARGET_P</code> indicates that the insn is from the target of
|
||
|
|
the branch and should be executed only if the branch is taken; otherwise
|
||
|
|
the insn should be executed only if the branch is not taken.
|
||
|
|
See <a href="Delay-Slots.html#Delay-Slots">Delay Slots</a>.
|
||
|
|
</p>
|
||
|
|
<p>Some back ends also use <code>sequence</code> objects for purposes other than
|
||
|
|
delay-slot groups. This is not supported in the common parts of the
|
||
|
|
compiler, which treat such sequences as delay-slot groups.
|
||
|
|
</p>
|
||
|
|
<p>DWARF2 Call Frame Address (CFA) adjustments are sometimes also expressed
|
||
|
|
using <code>sequence</code> objects as the value of a <code>RTX_FRAME_RELATED_P</code>
|
||
|
|
note. This only happens if the CFA adjustments cannot be easily derived
|
||
|
|
from the pattern of the instruction to which the note is attached. In
|
||
|
|
such cases, the value of the note is used instead of best-guesing the
|
||
|
|
semantics of the instruction. The back end can attach notes containing
|
||
|
|
a <code>sequence</code> of <code>set</code> patterns that express the effect of the
|
||
|
|
parent instruction.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p>These expression codes appear in place of a side effect, as the body of
|
||
|
|
an insn, though strictly speaking they do not always describe side
|
||
|
|
effects as such:
|
||
|
|
</p>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dd><a name="index-asm_005finput"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(asm_input <var>s</var>)</code></dt>
|
||
|
|
<dd><p>Represents literal assembler code as described by the string <var>s</var>.
|
||
|
|
</p>
|
||
|
|
<a name="index-unspec"></a>
|
||
|
|
<a name="index-unspec_005fvolatile"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(unspec [<var>operands</var> …] <var>index</var>)</code></dt>
|
||
|
|
<dt><code>(unspec_volatile [<var>operands</var> …] <var>index</var>)</code></dt>
|
||
|
|
<dd><p>Represents a machine-specific operation on <var>operands</var>. <var>index</var>
|
||
|
|
selects between multiple machine-specific operations.
|
||
|
|
<code>unspec_volatile</code> is used for volatile operations and operations
|
||
|
|
that may trap; <code>unspec</code> is used for other operations.
|
||
|
|
</p>
|
||
|
|
<p>These codes may appear inside a <code>pattern</code> of an
|
||
|
|
insn, inside a <code>parallel</code>, or inside an expression.
|
||
|
|
</p>
|
||
|
|
<a name="index-addr_005fvec"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(addr_vec:<var>m</var> [<var>lr0</var> <var>lr1</var> …])</code></dt>
|
||
|
|
<dd><p>Represents a table of jump addresses. The vector elements <var>lr0</var>,
|
||
|
|
etc., are <code>label_ref</code> expressions. The mode <var>m</var> specifies
|
||
|
|
how much space is given to each address; normally <var>m</var> would be
|
||
|
|
<code>Pmode</code>.
|
||
|
|
</p>
|
||
|
|
<a name="index-addr_005fdiff_005fvec"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(addr_diff_vec:<var>m</var> <var>base</var> [<var>lr0</var> <var>lr1</var> …] <var>min</var> <var>max</var> <var>flags</var>)</code></dt>
|
||
|
|
<dd><p>Represents a table of jump addresses expressed as offsets from
|
||
|
|
<var>base</var>. The vector elements <var>lr0</var>, etc., are <code>label_ref</code>
|
||
|
|
expressions and so is <var>base</var>. The mode <var>m</var> specifies how much
|
||
|
|
space is given to each address-difference. <var>min</var> and <var>max</var>
|
||
|
|
are set up by branch shortening and hold a label with a minimum and a
|
||
|
|
maximum address, respectively. <var>flags</var> indicates the relative
|
||
|
|
position of <var>base</var>, <var>min</var> and <var>max</var> to the containing insn
|
||
|
|
and of <var>min</var> and <var>max</var> to <var>base</var>. See rtl.def for details.
|
||
|
|
</p>
|
||
|
|
<a name="index-prefetch"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>(prefetch:<var>m</var> <var>addr</var> <var>rw</var> <var>locality</var>)</code></dt>
|
||
|
|
<dd><p>Represents prefetch of memory at address <var>addr</var>.
|
||
|
|
Operand <var>rw</var> is 1 if the prefetch is for data to be written, 0 otherwise;
|
||
|
|
targets that do not support write prefetches should treat this as a normal
|
||
|
|
prefetch.
|
||
|
|
Operand <var>locality</var> specifies the amount of temporal locality; 0 if there
|
||
|
|
is none or 1, 2, or 3 for increasing levels of temporal locality;
|
||
|
|
targets that do not support locality hints should ignore this.
|
||
|
|
</p>
|
||
|
|
<p>This insn is used to minimize cache-miss latency by moving data into a
|
||
|
|
cache before it is accessed. It should use only non-faulting data prefetch
|
||
|
|
instructions.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Incdec.html#Incdec" accesskey="n" rel="next">Incdec</a>, Previous: <a href="RTL-Declarations.html#RTL-Declarations" accesskey="p" rel="prev">RTL Declarations</a>, Up: <a href="RTL.html#RTL" accesskey="u" rel="up">RTL</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|