visus
/
toolchain-gcc-arm-embedded

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1988-2020 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Funding Free Software", the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
"GNU Free Documentation License".

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU
     software.  Copies published by the Free Software Foundation raise
     funds for GNU development. -->
<!-- Created by GNU Texinfo 6.5, http://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Addressing Modes (GNU Compiler Collection (GCC) Internals)</title>

<meta name="description" content="Addressing Modes (GNU Compiler Collection (GCC) Internals)">
<meta name="keywords" content="Addressing Modes (GNU Compiler Collection (GCC) Internals)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<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="Target-Macros.html#Target-Macros" rel="up" title="Target Macros">
<link href="Anchored-Addresses.html#Anchored-Addresses" rel="next" title="Anchored Addresses">
<link href="Library-Calls.html#Library-Calls" rel="prev" title="Library Calls">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en">
<a name="Addressing-Modes"></a>
<div class="header">
<p>
Next: <a href="Anchored-Addresses.html#Anchored-Addresses" accesskey="n" rel="next">Anchored Addresses</a>, Previous: <a href="Library-Calls.html#Library-Calls" accesskey="p" rel="prev">Library Calls</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> &nbsp; [<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="Addressing-Modes-1"></a>
<h3 class="section">18.13 Addressing Modes</h3>
<a name="index-addressing-modes"></a>

<p>This is about addressing modes.
</p>
<dl>
<dt><a name="index-HAVE_005fPRE_005fINCREMENT"></a>Macro: <strong>HAVE_PRE_INCREMENT</strong></dt>
<dt><a name="index-HAVE_005fPRE_005fDECREMENT"></a>Macro: <strong>HAVE_PRE_DECREMENT</strong></dt>
<dt><a name="index-HAVE_005fPOST_005fINCREMENT"></a>Macro: <strong>HAVE_POST_INCREMENT</strong></dt>
<dt><a name="index-HAVE_005fPOST_005fDECREMENT"></a>Macro: <strong>HAVE_POST_DECREMENT</strong></dt>
<dd><p>A C expression that is nonzero if the machine supports pre-increment,
pre-decrement, post-increment, or post-decrement addressing respectively.
</p></dd></dl>

<dl>
<dt><a name="index-HAVE_005fPRE_005fMODIFY_005fDISP"></a>Macro: <strong>HAVE_PRE_MODIFY_DISP</strong></dt>
<dt><a name="index-HAVE_005fPOST_005fMODIFY_005fDISP"></a>Macro: <strong>HAVE_POST_MODIFY_DISP</strong></dt>
<dd><p>A C expression that is nonzero if the machine supports pre- or
post-address side-effect generation involving constants other than
the size of the memory operand.
</p></dd></dl>

<dl>
<dt><a name="index-HAVE_005fPRE_005fMODIFY_005fREG"></a>Macro: <strong>HAVE_PRE_MODIFY_REG</strong></dt>
<dt><a name="index-HAVE_005fPOST_005fMODIFY_005fREG"></a>Macro: <strong>HAVE_POST_MODIFY_REG</strong></dt>
<dd><p>A C expression that is nonzero if the machine supports pre- or
post-address side-effect generation involving a register displacement.
</p></dd></dl>

<dl>
<dt><a name="index-CONSTANT_005fADDRESS_005fP"></a>Macro: <strong>CONSTANT_ADDRESS_P</strong> <em>(<var>x</var>)</em></dt>
<dd><p>A C expression that is 1 if the RTX <var>x</var> is a constant which
is a valid address.  On most machines the default definition of
<code>(CONSTANT_P (<var>x</var>) &amp;&amp; GET_CODE (<var>x</var>) != CONST_DOUBLE)</code>
is acceptable, but a few machines are more restrictive as to which
constant addresses are supported.
</p></dd></dl>

<dl>
<dt><a name="index-CONSTANT_005fP"></a>Macro: <strong>CONSTANT_P</strong> <em>(<var>x</var>)</em></dt>
<dd><p><code>CONSTANT_P</code>, which is defined by target-independent code,
accepts integer-values expressions whose values are not explicitly
known, such as <code>symbol_ref</code>, <code>label_ref</code>, and <code>high</code>
expressions and <code>const</code> arithmetic expressions, in addition to
<code>const_int</code> and <code>const_double</code> expressions.
</p></dd></dl>

<dl>
<dt><a name="index-MAX_005fREGS_005fPER_005fADDRESS"></a>Macro: <strong>MAX_REGS_PER_ADDRESS</strong></dt>
<dd><p>A number, the maximum number of registers that can appear in a valid
memory address.  Note that it is up to you to specify a value equal to
the maximum number that <code>TARGET_LEGITIMATE_ADDRESS_P</code> would ever
accept.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fLEGITIMATE_005fADDRESS_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_LEGITIMATE_ADDRESS_P</strong> <em>(machine_mode <var>mode</var>, rtx <var>x</var>, bool <var>strict</var>)</em></dt>
<dd><p>A function that returns whether <var>x</var> (an RTX) is a legitimate memory
address on the target machine for a memory operand of mode <var>mode</var>.
</p>
<p>Legitimate addresses are defined in two variants: a strict variant and a
non-strict one.  The <var>strict</var> parameter chooses which variant is
desired by the caller.
</p>
<p>The strict variant is used in the reload pass.  It must be defined so
that any pseudo-register that has not been allocated a hard register is
considered a memory reference.  This is because in contexts where some
kind of register is required, a pseudo-register with no hard register
must be rejected.  For non-hard registers, the strict variant should look
up the <code>reg_renumber</code> array; it should then proceed using the hard
register number in the array, or treat the pseudo as a memory reference
if the array holds <code>-1</code>.
</p>
<p>The non-strict variant is used in other passes.  It must be defined to
accept all pseudo-registers in every context where some kind of
register is required.
</p>
<p>Normally, constant addresses which are the sum of a <code>symbol_ref</code>
and an integer are stored inside a <code>const</code> RTX to mark them as
constant.  Therefore, there is no need to recognize such sums
specifically as legitimate addresses.  Normally you would simply
recognize any <code>const</code> as legitimate.
</p>
<p>Usually <code>PRINT_OPERAND_ADDRESS</code> is not prepared to handle constant
sums that are not marked with  <code>const</code>.  It assumes that a naked
<code>plus</code> indicates indexing.  If so, then you <em>must</em> reject such
naked constant sums as illegitimate addresses, so that none of them will
be given to <code>PRINT_OPERAND_ADDRESS</code>.
</p>
<a name="index-TARGET_005fENCODE_005fSECTION_005fINFO-and-address-validation"></a>
<p>On some machines, whether a symbolic address is legitimate depends on
the section that the address refers to.  On these machines, define the
target hook <code>TARGET_ENCODE_SECTION_INFO</code> to store the information
into the <code>symbol_ref</code>, and then check for it here.  When you see a
<code>const</code>, you will have to look inside it to find the
<code>symbol_ref</code> in order to determine the section.  See <a href="Assembler-Format.html#Assembler-Format">Assembler Format</a>.
</p>
<a name="index-GO_005fIF_005fLEGITIMATE_005fADDRESS"></a>
<p>Some ports are still using a deprecated legacy substitute for
this hook, the <code>GO_IF_LEGITIMATE_ADDRESS</code> macro.  This macro
has this syntax:
</p>
<div class="example">
<pre class="example">#define GO_IF_LEGITIMATE_ADDRESS (<var>mode</var>, <var>x</var>, <var>label</var>)
</pre></div>

<p>and should <code>goto <var>label</var></code> if the address <var>x</var> is a valid
address on the target machine for a memory operand of mode <var>mode</var>.
</p>
<a name="index-REG_005fOK_005fSTRICT"></a>
<p>Compiler source files that want to use the strict variant of this
macro define the macro <code>REG_OK_STRICT</code>.  You should use an
<code>#ifdef REG_OK_STRICT</code> conditional to define the strict variant in
that case and the non-strict variant otherwise.
</p>
<p>Using the hook is usually simpler because it limits the number of
files that are recompiled when changes are made.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fMEM_005fCONSTRAINT"></a>Macro: <strong>TARGET_MEM_CONSTRAINT</strong></dt>
<dd><p>A single character to be used instead of the default <code>'m'</code>
character for general memory addresses.  This defines the constraint
letter which matches the memory addresses accepted by
<code>TARGET_LEGITIMATE_ADDRESS_P</code>.  Define this macro if you want to
support new address formats in your back end without changing the
semantics of the <code>'m'</code> constraint.  This is necessary in order to
preserve functionality of inline assembly constructs using the
<code>'m'</code> constraint.
</p></dd></dl>

<dl>
<dt><a name="index-FIND_005fBASE_005fTERM"></a>Macro: <strong>FIND_BASE_TERM</strong> <em>(<var>x</var>)</em></dt>
<dd><p>A C expression to determine the base term of address <var>x</var>,
or to provide a simplified version of <var>x</var> from which <samp>alias.c</samp>
can easily find the base term.  This macro is used in only two places:
<code>find_base_value</code> and <code>find_base_term</code> in <samp>alias.c</samp>.
</p>
<p>It is always safe for this macro to not be defined.  It exists so
that alias analysis can understand machine-dependent addresses.
</p>
<p>The typical use of this macro is to handle addresses containing
a label_ref or symbol_ref within an UNSPEC.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fLEGITIMIZE_005fADDRESS"></a>Target Hook: <em>rtx</em> <strong>TARGET_LEGITIMIZE_ADDRESS</strong> <em>(rtx <var>x</var>, rtx <var>oldx</var>, machine_mode <var>mode</var>)</em></dt>
<dd><p>This hook is given an invalid memory address <var>x</var> for an
operand of mode <var>mode</var> and should try to return a valid memory
address.
</p>
<a name="index-break_005fout_005fmemory_005frefs"></a>
<p><var>x</var> will always be the result of a call to <code>break_out_memory_refs</code>,
and <var>oldx</var> will be the operand that was given to that function to produce
<var>x</var>.
</p>
<p>The code of the hook should not alter the substructure of
<var>x</var>.  If it transforms <var>x</var> into a more legitimate form, it
should return the new <var>x</var>.
</p>
<p>It is not necessary for this hook to come up with a legitimate address,
with the exception of native TLS addresses (see <a href="Emulated-TLS.html#Emulated-TLS">Emulated TLS</a>).
The compiler has standard ways of doing so in all cases.  In fact, if
the target supports only emulated TLS, it
is safe to omit this hook or make it return <var>x</var> if it cannot find
a valid way to legitimize the address.  But often a machine-dependent
strategy can generate better code.
</p></dd></dl>

<dl>
<dt><a name="index-LEGITIMIZE_005fRELOAD_005fADDRESS"></a>Macro: <strong>LEGITIMIZE_RELOAD_ADDRESS</strong> <em>(<var>x</var>, <var>mode</var>, <var>opnum</var>, <var>type</var>, <var>ind_levels</var>, <var>win</var>)</em></dt>
<dd><p>A C compound statement that attempts to replace <var>x</var>, which is an address
that needs reloading, with a valid memory address for an operand of mode
<var>mode</var>.  <var>win</var> will be a C statement label elsewhere in the code.
It is not necessary to define this macro, but it might be useful for
performance reasons.
</p>
<p>For example, on the i386, it is sometimes possible to use a single
reload register instead of two by reloading a sum of two pseudo
registers into a register.  On the other hand, for number of RISC
processors offsets are limited so that often an intermediate address
needs to be generated in order to address a stack slot.  By defining
<code>LEGITIMIZE_RELOAD_ADDRESS</code> appropriately, the intermediate addresses
generated for adjacent some stack slots can be made identical, and thus
be shared.
</p>
<p><em>Note</em>: This macro should be used with caution.  It is necessary
to know something of how reload works in order to effectively use this,
and it is quite easy to produce macros that build in too much knowledge
of reload internals.
</p>
<p><em>Note</em>: This macro must be able to reload an address created by a
previous invocation of this macro.  If it fails to handle such addresses
then the compiler may generate incorrect code or abort.
</p>
<a name="index-push_005freload"></a>
<p>The macro definition should use <code>push_reload</code> to indicate parts that
need reloading; <var>opnum</var>, <var>type</var> and <var>ind_levels</var> are usually
suitable to be passed unaltered to <code>push_reload</code>.
</p>
<p>The code generated by this macro must not alter the substructure of
<var>x</var>.  If it transforms <var>x</var> into a more legitimate form, it
should assign <var>x</var> (which will always be a C variable) a new value.
This also applies to parts that you change indirectly by calling
<code>push_reload</code>.
</p>
<a name="index-strict_005fmemory_005faddress_005fp"></a>
<p>The macro definition may use <code>strict_memory_address_p</code> to test if
the address has become legitimate.
</p>
<a name="index-copy_005frtx"></a>
<p>If you want to change only a part of <var>x</var>, one standard way of doing
this is to use <code>copy_rtx</code>.  Note, however, that it unshares only a
single level of rtl.  Thus, if the part to be changed is not at the
top level, you&rsquo;ll need to replace first the top level.
It is not necessary for this macro to come up with a legitimate
address;  but often a machine-dependent strategy can generate better code.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fMODE_005fDEPENDENT_005fADDRESS_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_MODE_DEPENDENT_ADDRESS_P</strong> <em>(const_rtx <var>addr</var>, addr_space_t <var>addrspace</var>)</em></dt>
<dd><p>This hook returns <code>true</code> if memory address <var>addr</var> in address
space <var>addrspace</var> can have
different meanings depending on the machine mode of the memory
reference it is used for or if the address is valid for some modes
but not others.
</p>
<p>Autoincrement and autodecrement addresses typically have mode-dependent
effects because the amount of the increment or decrement is the size
of the operand being addressed.  Some machines have other mode-dependent
addresses.  Many RISC machines have no mode-dependent addresses.
</p>
<p>You may assume that <var>addr</var> is a valid address for the machine.
</p>
<p>The default version of this hook returns <code>false</code>.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fLEGITIMATE_005fCONSTANT_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_LEGITIMATE_CONSTANT_P</strong> <em>(machine_mode <var>mode</var>, rtx <var>x</var>)</em></dt>
<dd><p>This hook returns true if <var>x</var> is a legitimate constant for a
<var>mode</var>-mode immediate operand on the target machine.  You can assume that
<var>x</var> satisfies <code>CONSTANT_P</code>, so you need not check this.
</p>
<p>The default definition returns true.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fDELEGITIMIZE_005fADDRESS"></a>Target Hook: <em>rtx</em> <strong>TARGET_DELEGITIMIZE_ADDRESS</strong> <em>(rtx <var>x</var>)</em></dt>
<dd><p>This hook is used to undo the possibly obfuscating effects of the
<code>LEGITIMIZE_ADDRESS</code> and <code>LEGITIMIZE_RELOAD_ADDRESS</code> target
macros.  Some backend implementations of these macros wrap symbol
references inside an <code>UNSPEC</code> rtx to represent PIC or similar
addressing modes.  This target hook allows GCC&rsquo;s optimizers to understand
the semantics of these opaque <code>UNSPEC</code>s by converting them back
into their original form.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fCONST_005fNOT_005fOK_005fFOR_005fDEBUG_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_CONST_NOT_OK_FOR_DEBUG_P</strong> <em>(rtx <var>x</var>)</em></dt>
<dd><p>This hook should return true if <var>x</var> should not be emitted into
debug sections.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fCANNOT_005fFORCE_005fCONST_005fMEM"></a>Target Hook: <em>bool</em> <strong>TARGET_CANNOT_FORCE_CONST_MEM</strong> <em>(machine_mode <var>mode</var>, rtx <var>x</var>)</em></dt>
<dd><p>This hook should return true if <var>x</var> is of a form that cannot (or
should not) be spilled to the constant pool.  <var>mode</var> is the mode
of <var>x</var>.
</p>
<p>The default version of this hook returns false.
</p>
<p>The primary reason to define this hook is to prevent reload from
deciding that a non-legitimate constant would be better reloaded
from the constant pool instead of spilling and reloading a register
holding the constant.  This restriction is often true of addresses
of TLS symbols for various targets.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fUSE_005fBLOCKS_005fFOR_005fCONSTANT_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_USE_BLOCKS_FOR_CONSTANT_P</strong> <em>(machine_mode <var>mode</var>, const_rtx <var>x</var>)</em></dt>
<dd><p>This hook should return true if pool entries for constant <var>x</var> can
be placed in an <code>object_block</code> structure.  <var>mode</var> is the mode
of <var>x</var>.
</p>
<p>The default version returns false for all constants.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fUSE_005fBLOCKS_005fFOR_005fDECL_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_USE_BLOCKS_FOR_DECL_P</strong> <em>(const_tree <var>decl</var>)</em></dt>
<dd><p>This hook should return true if pool entries for <var>decl</var> should
be placed in an <code>object_block</code> structure.
</p>
<p>The default version returns true for all decls.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fBUILTIN_005fRECIPROCAL"></a>Target Hook: <em>tree</em> <strong>TARGET_BUILTIN_RECIPROCAL</strong> <em>(tree <var>fndecl</var>)</em></dt>
<dd><p>This hook should return the DECL of a function that implements the
reciprocal of the machine-specific builtin function <var>fndecl</var>, or
<code>NULL_TREE</code> if such a function is not available.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fMASK_005fFOR_005fLOAD"></a>Target Hook: <em>tree</em> <strong>TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD</strong> <em>(void)</em></dt>
<dd><p>This hook should return the DECL of a function <var>f</var> that given an
address <var>addr</var> as an argument returns a mask <var>m</var> that can be
used to extract from two vectors the relevant data that resides in
<var>addr</var> in case <var>addr</var> is not properly aligned.
</p>
<p>The autovectorizer, when vectorizing a load operation from an address
<var>addr</var> that may be unaligned, will generate two vector loads from
the two aligned addresses around <var>addr</var>. It then generates a
<code>REALIGN_LOAD</code> operation to extract the relevant data from the
two loaded vectors. The first two arguments to <code>REALIGN_LOAD</code>,
<var>v1</var> and <var>v2</var>, are the two vectors, each of size <var>VS</var>, and
the third argument, <var>OFF</var>, defines how the data will be extracted
from these two vectors: if <var>OFF</var> is 0, then the returned vector is
<var>v2</var>; otherwise, the returned vector is composed from the last
<var>VS</var>-<var>OFF</var> elements of <var>v1</var> concatenated to the first
<var>OFF</var> elements of <var>v2</var>.
</p>
<p>If this hook is defined, the autovectorizer will generate a call
to <var>f</var> (using the DECL tree that this hook returns) and will
use the return value of <var>f</var> as the argument <var>OFF</var> to
<code>REALIGN_LOAD</code>. Therefore, the mask <var>m</var> returned by <var>f</var>
should comply with the semantics expected by <code>REALIGN_LOAD</code>
described above.
If this hook is not defined, then <var>addr</var> will be used as
the argument <var>OFF</var> to <code>REALIGN_LOAD</code>, in which case the low
log2(<var>VS</var>) - 1 bits of <var>addr</var> will be considered.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fVECTORIZATION_005fCOST"></a>Target Hook: <em>int</em> <strong>TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST</strong> <em>(enum vect_cost_for_stmt <var>type_of_cost</var>, tree <var>vectype</var>, int <var>misalign</var>)</em></dt>
<dd><p>Returns cost of different scalar or vector statements for vectorization cost model.
For vector memory operations the cost may depend on type (<var>vectype</var>) and
misalignment value (<var>misalign</var>).
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fPREFERRED_005fVECTOR_005fALIGNMENT"></a>Target Hook: <em>poly_uint64</em> <strong>TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT</strong> <em>(const_tree <var>type</var>)</em></dt>
<dd><p>This hook returns the preferred alignment in bits for accesses to
vectors of type <var>type</var> in vectorized code.  This might be less than
or greater than the ABI-defined value returned by
<code>TARGET_VECTOR_ALIGNMENT</code>.  It can be equal to the alignment of
a single element, in which case the vectorizer will not try to optimize
for alignment.
</p>
<p>The default hook returns <code>TYPE_ALIGN (<var>type</var>)</code>, which is
correct for most targets.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fVECTOR_005fALIGNMENT_005fREACHABLE"></a>Target Hook: <em>bool</em> <strong>TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE</strong> <em>(const_tree <var>type</var>, bool <var>is_packed</var>)</em></dt>
<dd><p>Return true if vector alignment is reachable (by peeling N iterations) for the given scalar type <var>type</var>.  <var>is_packed</var> is false if the scalar access using <var>type</var> is known to be naturally aligned.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fVEC_005fPERM_005fCONST"></a>Target Hook: <em>bool</em> <strong>TARGET_VECTORIZE_VEC_PERM_CONST</strong> <em>(machine_mode <var>mode</var>, rtx <var>output</var>, rtx <var>in0</var>, rtx <var>in1</var>, const vec_perm_indices <var>&amp;sel</var>)</em></dt>
<dd><p>This hook is used to test whether the target can permute up to two
vectors of mode <var>mode</var> using the permutation vector <code>sel</code>, and
also to emit such a permutation.  In the former case <var>in0</var>, <var>in1</var>
and <var>out</var> are all null.  In the latter case <var>in0</var> and <var>in1</var> are
the source vectors and <var>out</var> is the destination vector; all three are
registers of mode <var>mode</var>.  <var>in1</var> is the same as <var>in0</var> if
<var>sel</var> describes a permutation on one vector instead of two.
</p>
<p>Return true if the operation is possible, emitting instructions for it
if rtxes are provided.
</p>
<a name="index-vec_005fpermm-instruction-pattern-1"></a>
<p>If the hook returns false for a mode with multibyte elements, GCC will
try the equivalent byte operation.  If that also fails, it will try forcing
the selector into a register and using the <var>vec_perm<var>mode</var></var>
instruction pattern.  There is no need for the hook to handle these two
implementation approaches itself.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fVECTORIZED_005fFUNCTION"></a>Target Hook: <em>tree</em> <strong>TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION</strong> <em>(unsigned <var>code</var>, tree <var>vec_type_out</var>, tree <var>vec_type_in</var>)</em></dt>
<dd><p>This hook should return the decl of a function that implements the
vectorized variant of the function with the <code>combined_fn</code> code
<var>code</var> or <code>NULL_TREE</code> if such a function is not available.
The return type of the vectorized function shall be of vector type
<var>vec_type_out</var> and the argument types should be <var>vec_type_in</var>.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fMD_005fVECTORIZED_005fFUNCTION"></a>Target Hook: <em>tree</em> <strong>TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION</strong> <em>(tree <var>fndecl</var>, tree <var>vec_type_out</var>, tree <var>vec_type_in</var>)</em></dt>
<dd><p>This hook should return the decl of a function that implements the
vectorized variant of target built-in function <code>fndecl</code>.  The
return type of the vectorized function shall be of vector type
<var>vec_type_out</var> and the argument types should be <var>vec_type_in</var>.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fSUPPORT_005fVECTOR_005fMISALIGNMENT"></a>Target Hook: <em>bool</em> <strong>TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT</strong> <em>(machine_mode <var>mode</var>, const_tree <var>type</var>, int <var>misalignment</var>, bool <var>is_packed</var>)</em></dt>
<dd><p>This hook should return true if the target supports misaligned vector
store/load of a specific factor denoted in the <var>misalignment</var>
parameter.  The vector store/load should be of machine mode <var>mode</var> and
the elements in the vectors should be of type <var>type</var>.  <var>is_packed</var>
parameter is true if the memory access is defined in a packed struct.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fPREFERRED_005fSIMD_005fMODE"></a>Target Hook: <em>machine_mode</em> <strong>TARGET_VECTORIZE_PREFERRED_SIMD_MODE</strong> <em>(scalar_mode <var>mode</var>)</em></dt>
<dd><p>This hook should return the preferred mode for vectorizing scalar
mode <var>mode</var>.  The default is
equal to <code>word_mode</code>, because the vectorizer can do some
transformations even in absence of specialized <acronym>SIMD</acronym> hardware.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fSPLIT_005fREDUCTION"></a>Target Hook: <em>machine_mode</em> <strong>TARGET_VECTORIZE_SPLIT_REDUCTION</strong> <em>(machine_mode)</em></dt>
<dd><p>This hook should return the preferred mode to split the final reduction
step on <var>mode</var> to.  The reduction is then carried out reducing upper
against lower halves of vectors recursively until the specified mode is
reached.  The default is <var>mode</var> which means no splitting.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fAUTOVECTORIZE_005fVECTOR_005fMODES"></a>Target Hook: <em>unsigned int</em> <strong>TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES</strong> <em>(vector_modes *<var>modes</var>, bool <var>all</var>)</em></dt>
<dd><p>If using the mode returned by <code>TARGET_VECTORIZE_PREFERRED_SIMD_MODE</code>
is not the only approach worth considering, this hook should add one mode to
<var>modes</var> for each useful alternative approach.  These modes are then
passed to <code>TARGET_VECTORIZE_RELATED_MODE</code> to obtain the vector mode
for a given element mode.
</p>
<p>The modes returned in <var>modes</var> should use the smallest element mode
possible for the vectorization approach that they represent, preferring
integer modes over floating-poing modes in the event of a tie.  The first
mode should be the <code>TARGET_VECTORIZE_PREFERRED_SIMD_MODE</code> for its
element mode.
</p>
<p>If <var>all</var> is true, add suitable vector modes even when they are generally
not expected to be worthwhile.
</p>
<p>The hook returns a bitmask of flags that control how the modes in
<var>modes</var> are used.  The flags are:
</p><dl compact="compact">
<dt><code>VECT_COMPARE_COSTS</code></dt>
<dd><p>Tells the loop vectorizer to try all the provided modes and pick the one
with the lowest cost.  By default the vectorizer will choose the first
mode that works.
</p></dd>
</dl>

<p>The hook does not need to do anything if the vector returned by
<code>TARGET_VECTORIZE_PREFERRED_SIMD_MODE</code> is the only one relevant
for autovectorization.  The default implementation adds no modes and
returns 0.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fRELATED_005fMODE"></a>Target Hook: <em>opt_machine_mode</em> <strong>TARGET_VECTORIZE_RELATED_MODE</strong> <em>(machine_mode <var>vector_mode</var>, scalar_mode <var>element_mode</var>, poly_uint64 <var>nunits</var>)</em></dt>
<dd><p>If a piece of code is using vector mode <var>vector_mode</var> and also wants
to operate on elements of mode <var>element_mode</var>, return the vector mode
it should use for those elements.  If <var>nunits</var> is nonzero, ensure that
the mode has exactly <var>nunits</var> elements, otherwise pick whichever vector
size pairs the most naturally with <var>vector_mode</var>.  Return an empty
<code>opt_machine_mode</code> if there is no supported vector mode with the
required properties.
</p>
<p>There is no prescribed way of handling the case in which <var>nunits</var>
is zero.  One common choice is to pick a vector mode with the same size
as <var>vector_mode</var>; this is the natural choice if the target has a
fixed vector size.  Another option is to choose a vector mode with the
same number of elements as <var>vector_mode</var>; this is the natural choice
if the target has a fixed number of elements.  Alternatively, the hook
might choose a middle ground, such as trying to keep the number of
elements as similar as possible while applying maximum and minimum
vector sizes.
</p>
<p>The default implementation uses <code>mode_for_vector</code> to find the
requested mode, returning a mode with the same size as <var>vector_mode</var>
when <var>nunits</var> is zero.  This is the correct behavior for most targets.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fGET_005fMASK_005fMODE"></a>Target Hook: <em>opt_machine_mode</em> <strong>TARGET_VECTORIZE_GET_MASK_MODE</strong> <em>(machine_mode <var>mode</var>)</em></dt>
<dd><p>Return the mode to use for a vector mask that holds one boolean
result for each element of vector mode <var>mode</var>.  The returned mask mode
can be a vector of integers (class <code>MODE_VECTOR_INT</code>), a vector of
booleans (class <code>MODE_VECTOR_BOOL</code>) or a scalar integer (class
<code>MODE_INT</code>).  Return an empty <code>opt_machine_mode</code> if no such
mask mode exists.
</p>
<p>The default implementation returns a <code>MODE_VECTOR_INT</code> with the
same size and number of elements as <var>mode</var>, if such a mode exists.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fEMPTY_005fMASK_005fIS_005fEXPENSIVE"></a>Target Hook: <em>bool</em> <strong>TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE</strong> <em>(unsigned <var>ifn</var>)</em></dt>
<dd><p>This hook returns true if masked internal function <var>ifn</var> (really of
type <code>internal_fn</code>) should be considered expensive when the mask is
all zeros.  GCC can then try to branch around the instruction instead.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fINIT_005fCOST"></a>Target Hook: <em>void *</em> <strong>TARGET_VECTORIZE_INIT_COST</strong> <em>(class loop *<var>loop_info</var>)</em></dt>
<dd><p>This hook should initialize target-specific data structures in preparation for modeling the costs of vectorizing a loop or basic block.  The default allocates three unsigned integers for accumulating costs for the prologue, body, and epilogue of the loop or basic block.  If <var>loop_info</var> is non-NULL, it identifies the loop being vectorized; otherwise a single block is being vectorized.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fADD_005fSTMT_005fCOST"></a>Target Hook: <em>unsigned</em> <strong>TARGET_VECTORIZE_ADD_STMT_COST</strong> <em>(void *<var>data</var>, int <var>count</var>, enum vect_cost_for_stmt <var>kind</var>, class _stmt_vec_info *<var>stmt_info</var>, int <var>misalign</var>, enum vect_cost_model_location <var>where</var>)</em></dt>
<dd><p>This hook should update the target-specific <var>data</var> in response to adding <var>count</var> copies of the given <var>kind</var> of statement to a loop or basic block.  The default adds the builtin vectorizer cost for the copies of the statement to the accumulator specified by <var>where</var>, (the prologue, body, or epilogue) and returns the amount added.  The return value should be viewed as a tentative cost that may later be revised.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fFINISH_005fCOST"></a>Target Hook: <em>void</em> <strong>TARGET_VECTORIZE_FINISH_COST</strong> <em>(void *<var>data</var>, unsigned *<var>prologue_cost</var>, unsigned *<var>body_cost</var>, unsigned *<var>epilogue_cost</var>)</em></dt>
<dd><p>This hook should complete calculations of the cost of vectorizing a loop or basic block based on <var>data</var>, and return the prologue, body, and epilogue costs as unsigned integers.  The default returns the value of the three accumulators.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fDESTROY_005fCOST_005fDATA"></a>Target Hook: <em>void</em> <strong>TARGET_VECTORIZE_DESTROY_COST_DATA</strong> <em>(void *<var>data</var>)</em></dt>
<dd><p>This hook should release <var>data</var> and any related data structures allocated by TARGET_VECTORIZE_INIT_COST.  The default releases the accumulator.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fGATHER"></a>Target Hook: <em>tree</em> <strong>TARGET_VECTORIZE_BUILTIN_GATHER</strong> <em>(const_tree <var>mem_vectype</var>, const_tree <var>index_type</var>, int <var>scale</var>)</em></dt>
<dd><p>Target builtin that implements vector gather operation.  <var>mem_vectype</var>
is the vector type of the load and <var>index_type</var> is scalar type of
the index, scaled by <var>scale</var>.
The default is <code>NULL_TREE</code> which means to not vectorize gather
loads.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fVECTORIZE_005fBUILTIN_005fSCATTER"></a>Target Hook: <em>tree</em> <strong>TARGET_VECTORIZE_BUILTIN_SCATTER</strong> <em>(const_tree <var>vectype</var>, const_tree <var>index_type</var>, int <var>scale</var>)</em></dt>
<dd><p>Target builtin that implements vector scatter operation.  <var>vectype</var>
is the vector type of the store and <var>index_type</var> is scalar type of
the index, scaled by <var>scale</var>.
The default is <code>NULL_TREE</code> which means to not vectorize scatter
stores.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fSIMD_005fCLONE_005fCOMPUTE_005fVECSIZE_005fAND_005fSIMDLEN"></a>Target Hook: <em>int</em> <strong>TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN</strong> <em>(struct cgraph_node *<var></var>, struct cgraph_simd_clone *<var></var>, <var>tree</var>, <var>int</var>)</em></dt>
<dd><p>This hook should set <var>vecsize_mangle</var>, <var>vecsize_int</var>, <var>vecsize_float</var>
fields in <var>simd_clone</var> structure pointed by <var>clone_info</var> argument and also
<var>simdlen</var> field if it was previously 0.
The hook should return 0 if SIMD clones shouldn&rsquo;t be emitted,
or number of <var>vecsize_mangle</var> variants that should be emitted.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fSIMD_005fCLONE_005fADJUST"></a>Target Hook: <em>void</em> <strong>TARGET_SIMD_CLONE_ADJUST</strong> <em>(struct cgraph_node *<var></var>)</em></dt>
<dd><p>This hook should add implicit <code>attribute(target(&quot;...&quot;))</code> attribute
to SIMD clone <var>node</var> if needed.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fSIMD_005fCLONE_005fUSABLE"></a>Target Hook: <em>int</em> <strong>TARGET_SIMD_CLONE_USABLE</strong> <em>(struct cgraph_node *<var></var>)</em></dt>
<dd><p>This hook should return -1 if SIMD clone <var>node</var> shouldn&rsquo;t be used
in vectorized loops in current function, or non-negative number if it is
usable.  In that case, the smaller the number is, the more desirable it is
to use it.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fSIMT_005fVF"></a>Target Hook: <em>int</em> <strong>TARGET_SIMT_VF</strong> <em>(void)</em></dt>
<dd><p>Return number of threads in SIMT thread group on the target.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fOMP_005fDEVICE_005fKIND_005fARCH_005fISA"></a>Target Hook: <em>int</em> <strong>TARGET_OMP_DEVICE_KIND_ARCH_ISA</strong> <em>(enum omp_device_kind_arch_isa <var>trait</var>, const char *<var>name</var>)</em></dt>
<dd><p>Return 1 if <var>trait</var> <var>name</var> is present in the OpenMP context&rsquo;s
device trait set, return 0 if not present in any OpenMP context in the
whole translation unit, or -1 if not present in the current OpenMP context
but might be present in another OpenMP context in the same TU.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fGOACC_005fVALIDATE_005fDIMS"></a>Target Hook: <em>bool</em> <strong>TARGET_GOACC_VALIDATE_DIMS</strong> <em>(tree <var>decl</var>, int *<var>dims</var>, int <var>fn_level</var>, unsigned <var>used</var>)</em></dt>
<dd><p>This hook should check the launch dimensions provided for an OpenACC
compute region, or routine.  Defaulted values are represented as -1
and non-constant values as 0.  The <var>fn_level</var> is negative for the
function corresponding to the compute region.  For a routine it is the
outermost level at which partitioned execution may be spawned.  The hook
should verify non-default values.  If DECL is NULL, global defaults
are being validated and unspecified defaults should be filled in.
Diagnostics should be issued as appropriate.  Return
true, if changes have been made.  You must override this hook to
provide dimensions larger than 1.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fGOACC_005fDIM_005fLIMIT"></a>Target Hook: <em>int</em> <strong>TARGET_GOACC_DIM_LIMIT</strong> <em>(int <var>axis</var>)</em></dt>
<dd><p>This hook should return the maximum size of a particular dimension,
or zero if unbounded.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fGOACC_005fFORK_005fJOIN"></a>Target Hook: <em>bool</em> <strong>TARGET_GOACC_FORK_JOIN</strong> <em>(gcall *<var>call</var>, const int *<var>dims</var>, bool <var>is_fork</var>)</em></dt>
<dd><p>This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN
function calls to target-specific gimple, or indicate whether they
should be retained.  It is executed during the oacc_device_lower pass.
It should return true, if the call should be retained.  It should
return false, if it is to be deleted (either because target-specific
gimple has been inserted before it, or there is no need for it).
The default hook returns false, if there are no RTL expanders for them.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fGOACC_005fREDUCTION"></a>Target Hook: <em>void</em> <strong>TARGET_GOACC_REDUCTION</strong> <em>(gcall *<var>call</var>)</em></dt>
<dd><p>This hook is used by the oacc_transform pass to expand calls to the
<var>GOACC_REDUCTION</var> internal function, into a sequence of gimple
instructions.  <var>call</var> is gimple statement containing the call to
the function.  This hook removes statement <var>call</var> after the
expanded sequence has been inserted.  This hook is also responsible
for allocating any storage for reductions when necessary.
</p></dd></dl>

<dl>
<dt><a name="index-TARGET_005fPREFERRED_005fELSE_005fVALUE"></a>Target Hook: <em>tree</em> <strong>TARGET_PREFERRED_ELSE_VALUE</strong> <em>(unsigned <var>ifn</var>, tree <var>type</var>, unsigned <var>nops</var>, tree *<var>ops</var>)</em></dt>
<dd><p>This hook returns the target&rsquo;s preferred final argument for a call
to conditional internal function <var>ifn</var> (really of type
<code>internal_fn</code>).  <var>type</var> specifies the return type of the
function and <var>ops</var> are the operands to the conditional operation,
of which there are <var>nops</var>.
</p>
<p>For example, if <var>ifn</var> is <code>IFN_COND_ADD</code>, the hook returns
a value of type <var>type</var> that should be used when &lsquo;<samp><var>ops</var>[0]</samp>&rsquo;
and &lsquo;<samp><var>ops</var>[1]</samp>&rsquo; are conditionally added together.
</p>
<p>This hook is only relevant if the target supports conditional patterns
like <code>cond_add<var>m</var></code>.  The default implementation returns a zero
constant of type <var>type</var>.
</p></dd></dl>

<hr>
<div class="header">
<p>
Next: <a href="Anchored-Addresses.html#Anchored-Addresses" accesskey="n" rel="next">Anchored Addresses</a>, Previous: <a href="Library-Calls.html#Library-Calls" accesskey="p" rel="prev">Library Calls</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> &nbsp; [<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>