diff options
Diffstat (limited to 'share/doc/gccint/Side-Effects.html')
| -rw-r--r-- | share/doc/gccint/Side-Effects.html | 461 |
1 files changed, 461 insertions, 0 deletions
diff --git a/share/doc/gccint/Side-Effects.html b/share/doc/gccint/Side-Effects.html new file mode 100644 index 0000000..5686ca3 --- /dev/null +++ b/share/doc/gccint/Side-Effects.html @@ -0,0 +1,461 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<!-- Copyright (C) 1988-2023 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 5.1, http://www.gnu.org/software/texinfo/ --> +<head> +<title>GNU Compiler Collection (GCC) Internals: Side Effects</title> + +<meta name="description" content="GNU Compiler Collection (GCC) Internals: Side Effects"> +<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Side Effects"> +<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="previous" title="RTL Declarations"> +<style type="text/css"> +<!-- +a.summary-letter {text-decoration: none} +blockquote.smallquotation {font-size: smaller} +div.display {margin-left: 3.2em} +div.example {margin-left: 3.2em} +div.indentedblock {margin-left: 3.2em} +div.lisp {margin-left: 3.2em} +div.smalldisplay {margin-left: 3.2em} +div.smallexample {margin-left: 3.2em} +div.smallindentedblock {margin-left: 3.2em; font-size: smaller} +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.nocodebreak {white-space:nowrap} +span.nolinebreak {white-space:nowrap} +span.roman {font-family:serif; font-weight:normal} +span.sansserif {font-family:sans-serif; font-weight:normal} +ul.no-bullet {list-style: none} +--> +</style> + + +</head> + +<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> +<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="previous">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>, +or <code>parallel</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> cannot +appear in <var>lval</var>. +</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 not <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>cpymem<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 (reg:CC CC_REG) (reg:SI 34)) + (set (pc) (if_then_else + (eq (reg:CC CC_REG) (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. +</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="previous">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> |