| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <!-- 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. --> |
| <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ --> |
| <head> |
| <title>GNU Compiler Collection (GCC) Internals: Standard Names</title> |
| |
| <meta name="description" content="GNU Compiler Collection (GCC) Internals: Standard Names"> |
| <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Standard Names"> |
| <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="Machine-Desc.html#Machine-Desc" rel="up" title="Machine Desc"> |
| <link href="Pattern-Ordering.html#Pattern-Ordering" rel="next" title="Pattern Ordering"> |
| <link href="C-Constraint-Interface.html#C-Constraint-Interface" rel="prev" title="C Constraint Interface"> |
| <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="Standard-Names"></a> |
| <div class="header"> |
| <p> |
| Next: <a href="Pattern-Ordering.html#Pattern-Ordering" accesskey="n" rel="next">Pattern Ordering</a>, Previous: <a href="Constraints.html#Constraints" accesskey="p" rel="prev">Constraints</a>, Up: <a href="Machine-Desc.html#Machine-Desc" accesskey="u" rel="up">Machine Desc</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="Standard-Pattern-Names-For-Generation"></a> |
| <h3 class="section">16.9 Standard Pattern Names For Generation</h3> |
| <a name="index-standard-pattern-names"></a> |
| <a name="index-pattern-names"></a> |
| <a name="index-names_002c-pattern"></a> |
| |
| <p>Here is a table of the instruction names that are meaningful in the RTL |
| generation pass of the compiler. Giving one of these names to an |
| instruction pattern tells the RTL generation pass that it can use the |
| pattern to accomplish a certain task. |
| </p> |
| <dl compact="compact"> |
| <dd><a name="index-movm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mov<var>m</var></samp>’</dt> |
| <dd><p>Here <var>m</var> stands for a two-letter machine mode name, in lowercase. |
| This instruction pattern moves data with that machine mode from operand |
| 1 to operand 0. For example, ‘<samp>movsi</samp>’ moves full-word data. |
| </p> |
| <p>If operand 0 is a <code>subreg</code> with mode <var>m</var> of a register whose |
| own mode is wider than <var>m</var>, the effect of this instruction is |
| to store the specified value in the part of the register that corresponds |
| to mode <var>m</var>. Bits outside of <var>m</var>, but which are within the |
| same target word as the <code>subreg</code> are undefined. Bits which are |
| outside the target word are left unchanged. |
| </p> |
| <p>This class of patterns is special in several ways. First of all, each |
| of these names up to and including full word size <em>must</em> be defined, |
| because there is no other way to copy a datum from one place to another. |
| If there are patterns accepting operands in larger modes, |
| ‘<samp>mov<var>m</var></samp>’ must be defined for integer modes of those sizes. |
| </p> |
| <p>Second, these patterns are not used solely in the RTL generation pass. |
| Even the reload pass can generate move insns to copy values from stack |
| slots into temporary registers. When it does so, one of the operands is |
| a hard register and the other is an operand that can need to be reloaded |
| into a register. |
| </p> |
| <a name="index-force_005freg"></a> |
| <p>Therefore, when given such a pair of operands, the pattern must generate |
| RTL which needs no reloading and needs no temporary registers—no |
| registers other than the operands. For example, if you support the |
| pattern with a <code>define_expand</code>, then in such a case the |
| <code>define_expand</code> mustn’t call <code>force_reg</code> or any other such |
| function which might generate new pseudo registers. |
| </p> |
| <p>This requirement exists even for subword modes on a RISC machine where |
| fetching those modes from memory normally requires several insns and |
| some temporary registers. |
| </p> |
| <a name="index-change_005faddress"></a> |
| <p>During reload a memory reference with an invalid address may be passed |
| as an operand. Such an address will be replaced with a valid address |
| later in the reload pass. In this case, nothing may be done with the |
| address except to use it as it stands. If it is copied, it will not be |
| replaced with a valid address. No attempt should be made to make such |
| an address into a valid address and no routine (such as |
| <code>change_address</code>) that will do so may be called. Note that |
| <code>general_operand</code> will fail when applied to such an address. |
| </p> |
| <a name="index-reload_005fin_005fprogress"></a> |
| <p>The global variable <code>reload_in_progress</code> (which must be explicitly |
| declared if required) can be used to determine whether such special |
| handling is required. |
| </p> |
| <p>The variety of operands that have reloads depends on the rest of the |
| machine description, but typically on a RISC machine these can only be |
| pseudo registers that did not get hard registers, while on other |
| machines explicit memory references will get optional reloads. |
| </p> |
| <p>If a scratch register is required to move an object to or from memory, |
| it can be allocated using <code>gen_reg_rtx</code> prior to life analysis. |
| </p> |
| <p>If there are cases which need scratch registers during or after reload, |
| you must provide an appropriate secondary_reload target hook. |
| </p> |
| <a name="index-can_005fcreate_005fpseudo_005fp"></a> |
| <p>The macro <code>can_create_pseudo_p</code> can be used to determine if it |
| is unsafe to create new pseudo registers. If this variable is nonzero, then |
| it is unsafe to call <code>gen_reg_rtx</code> to allocate a new pseudo. |
| </p> |
| <p>The constraints on a ‘<samp>mov<var>m</var></samp>’ must permit moving any hard |
| register to any other hard register provided that |
| <code>HARD_REGNO_MODE_OK</code> permits mode <var>m</var> in both registers and |
| <code>TARGET_REGISTER_MOVE_COST</code> applied to their classes returns a value |
| of 2. |
| </p> |
| <p>It is obligatory to support floating point ‘<samp>mov<var>m</var></samp>’ |
| instructions into and out of any registers that can hold fixed point |
| values, because unions and structures (which have modes <code>SImode</code> or |
| <code>DImode</code>) can be in those registers and they may have floating |
| point members. |
| </p> |
| <p>There may also be a need to support fixed point ‘<samp>mov<var>m</var></samp>’ |
| instructions in and out of floating point registers. Unfortunately, I |
| have forgotten why this was so, and I don’t know whether it is still |
| true. If <code>HARD_REGNO_MODE_OK</code> rejects fixed point values in |
| floating point registers, then the constraints of the fixed point |
| ‘<samp>mov<var>m</var></samp>’ instructions must be designed to avoid ever trying to |
| reload into a floating point register. |
| </p> |
| <a name="index-reload_005fin-instruction-pattern"></a> |
| <a name="index-reload_005fout-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reload_in<var>m</var></samp>’</dt> |
| <dt>‘<samp>reload_out<var>m</var></samp>’</dt> |
| <dd><p>These named patterns have been obsoleted by the target hook |
| <code>secondary_reload</code>. |
| </p> |
| <p>Like ‘<samp>mov<var>m</var></samp>’, but used when a scratch register is required to |
| move between operand 0 and operand 1. Operand 2 describes the scratch |
| register. See the discussion of the <code>SECONDARY_RELOAD_CLASS</code> |
| macro in see <a href="Register-Classes.html#Register-Classes">Register Classes</a>. |
| </p> |
| <p>There are special restrictions on the form of the <code>match_operand</code>s |
| used in these patterns. First, only the predicate for the reload |
| operand is examined, i.e., <code>reload_in</code> examines operand 1, but not |
| the predicates for operand 0 or 2. Second, there may be only one |
| alternative in the constraints. Third, only a single register class |
| letter may be used for the constraint; subsequent constraint letters |
| are ignored. As a special exception, an empty constraint string |
| matches the <code>ALL_REGS</code> register class. This may relieve ports |
| of the burden of defining an <code>ALL_REGS</code> constraint letter just |
| for these patterns. |
| </p> |
| <a name="index-movstrictm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>movstrict<var>m</var></samp>’</dt> |
| <dd><p>Like ‘<samp>mov<var>m</var></samp>’ except that if operand 0 is a <code>subreg</code> |
| with mode <var>m</var> of a register whose natural mode is wider, |
| the ‘<samp>movstrict<var>m</var></samp>’ instruction is guaranteed not to alter |
| any of the register except the part which belongs to mode <var>m</var>. |
| </p> |
| <a name="index-movmisalignm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>movmisalign<var>m</var></samp>’</dt> |
| <dd><p>This variant of a move pattern is designed to load or store a value |
| from a memory address that is not naturally aligned for its mode. |
| For a store, the memory will be in operand 0; for a load, the memory |
| will be in operand 1. The other operand is guaranteed not to be a |
| memory, so that it’s easy to tell whether this is a load or store. |
| </p> |
| <p>This pattern is used by the autovectorizer, and when expanding a |
| <code>MISALIGNED_INDIRECT_REF</code> expression. |
| </p> |
| <a name="index-load_005fmultiple-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>load_multiple</samp>’</dt> |
| <dd><p>Load several consecutive memory locations into consecutive registers. |
| Operand 0 is the first of the consecutive registers, operand 1 |
| is the first memory location, and operand 2 is a constant: the |
| number of consecutive registers. |
| </p> |
| <p>Define this only if the target machine really has such an instruction; |
| do not define this if the most efficient way of loading consecutive |
| registers from memory is to do them one at a time. |
| </p> |
| <p>On some machines, there are restrictions as to which consecutive |
| registers can be stored into memory, such as particular starting or |
| ending register numbers or only a range of valid counts. For those |
| machines, use a <code>define_expand</code> (see <a href="Expander-Definitions.html#Expander-Definitions">Expander Definitions</a>) |
| and make the pattern fail if the restrictions are not met. |
| </p> |
| <p>Write the generated insn as a <code>parallel</code> with elements being a |
| <code>set</code> of one register from the appropriate memory location (you may |
| also need <code>use</code> or <code>clobber</code> elements). Use a |
| <code>match_parallel</code> (see <a href="RTL-Template.html#RTL-Template">RTL Template</a>) to recognize the insn. See |
| <samp>rs6000.md</samp> for examples of the use of this insn pattern. |
| </p> |
| <a name="index-store_005fmultiple-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>store_multiple</samp>’</dt> |
| <dd><p>Similar to ‘<samp>load_multiple</samp>’, but store several consecutive registers |
| into consecutive memory locations. Operand 0 is the first of the |
| consecutive memory locations, operand 1 is the first register, and |
| operand 2 is a constant: the number of consecutive registers. |
| </p> |
| <a name="index-vec_005fload_005flanesmn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_load_lanes<var>m</var><var>n</var></samp>’</dt> |
| <dd><p>Perform an interleaved load of several vectors from memory operand 1 |
| into register operand 0. Both operands have mode <var>m</var>. The register |
| operand is viewed as holding consecutive vectors of mode <var>n</var>, |
| while the memory operand is a flat array that contains the same number |
| of elements. The operation is equivalent to: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">int c = GET_MODE_SIZE (<var>m</var>) / GET_MODE_SIZE (<var>n</var>); |
| for (j = 0; j < GET_MODE_NUNITS (<var>n</var>); j++) |
| for (i = 0; i < c; i++) |
| operand0[i][j] = operand1[j * c + i]; |
| </pre></div> |
| |
| <p>For example, ‘<samp>vec_load_lanestiv4hi</samp>’ loads 8 16-bit values |
| from memory into a register of mode ‘<samp>TI</samp>’. The register |
| contains two consecutive vectors of mode ‘<samp>V4HI</samp>’. |
| </p> |
| <p>This pattern can only be used if: |
| </p><div class="smallexample"> |
| <pre class="smallexample">TARGET_ARRAY_MODE_SUPPORTED_P (<var>n</var>, <var>c</var>) |
| </pre></div> |
| <p>is true. GCC assumes that, if a target supports this kind of |
| instruction for some mode <var>n</var>, it also supports unaligned |
| loads for vectors of mode <var>n</var>. |
| </p> |
| <a name="index-vec_005fstore_005flanesmn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_store_lanes<var>m</var><var>n</var></samp>’</dt> |
| <dd><p>Equivalent to ‘<samp>vec_load_lanes<var>m</var><var>n</var></samp>’, with the memory |
| and register operands reversed. That is, the instruction is |
| equivalent to: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">int c = GET_MODE_SIZE (<var>m</var>) / GET_MODE_SIZE (<var>n</var>); |
| for (j = 0; j < GET_MODE_NUNITS (<var>n</var>); j++) |
| for (i = 0; i < c; i++) |
| operand0[j * c + i] = operand1[i][j]; |
| </pre></div> |
| |
| <p>for a memory operand 0 and register operand 1. |
| </p> |
| <a name="index-vec_005fsetm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_set<var>m</var></samp>’</dt> |
| <dd><p>Set given field in the vector value. Operand 0 is the vector to modify, |
| operand 1 is new value of field and operand 2 specify the field index. |
| </p> |
| <a name="index-vec_005fextractm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_extract<var>m</var></samp>’</dt> |
| <dd><p>Extract given field from the vector value. Operand 1 is the vector, operand 2 |
| specify field index and operand 0 place to store value into. |
| </p> |
| <a name="index-vec_005finitm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_init<var>m</var></samp>’</dt> |
| <dd><p>Initialize the vector to given values. Operand 0 is the vector to initialize |
| and operand 1 is parallel containing values for individual fields. |
| </p> |
| <a name="index-vcondmn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vcond<var>m</var><var>n</var></samp>’</dt> |
| <dd><p>Output a conditional vector move. Operand 0 is the destination to |
| receive a combination of operand 1 and operand 2, which are of mode <var>m</var>, |
| dependent on the outcome of the predicate in operand 3 which is a |
| vector comparison with operands of mode <var>n</var> in operands 4 and 5. The |
| modes <var>m</var> and <var>n</var> should have the same size. Operand 0 |
| will be set to the value <var>op1</var> & <var>msk</var> | <var>op2</var> & ~<var>msk</var> |
| where <var>msk</var> is computed by element-wise evaluation of the vector |
| comparison with a truth value of all-ones and a false value of all-zeros. |
| </p> |
| <a name="index-vec_005fpermm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_perm<var>m</var></samp>’</dt> |
| <dd><p>Output a (variable) vector permutation. Operand 0 is the destination |
| to receive elements from operand 1 and operand 2, which are of mode |
| <var>m</var>. Operand 3 is the <em>selector</em>. It is an integral mode |
| vector of the same width and number of elements as mode <var>m</var>. |
| </p> |
| <p>The input elements are numbered from 0 in operand 1 through |
| <em>2*<var>N</var>-1</em> in operand 2. The elements of the selector must |
| be computed modulo <em>2*<var>N</var></em>. Note that if |
| <code>rtx_equal_p(operand1, operand2)</code>, this can be implemented |
| with just operand 1 and selector elements modulo <var>N</var>. |
| </p> |
| <p>In order to make things easy for a number of targets, if there is no |
| ‘<samp>vec_perm</samp>’ pattern for mode <var>m</var>, but there is for mode <var>q</var> |
| where <var>q</var> is a vector of <code>QImode</code> of the same width as <var>m</var>, |
| the middle-end will lower the mode <var>m</var> <code>VEC_PERM_EXPR</code> to |
| mode <var>q</var>. |
| </p> |
| <a name="index-vec_005fperm_005fconstm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_perm_const<var>m</var></samp>’</dt> |
| <dd><p>Like ‘<samp>vec_perm</samp>’ except that the permutation is a compile-time |
| constant. That is, operand 3, the <em>selector</em>, is a <code>CONST_VECTOR</code>. |
| </p> |
| <p>Some targets cannot perform a permutation with a variable selector, |
| but can efficiently perform a constant permutation. Further, the |
| target hook <code>vec_perm_ok</code> is queried to determine if the |
| specific constant permutation is available efficiently; the named |
| pattern is never expanded without <code>vec_perm_ok</code> returning true. |
| </p> |
| <p>There is no need for a target to supply both ‘<samp>vec_perm<var>m</var></samp>’ |
| and ‘<samp>vec_perm_const<var>m</var></samp>’ if the former can trivially implement |
| the operation with, say, the vector constant loaded into a register. |
| </p> |
| <a name="index-pushm1-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>push<var>m</var>1</samp>’</dt> |
| <dd><p>Output a push instruction. Operand 0 is value to push. Used only when |
| <code>PUSH_ROUNDING</code> is defined. For historical reason, this pattern may be |
| missing and in such case an <code>mov</code> expander is used instead, with a |
| <code>MEM</code> expression forming the push operation. The <code>mov</code> expander |
| method is deprecated. |
| </p> |
| <a name="index-addm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>add<var>m</var>3</samp>’</dt> |
| <dd><p>Add operand 2 and operand 1, storing the result in operand 0. All operands |
| must have mode <var>m</var>. This can be used even on two-address machines, by |
| means of constraints requiring operands 1 and 0 to be the same location. |
| </p> |
| <a name="index-addptrm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>addptr<var>m</var>3</samp>’</dt> |
| <dd><p>Like <code>add<var>m</var>3</code> but is guaranteed to only be used for address |
| calculations. The expanded code is not allowed to clobber the |
| condition code. It only needs to be defined if <code>add<var>m</var>3</code> |
| sets the condition code. If adds used for address calculations and |
| normal adds are not compatible it is required to expand a distinct |
| pattern (e.g. using an unspec). The pattern is used by LRA to emit |
| address calculations. <code>add<var>m</var>3</code> is used if |
| <code>addptr<var>m</var>3</code> is not defined. |
| </p> |
| <a name="index-ssaddm3-instruction-pattern"></a> |
| <a name="index-usaddm3-instruction-pattern"></a> |
| <a name="index-subm3-instruction-pattern"></a> |
| <a name="index-sssubm3-instruction-pattern"></a> |
| <a name="index-ussubm3-instruction-pattern"></a> |
| <a name="index-mulm3-instruction-pattern"></a> |
| <a name="index-ssmulm3-instruction-pattern"></a> |
| <a name="index-usmulm3-instruction-pattern"></a> |
| <a name="index-divm3-instruction-pattern"></a> |
| <a name="index-ssdivm3-instruction-pattern"></a> |
| <a name="index-udivm3-instruction-pattern"></a> |
| <a name="index-usdivm3-instruction-pattern"></a> |
| <a name="index-modm3-instruction-pattern"></a> |
| <a name="index-umodm3-instruction-pattern"></a> |
| <a name="index-uminm3-instruction-pattern"></a> |
| <a name="index-umaxm3-instruction-pattern"></a> |
| <a name="index-andm3-instruction-pattern"></a> |
| <a name="index-iorm3-instruction-pattern"></a> |
| <a name="index-xorm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ssadd<var>m</var>3</samp>’, ‘<samp>usadd<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>sub<var>m</var>3</samp>’, ‘<samp>sssub<var>m</var>3</samp>’, ‘<samp>ussub<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>mul<var>m</var>3</samp>’, ‘<samp>ssmul<var>m</var>3</samp>’, ‘<samp>usmul<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>div<var>m</var>3</samp>’, ‘<samp>ssdiv<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>udiv<var>m</var>3</samp>’, ‘<samp>usdiv<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>mod<var>m</var>3</samp>’, ‘<samp>umod<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>umin<var>m</var>3</samp>’, ‘<samp>umax<var>m</var>3</samp>’</dt> |
| <dt>‘<samp>and<var>m</var>3</samp>’, ‘<samp>ior<var>m</var>3</samp>’, ‘<samp>xor<var>m</var>3</samp>’</dt> |
| <dd><p>Similar, for other arithmetic operations. |
| </p> |
| <a name="index-fmam4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fma<var>m</var>4</samp>’</dt> |
| <dd><p>Multiply operand 2 and operand 1, then add operand 3, storing the |
| result in operand 0 without doing an intermediate rounding step. All |
| operands must have mode <var>m</var>. This pattern is used to implement |
| the <code>fma</code>, <code>fmaf</code>, and <code>fmal</code> builtin functions from |
| the ISO C99 standard. |
| </p> |
| <a name="index-fmsm4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fms<var>m</var>4</samp>’</dt> |
| <dd><p>Like <code>fma<var>m</var>4</code>, except operand 3 subtracted from the |
| product instead of added to the product. This is represented |
| in the rtl as |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(fma:<var>m</var> <var>op1</var> <var>op2</var> (neg:<var>m</var> <var>op3</var>)) |
| </pre></div> |
| |
| <a name="index-fnmam4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fnma<var>m</var>4</samp>’</dt> |
| <dd><p>Like <code>fma<var>m</var>4</code> except that the intermediate product |
| is negated before being added to operand 3. This is represented |
| in the rtl as |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(fma:<var>m</var> (neg:<var>m</var> <var>op1</var>) <var>op2</var> <var>op3</var>) |
| </pre></div> |
| |
| <a name="index-fnmsm4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fnms<var>m</var>4</samp>’</dt> |
| <dd><p>Like <code>fms<var>m</var>4</code> except that the intermediate product |
| is negated before subtracting operand 3. This is represented |
| in the rtl as |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(fma:<var>m</var> (neg:<var>m</var> <var>op1</var>) <var>op2</var> (neg:<var>m</var> <var>op3</var>)) |
| </pre></div> |
| |
| <a name="index-minm3-instruction-pattern"></a> |
| <a name="index-maxm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>smin<var>m</var>3</samp>’, ‘<samp>smax<var>m</var>3</samp>’</dt> |
| <dd><p>Signed minimum and maximum operations. When used with floating point, |
| if both operands are zeros, or if either operand is <code>NaN</code>, then |
| it is unspecified which of the two operands is returned as the result. |
| </p> |
| <a name="index-reduc_005fsmin_005fm-instruction-pattern"></a> |
| <a name="index-reduc_005fsmax_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_smin_<var>m</var></samp>’, ‘<samp>reduc_smax_<var>m</var></samp>’</dt> |
| <dd><p>Find the signed minimum/maximum of the elements of a vector. The vector is |
| operand 1, and the result is stored in the least significant bits of |
| operand 0 (also a vector). The output and input vector should have the same |
| modes. These are legacy optabs, and platforms should prefer to implement |
| ‘<samp>reduc_smin_scal_<var>m</var></samp>’ and ‘<samp>reduc_smax_scal_<var>m</var></samp>’. |
| </p> |
| <a name="index-reduc_005fumin_005fm-instruction-pattern"></a> |
| <a name="index-reduc_005fumax_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_umin_<var>m</var></samp>’, ‘<samp>reduc_umax_<var>m</var></samp>’</dt> |
| <dd><p>Find the unsigned minimum/maximum of the elements of a vector. The vector is |
| operand 1, and the result is stored in the least significant bits of |
| operand 0 (also a vector). The output and input vector should have the same |
| modes. These are legacy optabs, and platforms should prefer to implement |
| ‘<samp>reduc_umin_scal_<var>m</var></samp>’ and ‘<samp>reduc_umax_scal_<var>m</var></samp>’. |
| </p> |
| <a name="index-reduc_005fsplus_005fm-instruction-pattern"></a> |
| <a name="index-reduc_005fuplus_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_splus_<var>m</var></samp>’, ‘<samp>reduc_uplus_<var>m</var></samp>’</dt> |
| <dd><p>Compute the sum of the signed/unsigned elements of a vector. The vector is |
| operand 1, and the result is stored in the least significant bits of operand 0 |
| (also a vector). The output and input vector should have the same modes. |
| These are legacy optabs, and platforms should prefer to implement |
| ‘<samp>reduc_plus_scal_<var>m</var></samp>’. |
| </p> |
| <a name="index-reduc_005fsmin_005fscal_005fm-instruction-pattern"></a> |
| <a name="index-reduc_005fsmax_005fscal_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_smin_scal_<var>m</var></samp>’, ‘<samp>reduc_smax_scal_<var>m</var></samp>’</dt> |
| <dd><p>Find the signed minimum/maximum of the elements of a vector. The vector is |
| operand 1, and operand 0 is the scalar result, with mode equal to the mode of |
| the elements of the input vector. |
| </p> |
| <a name="index-reduc_005fumin_005fscal_005fm-instruction-pattern"></a> |
| <a name="index-reduc_005fumax_005fscal_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_umin_scal_<var>m</var></samp>’, ‘<samp>reduc_umax_scal_<var>m</var></samp>’</dt> |
| <dd><p>Find the unsigned minimum/maximum of the elements of a vector. The vector is |
| operand 1, and operand 0 is the scalar result, with mode equal to the mode of |
| the elements of the input vector. |
| </p> |
| <a name="index-reduc_005fplus_005fscal_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>reduc_plus_scal_<var>m</var></samp>’</dt> |
| <dd><p>Compute the sum of the elements of a vector. The vector is operand 1, and |
| operand 0 is the scalar result, with mode equal to the mode of the elements of |
| the input vector. |
| </p> |
| <a name="index-sdot_005fprodm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sdot_prod<var>m</var></samp>’</dt> |
| <dd><a name="index-udot_005fprodm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>udot_prod<var>m</var></samp>’</dt> |
| <dd><p>Compute the sum of the products of two signed/unsigned elements. |
| Operand 1 and operand 2 are of the same mode. Their product, which is of a |
| wider mode, is computed and added to operand 3. Operand 3 is of a mode equal or |
| wider than the mode of the product. The result is placed in operand 0, which |
| is of the same mode as operand 3. |
| </p> |
| <a name="index-ssum_005fwidenm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ssum_widen<var>m3</var></samp>’</dt> |
| <dd><a name="index-usum_005fwidenm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>usum_widen<var>m3</var></samp>’</dt> |
| <dd><p>Operands 0 and 2 are of the same mode, which is wider than the mode of |
| operand 1. Add operand 1 to operand 2 and place the widened result in |
| operand 0. (This is used express accumulation of elements into an accumulator |
| of a wider mode.) |
| </p> |
| <a name="index-vec_005fshr_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_shr_<var>m</var></samp>’</dt> |
| <dd><p>Whole vector right shift in bits. |
| Operand 1 is a vector to be shifted. |
| Operand 2 is an integer shift amount in bits. |
| Operand 0 is where the resulting shifted vector is stored. |
| The output and input vectors should have the same modes. |
| </p> |
| <a name="index-vec_005fpack_005ftrunc_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_pack_trunc_<var>m</var></samp>’</dt> |
| <dd><p>Narrow (demote) and merge the elements of two vectors. Operands 1 and 2 |
| are vectors of the same mode having N integral or floating point elements |
| of size S. Operand 0 is the resulting vector in which 2*N elements of |
| size N/2 are concatenated after narrowing them down using truncation. |
| </p> |
| <a name="index-vec_005fpack_005fssat_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fpack_005fusat_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_pack_ssat_<var>m</var></samp>’, ‘<samp>vec_pack_usat_<var>m</var></samp>’</dt> |
| <dd><p>Narrow (demote) and merge the elements of two vectors. Operands 1 and 2 |
| are vectors of the same mode having N integral elements of size S. |
| Operand 0 is the resulting vector in which the elements of the two input |
| vectors are concatenated after narrowing them down using signed/unsigned |
| saturating arithmetic. |
| </p> |
| <a name="index-vec_005fpack_005fsfix_005ftrunc_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fpack_005fufix_005ftrunc_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_pack_sfix_trunc_<var>m</var></samp>’, ‘<samp>vec_pack_ufix_trunc_<var>m</var></samp>’</dt> |
| <dd><p>Narrow, convert to signed/unsigned integral type and merge the elements |
| of two vectors. Operands 1 and 2 are vectors of the same mode having N |
| floating point elements of size S. Operand 0 is the resulting vector |
| in which 2*N elements of size N/2 are concatenated. |
| </p> |
| <a name="index-vec_005funpacks_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005funpacks_005flo_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_unpacks_hi_<var>m</var></samp>’, ‘<samp>vec_unpacks_lo_<var>m</var></samp>’</dt> |
| <dd><p>Extract and widen (promote) the high/low part of a vector of signed |
| integral or floating point elements. The input vector (operand 1) has N |
| elements of size S. Widen (promote) the high/low elements of the vector |
| using signed or floating point extension and place the resulting N/2 |
| values of size 2*S in the output vector (operand 0). |
| </p> |
| <a name="index-vec_005funpacku_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005funpacku_005flo_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_unpacku_hi_<var>m</var></samp>’, ‘<samp>vec_unpacku_lo_<var>m</var></samp>’</dt> |
| <dd><p>Extract and widen (promote) the high/low part of a vector of unsigned |
| integral elements. The input vector (operand 1) has N elements of size S. |
| Widen (promote) the high/low elements of the vector using zero extension and |
| place the resulting N/2 values of size 2*S in the output vector (operand 0). |
| </p> |
| <a name="index-vec_005funpacks_005ffloat_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005funpacks_005ffloat_005flo_005fm-instruction-pattern"></a> |
| <a name="index-vec_005funpacku_005ffloat_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005funpacku_005ffloat_005flo_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_unpacks_float_hi_<var>m</var></samp>’, ‘<samp>vec_unpacks_float_lo_<var>m</var></samp>’</dt> |
| <dt>‘<samp>vec_unpacku_float_hi_<var>m</var></samp>’, ‘<samp>vec_unpacku_float_lo_<var>m</var></samp>’</dt> |
| <dd><p>Extract, convert to floating point type and widen the high/low part of a |
| vector of signed/unsigned integral elements. The input vector (operand 1) |
| has N elements of size S. Convert the high/low elements of the vector using |
| floating point conversion and place the resulting N/2 values of size 2*S in |
| the output vector (operand 0). |
| </p> |
| <a name="index-vec_005fwiden_005fumult_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fumult_005flo_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsmult_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsmult_005flo_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fumult_005feven_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fumult_005fodd_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsmult_005feven_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsmult_005fodd_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_widen_umult_hi_<var>m</var></samp>’, ‘<samp>vec_widen_umult_lo_<var>m</var></samp>’</dt> |
| <dt>‘<samp>vec_widen_smult_hi_<var>m</var></samp>’, ‘<samp>vec_widen_smult_lo_<var>m</var></samp>’</dt> |
| <dt>‘<samp>vec_widen_umult_even_<var>m</var></samp>’, ‘<samp>vec_widen_umult_odd_<var>m</var></samp>’</dt> |
| <dt>‘<samp>vec_widen_smult_even_<var>m</var></samp>’, ‘<samp>vec_widen_smult_odd_<var>m</var></samp>’</dt> |
| <dd><p>Signed/Unsigned widening multiplication. The two inputs (operands 1 and 2) |
| are vectors with N signed/unsigned elements of size S. Multiply the high/low |
| or even/odd elements of the two vectors, and put the N/2 products of size 2*S |
| in the output vector (operand 0). A target shouldn’t implement even/odd pattern |
| pair if it is less efficient than lo/hi one. |
| </p> |
| <a name="index-vec_005fwiden_005fushiftl_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fushiftl_005flo_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsshiftl_005fhi_005fm-instruction-pattern"></a> |
| <a name="index-vec_005fwiden_005fsshiftl_005flo_005fm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vec_widen_ushiftl_hi_<var>m</var></samp>’, ‘<samp>vec_widen_ushiftl_lo_<var>m</var></samp>’</dt> |
| <dt>‘<samp>vec_widen_sshiftl_hi_<var>m</var></samp>’, ‘<samp>vec_widen_sshiftl_lo_<var>m</var></samp>’</dt> |
| <dd><p>Signed/Unsigned widening shift left. The first input (operand 1) is a vector |
| with N signed/unsigned elements of size S. Operand 2 is a constant. Shift |
| the high/low elements of operand 1, and put the N/2 results of size 2*S in the |
| output vector (operand 0). |
| </p> |
| <a name="index-mulhisi3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mulhisi3</samp>’</dt> |
| <dd><p>Multiply operands 1 and 2, which have mode <code>HImode</code>, and store |
| a <code>SImode</code> product in operand 0. |
| </p> |
| <a name="index-mulqihi3-instruction-pattern"></a> |
| <a name="index-mulsidi3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mulqihi3</samp>’, ‘<samp>mulsidi3</samp>’</dt> |
| <dd><p>Similar widening-multiplication instructions of other widths. |
| </p> |
| <a name="index-umulqihi3-instruction-pattern"></a> |
| <a name="index-umulhisi3-instruction-pattern"></a> |
| <a name="index-umulsidi3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>umulqihi3</samp>’, ‘<samp>umulhisi3</samp>’, ‘<samp>umulsidi3</samp>’</dt> |
| <dd><p>Similar widening-multiplication instructions that do unsigned |
| multiplication. |
| </p> |
| <a name="index-usmulqihi3-instruction-pattern"></a> |
| <a name="index-usmulhisi3-instruction-pattern"></a> |
| <a name="index-usmulsidi3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>usmulqihi3</samp>’, ‘<samp>usmulhisi3</samp>’, ‘<samp>usmulsidi3</samp>’</dt> |
| <dd><p>Similar widening-multiplication instructions that interpret the first |
| operand as unsigned and the second operand as signed, then do a signed |
| multiplication. |
| </p> |
| <a name="index-smulm3_005fhighpart-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>smul<var>m</var>3_highpart</samp>’</dt> |
| <dd><p>Perform a signed multiplication of operands 1 and 2, which have mode |
| <var>m</var>, and store the most significant half of the product in operand 0. |
| The least significant half of the product is discarded. |
| </p> |
| <a name="index-umulm3_005fhighpart-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>umul<var>m</var>3_highpart</samp>’</dt> |
| <dd><p>Similar, but the multiplication is unsigned. |
| </p> |
| <a name="index-maddmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>madd<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Multiply operands 1 and 2, sign-extend them to mode <var>n</var>, add |
| operand 3, and store the result in operand 0. Operands 1 and 2 |
| have mode <var>m</var> and operands 0 and 3 have mode <var>n</var>. |
| Both modes must be integer or fixed-point modes and <var>n</var> must be twice |
| the size of <var>m</var>. |
| </p> |
| <p>In other words, <code>madd<var>m</var><var>n</var>4</code> is like |
| <code>mul<var>m</var><var>n</var>3</code> except that it also adds operand 3. |
| </p> |
| <p>These instructions are not allowed to <code>FAIL</code>. |
| </p> |
| <a name="index-umaddmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>umadd<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>madd<var>m</var><var>n</var>4</code>, but zero-extend the multiplication |
| operands instead of sign-extending them. |
| </p> |
| <a name="index-ssmaddmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ssmadd<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>madd<var>m</var><var>n</var>4</code>, but all involved operations must be |
| signed-saturating. |
| </p> |
| <a name="index-usmaddmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>usmadd<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>umadd<var>m</var><var>n</var>4</code>, but all involved operations must be |
| unsigned-saturating. |
| </p> |
| <a name="index-msubmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>msub<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Multiply operands 1 and 2, sign-extend them to mode <var>n</var>, subtract the |
| result from operand 3, and store the result in operand 0. Operands 1 and 2 |
| have mode <var>m</var> and operands 0 and 3 have mode <var>n</var>. |
| Both modes must be integer or fixed-point modes and <var>n</var> must be twice |
| the size of <var>m</var>. |
| </p> |
| <p>In other words, <code>msub<var>m</var><var>n</var>4</code> is like |
| <code>mul<var>m</var><var>n</var>3</code> except that it also subtracts the result |
| from operand 3. |
| </p> |
| <p>These instructions are not allowed to <code>FAIL</code>. |
| </p> |
| <a name="index-umsubmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>umsub<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>msub<var>m</var><var>n</var>4</code>, but zero-extend the multiplication |
| operands instead of sign-extending them. |
| </p> |
| <a name="index-ssmsubmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ssmsub<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>msub<var>m</var><var>n</var>4</code>, but all involved operations must be |
| signed-saturating. |
| </p> |
| <a name="index-usmsubmn4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>usmsub<var>m</var><var>n</var>4</samp>’</dt> |
| <dd><p>Like <code>umsub<var>m</var><var>n</var>4</code>, but all involved operations must be |
| unsigned-saturating. |
| </p> |
| <a name="index-divmodm4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>divmod<var>m</var>4</samp>’</dt> |
| <dd><p>Signed division that produces both a quotient and a remainder. |
| Operand 1 is divided by operand 2 to produce a quotient stored |
| in operand 0 and a remainder stored in operand 3. |
| </p> |
| <p>For machines with an instruction that produces both a quotient and a |
| remainder, provide a pattern for ‘<samp>divmod<var>m</var>4</samp>’ but do not |
| provide patterns for ‘<samp>div<var>m</var>3</samp>’ and ‘<samp>mod<var>m</var>3</samp>’. This |
| allows optimization in the relatively common case when both the quotient |
| and remainder are computed. |
| </p> |
| <p>If an instruction that just produces a quotient or just a remainder |
| exists and is more efficient than the instruction that produces both, |
| write the output routine of ‘<samp>divmod<var>m</var>4</samp>’ to call |
| <code>find_reg_note</code> and look for a <code>REG_UNUSED</code> note on the |
| quotient or remainder and generate the appropriate instruction. |
| </p> |
| <a name="index-udivmodm4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>udivmod<var>m</var>4</samp>’</dt> |
| <dd><p>Similar, but does unsigned division. |
| </p> |
| <a name="shift-patterns"></a><a name="index-ashlm3-instruction-pattern"></a> |
| <a name="index-ssashlm3-instruction-pattern"></a> |
| <a name="index-usashlm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ashl<var>m</var>3</samp>’, ‘<samp>ssashl<var>m</var>3</samp>’, ‘<samp>usashl<var>m</var>3</samp>’</dt> |
| <dd><p>Arithmetic-shift operand 1 left by a number of bits specified by operand |
| 2, and store the result in operand 0. Here <var>m</var> is the mode of |
| operand 0 and operand 1; operand 2’s mode is specified by the |
| instruction pattern, and the compiler will convert the operand to that |
| mode before generating the instruction. The meaning of out-of-range shift |
| counts can optionally be specified by <code>TARGET_SHIFT_TRUNCATION_MASK</code>. |
| See <a href="Misc.html#TARGET_005fSHIFT_005fTRUNCATION_005fMASK">TARGET_SHIFT_TRUNCATION_MASK</a>. Operand 2 is always a scalar type. |
| </p> |
| <a name="index-ashrm3-instruction-pattern"></a> |
| <a name="index-lshrm3-instruction-pattern"></a> |
| <a name="index-rotlm3-instruction-pattern"></a> |
| <a name="index-rotrm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ashr<var>m</var>3</samp>’, ‘<samp>lshr<var>m</var>3</samp>’, ‘<samp>rotl<var>m</var>3</samp>’, ‘<samp>rotr<var>m</var>3</samp>’</dt> |
| <dd><p>Other shift and rotate instructions, analogous to the |
| <code>ashl<var>m</var>3</code> instructions. Operand 2 is always a scalar type. |
| </p> |
| <a name="index-vashlm3-instruction-pattern"></a> |
| <a name="index-vashrm3-instruction-pattern"></a> |
| <a name="index-vlshrm3-instruction-pattern"></a> |
| <a name="index-vrotlm3-instruction-pattern"></a> |
| <a name="index-vrotrm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>vashl<var>m</var>3</samp>’, ‘<samp>vashr<var>m</var>3</samp>’, ‘<samp>vlshr<var>m</var>3</samp>’, ‘<samp>vrotl<var>m</var>3</samp>’, ‘<samp>vrotr<var>m</var>3</samp>’</dt> |
| <dd><p>Vector shift and rotate instructions that take vectors as operand 2 |
| instead of a scalar type. |
| </p> |
| <a name="index-bswapm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>bswap<var>m</var>2</samp>’</dt> |
| <dd><p>Reverse the order of bytes of operand 1 and store the result in operand 0. |
| </p> |
| <a name="index-negm2-instruction-pattern"></a> |
| <a name="index-ssnegm2-instruction-pattern"></a> |
| <a name="index-usnegm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>neg<var>m</var>2</samp>’, ‘<samp>ssneg<var>m</var>2</samp>’, ‘<samp>usneg<var>m</var>2</samp>’</dt> |
| <dd><p>Negate operand 1 and store the result in operand 0. |
| </p> |
| <a name="index-absm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>abs<var>m</var>2</samp>’</dt> |
| <dd><p>Store the absolute value of operand 1 into operand 0. |
| </p> |
| <a name="index-sqrtm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sqrt<var>m</var>2</samp>’</dt> |
| <dd><p>Store the square root of operand 1 into operand 0. |
| </p> |
| <p>The <code>sqrt</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>sqrtf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-fmodm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fmod<var>m</var>3</samp>’</dt> |
| <dd><p>Store the remainder of dividing operand 1 by operand 2 into |
| operand 0, rounded towards zero to an integer. |
| </p> |
| <p>The <code>fmod</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>fmodf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-remainderm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>remainder<var>m</var>3</samp>’</dt> |
| <dd><p>Store the remainder of dividing operand 1 by operand 2 into |
| operand 0, rounded to the nearest integer. |
| </p> |
| <p>The <code>remainder</code> built-in function of C always uses the mode |
| which corresponds to the C data type <code>double</code> and the |
| <code>remainderf</code> built-in function uses the mode which corresponds |
| to the C data type <code>float</code>. |
| </p> |
| <a name="index-cosm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cos<var>m</var>2</samp>’</dt> |
| <dd><p>Store the cosine of operand 1 into operand 0. |
| </p> |
| <p>The <code>cos</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>cosf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-sinm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sin<var>m</var>2</samp>’</dt> |
| <dd><p>Store the sine of operand 1 into operand 0. |
| </p> |
| <p>The <code>sin</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>sinf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-sincosm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sincos<var>m</var>3</samp>’</dt> |
| <dd><p>Store the cosine of operand 2 into operand 0 and the sine of |
| operand 2 into operand 1. |
| </p> |
| <p>The <code>sin</code> and <code>cos</code> built-in functions of C always use the |
| mode which corresponds to the C data type <code>double</code> and the |
| <code>sinf</code> and <code>cosf</code> built-in function use the mode which |
| corresponds to the C data type <code>float</code>. |
| Targets that can calculate the sine and cosine simultaneously can |
| implement this pattern as opposed to implementing individual |
| <code>sin<var>m</var>2</code> and <code>cos<var>m</var>2</code> patterns. The <code>sin</code> |
| and <code>cos</code> built-in functions will then be expanded to the |
| <code>sincos<var>m</var>3</code> pattern, with one of the output values |
| left unused. |
| </p> |
| <a name="index-expm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>exp<var>m</var>2</samp>’</dt> |
| <dd><p>Store the exponential of operand 1 into operand 0. |
| </p> |
| <p>The <code>exp</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>expf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-logm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>log<var>m</var>2</samp>’</dt> |
| <dd><p>Store the natural logarithm of operand 1 into operand 0. |
| </p> |
| <p>The <code>log</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>logf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-powm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>pow<var>m</var>3</samp>’</dt> |
| <dd><p>Store the value of operand 1 raised to the exponent operand 2 |
| into operand 0. |
| </p> |
| <p>The <code>pow</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>powf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-atan2m3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atan2<var>m</var>3</samp>’</dt> |
| <dd><p>Store the arc tangent (inverse tangent) of operand 1 divided by |
| operand 2 into operand 0, using the signs of both arguments to |
| determine the quadrant of the result. |
| </p> |
| <p>The <code>atan2</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>atan2f</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-floorm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>floor<var>m</var>2</samp>’</dt> |
| <dd><p>Store the largest integral value not greater than argument. |
| </p> |
| <p>The <code>floor</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>floorf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-btruncm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>btrunc<var>m</var>2</samp>’</dt> |
| <dd><p>Store the argument rounded to integer towards zero. |
| </p> |
| <p>The <code>trunc</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>truncf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-roundm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>round<var>m</var>2</samp>’</dt> |
| <dd><p>Store the argument rounded to integer away from zero. |
| </p> |
| <p>The <code>round</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>roundf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-ceilm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ceil<var>m</var>2</samp>’</dt> |
| <dd><p>Store the argument rounded to integer away from zero. |
| </p> |
| <p>The <code>ceil</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>ceilf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-nearbyintm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>nearbyint<var>m</var>2</samp>’</dt> |
| <dd><p>Store the argument rounded according to the default rounding mode |
| </p> |
| <p>The <code>nearbyint</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>nearbyintf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-rintm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>rint<var>m</var>2</samp>’</dt> |
| <dd><p>Store the argument rounded according to the default rounding mode and |
| raise the inexact exception when the result differs in value from |
| the argument |
| </p> |
| <p>The <code>rint</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>rintf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-lrintmn2"></a> |
| </dd> |
| <dt>‘<samp>lrint<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as a signed number according to the current |
| rounding mode and store in operand 0 (which has mode <var>n</var>). |
| </p> |
| <a name="index-lroundmn2"></a> |
| </dd> |
| <dt>‘<samp>lround<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as a signed number rounding to nearest and away |
| from zero and store in operand 0 (which has mode <var>n</var>). |
| </p> |
| <a name="index-lfloormn2"></a> |
| </dd> |
| <dt>‘<samp>lfloor<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as a signed number rounding down and store in |
| operand 0 (which has mode <var>n</var>). |
| </p> |
| <a name="index-lceilmn2"></a> |
| </dd> |
| <dt>‘<samp>lceil<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as a signed number rounding up and store in |
| operand 0 (which has mode <var>n</var>). |
| </p> |
| <a name="index-copysignm3-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>copysign<var>m</var>3</samp>’</dt> |
| <dd><p>Store a value with the magnitude of operand 1 and the sign of operand |
| 2 into operand 0. |
| </p> |
| <p>The <code>copysign</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>double</code> and the <code>copysignf</code> |
| built-in function uses the mode which corresponds to the C data |
| type <code>float</code>. |
| </p> |
| <a name="index-ffsm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ffs<var>m</var>2</samp>’</dt> |
| <dd><p>Store into operand 0 one plus the index of the least significant 1-bit |
| of operand 1. If operand 1 is zero, store zero. <var>m</var> is the mode |
| of operand 0; operand 1’s mode is specified by the instruction |
| pattern, and the compiler will convert the operand to that mode before |
| generating the instruction. |
| </p> |
| <p>The <code>ffs</code> built-in function of C always uses the mode which |
| corresponds to the C data type <code>int</code>. |
| </p> |
| <a name="index-clrsbm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>clrsb<var>m</var>2</samp>’</dt> |
| <dd><p>Count leading redundant sign bits. |
| Store into operand 0 the number of redundant sign bits in operand 1, starting |
| at the most significant bit position. |
| A redundant sign bit is defined as any sign bit after the first. As such, |
| this count will be one less than the count of leading sign bits. |
| </p> |
| <a name="index-clzm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>clz<var>m</var>2</samp>’</dt> |
| <dd><p>Store into operand 0 the number of leading 0-bits in operand 1, starting |
| at the most significant bit position. If operand 1 is 0, the |
| <code>CLZ_DEFINED_VALUE_AT_ZERO</code> (see <a href="Misc.html#Misc">Misc</a>) macro defines if |
| the result is undefined or has a useful value. |
| <var>m</var> is the mode of operand 0; operand 1’s mode is |
| specified by the instruction pattern, and the compiler will convert the |
| operand to that mode before generating the instruction. |
| </p> |
| <a name="index-ctzm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ctz<var>m</var>2</samp>’</dt> |
| <dd><p>Store into operand 0 the number of trailing 0-bits in operand 1, starting |
| at the least significant bit position. If operand 1 is 0, the |
| <code>CTZ_DEFINED_VALUE_AT_ZERO</code> (see <a href="Misc.html#Misc">Misc</a>) macro defines if |
| the result is undefined or has a useful value. |
| <var>m</var> is the mode of operand 0; operand 1’s mode is |
| specified by the instruction pattern, and the compiler will convert the |
| operand to that mode before generating the instruction. |
| </p> |
| <a name="index-popcountm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>popcount<var>m</var>2</samp>’</dt> |
| <dd><p>Store into operand 0 the number of 1-bits in operand 1. <var>m</var> is the |
| mode of operand 0; operand 1’s mode is specified by the instruction |
| pattern, and the compiler will convert the operand to that mode before |
| generating the instruction. |
| </p> |
| <a name="index-paritym2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>parity<var>m</var>2</samp>’</dt> |
| <dd><p>Store into operand 0 the parity of operand 1, i.e. the number of 1-bits |
| in operand 1 modulo 2. <var>m</var> is the mode of operand 0; operand 1’s mode |
| is specified by the instruction pattern, and the compiler will convert |
| the operand to that mode before generating the instruction. |
| </p> |
| <a name="index-one_005fcmplm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>one_cmpl<var>m</var>2</samp>’</dt> |
| <dd><p>Store the bitwise-complement of operand 1 into operand 0. |
| </p> |
| <a name="index-movmemm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>movmem<var>m</var></samp>’</dt> |
| <dd><p>Block move instruction. The destination and source blocks of memory |
| are the first two operands, and both are <code>mem:BLK</code>s with an |
| address in mode <code>Pmode</code>. |
| </p> |
| <p>The number of bytes to move is the third operand, in mode <var>m</var>. |
| Usually, you specify <code>Pmode</code> for <var>m</var>. However, if you can |
| generate better code knowing the range of valid lengths is smaller than |
| those representable in a full Pmode pointer, you should provide |
| a pattern with a |
| mode corresponding to the range of values you can handle efficiently |
| (e.g., <code>QImode</code> for values in the range 0–127; note we avoid numbers |
| that appear negative) and also a pattern with <code>Pmode</code>. |
| </p> |
| <p>The fourth operand is the known shared alignment of the source and |
| destination, in the form of a <code>const_int</code> rtx. Thus, if the |
| compiler knows that both source and destination are word-aligned, |
| it may provide the value 4 for this operand. |
| </p> |
| <p>Optional operands 5 and 6 specify expected alignment and size of block |
| respectively. The expected alignment differs from alignment in operand 4 |
| in a way that the blocks are not required to be aligned according to it in |
| all cases. This expected alignment is also in bytes, just like operand 4. |
| Expected size, when unknown, is set to <code>(const_int -1)</code>. |
| </p> |
| <p>Descriptions of multiple <code>movmem<var>m</var></code> patterns can only be |
| beneficial if the patterns for smaller modes have fewer restrictions |
| on their first, second and fourth operands. Note that the mode <var>m</var> |
| in <code>movmem<var>m</var></code> does not impose any restriction on the mode of |
| individually moved data units in the block. |
| </p> |
| <p>These patterns need not give special consideration to the possibility |
| that the source and destination strings might overlap. |
| </p> |
| <a name="index-movstr-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>movstr</samp>’</dt> |
| <dd><p>String copy instruction, with <code>stpcpy</code> semantics. Operand 0 is |
| an output operand in mode <code>Pmode</code>. The addresses of the |
| destination and source strings are operands 1 and 2, and both are |
| <code>mem:BLK</code>s with addresses in mode <code>Pmode</code>. The execution of |
| the expansion of this pattern should store in operand 0 the address in |
| which the <code>NUL</code> terminator was stored in the destination string. |
| </p> |
| <p>This patern has also several optional operands that are same as in |
| <code>setmem</code>. |
| </p> |
| <a name="index-setmemm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>setmem<var>m</var></samp>’</dt> |
| <dd><p>Block set instruction. The destination string is the first operand, |
| given as a <code>mem:BLK</code> whose address is in mode <code>Pmode</code>. The |
| number of bytes to set is the second operand, in mode <var>m</var>. The value to |
| initialize the memory with is the third operand. Targets that only support the |
| clearing of memory should reject any value that is not the constant 0. See |
| ‘<samp>movmem<var>m</var></samp>’ for a discussion of the choice of mode. |
| </p> |
| <p>The fourth operand is the known alignment of the destination, in the form |
| of a <code>const_int</code> rtx. Thus, if the compiler knows that the |
| destination is word-aligned, it may provide the value 4 for this |
| operand. |
| </p> |
| <p>Optional operands 5 and 6 specify expected alignment and size of block |
| respectively. The expected alignment differs from alignment in operand 4 |
| in a way that the blocks are not required to be aligned according to it in |
| all cases. This expected alignment is also in bytes, just like operand 4. |
| Expected size, when unknown, is set to <code>(const_int -1)</code>. |
| Operand 7 is the minimal size of the block and operand 8 is the |
| maximal size of the block (NULL if it can not be represented as CONST_INT). |
| Operand 9 is the probable maximal size (i.e. we can not rely on it for correctness, |
| but it can be used for choosing proper code sequence for a given size). |
| </p> |
| <p>The use for multiple <code>setmem<var>m</var></code> is as for <code>movmem<var>m</var></code>. |
| </p> |
| <a name="index-cmpstrnm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cmpstrn<var>m</var></samp>’</dt> |
| <dd><p>String compare instruction, with five operands. Operand 0 is the output; |
| it has mode <var>m</var>. The remaining four operands are like the operands |
| of ‘<samp>movmem<var>m</var></samp>’. The two memory blocks specified are compared |
| byte by byte in lexicographic order starting at the beginning of each |
| string. The instruction is not allowed to prefetch more than one byte |
| at a time since either string may end in the first byte and reading past |
| that may access an invalid page or segment and cause a fault. The |
| comparison terminates early if the fetched bytes are different or if |
| they are equal to zero. The effect of the instruction is to store a |
| value in operand 0 whose sign indicates the result of the comparison. |
| </p> |
| <a name="index-cmpstrm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cmpstr<var>m</var></samp>’</dt> |
| <dd><p>String compare instruction, without known maximum length. Operand 0 is the |
| output; it has mode <var>m</var>. The second and third operand are the blocks of |
| memory to be compared; both are <code>mem:BLK</code> with an address in mode |
| <code>Pmode</code>. |
| </p> |
| <p>The fourth operand is the known shared alignment of the source and |
| destination, in the form of a <code>const_int</code> rtx. Thus, if the |
| compiler knows that both source and destination are word-aligned, |
| it may provide the value 4 for this operand. |
| </p> |
| <p>The two memory blocks specified are compared byte by byte in lexicographic |
| order starting at the beginning of each string. The instruction is not allowed |
| to prefetch more than one byte at a time since either string may end in the |
| first byte and reading past that may access an invalid page or segment and |
| cause a fault. The comparison will terminate when the fetched bytes |
| are different or if they are equal to zero. The effect of the |
| instruction is to store a value in operand 0 whose sign indicates the |
| result of the comparison. |
| </p> |
| <a name="index-cmpmemm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cmpmem<var>m</var></samp>’</dt> |
| <dd><p>Block compare instruction, with five operands like the operands |
| of ‘<samp>cmpstr<var>m</var></samp>’. The two memory blocks specified are compared |
| byte by byte in lexicographic order starting at the beginning of each |
| block. Unlike ‘<samp>cmpstr<var>m</var></samp>’ the instruction can prefetch |
| any bytes in the two memory blocks. Also unlike ‘<samp>cmpstr<var>m</var></samp>’ |
| the comparison will not stop if both bytes are zero. The effect of |
| the instruction is to store a value in operand 0 whose sign indicates |
| the result of the comparison. |
| </p> |
| <a name="index-strlenm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>strlen<var>m</var></samp>’</dt> |
| <dd><p>Compute the length of a string, with three operands. |
| Operand 0 is the result (of mode <var>m</var>), operand 1 is |
| a <code>mem</code> referring to the first character of the string, |
| operand 2 is the character to search for (normally zero), |
| and operand 3 is a constant describing the known alignment |
| of the beginning of the string. |
| </p> |
| <a name="index-floatmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>float<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert signed integer operand 1 (valid for fixed point mode <var>m</var>) to |
| floating point mode <var>n</var> and store in operand 0 (which has mode |
| <var>n</var>). |
| </p> |
| <a name="index-floatunsmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>floatuns<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert unsigned integer operand 1 (valid for fixed point mode <var>m</var>) |
| to floating point mode <var>n</var> and store in operand 0 (which has mode |
| <var>n</var>). |
| </p> |
| <a name="index-fixmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fix<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as a signed number and store in operand 0 (which |
| has mode <var>n</var>). This instruction’s result is defined only when |
| the value of operand 1 is an integer. |
| </p> |
| <p>If the machine description defines this pattern, it also needs to |
| define the <code>ftrunc</code> pattern. |
| </p> |
| <a name="index-fixunsmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fixuns<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to fixed |
| point mode <var>n</var> as an unsigned number and store in operand 0 (which |
| has mode <var>n</var>). This instruction’s result is defined only when the |
| value of operand 1 is an integer. |
| </p> |
| <a name="index-ftruncm2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ftrunc<var>m</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 (valid for floating point mode <var>m</var>) to an |
| integer value, still represented in floating point mode <var>m</var>, and |
| store it in operand 0 (valid for floating point mode <var>m</var>). |
| </p> |
| <a name="index-fix_005ftruncmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fix_trunc<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Like ‘<samp>fix<var>m</var><var>n</var>2</samp>’ but works for any floating point value |
| of mode <var>m</var> by converting the value to an integer. |
| </p> |
| <a name="index-fixuns_005ftruncmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fixuns_trunc<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Like ‘<samp>fixuns<var>m</var><var>n</var>2</samp>’ but works for any floating point |
| value of mode <var>m</var> by converting the value to an integer. |
| </p> |
| <a name="index-truncmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>trunc<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Truncate operand 1 (valid for mode <var>m</var>) to mode <var>n</var> and |
| store in operand 0 (which has mode <var>n</var>). Both modes must be fixed |
| point or both floating point. |
| </p> |
| <a name="index-extendmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extend<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Sign-extend operand 1 (valid for mode <var>m</var>) to mode <var>n</var> and |
| store in operand 0 (which has mode <var>n</var>). Both modes must be fixed |
| point or both floating point. |
| </p> |
| <a name="index-zero_005fextendmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>zero_extend<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Zero-extend operand 1 (valid for mode <var>m</var>) to mode <var>n</var> and |
| store in operand 0 (which has mode <var>n</var>). Both modes must be fixed |
| point. |
| </p> |
| <a name="index-fractmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fract<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 of mode <var>m</var> to mode <var>n</var> and store in |
| operand 0 (which has mode <var>n</var>). Mode <var>m</var> and mode <var>n</var> |
| could be fixed-point to fixed-point, signed integer to fixed-point, |
| fixed-point to signed integer, floating-point to fixed-point, |
| or fixed-point to floating-point. |
| When overflows or underflows happen, the results are undefined. |
| </p> |
| <a name="index-satfractmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>satfract<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 of mode <var>m</var> to mode <var>n</var> and store in |
| operand 0 (which has mode <var>n</var>). Mode <var>m</var> and mode <var>n</var> |
| could be fixed-point to fixed-point, signed integer to fixed-point, |
| or floating-point to fixed-point. |
| When overflows or underflows happen, the instruction saturates the |
| results to the maximum or the minimum. |
| </p> |
| <a name="index-fractunsmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>fractuns<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert operand 1 of mode <var>m</var> to mode <var>n</var> and store in |
| operand 0 (which has mode <var>n</var>). Mode <var>m</var> and mode <var>n</var> |
| could be unsigned integer to fixed-point, or |
| fixed-point to unsigned integer. |
| When overflows or underflows happen, the results are undefined. |
| </p> |
| <a name="index-satfractunsmn2-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>satfractuns<var>m</var><var>n</var>2</samp>’</dt> |
| <dd><p>Convert unsigned integer operand 1 of mode <var>m</var> to fixed-point mode |
| <var>n</var> and store in operand 0 (which has mode <var>n</var>). |
| When overflows or underflows happen, the instruction saturates the |
| results to the maximum or the minimum. |
| </p> |
| <a name="index-extvm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extv<var>m</var></samp>’</dt> |
| <dd><p>Extract a bit-field from register operand 1, sign-extend it, and store |
| it in operand 0. Operand 2 specifies the width of the field in bits |
| and operand 3 the starting bit, which counts from the most significant |
| bit if ‘<samp>BITS_BIG_ENDIAN</samp>’ is true and from the least significant bit |
| otherwise. |
| </p> |
| <p>Operands 0 and 1 both have mode <var>m</var>. Operands 2 and 3 have a |
| target-specific mode. |
| </p> |
| <a name="index-extvmisalignm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extvmisalign<var>m</var></samp>’</dt> |
| <dd><p>Extract a bit-field from memory operand 1, sign extend it, and store |
| it in operand 0. Operand 2 specifies the width in bits and operand 3 |
| the starting bit. The starting bit is always somewhere in the first byte of |
| operand 1; it counts from the most significant bit if ‘<samp>BITS_BIG_ENDIAN</samp>’ |
| is true and from the least significant bit otherwise. |
| </p> |
| <p>Operand 0 has mode <var>m</var> while operand 1 has <code>BLK</code> mode. |
| Operands 2 and 3 have a target-specific mode. |
| </p> |
| <p>The instruction must not read beyond the last byte of the bit-field. |
| </p> |
| <a name="index-extzvm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extzv<var>m</var></samp>’</dt> |
| <dd><p>Like ‘<samp>extv<var>m</var></samp>’ except that the bit-field value is zero-extended. |
| </p> |
| <a name="index-extzvmisalignm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extzvmisalign<var>m</var></samp>’</dt> |
| <dd><p>Like ‘<samp>extvmisalign<var>m</var></samp>’ except that the bit-field value is |
| zero-extended. |
| </p> |
| <a name="index-insvm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>insv<var>m</var></samp>’</dt> |
| <dd><p>Insert operand 3 into a bit-field of register operand 0. Operand 1 |
| specifies the width of the field in bits and operand 2 the starting bit, |
| which counts from the most significant bit if ‘<samp>BITS_BIG_ENDIAN</samp>’ |
| is true and from the least significant bit otherwise. |
| </p> |
| <p>Operands 0 and 3 both have mode <var>m</var>. Operands 1 and 2 have a |
| target-specific mode. |
| </p> |
| <a name="index-insvmisalignm-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>insvmisalign<var>m</var></samp>’</dt> |
| <dd><p>Insert operand 3 into a bit-field of memory operand 0. Operand 1 |
| specifies the width of the field in bits and operand 2 the starting bit. |
| The starting bit is always somewhere in the first byte of operand 0; |
| it counts from the most significant bit if ‘<samp>BITS_BIG_ENDIAN</samp>’ |
| is true and from the least significant bit otherwise. |
| </p> |
| <p>Operand 3 has mode <var>m</var> while operand 0 has <code>BLK</code> mode. |
| Operands 1 and 2 have a target-specific mode. |
| </p> |
| <p>The instruction must not read or write beyond the last byte of the bit-field. |
| </p> |
| <a name="index-extv-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extv</samp>’</dt> |
| <dd><p>Extract a bit-field from operand 1 (a register or memory operand), where |
| operand 2 specifies the width in bits and operand 3 the starting bit, |
| and store it in operand 0. Operand 0 must have mode <code>word_mode</code>. |
| Operand 1 may have mode <code>byte_mode</code> or <code>word_mode</code>; often |
| <code>word_mode</code> is allowed only for registers. Operands 2 and 3 must |
| be valid for <code>word_mode</code>. |
| </p> |
| <p>The RTL generation pass generates this instruction only with constants |
| for operands 2 and 3 and the constant is never zero for operand 2. |
| </p> |
| <p>The bit-field value is sign-extended to a full word integer |
| before it is stored in operand 0. |
| </p> |
| <p>This pattern is deprecated; please use ‘<samp>extv<var>m</var></samp>’ and |
| <code>extvmisalign<var>m</var></code> instead. |
| </p> |
| <a name="index-extzv-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>extzv</samp>’</dt> |
| <dd><p>Like ‘<samp>extv</samp>’ except that the bit-field value is zero-extended. |
| </p> |
| <p>This pattern is deprecated; please use ‘<samp>extzv<var>m</var></samp>’ and |
| <code>extzvmisalign<var>m</var></code> instead. |
| </p> |
| <a name="index-insv-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>insv</samp>’</dt> |
| <dd><p>Store operand 3 (which must be valid for <code>word_mode</code>) into a |
| bit-field in operand 0, where operand 1 specifies the width in bits and |
| operand 2 the starting bit. Operand 0 may have mode <code>byte_mode</code> or |
| <code>word_mode</code>; often <code>word_mode</code> is allowed only for registers. |
| Operands 1 and 2 must be valid for <code>word_mode</code>. |
| </p> |
| <p>The RTL generation pass generates this instruction only with constants |
| for operands 1 and 2 and the constant is never zero for operand 1. |
| </p> |
| <p>This pattern is deprecated; please use ‘<samp>insv<var>m</var></samp>’ and |
| <code>insvmisalign<var>m</var></code> instead. |
| </p> |
| <a name="index-movmodecc-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mov<var>mode</var>cc</samp>’</dt> |
| <dd><p>Conditionally move operand 2 or operand 3 into operand 0 according to the |
| comparison in operand 1. If the comparison is true, operand 2 is moved |
| into operand 0, otherwise operand 3 is moved. |
| </p> |
| <p>The mode of the operands being compared need not be the same as the operands |
| being moved. Some machines, sparc64 for example, have instructions that |
| conditionally move an integer value based on the floating point condition |
| codes and vice versa. |
| </p> |
| <p>If the machine does not have conditional move instructions, do not |
| define these patterns. |
| </p> |
| <a name="index-addmodecc-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>add<var>mode</var>cc</samp>’</dt> |
| <dd><p>Similar to ‘<samp>mov<var>mode</var>cc</samp>’ but for conditional addition. Conditionally |
| move operand 2 or (operands 2 + operand 3) into operand 0 according to the |
| comparison in operand 1. If the comparison is false, operand 2 is moved into |
| operand 0, otherwise (operand 2 + operand 3) is moved. |
| </p> |
| <a name="index-cstoremode4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cstore<var>mode</var>4</samp>’</dt> |
| <dd><p>Store zero or nonzero in operand 0 according to whether a comparison |
| is true. Operand 1 is a comparison operator. Operand 2 and operand 3 |
| are the first and second operand of the comparison, respectively. |
| You specify the mode that operand 0 must have when you write the |
| <code>match_operand</code> expression. The compiler automatically sees which |
| mode you have used and supplies an operand of that mode. |
| </p> |
| <p>The value stored for a true condition must have 1 as its low bit, or |
| else must be negative. Otherwise the instruction is not suitable and |
| you should omit it from the machine description. You describe to the |
| compiler exactly which value is stored by defining the macro |
| <code>STORE_FLAG_VALUE</code> (see <a href="Misc.html#Misc">Misc</a>). If a description cannot be |
| found that can be used for all the possible comparison operators, you |
| should pick one and use a <code>define_expand</code> to map all results |
| onto the one you chose. |
| </p> |
| <p>These operations may <code>FAIL</code>, but should do so only in relatively |
| uncommon cases; if they would <code>FAIL</code> for common cases involving |
| integer comparisons, it is best to restrict the predicates to not |
| allow these operands. Likewise if a given comparison operator will |
| always fail, independent of the operands (for floating-point modes, the |
| <code>ordered_comparison_operator</code> predicate is often useful in this case). |
| </p> |
| <p>If this pattern is omitted, the compiler will generate a conditional |
| branch—for example, it may copy a constant one to the target and branching |
| around an assignment of zero to the target—or a libcall. If the predicate |
| for operand 1 only rejects some operators, it will also try reordering the |
| operands and/or inverting the result value (e.g. by an exclusive OR). |
| These possibilities could be cheaper or equivalent to the instructions |
| used for the ‘<samp>cstore<var>mode</var>4</samp>’ pattern followed by those required |
| to convert a positive result from <code>STORE_FLAG_VALUE</code> to 1; in this |
| case, you can and should make operand 1’s predicate reject some operators |
| in the ‘<samp>cstore<var>mode</var>4</samp>’ pattern, or remove the pattern altogether |
| from the machine description. |
| </p> |
| <a name="index-cbranchmode4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>cbranch<var>mode</var>4</samp>’</dt> |
| <dd><p>Conditional branch instruction combined with a compare instruction. |
| Operand 0 is a comparison operator. Operand 1 and operand 2 are the |
| first and second operands of the comparison, respectively. Operand 3 |
| is a <code>label_ref</code> that refers to the label to jump to. |
| </p> |
| <a name="index-jump-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>jump</samp>’</dt> |
| <dd><p>A jump inside a function; an unconditional branch. Operand 0 is the |
| <code>label_ref</code> of the label to jump to. This pattern name is mandatory |
| on all machines. |
| </p> |
| <a name="index-call-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>call</samp>’</dt> |
| <dd><p>Subroutine call instruction returning no value. Operand 0 is the |
| function to call; operand 1 is the number of bytes of arguments pushed |
| as a <code>const_int</code>; operand 2 is the number of registers used as |
| operands. |
| </p> |
| <p>On most machines, operand 2 is not actually stored into the RTL |
| pattern. It is supplied for the sake of some RISC machines which need |
| to put this information into the assembler code; they can put it in |
| the RTL instead of operand 1. |
| </p> |
| <p>Operand 0 should be a <code>mem</code> RTX whose address is the address of the |
| function. Note, however, that this address can be a <code>symbol_ref</code> |
| expression even if it would not be a legitimate memory address on the |
| target machine. If it is also not a valid argument for a call |
| instruction, the pattern for this operation should be a |
| <code>define_expand</code> (see <a href="Expander-Definitions.html#Expander-Definitions">Expander Definitions</a>) that places the |
| address into a register and uses that register in the call instruction. |
| </p> |
| <a name="index-call_005fvalue-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>call_value</samp>’</dt> |
| <dd><p>Subroutine call instruction returning a value. Operand 0 is the hard |
| register in which the value is returned. There are three more |
| operands, the same as the three operands of the ‘<samp>call</samp>’ |
| instruction (but with numbers increased by one). |
| </p> |
| <p>Subroutines that return <code>BLKmode</code> objects use the ‘<samp>call</samp>’ |
| insn. |
| </p> |
| <a name="index-call_005fpop-instruction-pattern"></a> |
| <a name="index-call_005fvalue_005fpop-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>call_pop</samp>’, ‘<samp>call_value_pop</samp>’</dt> |
| <dd><p>Similar to ‘<samp>call</samp>’ and ‘<samp>call_value</samp>’, except used if defined and |
| if <code>RETURN_POPS_ARGS</code> is nonzero. They should emit a <code>parallel</code> |
| that contains both the function call and a <code>set</code> to indicate the |
| adjustment made to the frame pointer. |
| </p> |
| <p>For machines where <code>RETURN_POPS_ARGS</code> can be nonzero, the use of these |
| patterns increases the number of functions for which the frame pointer |
| can be eliminated, if desired. |
| </p> |
| <a name="index-untyped_005fcall-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>untyped_call</samp>’</dt> |
| <dd><p>Subroutine call instruction returning a value of any type. Operand 0 is |
| the function to call; operand 1 is a memory location where the result of |
| calling the function is to be stored; operand 2 is a <code>parallel</code> |
| expression where each element is a <code>set</code> expression that indicates |
| the saving of a function return value into the result block. |
| </p> |
| <p>This instruction pattern should be defined to support |
| <code>__builtin_apply</code> on machines where special instructions are needed |
| to call a subroutine with arbitrary arguments or to save the value |
| returned. This instruction pattern is required on machines that have |
| multiple registers that can hold a return value |
| (i.e. <code>FUNCTION_VALUE_REGNO_P</code> is true for more than one register). |
| </p> |
| <a name="index-return-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>return</samp>’</dt> |
| <dd><p>Subroutine return instruction. This instruction pattern name should be |
| defined only if a single instruction can do all the work of returning |
| from a function. |
| </p> |
| <p>Like the ‘<samp>mov<var>m</var></samp>’ patterns, this pattern is also used after the |
| RTL generation phase. In this case it is to support machines where |
| multiple instructions are usually needed to return from a function, but |
| some class of functions only requires one instruction to implement a |
| return. Normally, the applicable functions are those which do not need |
| to save any registers or allocate stack space. |
| </p> |
| <p>It is valid for this pattern to expand to an instruction using |
| <code>simple_return</code> if no epilogue is required. |
| </p> |
| <a name="index-simple_005freturn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>simple_return</samp>’</dt> |
| <dd><p>Subroutine return instruction. This instruction pattern name should be |
| defined only if a single instruction can do all the work of returning |
| from a function on a path where no epilogue is required. This pattern |
| is very similar to the <code>return</code> instruction pattern, but it is emitted |
| only by the shrink-wrapping optimization on paths where the function |
| prologue has not been executed, and a function return should occur without |
| any of the effects of the epilogue. Additional uses may be introduced on |
| paths where both the prologue and the epilogue have executed. |
| </p> |
| <a name="index-reload_005fcompleted"></a> |
| <a name="index-leaf_005ffunction_005fp"></a> |
| <p>For such machines, the condition specified in this pattern should only |
| be true when <code>reload_completed</code> is nonzero and the function’s |
| epilogue would only be a single instruction. For machines with register |
| windows, the routine <code>leaf_function_p</code> may be used to determine if |
| a register window push is required. |
| </p> |
| <p>Machines that have conditional return instructions should define patterns |
| such as |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(define_insn "" |
| [(set (pc) |
| (if_then_else (match_operator |
| 0 "comparison_operator" |
| [(cc0) (const_int 0)]) |
| (return) |
| (pc)))] |
| "<var>condition</var>" |
| "…") |
| </pre></div> |
| |
| <p>where <var>condition</var> would normally be the same condition specified on the |
| named ‘<samp>return</samp>’ pattern. |
| </p> |
| <a name="index-untyped_005freturn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>untyped_return</samp>’</dt> |
| <dd><p>Untyped subroutine return instruction. This instruction pattern should |
| be defined to support <code>__builtin_return</code> on machines where special |
| instructions are needed to return a value of any type. |
| </p> |
| <p>Operand 0 is a memory location where the result of calling a function |
| with <code>__builtin_apply</code> is stored; operand 1 is a <code>parallel</code> |
| expression where each element is a <code>set</code> expression that indicates |
| the restoring of a function return value from the result block. |
| </p> |
| <a name="index-nop-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>nop</samp>’</dt> |
| <dd><p>No-op instruction. This instruction pattern name should always be defined |
| to output a no-op in assembler code. <code>(const_int 0)</code> will do as an |
| RTL pattern. |
| </p> |
| <a name="index-indirect_005fjump-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>indirect_jump</samp>’</dt> |
| <dd><p>An instruction to jump to an address which is operand zero. |
| This pattern name is mandatory on all machines. |
| </p> |
| <a name="index-casesi-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>casesi</samp>’</dt> |
| <dd><p>Instruction to jump through a dispatch table, including bounds checking. |
| This instruction takes five operands: |
| </p> |
| <ol> |
| <li> The index to dispatch on, which has mode <code>SImode</code>. |
| |
| </li><li> The lower bound for indices in the table, an integer constant. |
| |
| </li><li> The total range of indices in the table—the largest index |
| minus the smallest one (both inclusive). |
| |
| </li><li> A label that precedes the table itself. |
| |
| </li><li> A label to jump to if the index has a value outside the bounds. |
| </li></ol> |
| |
| <p>The table is an <code>addr_vec</code> or <code>addr_diff_vec</code> inside of a |
| <code>jump_table_data</code>. The number of elements in the table is one plus the |
| difference between the upper bound and the lower bound. |
| </p> |
| <a name="index-tablejump-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>tablejump</samp>’</dt> |
| <dd><p>Instruction to jump to a variable address. This is a low-level |
| capability which can be used to implement a dispatch table when there |
| is no ‘<samp>casesi</samp>’ pattern. |
| </p> |
| <p>This pattern requires two operands: the address or offset, and a label |
| which should immediately precede the jump table. If the macro |
| <code>CASE_VECTOR_PC_RELATIVE</code> evaluates to a nonzero value then the first |
| operand is an offset which counts from the address of the table; otherwise, |
| it is an absolute address to jump to. In either case, the first operand has |
| mode <code>Pmode</code>. |
| </p> |
| <p>The ‘<samp>tablejump</samp>’ insn is always the last insn before the jump |
| table it uses. Its assembler code normally has no need to use the |
| second operand, but you should incorporate it in the RTL pattern so |
| that the jump optimizer will not delete the table as unreachable code. |
| </p> |
| |
| <a name="index-decrement_005fand_005fbranch_005funtil_005fzero-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>decrement_and_branch_until_zero</samp>’</dt> |
| <dd><p>Conditional branch instruction that decrements a register and |
| jumps if the register is nonzero. Operand 0 is the register to |
| decrement and test; operand 1 is the label to jump to if the |
| register is nonzero. See <a href="Looping-Patterns.html#Looping-Patterns">Looping Patterns</a>. |
| </p> |
| <p>This optional instruction pattern is only used by the combiner, |
| typically for loops reversed by the loop optimizer when strength |
| reduction is enabled. |
| </p> |
| <a name="index-doloop_005fend-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>doloop_end</samp>’</dt> |
| <dd><p>Conditional branch instruction that decrements a register and |
| jumps if the register is nonzero. Operand 0 is the register to |
| decrement and test; operand 1 is the label to jump to if the |
| register is nonzero. |
| See <a href="Looping-Patterns.html#Looping-Patterns">Looping Patterns</a>. |
| </p> |
| <p>This optional instruction pattern should be defined for machines with |
| low-overhead looping instructions as the loop optimizer will try to |
| modify suitable loops to utilize it. The target hook |
| <code>TARGET_CAN_USE_DOLOOP_P</code> controls the conditions under which |
| low-overhead loops can be used. |
| </p> |
| <a name="index-doloop_005fbegin-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>doloop_begin</samp>’</dt> |
| <dd><p>Companion instruction to <code>doloop_end</code> required for machines that |
| need to perform some initialization, such as loading a special counter |
| register. Operand 1 is the associated <code>doloop_end</code> pattern and |
| operand 0 is the register that it decrements. |
| </p> |
| <p>If initialization insns do not always need to be emitted, use a |
| <code>define_expand</code> (see <a href="Expander-Definitions.html#Expander-Definitions">Expander Definitions</a>) and make it fail. |
| </p> |
| <a name="index-canonicalize_005ffuncptr_005ffor_005fcompare-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>canonicalize_funcptr_for_compare</samp>’</dt> |
| <dd><p>Canonicalize the function pointer in operand 1 and store the result |
| into operand 0. |
| </p> |
| <p>Operand 0 is always a <code>reg</code> and has mode <code>Pmode</code>; operand 1 |
| may be a <code>reg</code>, <code>mem</code>, <code>symbol_ref</code>, <code>const_int</code>, etc |
| and also has mode <code>Pmode</code>. |
| </p> |
| <p>Canonicalization of a function pointer usually involves computing |
| the address of the function which would be called if the function |
| pointer were used in an indirect call. |
| </p> |
| <p>Only define this pattern if function pointers on the target machine |
| can have different values but still call the same function when |
| used in an indirect call. |
| </p> |
| <a name="index-save_005fstack_005fblock-instruction-pattern"></a> |
| <a name="index-save_005fstack_005ffunction-instruction-pattern"></a> |
| <a name="index-save_005fstack_005fnonlocal-instruction-pattern"></a> |
| <a name="index-restore_005fstack_005fblock-instruction-pattern"></a> |
| <a name="index-restore_005fstack_005ffunction-instruction-pattern"></a> |
| <a name="index-restore_005fstack_005fnonlocal-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>save_stack_block</samp>’</dt> |
| <dt>‘<samp>save_stack_function</samp>’</dt> |
| <dt>‘<samp>save_stack_nonlocal</samp>’</dt> |
| <dt>‘<samp>restore_stack_block</samp>’</dt> |
| <dt>‘<samp>restore_stack_function</samp>’</dt> |
| <dt>‘<samp>restore_stack_nonlocal</samp>’</dt> |
| <dd><p>Most machines save and restore the stack pointer by copying it to or |
| from an object of mode <code>Pmode</code>. Do not define these patterns on |
| such machines. |
| </p> |
| <p>Some machines require special handling for stack pointer saves and |
| restores. On those machines, define the patterns corresponding to the |
| non-standard cases by using a <code>define_expand</code> (see <a href="Expander-Definitions.html#Expander-Definitions">Expander Definitions</a>) that produces the required insns. The three types of |
| saves and restores are: |
| </p> |
| <ol> |
| <li> ‘<samp>save_stack_block</samp>’ saves the stack pointer at the start of a block |
| that allocates a variable-sized object, and ‘<samp>restore_stack_block</samp>’ |
| restores the stack pointer when the block is exited. |
| |
| </li><li> ‘<samp>save_stack_function</samp>’ and ‘<samp>restore_stack_function</samp>’ do a |
| similar job for the outermost block of a function and are used when the |
| function allocates variable-sized objects or calls <code>alloca</code>. Only |
| the epilogue uses the restored stack pointer, allowing a simpler save or |
| restore sequence on some machines. |
| |
| </li><li> ‘<samp>save_stack_nonlocal</samp>’ is used in functions that contain labels |
| branched to by nested functions. It saves the stack pointer in such a |
| way that the inner function can use ‘<samp>restore_stack_nonlocal</samp>’ to |
| restore the stack pointer. The compiler generates code to restore the |
| frame and argument pointer registers, but some machines require saving |
| and restoring additional data such as register window information or |
| stack backchains. Place insns in these patterns to save and restore any |
| such required data. |
| </li></ol> |
| |
| <p>When saving the stack pointer, operand 0 is the save area and operand 1 |
| is the stack pointer. The mode used to allocate the save area defaults |
| to <code>Pmode</code> but you can override that choice by defining the |
| <code>STACK_SAVEAREA_MODE</code> macro (see <a href="Storage-Layout.html#Storage-Layout">Storage Layout</a>). You must |
| specify an integral mode, or <code>VOIDmode</code> if no save area is needed |
| for a particular type of save (either because no save is needed or |
| because a machine-specific save area can be used). Operand 0 is the |
| stack pointer and operand 1 is the save area for restore operations. If |
| ‘<samp>save_stack_block</samp>’ is defined, operand 0 must not be |
| <code>VOIDmode</code> since these saves can be arbitrarily nested. |
| </p> |
| <p>A save area is a <code>mem</code> that is at a constant offset from |
| <code>virtual_stack_vars_rtx</code> when the stack pointer is saved for use by |
| nonlocal gotos and a <code>reg</code> in the other two cases. |
| </p> |
| <a name="index-allocate_005fstack-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>allocate_stack</samp>’</dt> |
| <dd><p>Subtract (or add if <code>STACK_GROWS_DOWNWARD</code> is undefined) operand 1 from |
| the stack pointer to create space for dynamically allocated data. |
| </p> |
| <p>Store the resultant pointer to this space into operand 0. If you |
| are allocating space from the main stack, do this by emitting a |
| move insn to copy <code>virtual_stack_dynamic_rtx</code> to operand 0. |
| If you are allocating the space elsewhere, generate code to copy the |
| location of the space to operand 0. In the latter case, you must |
| ensure this space gets freed when the corresponding space on the main |
| stack is free. |
| </p> |
| <p>Do not define this pattern if all that must be done is the subtraction. |
| Some machines require other operations such as stack probes or |
| maintaining the back chain. Define this pattern to emit those |
| operations in addition to updating the stack pointer. |
| </p> |
| <a name="index-check_005fstack-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>check_stack</samp>’</dt> |
| <dd><p>If stack checking (see <a href="Stack-Checking.html#Stack-Checking">Stack Checking</a>) cannot be done on your system by |
| probing the stack, define this pattern to perform the needed check and signal |
| an error if the stack has overflowed. The single operand is the address in |
| the stack farthest from the current stack pointer that you need to validate. |
| Normally, on platforms where this pattern is needed, you would obtain the |
| stack limit from a global or thread-specific variable or register. |
| </p> |
| <a name="index-probe_005fstack_005faddress-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>probe_stack_address</samp>’</dt> |
| <dd><p>If stack checking (see <a href="Stack-Checking.html#Stack-Checking">Stack Checking</a>) can be done on your system by |
| probing the stack but without the need to actually access it, define this |
| pattern and signal an error if the stack has overflowed. The single operand |
| is the memory address in the stack that needs to be probed. |
| </p> |
| <a name="index-probe_005fstack-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>probe_stack</samp>’</dt> |
| <dd><p>If stack checking (see <a href="Stack-Checking.html#Stack-Checking">Stack Checking</a>) can be done on your system by |
| probing the stack but doing it with a “store zero” instruction is not valid |
| or optimal, define this pattern to do the probing differently and signal an |
| error if the stack has overflowed. The single operand is the memory reference |
| in the stack that needs to be probed. |
| </p> |
| <a name="index-nonlocal_005fgoto-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>nonlocal_goto</samp>’</dt> |
| <dd><p>Emit code to generate a non-local goto, e.g., a jump from one function |
| to a label in an outer function. This pattern has four arguments, |
| each representing a value to be used in the jump. The first |
| argument is to be loaded into the frame pointer, the second is |
| the address to branch to (code to dispatch to the actual label), |
| the third is the address of a location where the stack is saved, |
| and the last is the address of the label, to be placed in the |
| location for the incoming static chain. |
| </p> |
| <p>On most machines you need not define this pattern, since GCC will |
| already generate the correct code, which is to load the frame pointer |
| and static chain, restore the stack (using the |
| ‘<samp>restore_stack_nonlocal</samp>’ pattern, if defined), and jump indirectly |
| to the dispatcher. You need only define this pattern if this code will |
| not work on your machine. |
| </p> |
| <a name="index-nonlocal_005fgoto_005freceiver-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>nonlocal_goto_receiver</samp>’</dt> |
| <dd><p>This pattern, if defined, contains code needed at the target of a |
| nonlocal goto after the code already generated by GCC. You will not |
| normally need to define this pattern. A typical reason why you might |
| need this pattern is if some value, such as a pointer to a global table, |
| must be restored when the frame pointer is restored. Note that a nonlocal |
| goto only occurs within a unit-of-translation, so a global table pointer |
| that is shared by all functions of a given module need not be restored. |
| There are no arguments. |
| </p> |
| <a name="index-exception_005freceiver-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>exception_receiver</samp>’</dt> |
| <dd><p>This pattern, if defined, contains code needed at the site of an |
| exception handler that isn’t needed at the site of a nonlocal goto. You |
| will not normally need to define this pattern. A typical reason why you |
| might need this pattern is if some value, such as a pointer to a global |
| table, must be restored after control flow is branched to the handler of |
| an exception. There are no arguments. |
| </p> |
| <a name="index-builtin_005fsetjmp_005fsetup-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>builtin_setjmp_setup</samp>’</dt> |
| <dd><p>This pattern, if defined, contains additional code needed to initialize |
| the <code>jmp_buf</code>. You will not normally need to define this pattern. |
| A typical reason why you might need this pattern is if some value, such |
| as a pointer to a global table, must be restored. Though it is |
| preferred that the pointer value be recalculated if possible (given the |
| address of a label for instance). The single argument is a pointer to |
| the <code>jmp_buf</code>. Note that the buffer is five words long and that |
| the first three are normally used by the generic mechanism. |
| </p> |
| <a name="index-builtin_005fsetjmp_005freceiver-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>builtin_setjmp_receiver</samp>’</dt> |
| <dd><p>This pattern, if defined, contains code needed at the site of a |
| built-in setjmp that isn’t needed at the site of a nonlocal goto. You |
| will not normally need to define this pattern. A typical reason why you |
| might need this pattern is if some value, such as a pointer to a global |
| table, must be restored. It takes one argument, which is the label |
| to which builtin_longjmp transferred control; this pattern may be emitted |
| at a small offset from that label. |
| </p> |
| <a name="index-builtin_005flongjmp-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>builtin_longjmp</samp>’</dt> |
| <dd><p>This pattern, if defined, performs the entire action of the longjmp. |
| You will not normally need to define this pattern unless you also define |
| <code>builtin_setjmp_setup</code>. The single argument is a pointer to the |
| <code>jmp_buf</code>. |
| </p> |
| <a name="index-eh_005freturn-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>eh_return</samp>’</dt> |
| <dd><p>This pattern, if defined, affects the way <code>__builtin_eh_return</code>, |
| and thence the call frame exception handling library routines, are |
| built. It is intended to handle non-trivial actions needed along |
| the abnormal return path. |
| </p> |
| <p>The address of the exception handler to which the function should return |
| is passed as operand to this pattern. It will normally need to copied by |
| the pattern to some special register or memory location. |
| If the pattern needs to determine the location of the target call |
| frame in order to do so, it may use <code>EH_RETURN_STACKADJ_RTX</code>, |
| if defined; it will have already been assigned. |
| </p> |
| <p>If this pattern is not defined, the default action will be to simply |
| copy the return address to <code>EH_RETURN_HANDLER_RTX</code>. Either |
| that macro or this pattern needs to be defined if call frame exception |
| handling is to be used. |
| </p> |
| <a name="index-prologue-instruction-pattern"></a> |
| <a name="prologue-instruction-pattern"></a></dd> |
| <dt>‘<samp>prologue</samp>’</dt> |
| <dd><p>This pattern, if defined, emits RTL for entry to a function. The function |
| entry is responsible for setting up the stack frame, initializing the frame |
| pointer register, saving callee saved registers, etc. |
| </p> |
| <p>Using a prologue pattern is generally preferred over defining |
| <code>TARGET_ASM_FUNCTION_PROLOGUE</code> to emit assembly code for the prologue. |
| </p> |
| <p>The <code>prologue</code> pattern is particularly useful for targets which perform |
| instruction scheduling. |
| </p> |
| <a name="index-window_005fsave-instruction-pattern"></a> |
| <a name="window_005fsave-instruction-pattern"></a></dd> |
| <dt>‘<samp>window_save</samp>’</dt> |
| <dd><p>This pattern, if defined, emits RTL for a register window save. It should |
| be defined if the target machine has register windows but the window events |
| are decoupled from calls to subroutines. The canonical example is the SPARC |
| architecture. |
| </p> |
| <a name="index-epilogue-instruction-pattern"></a> |
| <a name="epilogue-instruction-pattern"></a></dd> |
| <dt>‘<samp>epilogue</samp>’</dt> |
| <dd><p>This pattern emits RTL for exit from a function. The function |
| exit is responsible for deallocating the stack frame, restoring callee saved |
| registers and emitting the return instruction. |
| </p> |
| <p>Using an epilogue pattern is generally preferred over defining |
| <code>TARGET_ASM_FUNCTION_EPILOGUE</code> to emit assembly code for the epilogue. |
| </p> |
| <p>The <code>epilogue</code> pattern is particularly useful for targets which perform |
| instruction scheduling or which have delay slots for their return instruction. |
| </p> |
| <a name="index-sibcall_005fepilogue-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sibcall_epilogue</samp>’</dt> |
| <dd><p>This pattern, if defined, emits RTL for exit from a function without the final |
| branch back to the calling function. This pattern will be emitted before any |
| sibling call (aka tail call) sites. |
| </p> |
| <p>The <code>sibcall_epilogue</code> pattern must not clobber any arguments used for |
| parameter passing or any stack slots for arguments passed to the current |
| function. |
| </p> |
| <a name="index-trap-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>trap</samp>’</dt> |
| <dd><p>This pattern, if defined, signals an error, typically by causing some |
| kind of signal to be raised. Among other places, it is used by the Java |
| front end to signal ‘invalid array index’ exceptions. |
| </p> |
| <a name="index-ctrapMM4-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>ctrap<var>MM</var>4</samp>’</dt> |
| <dd><p>Conditional trap instruction. Operand 0 is a piece of RTL which |
| performs a comparison, and operands 1 and 2 are the arms of the |
| comparison. Operand 3 is the trap code, an integer. |
| </p> |
| <p>A typical <code>ctrap</code> pattern looks like |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(define_insn "ctrapsi4" |
| [(trap_if (match_operator 0 "trap_operator" |
| [(match_operand 1 "register_operand") |
| (match_operand 2 "immediate_operand")]) |
| (match_operand 3 "const_int_operand" "i"))] |
| "" |
| "…") |
| </pre></div> |
| |
| <a name="index-prefetch-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>prefetch</samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, emits code for a non-faulting data prefetch |
| instruction. Operand 0 is the address of the memory to prefetch. Operand 1 |
| is a constant 1 if the prefetch is preparing for a write to the memory |
| address, or a constant 0 otherwise. Operand 2 is the expected degree of |
| temporal locality of the data and is a value between 0 and 3, inclusive; 0 |
| means that the data has no temporal locality, so it need not be left in the |
| cache after the access; 3 means that the data has a high degree of temporal |
| locality and should be left in all levels of cache possible; 1 and 2 mean, |
| respectively, a low or moderate degree of temporal locality. |
| </p> |
| <p>Targets that do not support write prefetches or locality hints can ignore |
| the values of operands 1 and 2. |
| </p> |
| <a name="index-blockage-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>blockage</samp>’</dt> |
| <dd> |
| <p>This pattern defines a pseudo insn that prevents the instruction |
| scheduler and other passes from moving instructions and using register |
| equivalences across the boundary defined by the blockage insn. |
| This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM. |
| </p> |
| <a name="index-memory_005fbarrier-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>memory_barrier</samp>’</dt> |
| <dd> |
| <p>If the target memory model is not fully synchronous, then this pattern |
| should be defined to an instruction that orders both loads and stores |
| before the instruction with respect to loads and stores after the instruction. |
| This pattern has no operands. |
| </p> |
| <a name="index-sync_005fcompare_005fand_005fswapmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_compare_and_swap<var>mode</var></samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, emits code for an atomic compare-and-swap |
| operation. Operand 1 is the memory on which the atomic operation is |
| performed. Operand 2 is the “old” value to be compared against the |
| current contents of the memory location. Operand 3 is the “new” value |
| to store in the memory if the compare succeeds. Operand 0 is the result |
| of the operation; it should contain the contents of the memory |
| before the operation. If the compare succeeds, this should obviously be |
| a copy of operand 2. |
| </p> |
| <p>This pattern must show that both operand 0 and operand 1 are modified. |
| </p> |
| <p>This pattern must issue any memory barrier instructions such that all |
| memory operations before the atomic operation occur before the atomic |
| operation and all memory operations after the atomic operation occur |
| after the atomic operation. |
| </p> |
| <p>For targets where the success or failure of the compare-and-swap |
| operation is available via the status flags, it is possible to |
| avoid a separate compare operation and issue the subsequent |
| branch or store-flag operation immediately after the compare-and-swap. |
| To this end, GCC will look for a <code>MODE_CC</code> set in the |
| output of <code>sync_compare_and_swap<var>mode</var></code>; if the machine |
| description includes such a set, the target should also define special |
| <code>cbranchcc4</code> and/or <code>cstorecc4</code> instructions. GCC will then |
| be able to take the destination of the <code>MODE_CC</code> set and pass it |
| to the <code>cbranchcc4</code> or <code>cstorecc4</code> pattern as the first |
| operand of the comparison (the second will be <code>(const_int 0)</code>). |
| </p> |
| <p>For targets where the operating system may provide support for this |
| operation via library calls, the <code>sync_compare_and_swap_optab</code> |
| may be initialized to a function with the same interface as the |
| <code>__sync_val_compare_and_swap_<var>n</var></code> built-in. If the entire |
| set of <var>__sync</var> builtins are supported via library calls, the |
| target can initialize all of the optabs at once with |
| <code>init_sync_libfuncs</code>. |
| For the purposes of C++11 <code>std::atomic::is_lock_free</code>, it is |
| assumed that these library calls do <em>not</em> use any kind of |
| interruptable locking. |
| </p> |
| <a name="index-sync_005faddmode-instruction-pattern"></a> |
| <a name="index-sync_005fsubmode-instruction-pattern"></a> |
| <a name="index-sync_005fiormode-instruction-pattern"></a> |
| <a name="index-sync_005fandmode-instruction-pattern"></a> |
| <a name="index-sync_005fxormode-instruction-pattern"></a> |
| <a name="index-sync_005fnandmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_add<var>mode</var></samp>’, ‘<samp>sync_sub<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_ior<var>mode</var></samp>’, ‘<samp>sync_and<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_xor<var>mode</var></samp>’, ‘<samp>sync_nand<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns emit code for an atomic operation on memory. |
| Operand 0 is the memory on which the atomic operation is performed. |
| Operand 1 is the second operand to the binary operator. |
| </p> |
| <p>This pattern must issue any memory barrier instructions such that all |
| memory operations before the atomic operation occur before the atomic |
| operation and all memory operations after the atomic operation occur |
| after the atomic operation. |
| </p> |
| <p>If these patterns are not defined, the operation will be constructed |
| from a compare-and-swap operation, if defined. |
| </p> |
| <a name="index-sync_005fold_005faddmode-instruction-pattern"></a> |
| <a name="index-sync_005fold_005fsubmode-instruction-pattern"></a> |
| <a name="index-sync_005fold_005fiormode-instruction-pattern"></a> |
| <a name="index-sync_005fold_005fandmode-instruction-pattern"></a> |
| <a name="index-sync_005fold_005fxormode-instruction-pattern"></a> |
| <a name="index-sync_005fold_005fnandmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_old_add<var>mode</var></samp>’, ‘<samp>sync_old_sub<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_old_ior<var>mode</var></samp>’, ‘<samp>sync_old_and<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_old_xor<var>mode</var></samp>’, ‘<samp>sync_old_nand<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns emit code for an atomic operation on memory, |
| and return the value that the memory contained before the operation. |
| Operand 0 is the result value, operand 1 is the memory on which the |
| atomic operation is performed, and operand 2 is the second operand |
| to the binary operator. |
| </p> |
| <p>This pattern must issue any memory barrier instructions such that all |
| memory operations before the atomic operation occur before the atomic |
| operation and all memory operations after the atomic operation occur |
| after the atomic operation. |
| </p> |
| <p>If these patterns are not defined, the operation will be constructed |
| from a compare-and-swap operation, if defined. |
| </p> |
| <a name="index-sync_005fnew_005faddmode-instruction-pattern"></a> |
| <a name="index-sync_005fnew_005fsubmode-instruction-pattern"></a> |
| <a name="index-sync_005fnew_005fiormode-instruction-pattern"></a> |
| <a name="index-sync_005fnew_005fandmode-instruction-pattern"></a> |
| <a name="index-sync_005fnew_005fxormode-instruction-pattern"></a> |
| <a name="index-sync_005fnew_005fnandmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_new_add<var>mode</var></samp>’, ‘<samp>sync_new_sub<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_new_ior<var>mode</var></samp>’, ‘<samp>sync_new_and<var>mode</var></samp>’</dt> |
| <dt>‘<samp>sync_new_xor<var>mode</var></samp>’, ‘<samp>sync_new_nand<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns are like their <code>sync_old_<var>op</var></code> counterparts, |
| except that they return the value that exists in the memory location |
| after the operation, rather than before the operation. |
| </p> |
| <a name="index-sync_005flock_005ftest_005fand_005fsetmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_lock_test_and_set<var>mode</var></samp>’</dt> |
| <dd> |
| <p>This pattern takes two forms, based on the capabilities of the target. |
| In either case, operand 0 is the result of the operand, operand 1 is |
| the memory on which the atomic operation is performed, and operand 2 |
| is the value to set in the lock. |
| </p> |
| <p>In the ideal case, this operation is an atomic exchange operation, in |
| which the previous value in memory operand is copied into the result |
| operand, and the value operand is stored in the memory operand. |
| </p> |
| <p>For less capable targets, any value operand that is not the constant 1 |
| should be rejected with <code>FAIL</code>. In this case the target may use |
| an atomic test-and-set bit operation. The result operand should contain |
| 1 if the bit was previously set and 0 if the bit was previously clear. |
| The true contents of the memory operand are implementation defined. |
| </p> |
| <p>This pattern must issue any memory barrier instructions such that the |
| pattern as a whole acts as an acquire barrier, that is all memory |
| operations after the pattern do not occur until the lock is acquired. |
| </p> |
| <p>If this pattern is not defined, the operation will be constructed from |
| a compare-and-swap operation, if defined. |
| </p> |
| <a name="index-sync_005flock_005freleasemode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>sync_lock_release<var>mode</var></samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, releases a lock set by |
| <code>sync_lock_test_and_set<var>mode</var></code>. Operand 0 is the memory |
| that contains the lock; operand 1 is the value to store in the lock. |
| </p> |
| <p>If the target doesn’t implement full semantics for |
| <code>sync_lock_test_and_set<var>mode</var></code>, any value operand which is not |
| the constant 0 should be rejected with <code>FAIL</code>, and the true contents |
| of the memory operand are implementation defined. |
| </p> |
| <p>This pattern must issue any memory barrier instructions such that the |
| pattern as a whole acts as a release barrier, that is the lock is |
| released only after all previous memory operations have completed. |
| </p> |
| <p>If this pattern is not defined, then a <code>memory_barrier</code> pattern |
| will be emitted, followed by a store of the value to the memory operand. |
| </p> |
| <a name="index-atomic_005fcompare_005fand_005fswapmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_compare_and_swap<var>mode</var></samp>’</dt> |
| <dd><p>This pattern, if defined, emits code for an atomic compare-and-swap |
| operation with memory model semantics. Operand 2 is the memory on which |
| the atomic operation is performed. Operand 0 is an output operand which |
| is set to true or false based on whether the operation succeeded. Operand |
| 1 is an output operand which is set to the contents of the memory before |
| the operation was attempted. Operand 3 is the value that is expected to |
| be in memory. Operand 4 is the value to put in memory if the expected |
| value is found there. Operand 5 is set to 1 if this compare and swap is to |
| be treated as a weak operation. Operand 6 is the memory model to be used |
| if the operation is a success. Operand 7 is the memory model to be used |
| if the operation fails. |
| </p> |
| <p>If memory referred to in operand 2 contains the value in operand 3, then |
| operand 4 is stored in memory pointed to by operand 2 and fencing based on |
| the memory model in operand 6 is issued. |
| </p> |
| <p>If memory referred to in operand 2 does not contain the value in operand 3, |
| then fencing based on the memory model in operand 7 is issued. |
| </p> |
| <p>If a target does not support weak compare-and-swap operations, or the port |
| elects not to implement weak operations, the argument in operand 5 can be |
| ignored. Note a strong implementation must be provided. |
| </p> |
| <p>If this pattern is not provided, the <code>__atomic_compare_exchange</code> |
| built-in functions will utilize the legacy <code>sync_compare_and_swap</code> |
| pattern with an <code>__ATOMIC_SEQ_CST</code> memory model. |
| </p> |
| <a name="index-atomic_005floadmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_load<var>mode</var></samp>’</dt> |
| <dd><p>This pattern implements an atomic load operation with memory model |
| semantics. Operand 1 is the memory address being loaded from. Operand 0 |
| is the result of the load. Operand 2 is the memory model to be used for |
| the load operation. |
| </p> |
| <p>If not present, the <code>__atomic_load</code> built-in function will either |
| resort to a normal load with memory barriers, or a compare-and-swap |
| operation if a normal load would not be atomic. |
| </p> |
| <a name="index-atomic_005fstoremode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_store<var>mode</var></samp>’</dt> |
| <dd><p>This pattern implements an atomic store operation with memory model |
| semantics. Operand 0 is the memory address being stored to. Operand 1 |
| is the value to be written. Operand 2 is the memory model to be used for |
| the operation. |
| </p> |
| <p>If not present, the <code>__atomic_store</code> built-in function will attempt to |
| perform a normal store and surround it with any required memory fences. If |
| the store would not be atomic, then an <code>__atomic_exchange</code> is |
| attempted with the result being ignored. |
| </p> |
| <a name="index-atomic_005fexchangemode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_exchange<var>mode</var></samp>’</dt> |
| <dd><p>This pattern implements an atomic exchange operation with memory model |
| semantics. Operand 1 is the memory location the operation is performed on. |
| Operand 0 is an output operand which is set to the original value contained |
| in the memory pointed to by operand 1. Operand 2 is the value to be |
| stored. Operand 3 is the memory model to be used. |
| </p> |
| <p>If this pattern is not present, the built-in function |
| <code>__atomic_exchange</code> will attempt to preform the operation with a |
| compare and swap loop. |
| </p> |
| <a name="index-atomic_005faddmode-instruction-pattern"></a> |
| <a name="index-atomic_005fsubmode-instruction-pattern"></a> |
| <a name="index-atomic_005formode-instruction-pattern"></a> |
| <a name="index-atomic_005fandmode-instruction-pattern"></a> |
| <a name="index-atomic_005fxormode-instruction-pattern"></a> |
| <a name="index-atomic_005fnandmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_add<var>mode</var></samp>’, ‘<samp>atomic_sub<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_or<var>mode</var></samp>’, ‘<samp>atomic_and<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_xor<var>mode</var></samp>’, ‘<samp>atomic_nand<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns emit code for an atomic operation on memory with memory |
| model semantics. Operand 0 is the memory on which the atomic operation is |
| performed. Operand 1 is the second operand to the binary operator. |
| Operand 2 is the memory model to be used by the operation. |
| </p> |
| <p>If these patterns are not defined, attempts will be made to use legacy |
| <code>sync</code> patterns, or equivalent patterns which return a result. If |
| none of these are available a compare-and-swap loop will be used. |
| </p> |
| <a name="index-atomic_005ffetch_005faddmode-instruction-pattern"></a> |
| <a name="index-atomic_005ffetch_005fsubmode-instruction-pattern"></a> |
| <a name="index-atomic_005ffetch_005formode-instruction-pattern"></a> |
| <a name="index-atomic_005ffetch_005fandmode-instruction-pattern"></a> |
| <a name="index-atomic_005ffetch_005fxormode-instruction-pattern"></a> |
| <a name="index-atomic_005ffetch_005fnandmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_fetch_add<var>mode</var></samp>’, ‘<samp>atomic_fetch_sub<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_fetch_or<var>mode</var></samp>’, ‘<samp>atomic_fetch_and<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_fetch_xor<var>mode</var></samp>’, ‘<samp>atomic_fetch_nand<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns emit code for an atomic operation on memory with memory |
| model semantics, and return the original value. Operand 0 is an output |
| operand which contains the value of the memory location before the |
| operation was performed. Operand 1 is the memory on which the atomic |
| operation is performed. Operand 2 is the second operand to the binary |
| operator. Operand 3 is the memory model to be used by the operation. |
| </p> |
| <p>If these patterns are not defined, attempts will be made to use legacy |
| <code>sync</code> patterns. If none of these are available a compare-and-swap |
| loop will be used. |
| </p> |
| <a name="index-atomic_005fadd_005ffetchmode-instruction-pattern"></a> |
| <a name="index-atomic_005fsub_005ffetchmode-instruction-pattern"></a> |
| <a name="index-atomic_005for_005ffetchmode-instruction-pattern"></a> |
| <a name="index-atomic_005fand_005ffetchmode-instruction-pattern"></a> |
| <a name="index-atomic_005fxor_005ffetchmode-instruction-pattern"></a> |
| <a name="index-atomic_005fnand_005ffetchmode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_add_fetch<var>mode</var></samp>’, ‘<samp>atomic_sub_fetch<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_or_fetch<var>mode</var></samp>’, ‘<samp>atomic_and_fetch<var>mode</var></samp>’</dt> |
| <dt>‘<samp>atomic_xor_fetch<var>mode</var></samp>’, ‘<samp>atomic_nand_fetch<var>mode</var></samp>’</dt> |
| <dd> |
| <p>These patterns emit code for an atomic operation on memory with memory |
| model semantics and return the result after the operation is performed. |
| Operand 0 is an output operand which contains the value after the |
| operation. Operand 1 is the memory on which the atomic operation is |
| performed. Operand 2 is the second operand to the binary operator. |
| Operand 3 is the memory model to be used by the operation. |
| </p> |
| <p>If these patterns are not defined, attempts will be made to use legacy |
| <code>sync</code> patterns, or equivalent patterns which return the result before |
| the operation followed by the arithmetic operation required to produce the |
| result. If none of these are available a compare-and-swap loop will be |
| used. |
| </p> |
| <a name="index-atomic_005ftest_005fand_005fset-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>atomic_test_and_set</samp>’</dt> |
| <dd> |
| <p>This pattern emits code for <code>__builtin_atomic_test_and_set</code>. |
| Operand 0 is an output operand which is set to true if the previous |
| previous contents of the byte was "set", and false otherwise. Operand 1 |
| is the <code>QImode</code> memory to be modified. Operand 2 is the memory |
| model to be used. |
| </p> |
| <p>The specific value that defines "set" is implementation defined, and |
| is normally based on what is performed by the native atomic test and set |
| instruction. |
| </p> |
| <a name="index-mem_005fthread_005ffencemode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mem_thread_fence<var>mode</var></samp>’</dt> |
| <dd><p>This pattern emits code required to implement a thread fence with |
| memory model semantics. Operand 0 is the memory model to be used. |
| </p> |
| <p>If this pattern is not specified, all memory models except |
| <code>__ATOMIC_RELAXED</code> will result in issuing a <code>sync_synchronize</code> |
| barrier pattern. |
| </p> |
| <a name="index-mem_005fsignal_005ffencemode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>mem_signal_fence<var>mode</var></samp>’</dt> |
| <dd><p>This pattern emits code required to implement a signal fence with |
| memory model semantics. Operand 0 is the memory model to be used. |
| </p> |
| <p>This pattern should impact the compiler optimizers the same way that |
| mem_signal_fence does, but it does not need to issue any barrier |
| instructions. |
| </p> |
| <p>If this pattern is not specified, all memory models except |
| <code>__ATOMIC_RELAXED</code> will result in issuing a <code>sync_synchronize</code> |
| barrier pattern. |
| </p> |
| <a name="index-get_005fthread_005fpointermode-instruction-pattern"></a> |
| <a name="index-set_005fthread_005fpointermode-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>get_thread_pointer<var>mode</var></samp>’</dt> |
| <dt>‘<samp>set_thread_pointer<var>mode</var></samp>’</dt> |
| <dd><p>These patterns emit code that reads/sets the TLS thread pointer. Currently, |
| these are only needed if the target needs to support the |
| <code>__builtin_thread_pointer</code> and <code>__builtin_set_thread_pointer</code> |
| builtins. |
| </p> |
| <p>The get/set patterns have a single output/input operand respectively, |
| with <var>mode</var> intended to be <code>Pmode</code>. |
| </p> |
| <a name="index-stack_005fprotect_005fset-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>stack_protect_set</samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, moves a <code>ptr_mode</code> value from the memory |
| in operand 1 to the memory in operand 0 without leaving the value in |
| a register afterward. This is to avoid leaking the value some place |
| that an attacker might use to rewrite the stack guard slot after |
| having clobbered it. |
| </p> |
| <p>If this pattern is not defined, then a plain move pattern is generated. |
| </p> |
| <a name="index-stack_005fprotect_005ftest-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>stack_protect_test</samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, compares a <code>ptr_mode</code> value from the |
| memory in operand 1 with the memory in operand 0 without leaving the |
| value in a register afterward and branches to operand 2 if the values |
| were equal. |
| </p> |
| <p>If this pattern is not defined, then a plain compare pattern and |
| conditional branch pattern is used. |
| </p> |
| <a name="index-clear_005fcache-instruction-pattern"></a> |
| </dd> |
| <dt>‘<samp>clear_cache</samp>’</dt> |
| <dd> |
| <p>This pattern, if defined, flushes the instruction cache for a region of |
| memory. The region is bounded to by the Pmode pointers in operand 0 |
| inclusive and operand 1 exclusive. |
| </p> |
| <p>If this pattern is not defined, a call to the library function |
| <code>__clear_cache</code> is used. |
| </p> |
| </dd> |
| </dl> |
| |
| <hr> |
| <div class="header"> |
| <p> |
| Next: <a href="Pattern-Ordering.html#Pattern-Ordering" accesskey="n" rel="next">Pattern Ordering</a>, Previous: <a href="Constraints.html#Constraints" accesskey="p" rel="prev">Constraints</a>, Up: <a href="Machine-Desc.html#Machine-Desc" accesskey="u" rel="up">Machine Desc</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> |
