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.
590 lines
35 KiB
HTML
590 lines
35 KiB
HTML
<html lang="en">
|
|
<head>
|
|
<title>Insns - GNU Compiler Collection (GCC) Internals</title>
|
|
<meta http-equiv="Content-Type" content="text/html">
|
|
<meta name="description" content="GNU Compiler Collection (GCC) Internals">
|
|
<meta name="generator" content="makeinfo 4.13">
|
|
<link title="Top" rel="start" href="index.html#Top">
|
|
<link rel="up" href="RTL.html#RTL" title="RTL">
|
|
<link rel="prev" href="Debug-Information.html#Debug-Information" title="Debug Information">
|
|
<link rel="next" href="Calls.html#Calls" title="Calls">
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
|
<!--
|
|
Copyright (C) 1988-2015 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.-->
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
|
<style type="text/css"><!--
|
|
pre.display { font-family:inherit }
|
|
pre.format { font-family:inherit }
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
|
pre.smallexample { font-size:smaller }
|
|
pre.smalllisp { font-size:smaller }
|
|
span.sc { font-variant:small-caps }
|
|
span.roman { font-family:serif; font-weight:normal; }
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
|
--></style>
|
|
</head>
|
|
<body>
|
|
<div class="node">
|
|
<a name="Insns"></a>
|
|
<p>
|
|
Next: <a rel="next" accesskey="n" href="Calls.html#Calls">Calls</a>,
|
|
Previous: <a rel="previous" accesskey="p" href="Debug-Information.html#Debug-Information">Debug Information</a>,
|
|
Up: <a rel="up" accesskey="u" href="RTL.html#RTL">RTL</a>
|
|
<hr>
|
|
</div>
|
|
|
|
<h3 class="section">13.19 Insns</h3>
|
|
|
|
<p><a name="index-insns-3067"></a>
|
|
The RTL representation of the code for a function is a doubly-linked
|
|
chain of objects called <dfn>insns</dfn>. Insns are expressions with
|
|
special codes that are used for no other purpose. Some insns are
|
|
actual instructions; others represent dispatch tables for <code>switch</code>
|
|
statements; others represent labels to jump to or various sorts of
|
|
declarative information.
|
|
|
|
<p>In addition to its own specific data, each insn must have a unique
|
|
id-number that distinguishes it from all other insns in the current
|
|
function (after delayed branch scheduling, copies of an insn with the
|
|
same id-number may be present in multiple places in a function, but
|
|
these copies will always be identical and will only appear inside a
|
|
<code>sequence</code>), and chain pointers to the preceding and following
|
|
insns. These three fields occupy the same position in every insn,
|
|
independent of the expression code of the insn. They could be accessed
|
|
with <code>XEXP</code> and <code>XINT</code>, but instead three special macros are
|
|
always used:
|
|
|
|
|
|
<a name="index-INSN_005fUID-3068"></a>
|
|
<dl><dt><code>INSN_UID (</code><var>i</var><code>)</code><dd>Accesses the unique id of insn <var>i</var>.
|
|
|
|
<p><a name="index-PREV_005fINSN-3069"></a><br><dt><code>PREV_INSN (</code><var>i</var><code>)</code><dd>Accesses the chain pointer to the insn preceding <var>i</var>.
|
|
If <var>i</var> is the first insn, this is a null pointer.
|
|
|
|
<p><a name="index-NEXT_005fINSN-3070"></a><br><dt><code>NEXT_INSN (</code><var>i</var><code>)</code><dd>Accesses the chain pointer to the insn following <var>i</var>.
|
|
If <var>i</var> is the last insn, this is a null pointer.
|
|
</dl>
|
|
|
|
<p><a name="index-get_005finsns-3071"></a><a name="index-get_005flast_005finsn-3072"></a>The first insn in the chain is obtained by calling <code>get_insns</code>; the
|
|
last insn is the result of calling <code>get_last_insn</code>. Within the
|
|
chain delimited by these insns, the <code>NEXT_INSN</code> and
|
|
<code>PREV_INSN</code> pointers must always correspond: if <var>insn</var> is not
|
|
the first insn,
|
|
|
|
<pre class="smallexample"> NEXT_INSN (PREV_INSN (<var>insn</var>)) == <var>insn</var>
|
|
</pre>
|
|
<p class="noindent">is always true and if <var>insn</var> is not the last insn,
|
|
|
|
<pre class="smallexample"> PREV_INSN (NEXT_INSN (<var>insn</var>)) == <var>insn</var>
|
|
</pre>
|
|
<p class="noindent">is always true.
|
|
|
|
<p>After delay slot scheduling, some of the insns in the chain might be
|
|
<code>sequence</code> expressions, which contain a vector of insns. The value
|
|
of <code>NEXT_INSN</code> in all but the last of these insns is the next insn
|
|
in the vector; the value of <code>NEXT_INSN</code> of the last insn in the vector
|
|
is the same as the value of <code>NEXT_INSN</code> for the <code>sequence</code> in
|
|
which it is contained. Similar rules apply for <code>PREV_INSN</code>.
|
|
|
|
<p>This means that the above invariants are not necessarily true for insns
|
|
inside <code>sequence</code> expressions. Specifically, if <var>insn</var> is the
|
|
first insn in a <code>sequence</code>, <code>NEXT_INSN (PREV_INSN (</code><var>insn</var><code>))</code>
|
|
is the insn containing the <code>sequence</code> expression, as is the value
|
|
of <code>PREV_INSN (NEXT_INSN (</code><var>insn</var><code>))</code> if <var>insn</var> is the last
|
|
insn in the <code>sequence</code> expression. You can use these expressions
|
|
to find the containing <code>sequence</code> expression.
|
|
|
|
<p>Every insn has one of the following expression codes:
|
|
|
|
|
|
<a name="index-insn-3073"></a>
|
|
<dl><dt><code>insn</code><dd>The expression code <code>insn</code> is used for instructions that do not jump
|
|
and do not do function calls. <code>sequence</code> expressions are always
|
|
contained in insns with code <code>insn</code> even if one of those insns
|
|
should jump or do function calls.
|
|
|
|
<p>Insns with code <code>insn</code> have four additional fields beyond the three
|
|
mandatory ones listed above. These four are described in a table below.
|
|
|
|
<p><a name="index-jump_005finsn-3074"></a><br><dt><code>jump_insn</code><dd>The expression code <code>jump_insn</code> is used for instructions that may
|
|
jump (or, more generally, may contain <code>label_ref</code> expressions to
|
|
which <code>pc</code> can be set in that instruction). If there is an
|
|
instruction to return from the current function, it is recorded as a
|
|
<code>jump_insn</code>.
|
|
|
|
<p><a name="index-JUMP_005fLABEL-3075"></a><code>jump_insn</code> insns have the same extra fields as <code>insn</code> insns,
|
|
accessed in the same way and in addition contain a field
|
|
<code>JUMP_LABEL</code> which is defined once jump optimization has completed.
|
|
|
|
<p>For simple conditional and unconditional jumps, this field contains
|
|
the <code>code_label</code> to which this insn will (possibly conditionally)
|
|
branch. In a more complex jump, <code>JUMP_LABEL</code> records one of the
|
|
labels that the insn refers to; other jump target labels are recorded
|
|
as <code>REG_LABEL_TARGET</code> notes. The exception is <code>addr_vec</code>
|
|
and <code>addr_diff_vec</code>, where <code>JUMP_LABEL</code> is <code>NULL_RTX</code>
|
|
and the only way to find the labels is to scan the entire body of the
|
|
insn.
|
|
|
|
<p>Return insns count as jumps, but since they do not refer to any
|
|
labels, their <code>JUMP_LABEL</code> is <code>NULL_RTX</code>.
|
|
|
|
<p><a name="index-call_005finsn-3076"></a><br><dt><code>call_insn</code><dd>The expression code <code>call_insn</code> is used for instructions that may do
|
|
function calls. It is important to distinguish these instructions because
|
|
they imply that certain registers and memory locations may be altered
|
|
unpredictably.
|
|
|
|
<p><a name="index-CALL_005fINSN_005fFUNCTION_005fUSAGE-3077"></a><code>call_insn</code> insns have the same extra fields as <code>insn</code> insns,
|
|
accessed in the same way and in addition contain a field
|
|
<code>CALL_INSN_FUNCTION_USAGE</code>, which contains a list (chain of
|
|
<code>expr_list</code> expressions) containing <code>use</code>, <code>clobber</code> and
|
|
sometimes <code>set</code> expressions that denote hard registers and
|
|
<code>mem</code>s used or clobbered by the called function.
|
|
|
|
<p>A <code>mem</code> generally points to a stack slot in which arguments passed
|
|
to the libcall by reference (see <a href="Register-Arguments.html#Register-Arguments">TARGET_PASS_BY_REFERENCE</a>) are stored. If the argument is
|
|
caller-copied (see <a href="Register-Arguments.html#Register-Arguments">TARGET_CALLEE_COPIES</a>),
|
|
the stack slot will be mentioned in <code>clobber</code> and <code>use</code>
|
|
entries; if it's callee-copied, only a <code>use</code> will appear, and the
|
|
<code>mem</code> may point to addresses that are not stack slots.
|
|
|
|
<p>Registers occurring inside a <code>clobber</code> in this list augment
|
|
registers specified in <code>CALL_USED_REGISTERS</code> (see <a href="Register-Basics.html#Register-Basics">Register Basics</a>).
|
|
|
|
<p>If the list contains a <code>set</code> involving two registers, it indicates
|
|
that the function returns one of its arguments. Such a <code>set</code> may
|
|
look like a no-op if the same register holds the argument and the return
|
|
value.
|
|
|
|
<p><a name="index-code_005flabel-3078"></a><a name="index-CODE_005fLABEL_005fNUMBER-3079"></a><br><dt><code>code_label</code><dd>A <code>code_label</code> insn represents a label that a jump insn can jump
|
|
to. It contains two special fields of data in addition to the three
|
|
standard ones. <code>CODE_LABEL_NUMBER</code> is used to hold the <dfn>label
|
|
number</dfn>, a number that identifies this label uniquely among all the
|
|
labels in the compilation (not just in the current function).
|
|
Ultimately, the label is represented in the assembler output as an
|
|
assembler label, usually of the form ‘<samp><span class="samp">L</span><var>n</var></samp>’ where <var>n</var> is
|
|
the label number.
|
|
|
|
<p>When a <code>code_label</code> appears in an RTL expression, it normally
|
|
appears within a <code>label_ref</code> which represents the address of
|
|
the label, as a number.
|
|
|
|
<p>Besides as a <code>code_label</code>, a label can also be represented as a
|
|
<code>note</code> of type <code>NOTE_INSN_DELETED_LABEL</code>.
|
|
|
|
<p><a name="index-LABEL_005fNUSES-3080"></a>The field <code>LABEL_NUSES</code> is only defined once the jump optimization
|
|
phase is completed. It contains the number of times this label is
|
|
referenced in the current function.
|
|
|
|
<p><a name="index-LABEL_005fKIND-3081"></a><a name="index-SET_005fLABEL_005fKIND-3082"></a><a name="index-LABEL_005fALT_005fENTRY_005fP-3083"></a><a name="index-alternate-entry-points-3084"></a>The field <code>LABEL_KIND</code> differentiates four different types of
|
|
labels: <code>LABEL_NORMAL</code>, <code>LABEL_STATIC_ENTRY</code>,
|
|
<code>LABEL_GLOBAL_ENTRY</code>, and <code>LABEL_WEAK_ENTRY</code>. The only labels
|
|
that do not have type <code>LABEL_NORMAL</code> are <dfn>alternate entry
|
|
points</dfn> to the current function. These may be static (visible only in
|
|
the containing translation unit), global (exposed to all translation
|
|
units), or weak (global, but can be overridden by another symbol with the
|
|
same name).
|
|
|
|
<p>Much of the compiler treats all four kinds of label identically. Some
|
|
of it needs to know whether or not a label is an alternate entry point;
|
|
for this purpose, the macro <code>LABEL_ALT_ENTRY_P</code> is provided. It is
|
|
equivalent to testing whether ‘<samp><span class="samp">LABEL_KIND (label) == LABEL_NORMAL</span></samp>’.
|
|
The only place that cares about the distinction between static, global,
|
|
and weak alternate entry points, besides the front-end code that creates
|
|
them, is the function <code>output_alternate_entry_point</code>, in
|
|
<samp><span class="file">final.c</span></samp>.
|
|
|
|
<p>To set the kind of a label, use the <code>SET_LABEL_KIND</code> macro.
|
|
|
|
<p><a name="index-jump_005ftable_005fdata-3085"></a><br><dt><code>jump_table_data</code><dd>A <code>jump_table_data</code> insn is a placeholder for the jump-table data
|
|
of a <code>casesi</code> or <code>tablejump</code> insn. They are placed after
|
|
a <code>tablejump_p</code> insn. A <code>jump_table_data</code> insn is not part o
|
|
a basic blockm but it is associated with the basic block that ends with
|
|
the <code>tablejump_p</code> insn. The <code>PATTERN</code> of a <code>jump_table_data</code>
|
|
is always either an <code>addr_vec</code> or an <code>addr_diff_vec</code>, and a
|
|
<code>jump_table_data</code> insn is always preceded by a <code>code_label</code>.
|
|
The <code>tablejump_p</code> insn refers to that <code>code_label</code> via its
|
|
<code>JUMP_LABEL</code>.
|
|
|
|
<p><a name="index-barrier-3086"></a><br><dt><code>barrier</code><dd>Barriers are placed in the instruction stream when control cannot flow
|
|
past them. They are placed after unconditional jump instructions to
|
|
indicate that the jumps are unconditional and after calls to
|
|
<code>volatile</code> functions, which do not return (e.g., <code>exit</code>).
|
|
They contain no information beyond the three standard fields.
|
|
|
|
<p><a name="index-note-3087"></a><a name="index-NOTE_005fLINE_005fNUMBER-3088"></a><a name="index-NOTE_005fSOURCE_005fFILE-3089"></a><br><dt><code>note</code><dd><code>note</code> insns are used to represent additional debugging and
|
|
declarative information. They contain two nonstandard fields, an
|
|
integer which is accessed with the macro <code>NOTE_LINE_NUMBER</code> and a
|
|
string accessed with <code>NOTE_SOURCE_FILE</code>.
|
|
|
|
<p>If <code>NOTE_LINE_NUMBER</code> is positive, the note represents the
|
|
position of a source line and <code>NOTE_SOURCE_FILE</code> is the source file name
|
|
that the line came from. These notes control generation of line
|
|
number data in the assembler output.
|
|
|
|
<p>Otherwise, <code>NOTE_LINE_NUMBER</code> is not really a line number but a
|
|
code with one of the following values (and <code>NOTE_SOURCE_FILE</code>
|
|
must contain a null pointer):
|
|
|
|
|
|
<a name="index-NOTE_005fINSN_005fDELETED-3090"></a>
|
|
<dl><dt><code>NOTE_INSN_DELETED</code><dd>Such a note is completely ignorable. Some passes of the compiler
|
|
delete insns by altering them into notes of this kind.
|
|
|
|
<p><a name="index-NOTE_005fINSN_005fDELETED_005fLABEL-3091"></a><br><dt><code>NOTE_INSN_DELETED_LABEL</code><dd>This marks what used to be a <code>code_label</code>, but was not used for other
|
|
purposes than taking its address and was transformed to mark that no
|
|
code jumps to it.
|
|
|
|
<p><a name="index-NOTE_005fINSN_005fBLOCK_005fBEG-3092"></a><a name="index-NOTE_005fINSN_005fBLOCK_005fEND-3093"></a><br><dt><code>NOTE_INSN_BLOCK_BEG</code><dt><code>NOTE_INSN_BLOCK_END</code><dd>These types of notes indicate the position of the beginning and end
|
|
of a level of scoping of variable names. They control the output
|
|
of debugging information.
|
|
|
|
<p><a name="index-NOTE_005fINSN_005fEH_005fREGION_005fBEG-3094"></a><a name="index-NOTE_005fINSN_005fEH_005fREGION_005fEND-3095"></a><br><dt><code>NOTE_INSN_EH_REGION_BEG</code><dt><code>NOTE_INSN_EH_REGION_END</code><dd>These types of notes indicate the position of the beginning and end of a
|
|
level of scoping for exception handling. <code>NOTE_EH_HANDLER</code>
|
|
identifies which region is associated with these notes.
|
|
|
|
<p><a name="index-NOTE_005fINSN_005fFUNCTION_005fBEG-3096"></a><br><dt><code>NOTE_INSN_FUNCTION_BEG</code><dd>Appears at the start of the function body, after the function
|
|
prologue.
|
|
|
|
<p><a name="index-NOTE_005fINSN_005fVAR_005fLOCATION-3097"></a><a name="index-NOTE_005fVAR_005fLOCATION-3098"></a><br><dt><code>NOTE_INSN_VAR_LOCATION</code><dd>This note is used to generate variable location debugging information.
|
|
It indicates that the user variable in its <code>VAR_LOCATION</code> operand
|
|
is at the location given in the RTL expression, or holds a value that
|
|
can be computed by evaluating the RTL expression from that static
|
|
point in the program up to the next such note for the same user
|
|
variable.
|
|
|
|
</dl>
|
|
|
|
<p>These codes are printed symbolically when they appear in debugging dumps.
|
|
|
|
<p><a name="index-debug_005finsn-3099"></a><a name="index-INSN_005fVAR_005fLOCATION-3100"></a><br><dt><code>debug_insn</code><dd>The expression code <code>debug_insn</code> is used for pseudo-instructions
|
|
that hold debugging information for variable tracking at assignments
|
|
(see <samp><span class="option">-fvar-tracking-assignments</span></samp> option). They are the RTL
|
|
representation of <code>GIMPLE_DEBUG</code> statements
|
|
(<a href="_003ccode_003eGIMPLE_005fDEBUG_003c_002fcode_003e.html#g_t_003ccode_003eGIMPLE_005fDEBUG_003c_002fcode_003e"><code>GIMPLE_DEBUG</code></a>), with a <code>VAR_LOCATION</code> operand that
|
|
binds a user variable tree to an RTL representation of the
|
|
<code>value</code> in the corresponding statement. A <code>DEBUG_EXPR</code> in
|
|
it stands for the value bound to the corresponding
|
|
<code>DEBUG_EXPR_DECL</code>.
|
|
|
|
<p>Throughout optimization passes, binding information is kept in
|
|
pseudo-instruction form, so that, unlike notes, it gets the same
|
|
treatment and adjustments that regular instructions would. It is the
|
|
variable tracking pass that turns these pseudo-instructions into var
|
|
location notes, analyzing control flow, value equivalences and changes
|
|
to registers and memory referenced in value expressions, propagating
|
|
the values of debug temporaries and determining expressions that can
|
|
be used to compute the value of each user variable at as many points
|
|
(ranges, actually) in the program as possible.
|
|
|
|
<p>Unlike <code>NOTE_INSN_VAR_LOCATION</code>, the value expression in an
|
|
<code>INSN_VAR_LOCATION</code> denotes a value at that specific point in the
|
|
program, rather than an expression that can be evaluated at any later
|
|
point before an overriding <code>VAR_LOCATION</code> is encountered. E.g.,
|
|
if a user variable is bound to a <code>REG</code> and then a subsequent insn
|
|
modifies the <code>REG</code>, the note location would keep mapping the user
|
|
variable to the register across the insn, whereas the insn location
|
|
would keep the variable bound to the value, so that the variable
|
|
tracking pass would emit another location note for the variable at the
|
|
point in which the register is modified.
|
|
|
|
</dl>
|
|
|
|
<p><a name="index-g_t_0040code_007bTImode_007d_002c-in-_0040code_007binsn_007d-3101"></a><a name="index-g_t_0040code_007bHImode_007d_002c-in-_0040code_007binsn_007d-3102"></a><a name="index-g_t_0040code_007bQImode_007d_002c-in-_0040code_007binsn_007d-3103"></a>The machine mode of an insn is normally <code>VOIDmode</code>, but some
|
|
phases use the mode for various purposes.
|
|
|
|
<p>The common subexpression elimination pass sets the mode of an insn to
|
|
<code>QImode</code> when it is the first insn in a block that has already
|
|
been processed.
|
|
|
|
<p>The second Haifa scheduling pass, for targets that can multiple issue,
|
|
sets the mode of an insn to <code>TImode</code> when it is believed that the
|
|
instruction begins an issue group. That is, when the instruction
|
|
cannot issue simultaneously with the previous. This may be relied on
|
|
by later passes, in particular machine-dependent reorg.
|
|
|
|
<p>Here is a table of the extra fields of <code>insn</code>, <code>jump_insn</code>
|
|
and <code>call_insn</code> insns:
|
|
|
|
|
|
<a name="index-PATTERN-3104"></a>
|
|
<dl><dt><code>PATTERN (</code><var>i</var><code>)</code><dd>An expression for the side effect performed by this insn. This must
|
|
be one of the following codes: <code>set</code>, <code>call</code>, <code>use</code>,
|
|
<code>clobber</code>, <code>return</code>, <code>simple_return</code>, <code>asm_input</code>,
|
|
<code>asm_output</code>, <code>addr_vec</code>, <code>addr_diff_vec</code>,
|
|
<code>trap_if</code>, <code>unspec</code>, <code>unspec_volatile</code>,
|
|
<code>parallel</code>, <code>cond_exec</code>, or <code>sequence</code>. If it is a
|
|
<code>parallel</code>, each element of the <code>parallel</code> must be one these
|
|
codes, except that <code>parallel</code> expressions cannot be nested and
|
|
<code>addr_vec</code> and <code>addr_diff_vec</code> are not permitted inside a
|
|
<code>parallel</code> expression.
|
|
|
|
<p><a name="index-INSN_005fCODE-3105"></a><br><dt><code>INSN_CODE (</code><var>i</var><code>)</code><dd>An integer that says which pattern in the machine description matches
|
|
this insn, or −1 if the matching has not yet been attempted.
|
|
|
|
<p>Such matching is never attempted and this field remains −1 on an insn
|
|
whose pattern consists of a single <code>use</code>, <code>clobber</code>,
|
|
<code>asm_input</code>, <code>addr_vec</code> or <code>addr_diff_vec</code> expression.
|
|
|
|
<p><a name="index-asm_005fnoperands-3106"></a>Matching is also never attempted on insns that result from an <code>asm</code>
|
|
statement. These contain at least one <code>asm_operands</code> expression.
|
|
The function <code>asm_noperands</code> returns a non-negative value for
|
|
such insns.
|
|
|
|
<p>In the debugging output, this field is printed as a number followed by
|
|
a symbolic representation that locates the pattern in the <samp><span class="file">md</span></samp>
|
|
file as some small positive or negative offset from a named pattern.
|
|
|
|
<p><a name="index-LOG_005fLINKS-3107"></a><br><dt><code>LOG_LINKS (</code><var>i</var><code>)</code><dd>A list (chain of <code>insn_list</code> expressions) giving information about
|
|
dependencies between instructions within a basic block. Neither a jump
|
|
nor a label may come between the related insns. These are only used by
|
|
the schedulers and by combine. This is a deprecated data structure.
|
|
Def-use and use-def chains are now preferred.
|
|
|
|
<p><a name="index-REG_005fNOTES-3108"></a><br><dt><code>REG_NOTES (</code><var>i</var><code>)</code><dd>A list (chain of <code>expr_list</code>, <code>insn_list</code> and <code>int_list</code>
|
|
expressions) giving miscellaneous information about the insn. It is often
|
|
information pertaining to the registers used in this insn.
|
|
</dl>
|
|
|
|
<p>The <code>LOG_LINKS</code> field of an insn is a chain of <code>insn_list</code>
|
|
expressions. Each of these has two operands: the first is an insn,
|
|
and the second is another <code>insn_list</code> expression (the next one in
|
|
the chain). The last <code>insn_list</code> in the chain has a null pointer
|
|
as second operand. The significant thing about the chain is which
|
|
insns appear in it (as first operands of <code>insn_list</code>
|
|
expressions). Their order is not significant.
|
|
|
|
<p>This list is originally set up by the flow analysis pass; it is a null
|
|
pointer until then. Flow only adds links for those data dependencies
|
|
which can be used for instruction combination. For each insn, the flow
|
|
analysis pass adds a link to insns which store into registers values
|
|
that are used for the first time in this insn.
|
|
|
|
<p>The <code>REG_NOTES</code> field of an insn is a chain similar to the
|
|
<code>LOG_LINKS</code> field but it includes <code>expr_list</code> and <code>int_list</code>
|
|
expressions in addition to <code>insn_list</code> expressions. There are several
|
|
kinds of register notes, which are distinguished by the machine mode, which
|
|
in a register note is really understood as being an <code>enum reg_note</code>.
|
|
The first operand <var>op</var> of the note is data whose meaning depends on
|
|
the kind of note.
|
|
|
|
<p><a name="index-REG_005fNOTE_005fKIND-3109"></a><a name="index-PUT_005fREG_005fNOTE_005fKIND-3110"></a>The macro <code>REG_NOTE_KIND (</code><var>x</var><code>)</code> returns the kind of
|
|
register note. Its counterpart, the macro <code>PUT_REG_NOTE_KIND
|
|
(</code><var>x</var><code>, </code><var>newkind</var><code>)</code> sets the register note type of <var>x</var> to be
|
|
<var>newkind</var>.
|
|
|
|
<p>Register notes are of three classes: They may say something about an
|
|
input to an insn, they may say something about an output of an insn, or
|
|
they may create a linkage between two insns. There are also a set
|
|
of values that are only used in <code>LOG_LINKS</code>.
|
|
|
|
<p>These register notes annotate inputs to an insn:
|
|
|
|
|
|
<a name="index-REG_005fDEAD-3111"></a>
|
|
<dl><dt><code>REG_DEAD</code><dd>The value in <var>op</var> dies in this insn; that is to say, altering the
|
|
value immediately after this insn would not affect the future behavior
|
|
of the program.
|
|
|
|
<p>It does not follow that the register <var>op</var> has no useful value after
|
|
this insn since <var>op</var> is not necessarily modified by this insn.
|
|
Rather, no subsequent instruction uses the contents of <var>op</var>.
|
|
|
|
<p><a name="index-REG_005fUNUSED-3112"></a><br><dt><code>REG_UNUSED</code><dd>The register <var>op</var> being set by this insn will not be used in a
|
|
subsequent insn. This differs from a <code>REG_DEAD</code> note, which
|
|
indicates that the value in an input will not be used subsequently.
|
|
These two notes are independent; both may be present for the same
|
|
register.
|
|
|
|
<p><a name="index-REG_005fINC-3113"></a><br><dt><code>REG_INC</code><dd>The register <var>op</var> is incremented (or decremented; at this level
|
|
there is no distinction) by an embedded side effect inside this insn.
|
|
This means it appears in a <code>post_inc</code>, <code>pre_inc</code>,
|
|
<code>post_dec</code> or <code>pre_dec</code> expression.
|
|
|
|
<p><a name="index-REG_005fNONNEG-3114"></a><br><dt><code>REG_NONNEG</code><dd>The register <var>op</var> is known to have a nonnegative value when this
|
|
insn is reached. This is used so that decrement and branch until zero
|
|
instructions, such as the m68k dbra, can be matched.
|
|
|
|
<p>The <code>REG_NONNEG</code> note is added to insns only if the machine
|
|
description has a ‘<samp><span class="samp">decrement_and_branch_until_zero</span></samp>’ pattern.
|
|
|
|
<p><a name="index-REG_005fLABEL_005fOPERAND-3115"></a><br><dt><code>REG_LABEL_OPERAND</code><dd>This insn uses <var>op</var>, a <code>code_label</code> or a <code>note</code> of type
|
|
<code>NOTE_INSN_DELETED_LABEL</code>, but is not a <code>jump_insn</code>, or it
|
|
is a <code>jump_insn</code> that refers to the operand as an ordinary
|
|
operand. The label may still eventually be a jump target, but if so
|
|
in an indirect jump in a subsequent insn. The presence of this note
|
|
allows jump optimization to be aware that <var>op</var> is, in fact, being
|
|
used, and flow optimization to build an accurate flow graph.
|
|
|
|
<p><a name="index-REG_005fLABEL_005fTARGET-3116"></a><br><dt><code>REG_LABEL_TARGET</code><dd>This insn is a <code>jump_insn</code> but not an <code>addr_vec</code> or
|
|
<code>addr_diff_vec</code>. It uses <var>op</var>, a <code>code_label</code> as a
|
|
direct or indirect jump target. Its purpose is similar to that of
|
|
<code>REG_LABEL_OPERAND</code>. This note is only present if the insn has
|
|
multiple targets; the last label in the insn (in the highest numbered
|
|
insn-field) goes into the <code>JUMP_LABEL</code> field and does not have a
|
|
<code>REG_LABEL_TARGET</code> note. See <a href="Insns.html#Insns">JUMP_LABEL</a>.
|
|
|
|
<p><a name="index-REG_005fCROSSING_005fJUMP-3117"></a><br><dt><code>REG_CROSSING_JUMP</code><dd>This insn is a branching instruction (either an unconditional jump or
|
|
an indirect jump) which crosses between hot and cold sections, which
|
|
could potentially be very far apart in the executable. The presence
|
|
of this note indicates to other optimizations that this branching
|
|
instruction should not be “collapsed” into a simpler branching
|
|
construct. It is used when the optimization to partition basic blocks
|
|
into hot and cold sections is turned on.
|
|
|
|
<p><a name="index-REG_005fSETJMP-3118"></a><br><dt><code>REG_SETJMP</code><dd>Appears attached to each <code>CALL_INSN</code> to <code>setjmp</code> or a
|
|
related function.
|
|
</dl>
|
|
|
|
<p>The following notes describe attributes of outputs of an insn:
|
|
|
|
|
|
<a name="index-REG_005fEQUIV-3119"></a>
|
|
<a name="index-REG_005fEQUAL-3120"></a>
|
|
<dl><dt><code>REG_EQUIV</code><dt><code>REG_EQUAL</code><dd>This note is only valid on an insn that sets only one register and
|
|
indicates that that register will be equal to <var>op</var> at run time; the
|
|
scope of this equivalence differs between the two types of notes. The
|
|
value which the insn explicitly copies into the register may look
|
|
different from <var>op</var>, but they will be equal at run time. If the
|
|
output of the single <code>set</code> is a <code>strict_low_part</code> expression,
|
|
the note refers to the register that is contained in <code>SUBREG_REG</code>
|
|
of the <code>subreg</code> expression.
|
|
|
|
<p>For <code>REG_EQUIV</code>, the register is equivalent to <var>op</var> throughout
|
|
the entire function, and could validly be replaced in all its
|
|
occurrences by <var>op</var>. (“Validly” here refers to the data flow of
|
|
the program; simple replacement may make some insns invalid.) For
|
|
example, when a constant is loaded into a register that is never
|
|
assigned any other value, this kind of note is used.
|
|
|
|
<p>When a parameter is copied into a pseudo-register at entry to a function,
|
|
a note of this kind records that the register is equivalent to the stack
|
|
slot where the parameter was passed. Although in this case the register
|
|
may be set by other insns, it is still valid to replace the register
|
|
by the stack slot throughout the function.
|
|
|
|
<p>A <code>REG_EQUIV</code> note is also used on an instruction which copies a
|
|
register parameter into a pseudo-register at entry to a function, if
|
|
there is a stack slot where that parameter could be stored. Although
|
|
other insns may set the pseudo-register, it is valid for the compiler to
|
|
replace the pseudo-register by stack slot throughout the function,
|
|
provided the compiler ensures that the stack slot is properly
|
|
initialized by making the replacement in the initial copy instruction as
|
|
well. This is used on machines for which the calling convention
|
|
allocates stack space for register parameters. See
|
|
<code>REG_PARM_STACK_SPACE</code> in <a href="Stack-Arguments.html#Stack-Arguments">Stack Arguments</a>.
|
|
|
|
<p>In the case of <code>REG_EQUAL</code>, the register that is set by this insn
|
|
will be equal to <var>op</var> at run time at the end of this insn but not
|
|
necessarily elsewhere in the function. In this case, <var>op</var>
|
|
is typically an arithmetic expression. For example, when a sequence of
|
|
insns such as a library call is used to perform an arithmetic operation,
|
|
this kind of note is attached to the insn that produces or copies the
|
|
final value.
|
|
|
|
<p>These two notes are used in different ways by the compiler passes.
|
|
<code>REG_EQUAL</code> is used by passes prior to register allocation (such as
|
|
common subexpression elimination and loop optimization) to tell them how
|
|
to think of that value. <code>REG_EQUIV</code> notes are used by register
|
|
allocation to indicate that there is an available substitute expression
|
|
(either a constant or a <code>mem</code> expression for the location of a
|
|
parameter on the stack) that may be used in place of a register if
|
|
insufficient registers are available.
|
|
|
|
<p>Except for stack homes for parameters, which are indicated by a
|
|
<code>REG_EQUIV</code> note and are not useful to the early optimization
|
|
passes and pseudo registers that are equivalent to a memory location
|
|
throughout their entire life, which is not detected until later in
|
|
the compilation, all equivalences are initially indicated by an attached
|
|
<code>REG_EQUAL</code> note. In the early stages of register allocation, a
|
|
<code>REG_EQUAL</code> note is changed into a <code>REG_EQUIV</code> note if
|
|
<var>op</var> is a constant and the insn represents the only set of its
|
|
destination register.
|
|
|
|
<p>Thus, compiler passes prior to register allocation need only check for
|
|
<code>REG_EQUAL</code> notes and passes subsequent to register allocation
|
|
need only check for <code>REG_EQUIV</code> notes.
|
|
</dl>
|
|
|
|
<p>These notes describe linkages between insns. They occur in pairs: one
|
|
insn has one of a pair of notes that points to a second insn, which has
|
|
the inverse note pointing back to the first insn.
|
|
|
|
|
|
<a name="index-REG_005fCC_005fSETTER-3121"></a>
|
|
<a name="index-REG_005fCC_005fUSER-3122"></a>
|
|
<dl><dt><code>REG_CC_SETTER</code><dt><code>REG_CC_USER</code><dd>On machines that use <code>cc0</code>, the insns which set and use <code>cc0</code>
|
|
set and use <code>cc0</code> are adjacent. However, when branch delay slot
|
|
filling is done, this may no longer be true. In this case a
|
|
<code>REG_CC_USER</code> note will be placed on the insn setting <code>cc0</code> to
|
|
point to the insn using <code>cc0</code> and a <code>REG_CC_SETTER</code> note will
|
|
be placed on the insn using <code>cc0</code> to point to the insn setting
|
|
<code>cc0</code>.
|
|
</dl>
|
|
|
|
<p>These values are only used in the <code>LOG_LINKS</code> field, and indicate
|
|
the type of dependency that each link represents. Links which indicate
|
|
a data dependence (a read after write dependence) do not use any code,
|
|
they simply have mode <code>VOIDmode</code>, and are printed without any
|
|
descriptive text.
|
|
|
|
|
|
<a name="index-REG_005fDEP_005fTRUE-3123"></a>
|
|
<dl><dt><code>REG_DEP_TRUE</code><dd>This indicates a true dependence (a read after write dependence).
|
|
|
|
<p><a name="index-REG_005fDEP_005fOUTPUT-3124"></a><br><dt><code>REG_DEP_OUTPUT</code><dd>This indicates an output dependence (a write after write dependence).
|
|
|
|
<p><a name="index-REG_005fDEP_005fANTI-3125"></a><br><dt><code>REG_DEP_ANTI</code><dd>This indicates an anti dependence (a write after read dependence).
|
|
|
|
</dl>
|
|
|
|
<p>These notes describe information gathered from gcov profile data. They
|
|
are stored in the <code>REG_NOTES</code> field of an insn.
|
|
|
|
|
|
<a name="index-REG_005fBR_005fPROB-3126"></a>
|
|
<dl><dt><code>REG_BR_PROB</code><dd>This is used to specify the ratio of branches to non-branches of a
|
|
branch insn according to the profile data. The note is represented
|
|
as an <code>int_list</code> expression whose integer value is between 0 and
|
|
REG_BR_PROB_BASE. Larger values indicate a higher probability that
|
|
the branch will be taken.
|
|
|
|
<p><a name="index-REG_005fBR_005fPRED-3127"></a><br><dt><code>REG_BR_PRED</code><dd>These notes are found in JUMP insns after delayed branch scheduling
|
|
has taken place. They indicate both the direction and the likelihood
|
|
of the JUMP. The format is a bitmask of ATTR_FLAG_* values.
|
|
|
|
<p><a name="index-REG_005fFRAME_005fRELATED_005fEXPR-3128"></a><br><dt><code>REG_FRAME_RELATED_EXPR</code><dd>This is used on an RTX_FRAME_RELATED_P insn wherein the attached expression
|
|
is used in place of the actual insn pattern. This is done in cases where
|
|
the pattern is either complex or misleading.
|
|
</dl>
|
|
|
|
<p>For convenience, the machine mode in an <code>insn_list</code> or
|
|
<code>expr_list</code> is printed using these symbolic codes in debugging dumps.
|
|
|
|
<p><a name="index-insn_005flist-3129"></a><a name="index-expr_005flist-3130"></a>The only difference between the expression codes <code>insn_list</code> and
|
|
<code>expr_list</code> is that the first operand of an <code>insn_list</code> is
|
|
assumed to be an insn and is printed in debugging dumps as the insn's
|
|
unique id; the first operand of an <code>expr_list</code> is printed in the
|
|
ordinary way as an expression.
|
|
|
|
</body></html>
|
|
|