diff options
author | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
---|---|---|
committer | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
commit | abdaadbcae30fe0c9a66c7516798279fdfd97750 (patch) | |
tree | 00a54a6e25601e43876d03c1a4a12a749d4a914c /share/doc/gccint/Insns.html |
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Change-Id: I7303388733328cd98ab9aa3c30236db67f2e9e9c
Diffstat (limited to 'share/doc/gccint/Insns.html')
-rw-r--r-- | share/doc/gccint/Insns.html | 754 |
1 files changed, 754 insertions, 0 deletions
diff --git a/share/doc/gccint/Insns.html b/share/doc/gccint/Insns.html new file mode 100644 index 0000000..ebe8053 --- /dev/null +++ b/share/doc/gccint/Insns.html @@ -0,0 +1,754 @@ +<!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: Insns</title> + +<meta name="description" content="GNU Compiler Collection (GCC) Internals: Insns"> +<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Insns"> +<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="Calls.html#Calls" rel="next" title="Calls"> +<link href="Debug-Information.html#Debug-Information" rel="previous" title="Debug Information"> +<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="Insns"></a> +<div class="header"> +<p> +Next: <a href="Calls.html#Calls" accesskey="n" rel="next">Calls</a>, Previous: <a href="Debug-Information.html#Debug-Information" accesskey="p" rel="previous">Debug Information</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="Insns-1"></a> +<h3 class="section">14.19 Insns</h3> +<a name="index-insns"></a> + +<p>The RTL representation of the code for a function is a doubly-linked +chain of objects called <em>insns</em>. 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> +<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: +</p> +<dl compact="compact"> +<dd><a name="index-INSN_005fUID"></a> +</dd> +<dt><code>INSN_UID (<var>i</var>)</code></dt> +<dd><p>Accesses the unique id of insn <var>i</var>. +</p> +<a name="index-PREV_005fINSN"></a> +</dd> +<dt><code>PREV_INSN (<var>i</var>)</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>NEXT_INSN (<var>i</var>)</code></dt> +<dd><p>Accesses the chain pointer to the insn following <var>i</var>. +If <var>i</var> is the last insn, this is a null pointer. +</p></dd> +</dl> + +<a name="index-get_005finsns"></a> +<a name="index-get_005flast_005finsn"></a> +<p>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, +</p> +<div class="smallexample"> +<pre class="smallexample">NEXT_INSN (PREV_INSN (<var>insn</var>)) == <var>insn</var> +</pre></div> + +<p>is always true and if <var>insn</var> is not the last insn, +</p> +<div class="smallexample"> +<pre class="smallexample">PREV_INSN (NEXT_INSN (<var>insn</var>)) == <var>insn</var> +</pre></div> + +<p>is always true. +</p> +<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> +<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 (<var>insn</var>))</code> +is the insn containing the <code>sequence</code> expression, as is the value +of <code>PREV_INSN (NEXT_INSN (<var>insn</var>))</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> +<p>Every insn has one of the following expression codes: +</p> +<dl compact="compact"> +<dd><a name="index-insn"></a> +</dd> +<dt><code>insn</code></dt> +<dd><p>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> +<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"></a> +</dd> +<dt><code>jump_insn</code></dt> +<dd><p>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"></a> +<p><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> +<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> +<p>Return insns count as jumps, but their <code>JUMP_LABEL</code> is <code>RETURN</code> +or <code>SIMPLE_RETURN</code>. +</p> +<a name="index-call_005finsn"></a> +</dd> +<dt><code>call_insn</code></dt> +<dd><p>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"></a> +<p><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> +<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> +<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> +<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"></a> +<a name="index-CODE_005fLABEL_005fNUMBER"></a> +</dd> +<dt><code>code_label</code></dt> +<dd><p>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 <em>label +number</em>, 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>L<var>n</var></samp>’ where <var>n</var> is +the label number. +</p> +<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> +<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"></a> +<p>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"></a> +<a name="index-SET_005fLABEL_005fKIND"></a> +<a name="index-LABEL_005fALT_005fENTRY_005fP"></a> +<a name="index-alternate-entry-points"></a> +<p>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 <em>alternate entry +points</em> 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> +<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>LABEL_KIND (label) == LABEL_NORMAL</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>final.cc</samp>. +</p> +<p>To set the kind of a label, use the <code>SET_LABEL_KIND</code> macro. +</p> +<a name="index-jump_005ftable_005fdata"></a> +</dd> +<dt><code>jump_table_data</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>barrier</code></dt> +<dd><p>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"></a> +<a name="index-NOTE_005fLINE_005fNUMBER"></a> +<a name="index-NOTE_005fSOURCE_005fFILE"></a> +</dd> +<dt><code>note</code></dt> +<dd><p><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> +<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> +<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): +</p> +<dl compact="compact"> +<dd><a name="index-NOTE_005fINSN_005fDELETED"></a> +</dd> +<dt><code>NOTE_INSN_DELETED</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>NOTE_INSN_DELETED_LABEL</code></dt> +<dd><p>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"></a> +<a name="index-NOTE_005fINSN_005fBLOCK_005fEND"></a> +</dd> +<dt><code>NOTE_INSN_BLOCK_BEG</code></dt> +<dt><code>NOTE_INSN_BLOCK_END</code></dt> +<dd><p>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"></a> +<a name="index-NOTE_005fINSN_005fEH_005fREGION_005fEND"></a> +</dd> +<dt><code>NOTE_INSN_EH_REGION_BEG</code></dt> +<dt><code>NOTE_INSN_EH_REGION_END</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>NOTE_INSN_FUNCTION_BEG</code></dt> +<dd><p>Appears at the start of the function body, after the function +prologue. +</p> +<a name="index-NOTE_005fINSN_005fVAR_005fLOCATION"></a> +<a name="index-NOTE_005fVAR_005fLOCATION"></a> +</dd> +<dt><code>NOTE_INSN_VAR_LOCATION</code></dt> +<dd><p>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. +</p> +<a name="index-NOTE_005fINSN_005fBEGIN_005fSTMT"></a> +</dd> +<dt><code>NOTE_INSN_BEGIN_STMT</code></dt> +<dd><p>This note is used to generate <code>is_stmt</code> markers in line number +debugging information. It indicates the beginning of a user +statement. +</p> +<a name="index-NOTE_005fINSN_005fINLINE_005fENTRY"></a> +</dd> +<dt><code>NOTE_INSN_INLINE_ENTRY</code></dt> +<dd><p>This note is used to generate <code>entry_pc</code> for inlined subroutines in +debugging information. It indicates an inspection point at which all +arguments for the inlined function have been bound, and before its first +statement. +</p> +</dd> +</dl> + +<p>These codes are printed symbolically when they appear in debugging dumps. +</p> +<a name="index-debug_005finsn"></a> +<a name="index-INSN_005fVAR_005fLOCATION"></a> +</dd> +<dt><code>debug_insn</code></dt> +<dd><p>The expression code <code>debug_insn</code> is used for pseudo-instructions +that hold debugging information for variable tracking at assignments +(see <samp>-fvar-tracking-assignments</samp> option). They are the RTL +representation of <code>GIMPLE_DEBUG</code> statements +(<a href="GIMPLE_005fDEBUG.html#GIMPLE_005fDEBUG"><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> +<p><code>GIMPLE_DEBUG_BEGIN_STMT</code> and <code>GIMPLE_DEBUG_INLINE_ENTRY</code> are +expanded to RTL as a <code>DEBUG_INSN</code> with a <code>DEBUG_MARKER</code> +<code>PATTERN</code>; the difference is the RTL mode: the former’s +<code>DEBUG_MARKER</code> is <code>VOIDmode</code>, whereas the latter is +<code>BLKmode</code>; information about the inlined function can be taken from +the lexical block encoded in the <code>INSN_LOCATION</code>. These +<code>DEBUG_INSN</code>s, that do not carry <code>VAR_LOCATION</code> information, +just <code>DEBUG_MARKER</code>s, can be detected by testing +<code>DEBUG_MARKER_INSN_P</code>, whereas those that do can be recognized as +<code>DEBUG_BIND_INSN_P</code>. +</p> +<p>Throughout optimization passes, <code>DEBUG_INSN</code>s are not reordered +with respect to each other, particularly during scheduling. 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 <code>NOTE_INSN_VAR_LOCATION</code>, +<code>NOTE_INSN_BEGIN_STMT</code> and <code>NOTE_INSN_INLINE_ENTRY</code> 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> +<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. +</p> +</dd> +</dl> + +<a name="index-TImode_002c-in-insn"></a> +<a name="index-HImode_002c-in-insn"></a> +<a name="index-QImode_002c-in-insn"></a> +<p>The machine mode of an insn is normally <code>VOIDmode</code>, but some +phases use the mode for various purposes. +</p> +<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> +<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> +<p>Here is a table of the extra fields of <code>insn</code>, <code>jump_insn</code> +and <code>call_insn</code> insns: +</p> +<dl compact="compact"> +<dd><a name="index-PATTERN"></a> +</dd> +<dt><code>PATTERN (<var>i</var>)</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>INSN_CODE (<var>i</var>)</code></dt> +<dd><p>An integer that says which pattern in the machine description matches +this insn, or -1 if the matching has not yet been attempted. +</p> +<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"></a> +<p>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> +<p>In the debugging output, this field is printed as a number followed by +a symbolic representation that locates the pattern in the <samp>md</samp> +file as some small positive or negative offset from a named pattern. +</p> +<a name="index-REG_005fNOTES"></a> +</dd> +<dt><code>REG_NOTES (<var>i</var>)</code></dt> +<dd><p>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. +</p></dd> +</dl> + +<p>The <code>REG_NOTES</code> field of an insn is a chain that includes +<code>expr_list</code> and <code>int_list</code> expressions as well as <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"></a> +<a name="index-PUT_005fREG_005fNOTE_005fKIND"></a> +<p>The macro <code>REG_NOTE_KIND (<var>x</var>)</code> returns the kind of +register note. Its counterpart, the macro <code>PUT_REG_NOTE_KIND +(<var>x</var>, <var>newkind</var>)</code> sets the register note type of <var>x</var> to be +<var>newkind</var>. +</p> +<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. +</p> +<p>These register notes annotate inputs to an insn: +</p> +<dl compact="compact"> +<dd><a name="index-REG_005fDEAD"></a> +</dd> +<dt><code>REG_DEAD</code></dt> +<dd><p>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> +<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"></a> +</dd> +<dt><code>REG_UNUSED</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>REG_INC</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>REG_NONNEG</code></dt> +<dd><p>The register <var>op</var> is known to have a nonnegative value when this +insn is reached. This is used by special looping instructions +that terminate when the register goes negative. +</p> +<p>The <code>REG_NONNEG</code> note is added only to ‘<samp>doloop_end</samp>’ +insns, if its pattern uses a <code>ge</code> condition. +</p> +<a name="index-REG_005fLABEL_005fOPERAND"></a> +</dd> +<dt><code>REG_LABEL_OPERAND</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>REG_LABEL_TARGET</code></dt> +<dd><p>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">JUMP_LABEL</a>. +</p> +<a name="index-REG_005fSETJMP"></a> +</dd> +<dt><code>REG_SETJMP</code></dt> +<dd><p>Appears attached to each <code>CALL_INSN</code> to <code>setjmp</code> or a +related function. +</p></dd> +</dl> + +<p>The following notes describe attributes of outputs of an insn: +</p> +<dl compact="compact"> +<dd><a name="index-REG_005fEQUIV"></a> +<a name="index-REG_005fEQUAL"></a> +</dd> +<dt><code>REG_EQUIV</code></dt> +<dt><code>REG_EQUAL</code></dt> +<dd><p>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> or +<code>zero_extract</code> expression, the note refers to the register that +is contained in its first operand. +</p> +<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> +<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> +<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> +<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> +<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> +<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> +<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. +</p></dd> +</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. +</p> +<dl compact="compact"> +<dd><a name="index-REG_005fDEP_005fTRUE"></a> +</dd> +<dt><code>REG_DEP_TRUE</code></dt> +<dd><p>This indicates a true dependence (a read after write dependence). +</p> +<a name="index-REG_005fDEP_005fOUTPUT"></a> +</dd> +<dt><code>REG_DEP_OUTPUT</code></dt> +<dd><p>This indicates an output dependence (a write after write dependence). +</p> +<a name="index-REG_005fDEP_005fANTI"></a> +</dd> +<dt><code>REG_DEP_ANTI</code></dt> +<dd><p>This indicates an anti dependence (a write after read dependence). +</p> +</dd> +</dl> + +<p>These notes describe information gathered from gcov profile data. They +are stored in the <code>REG_NOTES</code> field of an insn. +</p> +<dl compact="compact"> +<dd><a name="index-REG_005fBR_005fPROB"></a> +</dd> +<dt><code>REG_BR_PROB</code></dt> +<dd><p>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 an encoding +of <code>profile_probability</code> type. <code>profile_probability</code> provide +member function <code>from_reg_br_prob_note</code> and <code>to_reg_br_prob_note</code> +to extract and store the probability into the RTL encoding. +</p> +<a name="index-REG_005fBR_005fPRED"></a> +</dd> +<dt><code>REG_BR_PRED</code></dt> +<dd><p>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"></a> +</dd> +<dt><code>REG_FRAME_RELATED_EXPR</code></dt> +<dd><p>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. +</p></dd> +</dl> + +<p>The note <code>REG_CALL_NOCF_CHECK</code> is used in conjunction with the +<samp>-fcf-protection=branch</samp> option. The note is set if a +<code>nocf_check</code> attribute is specified for a function type or a +pointer to function type. The note is stored in the <code>REG_NOTES</code> +field of an insn. +</p> +<dl compact="compact"> +<dd><a name="index-REG_005fCALL_005fNOCF_005fCHECK"></a> +</dd> +<dt><code>REG_CALL_NOCF_CHECK</code></dt> +<dd><p>Users have control through the <code>nocf_check</code> attribute to identify +which calls to a function should be skipped from control-flow instrumentation +when the option <samp>-fcf-protection=branch</samp> is specified. The compiler +puts a <code>REG_CALL_NOCF_CHECK</code> note on each <code>CALL_INSN</code> instruction +that has a function type marked with a <code>nocf_check</code> attribute. +</p></dd> +</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"></a> +<a name="index-expr_005flist"></a> +<p>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. +</p> +<hr> +<div class="header"> +<p> +Next: <a href="Calls.html#Calls" accesskey="n" rel="next">Calls</a>, Previous: <a href="Debug-Information.html#Debug-Information" accesskey="p" rel="previous">Debug Information</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> |