1479 lines
83 KiB
HTML
1479 lines
83 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
<html>
|
||
|
<!-- Copyright (C) 1988-2016 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: Misc</title>
|
||
|
|
||
|
<meta name="description" content="GNU Compiler Collection (GCC) Internals: Misc">
|
||
|
<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Misc">
|
||
|
<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="Target-Macros.html#Target-Macros" rel="up" title="Target Macros">
|
||
|
<link href="Host-Config.html#Host-Config" rel="next" title="Host Config">
|
||
|
<link href="Named-Address-Spaces.html#Named-Address-Spaces" rel="prev" title="Named Address Spaces">
|
||
|
<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="Misc"></a>
|
||
|
<div class="header">
|
||
|
<p>
|
||
|
Previous: <a href="Named-Address-Spaces.html#Named-Address-Spaces" accesskey="p" rel="prev">Named Address Spaces</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</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="Miscellaneous-Parameters"></a>
|
||
|
<h3 class="section">17.30 Miscellaneous Parameters</h3>
|
||
|
<a name="index-parameters_002c-miscellaneous"></a>
|
||
|
|
||
|
<p>Here are several miscellaneous parameters.
|
||
|
</p>
|
||
|
<dl>
|
||
|
<dt><a name="index-HAS_005fLONG_005fCOND_005fBRANCH"></a>Macro: <strong>HAS_LONG_COND_BRANCH</strong></dt>
|
||
|
<dd><p>Define this boolean macro to indicate whether or not your architecture
|
||
|
has conditional branches that can span all of memory. It is used in
|
||
|
conjunction with an optimization that partitions hot and cold basic
|
||
|
blocks into separate sections of the executable. If this macro is
|
||
|
set to false, gcc will convert any conditional branches that attempt
|
||
|
to cross between sections into unconditional branches or indirect jumps.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-HAS_005fLONG_005fUNCOND_005fBRANCH"></a>Macro: <strong>HAS_LONG_UNCOND_BRANCH</strong></dt>
|
||
|
<dd><p>Define this boolean macro to indicate whether or not your architecture
|
||
|
has unconditional branches that can span all of memory. It is used in
|
||
|
conjunction with an optimization that partitions hot and cold basic
|
||
|
blocks into separate sections of the executable. If this macro is
|
||
|
set to false, gcc will convert any unconditional branches that attempt
|
||
|
to cross between sections into indirect jumps.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-CASE_005fVECTOR_005fMODE"></a>Macro: <strong>CASE_VECTOR_MODE</strong></dt>
|
||
|
<dd><p>An alias for a machine mode name. This is the machine mode that
|
||
|
elements of a jump-table should have.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-CASE_005fVECTOR_005fSHORTEN_005fMODE"></a>Macro: <strong>CASE_VECTOR_SHORTEN_MODE</strong> <em>(<var>min_offset</var>, <var>max_offset</var>, <var>body</var>)</em></dt>
|
||
|
<dd><p>Optional: return the preferred mode for an <code>addr_diff_vec</code>
|
||
|
when the minimum and maximum offset are known. If you define this,
|
||
|
it enables extra code in branch shortening to deal with <code>addr_diff_vec</code>.
|
||
|
To make this work, you also have to define <code>INSN_ALIGN</code> and
|
||
|
make the alignment for <code>addr_diff_vec</code> explicit.
|
||
|
The <var>body</var> argument is provided so that the offset_unsigned and scale
|
||
|
flags can be updated.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-CASE_005fVECTOR_005fPC_005fRELATIVE"></a>Macro: <strong>CASE_VECTOR_PC_RELATIVE</strong></dt>
|
||
|
<dd><p>Define this macro to be a C expression to indicate when jump-tables
|
||
|
should contain relative addresses. You need not define this macro if
|
||
|
jump-tables never contain relative addresses, or jump-tables should
|
||
|
contain relative addresses only when <samp>-fPIC</samp> or <samp>-fPIC</samp>
|
||
|
is in effect.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCASE_005fVALUES_005fTHRESHOLD"></a>Target Hook: <em>unsigned int</em> <strong>TARGET_CASE_VALUES_THRESHOLD</strong> <em>(void)</em></dt>
|
||
|
<dd><p>This function return the smallest number of different values for which it
|
||
|
is best to use a jump-table instead of a tree of conditional branches.
|
||
|
The default is four for machines with a <code>casesi</code> instruction and
|
||
|
five otherwise. This is best for most machines.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-WORD_005fREGISTER_005fOPERATIONS"></a>Macro: <strong>WORD_REGISTER_OPERATIONS</strong></dt>
|
||
|
<dd><p>Define this macro to 1 if operations between registers with integral mode
|
||
|
smaller than a word are always performed on the entire register.
|
||
|
Most RISC machines have this property and most CISC machines do not.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-LOAD_005fEXTEND_005fOP"></a>Macro: <strong>LOAD_EXTEND_OP</strong> <em>(<var>mem_mode</var>)</em></dt>
|
||
|
<dd><p>Define this macro to be a C expression indicating when insns that read
|
||
|
memory in <var>mem_mode</var>, an integral mode narrower than a word, set the
|
||
|
bits outside of <var>mem_mode</var> to be either the sign-extension or the
|
||
|
zero-extension of the data read. Return <code>SIGN_EXTEND</code> for values
|
||
|
of <var>mem_mode</var> for which the
|
||
|
insn sign-extends, <code>ZERO_EXTEND</code> for which it zero-extends, and
|
||
|
<code>UNKNOWN</code> for other modes.
|
||
|
</p>
|
||
|
<p>This macro is not called with <var>mem_mode</var> non-integral or with a width
|
||
|
greater than or equal to <code>BITS_PER_WORD</code>, so you may return any
|
||
|
value in this case. Do not define this macro if it would always return
|
||
|
<code>UNKNOWN</code>. On machines where this macro is defined, you will normally
|
||
|
define it as the constant <code>SIGN_EXTEND</code> or <code>ZERO_EXTEND</code>.
|
||
|
</p>
|
||
|
<p>You may return a non-<code>UNKNOWN</code> value even if for some hard registers
|
||
|
the sign extension is not performed, if for the <code>REGNO_REG_CLASS</code>
|
||
|
of these hard registers <code>CANNOT_CHANGE_MODE_CLASS</code> returns nonzero
|
||
|
when the <var>from</var> mode is <var>mem_mode</var> and the <var>to</var> mode is any
|
||
|
integral mode larger than this but not larger than <code>word_mode</code>.
|
||
|
</p>
|
||
|
<p>You must return <code>UNKNOWN</code> if for some hard registers that allow this
|
||
|
mode, <code>CANNOT_CHANGE_MODE_CLASS</code> says that they cannot change to
|
||
|
<code>word_mode</code>, but that they can change to another integral mode that
|
||
|
is larger then <var>mem_mode</var> but still smaller than <code>word_mode</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-SHORT_005fIMMEDIATES_005fSIGN_005fEXTEND"></a>Macro: <strong>SHORT_IMMEDIATES_SIGN_EXTEND</strong></dt>
|
||
|
<dd><p>Define this macro to 1 if loading short immediate values into registers sign
|
||
|
extends.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fMIN_005fDIVISIONS_005fFOR_005fRECIP_005fMUL"></a>Target Hook: <em>unsigned int</em> <strong>TARGET_MIN_DIVISIONS_FOR_RECIP_MUL</strong> <em>(machine_mode <var>mode</var>)</em></dt>
|
||
|
<dd><p>When <samp>-ffast-math</samp> is in effect, GCC tries to optimize
|
||
|
divisions by the same divisor, by turning them into multiplications by
|
||
|
the reciprocal. This target hook specifies the minimum number of divisions
|
||
|
that should be there for GCC to perform the optimization for a variable
|
||
|
of mode <var>mode</var>. The default implementation returns 3 if the machine
|
||
|
has an instruction for the division, and 2 if it does not.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MOVE_005fMAX"></a>Macro: <strong>MOVE_MAX</strong></dt>
|
||
|
<dd><p>The maximum number of bytes that a single instruction can move quickly
|
||
|
between memory and registers or between two memory locations.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MAX_005fMOVE_005fMAX"></a>Macro: <strong>MAX_MOVE_MAX</strong></dt>
|
||
|
<dd><p>The maximum number of bytes that a single instruction can move quickly
|
||
|
between memory and registers or between two memory locations. If this
|
||
|
is undefined, the default is <code>MOVE_MAX</code>. Otherwise, it is the
|
||
|
constant value that is the largest value that <code>MOVE_MAX</code> can have
|
||
|
at run-time.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-SHIFT_005fCOUNT_005fTRUNCATED"></a>Macro: <strong>SHIFT_COUNT_TRUNCATED</strong></dt>
|
||
|
<dd><p>A C expression that is nonzero if on this machine the number of bits
|
||
|
actually used for the count of a shift operation is equal to the number
|
||
|
of bits needed to represent the size of the object being shifted. When
|
||
|
this macro is nonzero, the compiler will assume that it is safe to omit
|
||
|
a sign-extend, zero-extend, and certain bitwise ‘and’ instructions that
|
||
|
truncates the count of a shift operation. On machines that have
|
||
|
instructions that act on bit-fields at variable positions, which may
|
||
|
include ‘bit test’ instructions, a nonzero <code>SHIFT_COUNT_TRUNCATED</code>
|
||
|
also enables deletion of truncations of the values that serve as
|
||
|
arguments to bit-field instructions.
|
||
|
</p>
|
||
|
<p>If both types of instructions truncate the count (for shifts) and
|
||
|
position (for bit-field operations), or if no variable-position bit-field
|
||
|
instructions exist, you should define this macro.
|
||
|
</p>
|
||
|
<p>However, on some machines, such as the 80386 and the 680x0, truncation
|
||
|
only applies to shift operations and not the (real or pretended)
|
||
|
bit-field operations. Define <code>SHIFT_COUNT_TRUNCATED</code> to be zero on
|
||
|
such machines. Instead, add patterns to the <samp>md</samp> file that include
|
||
|
the implied truncation of the shift instructions.
|
||
|
</p>
|
||
|
<p>You need not define this macro if it would always have the value of zero.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<a name="TARGET_005fSHIFT_005fTRUNCATION_005fMASK"></a><dl>
|
||
|
<dt><a name="index-TARGET_005fSHIFT_005fTRUNCATION_005fMASK"></a>Target Hook: <em>unsigned HOST_WIDE_INT</em> <strong>TARGET_SHIFT_TRUNCATION_MASK</strong> <em>(machine_mode <var>mode</var>)</em></dt>
|
||
|
<dd><p>This function describes how the standard shift patterns for <var>mode</var>
|
||
|
deal with shifts by negative amounts or by more than the width of the mode.
|
||
|
See <a href="Standard-Names.html#shift-patterns">shift patterns</a>.
|
||
|
</p>
|
||
|
<p>On many machines, the shift patterns will apply a mask <var>m</var> to the
|
||
|
shift count, meaning that a fixed-width shift of <var>x</var> by <var>y</var> is
|
||
|
equivalent to an arbitrary-width shift of <var>x</var> by <var>y & m</var>. If
|
||
|
this is true for mode <var>mode</var>, the function should return <var>m</var>,
|
||
|
otherwise it should return 0. A return value of 0 indicates that no
|
||
|
particular behavior is guaranteed.
|
||
|
</p>
|
||
|
<p>Note that, unlike <code>SHIFT_COUNT_TRUNCATED</code>, this function does
|
||
|
<em>not</em> apply to general shift rtxes; it applies only to instructions
|
||
|
that are generated by the named shift patterns.
|
||
|
</p>
|
||
|
<p>The default implementation of this function returns
|
||
|
<code>GET_MODE_BITSIZE (<var>mode</var>) - 1</code> if <code>SHIFT_COUNT_TRUNCATED</code>
|
||
|
and 0 otherwise. This definition is always safe, but if
|
||
|
<code>SHIFT_COUNT_TRUNCATED</code> is false, and some shift patterns
|
||
|
nevertheless truncate the shift count, you may get better code
|
||
|
by overriding it.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TRULY_005fNOOP_005fTRUNCATION"></a>Macro: <strong>TRULY_NOOP_TRUNCATION</strong> <em>(<var>outprec</var>, <var>inprec</var>)</em></dt>
|
||
|
<dd><p>A C expression which is nonzero if on this machine it is safe to
|
||
|
“convert” an integer of <var>inprec</var> bits to one of <var>outprec</var>
|
||
|
bits (where <var>outprec</var> is smaller than <var>inprec</var>) by merely
|
||
|
operating on it as if it had only <var>outprec</var> bits.
|
||
|
</p>
|
||
|
<p>On many machines, this expression can be 1.
|
||
|
</p>
|
||
|
<p>When <code>TRULY_NOOP_TRUNCATION</code> returns 1 for a pair of sizes for
|
||
|
modes for which <code>MODES_TIEABLE_P</code> is 0, suboptimal code can result.
|
||
|
If this is the case, making <code>TRULY_NOOP_TRUNCATION</code> return 0 in
|
||
|
such cases may improve things.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fMODE_005fREP_005fEXTENDED"></a>Target Hook: <em>int</em> <strong>TARGET_MODE_REP_EXTENDED</strong> <em>(machine_mode <var>mode</var>, machine_mode <var>rep_mode</var>)</em></dt>
|
||
|
<dd><p>The representation of an integral mode can be such that the values
|
||
|
are always extended to a wider integral mode. Return
|
||
|
<code>SIGN_EXTEND</code> if values of <var>mode</var> are represented in
|
||
|
sign-extended form to <var>rep_mode</var>. Return <code>UNKNOWN</code>
|
||
|
otherwise. (Currently, none of the targets use zero-extended
|
||
|
representation this way so unlike <code>LOAD_EXTEND_OP</code>,
|
||
|
<code>TARGET_MODE_REP_EXTENDED</code> is expected to return either
|
||
|
<code>SIGN_EXTEND</code> or <code>UNKNOWN</code>. Also no target extends
|
||
|
<var>mode</var> to <var>rep_mode</var> so that <var>rep_mode</var> is not the next
|
||
|
widest integral mode and currently we take advantage of this fact.)
|
||
|
</p>
|
||
|
<p>Similarly to <code>LOAD_EXTEND_OP</code> you may return a non-<code>UNKNOWN</code>
|
||
|
value even if the extension is not performed on certain hard registers
|
||
|
as long as for the <code>REGNO_REG_CLASS</code> of these hard registers
|
||
|
<code>CANNOT_CHANGE_MODE_CLASS</code> returns nonzero.
|
||
|
</p>
|
||
|
<p>Note that <code>TARGET_MODE_REP_EXTENDED</code> and <code>LOAD_EXTEND_OP</code>
|
||
|
describe two related properties. If you define
|
||
|
<code>TARGET_MODE_REP_EXTENDED (mode, word_mode)</code> you probably also want
|
||
|
to define <code>LOAD_EXTEND_OP (mode)</code> to return the same type of
|
||
|
extension.
|
||
|
</p>
|
||
|
<p>In order to enforce the representation of <code>mode</code>,
|
||
|
<code>TRULY_NOOP_TRUNCATION</code> should return false when truncating to
|
||
|
<code>mode</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-STORE_005fFLAG_005fVALUE"></a>Macro: <strong>STORE_FLAG_VALUE</strong></dt>
|
||
|
<dd><p>A C expression describing the value returned by a comparison operator
|
||
|
with an integral mode and stored by a store-flag instruction
|
||
|
(‘<samp>cstore<var>mode</var>4</samp>’) when the condition is true. This description must
|
||
|
apply to <em>all</em> the ‘<samp>cstore<var>mode</var>4</samp>’ patterns and all the
|
||
|
comparison operators whose results have a <code>MODE_INT</code> mode.
|
||
|
</p>
|
||
|
<p>A value of 1 or -1 means that the instruction implementing the
|
||
|
comparison operator returns exactly 1 or -1 when the comparison is true
|
||
|
and 0 when the comparison is false. Otherwise, the value indicates
|
||
|
which bits of the result are guaranteed to be 1 when the comparison is
|
||
|
true. This value is interpreted in the mode of the comparison
|
||
|
operation, which is given by the mode of the first operand in the
|
||
|
‘<samp>cstore<var>mode</var>4</samp>’ pattern. Either the low bit or the sign bit of
|
||
|
<code>STORE_FLAG_VALUE</code> be on. Presently, only those bits are used by
|
||
|
the compiler.
|
||
|
</p>
|
||
|
<p>If <code>STORE_FLAG_VALUE</code> is neither 1 or -1, the compiler will
|
||
|
generate code that depends only on the specified bits. It can also
|
||
|
replace comparison operators with equivalent operations if they cause
|
||
|
the required bits to be set, even if the remaining bits are undefined.
|
||
|
For example, on a machine whose comparison operators return an
|
||
|
<code>SImode</code> value and where <code>STORE_FLAG_VALUE</code> is defined as
|
||
|
‘<samp>0x80000000</samp>’, saying that just the sign bit is relevant, the
|
||
|
expression
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">(ne:SI (and:SI <var>x</var> (const_int <var>power-of-2</var>)) (const_int 0))
|
||
|
</pre></div>
|
||
|
|
||
|
<p>can be converted to
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">(ashift:SI <var>x</var> (const_int <var>n</var>))
|
||
|
</pre></div>
|
||
|
|
||
|
<p>where <var>n</var> is the appropriate shift count to move the bit being
|
||
|
tested into the sign bit.
|
||
|
</p>
|
||
|
<p>There is no way to describe a machine that always sets the low-order bit
|
||
|
for a true value, but does not guarantee the value of any other bits,
|
||
|
but we do not know of any machine that has such an instruction. If you
|
||
|
are trying to port GCC to such a machine, include an instruction to
|
||
|
perform a logical-and of the result with 1 in the pattern for the
|
||
|
comparison operators and let us know at <a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a>.
|
||
|
</p>
|
||
|
<p>Often, a machine will have multiple instructions that obtain a value
|
||
|
from a comparison (or the condition codes). Here are rules to guide the
|
||
|
choice of value for <code>STORE_FLAG_VALUE</code>, and hence the instructions
|
||
|
to be used:
|
||
|
</p>
|
||
|
<ul>
|
||
|
<li> Use the shortest sequence that yields a valid definition for
|
||
|
<code>STORE_FLAG_VALUE</code>. It is more efficient for the compiler to
|
||
|
“normalize” the value (convert it to, e.g., 1 or 0) than for the
|
||
|
comparison operators to do so because there may be opportunities to
|
||
|
combine the normalization with other operations.
|
||
|
|
||
|
</li><li> For equal-length sequences, use a value of 1 or -1, with -1 being
|
||
|
slightly preferred on machines with expensive jumps and 1 preferred on
|
||
|
other machines.
|
||
|
|
||
|
</li><li> As a second choice, choose a value of ‘<samp>0x80000001</samp>’ if instructions
|
||
|
exist that set both the sign and low-order bits but do not define the
|
||
|
others.
|
||
|
|
||
|
</li><li> Otherwise, use a value of ‘<samp>0x80000000</samp>’.
|
||
|
</li></ul>
|
||
|
|
||
|
<p>Many machines can produce both the value chosen for
|
||
|
<code>STORE_FLAG_VALUE</code> and its negation in the same number of
|
||
|
instructions. On those machines, you should also define a pattern for
|
||
|
those cases, e.g., one matching
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">(set <var>A</var> (neg:<var>m</var> (ne:<var>m</var> <var>B</var> <var>C</var>)))
|
||
|
</pre></div>
|
||
|
|
||
|
<p>Some machines can also perform <code>and</code> or <code>plus</code> operations on
|
||
|
condition code values with less instructions than the corresponding
|
||
|
‘<samp>cstore<var>mode</var>4</samp>’ insn followed by <code>and</code> or <code>plus</code>. On those
|
||
|
machines, define the appropriate patterns. Use the names <code>incscc</code>
|
||
|
and <code>decscc</code>, respectively, for the patterns which perform
|
||
|
<code>plus</code> or <code>minus</code> operations on condition code values. See
|
||
|
<samp>rs6000.md</samp> for some examples. The GNU Superoptimizer can be used to
|
||
|
find such instruction sequences on other machines.
|
||
|
</p>
|
||
|
<p>If this macro is not defined, the default value, 1, is used. You need
|
||
|
not define <code>STORE_FLAG_VALUE</code> if the machine has no store-flag
|
||
|
instructions, or if the value generated by these instructions is 1.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-FLOAT_005fSTORE_005fFLAG_005fVALUE"></a>Macro: <strong>FLOAT_STORE_FLAG_VALUE</strong> <em>(<var>mode</var>)</em></dt>
|
||
|
<dd><p>A C expression that gives a nonzero <code>REAL_VALUE_TYPE</code> value that is
|
||
|
returned when comparison operators with floating-point results are true.
|
||
|
Define this macro on machines that have comparison operations that return
|
||
|
floating-point values. If there are no such operations, do not define
|
||
|
this macro.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-VECTOR_005fSTORE_005fFLAG_005fVALUE"></a>Macro: <strong>VECTOR_STORE_FLAG_VALUE</strong> <em>(<var>mode</var>)</em></dt>
|
||
|
<dd><p>A C expression that gives a rtx representing the nonzero true element
|
||
|
for vector comparisons. The returned rtx should be valid for the inner
|
||
|
mode of <var>mode</var> which is guaranteed to be a vector mode. Define
|
||
|
this macro on machines that have vector comparison operations that
|
||
|
return a vector result. If there are no such operations, do not define
|
||
|
this macro. Typically, this macro is defined as <code>const1_rtx</code> or
|
||
|
<code>constm1_rtx</code>. This macro may return <code>NULL_RTX</code> to prevent
|
||
|
the compiler optimizing such vector comparison operations for the
|
||
|
given mode.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-CLZ_005fDEFINED_005fVALUE_005fAT_005fZERO"></a>Macro: <strong>CLZ_DEFINED_VALUE_AT_ZERO</strong> <em>(<var>mode</var>, <var>value</var>)</em></dt>
|
||
|
<dt><a name="index-CTZ_005fDEFINED_005fVALUE_005fAT_005fZERO"></a>Macro: <strong>CTZ_DEFINED_VALUE_AT_ZERO</strong> <em>(<var>mode</var>, <var>value</var>)</em></dt>
|
||
|
<dd><p>A C expression that indicates whether the architecture defines a value
|
||
|
for <code>clz</code> or <code>ctz</code> with a zero operand.
|
||
|
A result of <code>0</code> indicates the value is undefined.
|
||
|
If the value is defined for only the RTL expression, the macro should
|
||
|
evaluate to <code>1</code>; if the value applies also to the corresponding optab
|
||
|
entry (which is normally the case if it expands directly into
|
||
|
the corresponding RTL), then the macro should evaluate to <code>2</code>.
|
||
|
In the cases where the value is defined, <var>value</var> should be set to
|
||
|
this value.
|
||
|
</p>
|
||
|
<p>If this macro is not defined, the value of <code>clz</code> or
|
||
|
<code>ctz</code> at zero is assumed to be undefined.
|
||
|
</p>
|
||
|
<p>This macro must be defined if the target’s expansion for <code>ffs</code>
|
||
|
relies on a particular value to get correct results. Otherwise it
|
||
|
is not necessary, though it may be used to optimize some corner cases, and
|
||
|
to provide a default expansion for the <code>ffs</code> optab.
|
||
|
</p>
|
||
|
<p>Note that regardless of this macro the “definedness” of <code>clz</code>
|
||
|
and <code>ctz</code> at zero do <em>not</em> extend to the builtin functions
|
||
|
visible to the user. Thus one may be free to adjust the value at will
|
||
|
to match the target expansion of these operations without fear of
|
||
|
breaking the API.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-Pmode"></a>Macro: <strong>Pmode</strong></dt>
|
||
|
<dd><p>An alias for the machine mode for pointers. On most machines, define
|
||
|
this to be the integer mode corresponding to the width of a hardware
|
||
|
pointer; <code>SImode</code> on 32-bit machine or <code>DImode</code> on 64-bit machines.
|
||
|
On some machines you must define this to be one of the partial integer
|
||
|
modes, such as <code>PSImode</code>.
|
||
|
</p>
|
||
|
<p>The width of <code>Pmode</code> must be at least as large as the value of
|
||
|
<code>POINTER_SIZE</code>. If it is not equal, you must define the macro
|
||
|
<code>POINTERS_EXTEND_UNSIGNED</code> to specify how pointers are extended
|
||
|
to <code>Pmode</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-FUNCTION_005fMODE"></a>Macro: <strong>FUNCTION_MODE</strong></dt>
|
||
|
<dd><p>An alias for the machine mode used for memory references to functions
|
||
|
being called, in <code>call</code> RTL expressions. On most CISC machines,
|
||
|
where an instruction can begin at any byte address, this should be
|
||
|
<code>QImode</code>. On most RISC machines, where all instructions have fixed
|
||
|
size and alignment, this should be a mode with the same size and alignment
|
||
|
as the machine instruction words - typically <code>SImode</code> or <code>HImode</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-STDC_005f0_005fIN_005fSYSTEM_005fHEADERS"></a>Macro: <strong>STDC_0_IN_SYSTEM_HEADERS</strong></dt>
|
||
|
<dd><p>In normal operation, the preprocessor expands <code>__STDC__</code> to the
|
||
|
constant 1, to signify that GCC conforms to ISO Standard C. On some
|
||
|
hosts, like Solaris, the system compiler uses a different convention,
|
||
|
where <code>__STDC__</code> is normally 0, but is 1 if the user specifies
|
||
|
strict conformance to the C Standard.
|
||
|
</p>
|
||
|
<p>Defining <code>STDC_0_IN_SYSTEM_HEADERS</code> makes GNU CPP follows the host
|
||
|
convention when processing system header files, but when processing user
|
||
|
files <code>__STDC__</code> will always expand to 1.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fC_005fPREINCLUDE"></a>C Target Hook: <em>const char *</em> <strong>TARGET_C_PREINCLUDE</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Define this hook to return the name of a header file to be included at the start of all compilations, as if it had been included with <code>#include <<var>file</var>></code>. If this hook returns <code>NULL</code>, or is not defined, or the header is not found, or if the user specifies <samp>-ffreestanding</samp> or <samp>-nostdinc</samp>, no header is included.
|
||
|
</p>
|
||
|
<p>This hook can be used together with a header provided by the system C library to implement ISO C requirements for certain macros to be predefined that describe properties of the whole implementation rather than just the compiler.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCXX_005fIMPLICIT_005fEXTERN_005fC"></a>C Target Hook: <em>bool</em> <strong>TARGET_CXX_IMPLICIT_EXTERN_C</strong> <em>(const char*<var></var>)</em></dt>
|
||
|
<dd><p>Define this hook to add target-specific C++ implicit extern C functions. If this function returns true for the name of a file-scope function, that function implicitly gets extern "C" linkage rather than whatever language linkage the declaration would normally have. An example of such function is WinMain on Win32 targets.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-NO_005fIMPLICIT_005fEXTERN_005fC"></a>Macro: <strong>NO_IMPLICIT_EXTERN_C</strong></dt>
|
||
|
<dd><p>Define this macro if the system header files support C++ as well as C.
|
||
|
This macro inhibits the usual method of using system header files in
|
||
|
C++, which is to pretend that the file’s contents are enclosed in
|
||
|
‘<samp>extern "C" {…}</samp>’.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<a name="index-_0023pragma"></a>
|
||
|
<a name="index-pragma"></a>
|
||
|
<dl>
|
||
|
<dt><a name="index-REGISTER_005fTARGET_005fPRAGMAS"></a>Macro: <strong>REGISTER_TARGET_PRAGMAS</strong> <em>()</em></dt>
|
||
|
<dd><p>Define this macro if you want to implement any target-specific pragmas.
|
||
|
If defined, it is a C expression which makes a series of calls to
|
||
|
<code>c_register_pragma</code> or <code>c_register_pragma_with_expansion</code>
|
||
|
for each pragma. The macro may also do any
|
||
|
setup required for the pragmas.
|
||
|
</p>
|
||
|
<p>The primary reason to define this macro is to provide compatibility with
|
||
|
other compilers for the same target. In general, we discourage
|
||
|
definition of target-specific pragmas for GCC.
|
||
|
</p>
|
||
|
<p>If the pragma can be implemented by attributes then you should consider
|
||
|
defining the target hook ‘<samp>TARGET_INSERT_ATTRIBUTES</samp>’ as well.
|
||
|
</p>
|
||
|
<p>Preprocessor macros that appear on pragma lines are not expanded. All
|
||
|
‘<samp>#pragma</samp>’ directives that do not match any registered pragma are
|
||
|
silently ignored, unless the user specifies <samp>-Wunknown-pragmas</samp>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-c_005fregister_005fpragma"></a>Function: <em>void</em> <strong>c_register_pragma</strong> <em>(const char *<var>space</var>, const char *<var>name</var>, void (*<var>callback</var>) (struct cpp_reader *))</em></dt>
|
||
|
<dt><a name="index-c_005fregister_005fpragma_005fwith_005fexpansion"></a>Function: <em>void</em> <strong>c_register_pragma_with_expansion</strong> <em>(const char *<var>space</var>, const char *<var>name</var>, void (*<var>callback</var>) (struct cpp_reader *))</em></dt>
|
||
|
<dd>
|
||
|
<p>Each call to <code>c_register_pragma</code> or
|
||
|
<code>c_register_pragma_with_expansion</code> establishes one pragma. The
|
||
|
<var>callback</var> routine will be called when the preprocessor encounters a
|
||
|
pragma of the form
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">#pragma [<var>space</var>] <var>name</var> …
|
||
|
</pre></div>
|
||
|
|
||
|
<p><var>space</var> is the case-sensitive namespace of the pragma, or
|
||
|
<code>NULL</code> to put the pragma in the global namespace. The callback
|
||
|
routine receives <var>pfile</var> as its first argument, which can be passed
|
||
|
on to cpplib’s functions if necessary. You can lex tokens after the
|
||
|
<var>name</var> by calling <code>pragma_lex</code>. Tokens that are not read by the
|
||
|
callback will be silently ignored. The end of the line is indicated by
|
||
|
a token of type <code>CPP_EOF</code>. Macro expansion occurs on the
|
||
|
arguments of pragmas registered with
|
||
|
<code>c_register_pragma_with_expansion</code> but not on the arguments of
|
||
|
pragmas registered with <code>c_register_pragma</code>.
|
||
|
</p>
|
||
|
<p>Note that the use of <code>pragma_lex</code> is specific to the C and C++
|
||
|
compilers. It will not work in the Java or Fortran compilers, or any
|
||
|
other language compilers for that matter. Thus if <code>pragma_lex</code> is going
|
||
|
to be called from target-specific code, it must only be done so when
|
||
|
building the C and C++ compilers. This can be done by defining the
|
||
|
variables <code>c_target_objs</code> and <code>cxx_target_objs</code> in the
|
||
|
target entry in the <samp>config.gcc</samp> file. These variables should name
|
||
|
the target-specific, language-specific object file which contains the
|
||
|
code that uses <code>pragma_lex</code>. Note it will also be necessary to add a
|
||
|
rule to the makefile fragment pointed to by <code>tmake_file</code> that shows
|
||
|
how to build this object file.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-HANDLE_005fPRAGMA_005fPACK_005fWITH_005fEXPANSION"></a>Macro: <strong>HANDLE_PRAGMA_PACK_WITH_EXPANSION</strong></dt>
|
||
|
<dd><p>Define this macro if macros should be expanded in the
|
||
|
arguments of ‘<samp>#pragma pack</samp>’.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fDEFAULT_005fPACK_005fSTRUCT"></a>Macro: <strong>TARGET_DEFAULT_PACK_STRUCT</strong></dt>
|
||
|
<dd><p>If your target requires a structure packing default other than 0 (meaning
|
||
|
the machine default), define this macro to the necessary value (in bytes).
|
||
|
This must be a value that would also be valid to use with
|
||
|
‘<samp>#pragma pack()</samp>’ (that is, a small power of two).
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-DOLLARS_005fIN_005fIDENTIFIERS"></a>Macro: <strong>DOLLARS_IN_IDENTIFIERS</strong></dt>
|
||
|
<dd><p>Define this macro to control use of the character ‘<samp>$</samp>’ in
|
||
|
identifier names for the C family of languages. 0 means ‘<samp>$</samp>’ is
|
||
|
not allowed by default; 1 means it is allowed. 1 is the default;
|
||
|
there is no need to define this macro in that case.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-INSN_005fSETS_005fARE_005fDELAYED"></a>Macro: <strong>INSN_SETS_ARE_DELAYED</strong> <em>(<var>insn</var>)</em></dt>
|
||
|
<dd><p>Define this macro as a C expression that is nonzero if it is safe for the
|
||
|
delay slot scheduler to place instructions in the delay slot of <var>insn</var>,
|
||
|
even if they appear to use a resource set or clobbered in <var>insn</var>.
|
||
|
<var>insn</var> is always a <code>jump_insn</code> or an <code>insn</code>; GCC knows that
|
||
|
every <code>call_insn</code> has this behavior. On machines where some <code>insn</code>
|
||
|
or <code>jump_insn</code> is really a function call and hence has this behavior,
|
||
|
you should define this macro.
|
||
|
</p>
|
||
|
<p>You need not define this macro if it would always return zero.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-INSN_005fREFERENCES_005fARE_005fDELAYED"></a>Macro: <strong>INSN_REFERENCES_ARE_DELAYED</strong> <em>(<var>insn</var>)</em></dt>
|
||
|
<dd><p>Define this macro as a C expression that is nonzero if it is safe for the
|
||
|
delay slot scheduler to place instructions in the delay slot of <var>insn</var>,
|
||
|
even if they appear to set or clobber a resource referenced in <var>insn</var>.
|
||
|
<var>insn</var> is always a <code>jump_insn</code> or an <code>insn</code>. On machines where
|
||
|
some <code>insn</code> or <code>jump_insn</code> is really a function call and its operands
|
||
|
are registers whose use is actually in the subroutine it calls, you should
|
||
|
define this macro. Doing so allows the delay slot scheduler to move
|
||
|
instructions which copy arguments into the argument registers into the delay
|
||
|
slot of <var>insn</var>.
|
||
|
</p>
|
||
|
<p>You need not define this macro if it would always return zero.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MULTIPLE_005fSYMBOL_005fSPACES"></a>Macro: <strong>MULTIPLE_SYMBOL_SPACES</strong></dt>
|
||
|
<dd><p>Define this macro as a C expression that is nonzero if, in some cases,
|
||
|
global symbols from one translation unit may not be bound to undefined
|
||
|
symbols in another translation unit without user intervention. For
|
||
|
instance, under Microsoft Windows symbols must be explicitly imported
|
||
|
from shared libraries (DLLs).
|
||
|
</p>
|
||
|
<p>You need not define this macro if it would always evaluate to zero.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fMD_005fASM_005fADJUST"></a>Target Hook: <em>rtx_insn *</em> <strong>TARGET_MD_ASM_ADJUST</strong> <em>(vec<rtx>& <var>outputs</var>, vec<rtx>& <var>inputs</var>, vec<const char *>& <var>constraints</var>, vec<rtx>& <var>clobbers</var>, HARD_REG_SET& <var>clobbered_regs</var>)</em></dt>
|
||
|
<dd><p>This target hook may add <em>clobbers</em> to <var>clobbers</var> and
|
||
|
<var>clobbered_regs</var> for any hard regs the port wishes to automatically
|
||
|
clobber for an asm. The <var>outputs</var> and <var>inputs</var> may be inspected
|
||
|
to avoid clobbering a register that is already used by the asm.
|
||
|
</p>
|
||
|
<p>It may modify the <var>outputs</var>, <var>inputs</var>, and <var>constraints</var>
|
||
|
as necessary for other pre-processing. In this case the return value is
|
||
|
a sequence of insns to emit after the asm.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MATH_005fLIBRARY"></a>Macro: <strong>MATH_LIBRARY</strong></dt>
|
||
|
<dd><p>Define this macro as a C string constant for the linker argument to link
|
||
|
in the system math library, minus the initial ‘<samp>"-l"</samp>’, or
|
||
|
‘<samp>""</samp>’ if the target does not have a
|
||
|
separate math library.
|
||
|
</p>
|
||
|
<p>You need only define this macro if the default of ‘<samp>"m"</samp>’ is wrong.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-LIBRARY_005fPATH_005fENV"></a>Macro: <strong>LIBRARY_PATH_ENV</strong></dt>
|
||
|
<dd><p>Define this macro as a C string constant for the environment variable that
|
||
|
specifies where the linker should look for libraries.
|
||
|
</p>
|
||
|
<p>You need only define this macro if the default of ‘<samp>"LIBRARY_PATH"</samp>’
|
||
|
is wrong.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fPOSIX_005fIO"></a>Macro: <strong>TARGET_POSIX_IO</strong></dt>
|
||
|
<dd><p>Define this macro if the target supports the following POSIX file
|
||
|
functions, access, mkdir and file locking with fcntl / F_SETLKW.
|
||
|
Defining <code>TARGET_POSIX_IO</code> will enable the test coverage code
|
||
|
to use file locking when exiting a program, which avoids race conditions
|
||
|
if the program has forked. It will also create directories at run-time
|
||
|
for cross-profiling.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MAX_005fCONDITIONAL_005fEXECUTE"></a>Macro: <strong>MAX_CONDITIONAL_EXECUTE</strong></dt>
|
||
|
<dd>
|
||
|
<p>A C expression for the maximum number of instructions to execute via
|
||
|
conditional execution instructions instead of a branch. A value of
|
||
|
<code>BRANCH_COST</code>+1 is the default if the machine does not use cc0, and
|
||
|
1 if it does use cc0.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMODIFY_005fTESTS"></a>Macro: <strong>IFCVT_MODIFY_TESTS</strong> <em>(<var>ce_info</var>, <var>true_expr</var>, <var>false_expr</var>)</em></dt>
|
||
|
<dd><p>Used if the target needs to perform machine-dependent modifications on the
|
||
|
conditionals used for turning basic blocks into conditionally executed code.
|
||
|
<var>ce_info</var> points to a data structure, <code>struct ce_if_block</code>, which
|
||
|
contains information about the currently processed blocks. <var>true_expr</var>
|
||
|
and <var>false_expr</var> are the tests that are used for converting the
|
||
|
then-block and the else-block, respectively. Set either <var>true_expr</var> or
|
||
|
<var>false_expr</var> to a null pointer if the tests cannot be converted.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMODIFY_005fMULTIPLE_005fTESTS"></a>Macro: <strong>IFCVT_MODIFY_MULTIPLE_TESTS</strong> <em>(<var>ce_info</var>, <var>bb</var>, <var>true_expr</var>, <var>false_expr</var>)</em></dt>
|
||
|
<dd><p>Like <code>IFCVT_MODIFY_TESTS</code>, but used when converting more complicated
|
||
|
if-statements into conditions combined by <code>and</code> and <code>or</code> operations.
|
||
|
<var>bb</var> contains the basic block that contains the test that is currently
|
||
|
being processed and about to be turned into a condition.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMODIFY_005fINSN"></a>Macro: <strong>IFCVT_MODIFY_INSN</strong> <em>(<var>ce_info</var>, <var>pattern</var>, <var>insn</var>)</em></dt>
|
||
|
<dd><p>A C expression to modify the <var>PATTERN</var> of an <var>INSN</var> that is to
|
||
|
be converted to conditional execution format. <var>ce_info</var> points to
|
||
|
a data structure, <code>struct ce_if_block</code>, which contains information
|
||
|
about the currently processed blocks.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMODIFY_005fFINAL"></a>Macro: <strong>IFCVT_MODIFY_FINAL</strong> <em>(<var>ce_info</var>)</em></dt>
|
||
|
<dd><p>A C expression to perform any final machine dependent modifications in
|
||
|
converting code to conditional execution. The involved basic blocks
|
||
|
can be found in the <code>struct ce_if_block</code> structure that is pointed
|
||
|
to by <var>ce_info</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMODIFY_005fCANCEL"></a>Macro: <strong>IFCVT_MODIFY_CANCEL</strong> <em>(<var>ce_info</var>)</em></dt>
|
||
|
<dd><p>A C expression to cancel any machine dependent modifications in
|
||
|
converting code to conditional execution. The involved basic blocks
|
||
|
can be found in the <code>struct ce_if_block</code> structure that is pointed
|
||
|
to by <var>ce_info</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-IFCVT_005fMACHDEP_005fINIT"></a>Macro: <strong>IFCVT_MACHDEP_INIT</strong> <em>(<var>ce_info</var>)</em></dt>
|
||
|
<dd><p>A C expression to initialize any machine specific data for if-conversion
|
||
|
of the if-block in the <code>struct ce_if_block</code> structure that is pointed
|
||
|
to by <var>ce_info</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fMACHINE_005fDEPENDENT_005fREORG"></a>Target Hook: <em>void</em> <strong>TARGET_MACHINE_DEPENDENT_REORG</strong> <em>(void)</em></dt>
|
||
|
<dd><p>If non-null, this hook performs a target-specific pass over the
|
||
|
instruction stream. The compiler will run it at all optimization levels,
|
||
|
just before the point at which it normally does delayed-branch scheduling.
|
||
|
</p>
|
||
|
<p>The exact purpose of the hook varies from target to target. Some use
|
||
|
it to do transformations that are necessary for correctness, such as
|
||
|
laying out in-function constant pools or avoiding hardware hazards.
|
||
|
Others use it as an opportunity to do some machine-dependent optimizations.
|
||
|
</p>
|
||
|
<p>You need not implement the hook if it has nothing to do. The default
|
||
|
definition is null.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINIT_005fBUILTINS"></a>Target Hook: <em>void</em> <strong>TARGET_INIT_BUILTINS</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Define this hook if you have any machine-specific built-in functions
|
||
|
that need to be defined. It should be a function that performs the
|
||
|
necessary setup.
|
||
|
</p>
|
||
|
<p>Machine specific built-in functions can be useful to expand special machine
|
||
|
instructions that would otherwise not normally be generated because
|
||
|
they have no equivalent in the source language (for example, SIMD vector
|
||
|
instructions or prefetch instructions).
|
||
|
</p>
|
||
|
<p>To create a built-in function, call the function
|
||
|
<code>lang_hooks.builtin_function</code>
|
||
|
which is defined by the language front end. You can use any type nodes set
|
||
|
up by <code>build_common_tree_nodes</code>;
|
||
|
only language front ends that use those two functions will call
|
||
|
‘<samp>TARGET_INIT_BUILTINS</samp>’.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fBUILTIN_005fDECL"></a>Target Hook: <em>tree</em> <strong>TARGET_BUILTIN_DECL</strong> <em>(unsigned <var>code</var>, bool <var>initialize_p</var>)</em></dt>
|
||
|
<dd><p>Define this hook if you have any machine-specific built-in functions
|
||
|
that need to be defined. It should be a function that returns the
|
||
|
builtin function declaration for the builtin function code <var>code</var>.
|
||
|
If there is no such builtin and it cannot be initialized at this time
|
||
|
if <var>initialize_p</var> is true the function should return <code>NULL_TREE</code>.
|
||
|
If <var>code</var> is out of range the function should return
|
||
|
<code>error_mark_node</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fEXPAND_005fBUILTIN"></a>Target Hook: <em>rtx</em> <strong>TARGET_EXPAND_BUILTIN</strong> <em>(tree <var>exp</var>, rtx <var>target</var>, rtx <var>subtarget</var>, machine_mode <var>mode</var>, int <var>ignore</var>)</em></dt>
|
||
|
<dd>
|
||
|
<p>Expand a call to a machine specific built-in function that was set up by
|
||
|
‘<samp>TARGET_INIT_BUILTINS</samp>’. <var>exp</var> is the expression for the
|
||
|
function call; the result should go to <var>target</var> if that is
|
||
|
convenient, and have mode <var>mode</var> if that is convenient.
|
||
|
<var>subtarget</var> may be used as the target for computing one of
|
||
|
<var>exp</var>’s operands. <var>ignore</var> is nonzero if the value is to be
|
||
|
ignored. This function should return the result of the call to the
|
||
|
built-in function.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fBUILTIN_005fCHKP_005fFUNCTION"></a>Target Hook: <em>tree</em> <strong>TARGET_BUILTIN_CHKP_FUNCTION</strong> <em>(unsigned <var>fcode</var>)</em></dt>
|
||
|
<dd><p>This hook allows target to redefine built-in functions used by
|
||
|
Pointer Bounds Checker for code instrumentation. Hook should return
|
||
|
fndecl of function implementing generic builtin whose code is
|
||
|
passed in <var>fcode</var>. Currently following built-in functions are
|
||
|
obtained using this hook:
|
||
|
</p><dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndmk"></a>Built-in Function: <em>__bounds_type</em> <strong>__chkp_bndmk</strong> <em>(const void *<var>lb</var>, size_t <var>size</var>)</em></dt>
|
||
|
<dd><p>Function code - BUILT_IN_CHKP_BNDMK. This built-in function is used
|
||
|
by Pointer Bounds Checker to create bound values. <var>lb</var> holds low
|
||
|
bound of the resulting bounds. <var>size</var> holds size of created bounds.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndstx"></a>Built-in Function: <em>void</em> <strong>__chkp_bndstx</strong> <em>(const void *<var>ptr</var>, __bounds_type <var>b</var>, const void **<var>loc</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_BNDSTX</code>. This built-in function is used
|
||
|
by Pointer Bounds Checker to store bounds <var>b</var> for pointer <var>ptr</var>
|
||
|
when <var>ptr</var> is stored by address <var>loc</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndldx"></a>Built-in Function: <em>__bounds_type</em> <strong>__chkp_bndldx</strong> <em>(const void **<var>loc</var>, const void *<var>ptr</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_BNDLDX</code>. This built-in function is used
|
||
|
by Pointer Bounds Checker to get bounds of pointer <var>ptr</var> loaded by
|
||
|
address <var>loc</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndcl"></a>Built-in Function: <em>void</em> <strong>__chkp_bndcl</strong> <em>(const void *<var>ptr</var>, __bounds_type <var>b</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_BNDCL</code>. This built-in function is used
|
||
|
by Pointer Bounds Checker to perform check for pointer <var>ptr</var> against
|
||
|
lower bound of bounds <var>b</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndcu"></a>Built-in Function: <em>void</em> <strong>__chkp_bndcu</strong> <em>(const void *<var>ptr</var>, __bounds_type <var>b</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_BNDCU</code>. This built-in function is used
|
||
|
by Pointer Bounds Checker to perform check for pointer <var>ptr</var> against
|
||
|
upper bound of bounds <var>b</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fbndret"></a>Built-in Function: <em>__bounds_type</em> <strong>__chkp_bndret</strong> <em>(void *<var>ptr</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_BNDRET</code>. This built-in function is used
|
||
|
by Pointer Bounds Checker to obtain bounds returned by a call statement.
|
||
|
<var>ptr</var> passed to built-in is <code>SSA_NAME</code> returned by the call.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fintersect"></a>Built-in Function: <em>__bounds_type</em> <strong>__chkp_intersect</strong> <em>(__bounds_type <var>b1</var>, __bounds_type <var>b2</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_INTERSECT</code>. This built-in function
|
||
|
returns intersection of bounds <var>b1</var> and <var>b2</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fnarrow"></a>Built-in Function: <em>__bounds_type</em> <strong>__chkp_narrow</strong> <em>(const void *<var>ptr</var>, __bounds_type <var>b</var>, size_t <var>s</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_NARROW</code>. This built-in function
|
||
|
returns intersection of bounds <var>b</var> and
|
||
|
[<var>ptr</var>, <var>ptr</var> + <var>s</var> - <code>1</code>].
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-_005f_005fchkp_005fsizeof"></a>Built-in Function: <em>size_t</em> <strong>__chkp_sizeof</strong> <em>(const void *<var>ptr</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_SIZEOF</code>. This built-in function
|
||
|
returns size of object referenced by <var>ptr</var>. <var>ptr</var> is always
|
||
|
<code>ADDR_EXPR</code> of <code>VAR_DECL</code>. This built-in is used by
|
||
|
Pointer Bounds Checker when bounds of object cannot be computed statically
|
||
|
(e.g. object has incomplete type).
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-void"></a>Built-in Function: <em>const</em> <strong>void</strong> <em>*__chkp_extract_lower (__bounds_type <var>b</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_EXTRACT_LOWER</code>. This built-in function
|
||
|
returns lower bound of bounds <var>b</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-void-1"></a>Built-in Function: <em>const</em> <strong>void</strong> <em>*__chkp_extract_upper (__bounds_type <var>b</var>)</em></dt>
|
||
|
<dd><p>Function code - <code>BUILT_IN_CHKP_EXTRACT_UPPER</code>. This built-in function
|
||
|
returns upper bound of bounds <var>b</var>.
|
||
|
</p></dd></dl>
|
||
|
</dd></dl>
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCHKP_005fBOUND_005fTYPE"></a>Target Hook: <em>tree</em> <strong>TARGET_CHKP_BOUND_TYPE</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Return type to be used for bounds
|
||
|
</p></dd></dl>
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCHKP_005fBOUND_005fMODE"></a>Target Hook: <em>enum machine_mode</em> <strong>TARGET_CHKP_BOUND_MODE</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Return mode to be used for bounds.
|
||
|
</p></dd></dl>
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCHKP_005fMAKE_005fBOUNDS_005fCONSTANT"></a>Target Hook: <em>tree</em> <strong>TARGET_CHKP_MAKE_BOUNDS_CONSTANT</strong> <em>(HOST_WIDE_INT <var>lb</var>, HOST_WIDE_INT <var>ub</var>)</em></dt>
|
||
|
<dd><p>Return constant used to statically initialize constant bounds
|
||
|
with specified lower bound <var>lb</var> and upper bounds <var>ub</var>.
|
||
|
</p></dd></dl>
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCHKP_005fINITIALIZE_005fBOUNDS"></a>Target Hook: <em>int</em> <strong>TARGET_CHKP_INITIALIZE_BOUNDS</strong> <em>(tree <var>var</var>, tree <var>lb</var>, tree <var>ub</var>, tree *<var>stmts</var>)</em></dt>
|
||
|
<dd><p>Generate a list of statements <var>stmts</var> to initialize pointer
|
||
|
bounds variable <var>var</var> with bounds <var>lb</var> and <var>ub</var>. Return
|
||
|
the number of generated statements.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fRESOLVE_005fOVERLOADED_005fBUILTIN"></a>Target Hook: <em>tree</em> <strong>TARGET_RESOLVE_OVERLOADED_BUILTIN</strong> <em>(unsigned int <var>loc</var>, tree <var>fndecl</var>, void *<var>arglist</var>)</em></dt>
|
||
|
<dd><p>Select a replacement for a machine specific built-in function that
|
||
|
was set up by ‘<samp>TARGET_INIT_BUILTINS</samp>’. This is done
|
||
|
<em>before</em> regular type checking, and so allows the target to
|
||
|
implement a crude form of function overloading. <var>fndecl</var> is the
|
||
|
declaration of the built-in function. <var>arglist</var> is the list of
|
||
|
arguments passed to the built-in function. The result is a
|
||
|
complete expression that implements the operation, usually
|
||
|
another <code>CALL_EXPR</code>.
|
||
|
<var>arglist</var> really has type ‘<samp>VEC(tree,gc)*</samp>’
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fFOLD_005fBUILTIN"></a>Target Hook: <em>tree</em> <strong>TARGET_FOLD_BUILTIN</strong> <em>(tree <var>fndecl</var>, int <var>n_args</var>, tree *<var>argp</var>, bool <var>ignore</var>)</em></dt>
|
||
|
<dd><p>Fold a call to a machine specific built-in function that was set up by
|
||
|
‘<samp>TARGET_INIT_BUILTINS</samp>’. <var>fndecl</var> is the declaration of the
|
||
|
built-in function. <var>n_args</var> is the number of arguments passed to
|
||
|
the function; the arguments themselves are pointed to by <var>argp</var>.
|
||
|
The result is another tree, valid for both GIMPLE and GENERIC,
|
||
|
containing a simplified expression for the call’s result. If
|
||
|
<var>ignore</var> is true the value will be ignored.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGIMPLE_005fFOLD_005fBUILTIN"></a>Target Hook: <em>bool</em> <strong>TARGET_GIMPLE_FOLD_BUILTIN</strong> <em>(gimple_stmt_iterator *<var>gsi</var>)</em></dt>
|
||
|
<dd><p>Fold a call to a machine specific built-in function that was set up
|
||
|
by ‘<samp>TARGET_INIT_BUILTINS</samp>’. <var>gsi</var> points to the gimple
|
||
|
statement holding the function call. Returns true if any change
|
||
|
was made to the GIMPLE stream.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCOMPARE_005fVERSION_005fPRIORITY"></a>Target Hook: <em>int</em> <strong>TARGET_COMPARE_VERSION_PRIORITY</strong> <em>(tree <var>decl1</var>, tree <var>decl2</var>)</em></dt>
|
||
|
<dd><p>This hook is used to compare the target attributes in two functions to
|
||
|
determine which function’s features get higher priority. This is used
|
||
|
during function multi-versioning to figure out the order in which two
|
||
|
versions must be dispatched. A function version with a higher priority
|
||
|
is checked for dispatching earlier. <var>decl1</var> and <var>decl2</var> are
|
||
|
the two function decls that will be compared.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGET_005fFUNCTION_005fVERSIONS_005fDISPATCHER"></a>Target Hook: <em>tree</em> <strong>TARGET_GET_FUNCTION_VERSIONS_DISPATCHER</strong> <em>(void *<var>decl</var>)</em></dt>
|
||
|
<dd><p>This hook is used to get the dispatcher function for a set of function
|
||
|
versions. The dispatcher function is called to invoke the right function
|
||
|
version at run-time. <var>decl</var> is one version from a set of semantically
|
||
|
identical versions.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGENERATE_005fVERSION_005fDISPATCHER_005fBODY"></a>Target Hook: <em>tree</em> <strong>TARGET_GENERATE_VERSION_DISPATCHER_BODY</strong> <em>(void *<var>arg</var>)</em></dt>
|
||
|
<dd><p>This hook is used to generate the dispatcher logic to invoke the right
|
||
|
function version at run-time for a given set of function versions.
|
||
|
<var>arg</var> points to the callgraph node of the dispatcher function whose
|
||
|
body must be generated.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCAN_005fUSE_005fDOLOOP_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_CAN_USE_DOLOOP_P</strong> <em>(const widest_int <var>&iterations</var>, const widest_int <var>&iterations_max</var>, unsigned int <var>loop_depth</var>, bool <var>entered_at_top</var>)</em></dt>
|
||
|
<dd><p>Return true if it is possible to use low-overhead loops (<code>doloop_end</code>
|
||
|
and <code>doloop_begin</code>) for a particular loop. <var>iterations</var> gives the
|
||
|
exact number of iterations, or 0 if not known. <var>iterations_max</var> gives
|
||
|
the maximum number of iterations, or 0 if not known. <var>loop_depth</var> is
|
||
|
the nesting depth of the loop, with 1 for innermost loops, 2 for loops that
|
||
|
contain innermost loops, and so on. <var>entered_at_top</var> is true if the
|
||
|
loop is only entered from the top.
|
||
|
</p>
|
||
|
<p>This hook is only used if <code>doloop_end</code> is available. The default
|
||
|
implementation returns true. You can use <code>can_use_doloop_if_innermost</code>
|
||
|
if the loop must be the innermost, and if there are no other restrictions.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fWITHIN_005fDOLOOP"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_WITHIN_DOLOOP</strong> <em>(const rtx_insn *<var>insn</var>)</em></dt>
|
||
|
<dd>
|
||
|
<p>Take an instruction in <var>insn</var> and return NULL if it is valid within a
|
||
|
low-overhead loop, otherwise return a string explaining why doloop
|
||
|
could not be applied.
|
||
|
</p>
|
||
|
<p>Many targets use special registers for low-overhead looping. For any
|
||
|
instruction that clobbers these this function should return a string indicating
|
||
|
the reason why the doloop could not be applied.
|
||
|
By default, the RTL loop optimizer does not use a present doloop pattern for
|
||
|
loops containing function calls or branch on table instructions.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fLEGITIMATE_005fCOMBINED_005fINSN"></a>Target Hook: <em>bool</em> <strong>TARGET_LEGITIMATE_COMBINED_INSN</strong> <em>(rtx_insn *<var>insn</var>)</em></dt>
|
||
|
<dd><p>Take an instruction in <var>insn</var> and return <code>false</code> if the instruction is not appropriate as a combination of two or more instructions. The default is to accept all instructions.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCAN_005fFOLLOW_005fJUMP"></a>Target Hook: <em>bool</em> <strong>TARGET_CAN_FOLLOW_JUMP</strong> <em>(const rtx_insn *<var>follower</var>, const rtx_insn *<var>followee</var>)</em></dt>
|
||
|
<dd><p>FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if FOLLOWER may be modified to follow FOLLOWEE; false, if it can’t. For example, on some targets, certain kinds of branches can’t be made to follow through a hot/cold partitioning.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCOMMUTATIVE_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_COMMUTATIVE_P</strong> <em>(const_rtx <var>x</var>, int <var>outer_code</var>)</em></dt>
|
||
|
<dd><p>This target hook returns <code>true</code> if <var>x</var> is considered to be commutative.
|
||
|
Usually, this is just COMMUTATIVE_P (<var>x</var>), but the HP PA doesn’t consider
|
||
|
PLUS to be commutative inside a MEM. <var>outer_code</var> is the rtx code
|
||
|
of the enclosing rtl, if known, otherwise it is UNKNOWN.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fALLOCATE_005fINITIAL_005fVALUE"></a>Target Hook: <em>rtx</em> <strong>TARGET_ALLOCATE_INITIAL_VALUE</strong> <em>(rtx <var>hard_reg</var>)</em></dt>
|
||
|
<dd>
|
||
|
<p>When the initial value of a hard register has been copied in a pseudo
|
||
|
register, it is often not necessary to actually allocate another register
|
||
|
to this pseudo register, because the original hard register or a stack slot
|
||
|
it has been saved into can be used. <code>TARGET_ALLOCATE_INITIAL_VALUE</code>
|
||
|
is called at the start of register allocation once for each hard register
|
||
|
that had its initial value copied by using
|
||
|
<code>get_func_hard_reg_initial_val</code> or <code>get_hard_reg_initial_val</code>.
|
||
|
Possible values are <code>NULL_RTX</code>, if you don’t want
|
||
|
to do any special allocation, a <code>REG</code> rtx—that would typically be
|
||
|
the hard register itself, if it is known not to be clobbered—or a
|
||
|
<code>MEM</code>.
|
||
|
If you are returning a <code>MEM</code>, this is only a hint for the allocator;
|
||
|
it might decide to use another register anyways.
|
||
|
You may use <code>current_function_is_leaf</code> or
|
||
|
<code>REG_N_SETS</code> in the hook to determine if the hard
|
||
|
register in question will not be clobbered.
|
||
|
The default value of this hook is <code>NULL</code>, which disables any special
|
||
|
allocation.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fUNSPEC_005fMAY_005fTRAP_005fP"></a>Target Hook: <em>int</em> <strong>TARGET_UNSPEC_MAY_TRAP_P</strong> <em>(const_rtx <var>x</var>, unsigned <var>flags</var>)</em></dt>
|
||
|
<dd><p>This target hook returns nonzero if <var>x</var>, an <code>unspec</code> or
|
||
|
<code>unspec_volatile</code> operation, might cause a trap. Targets can use
|
||
|
this hook to enhance precision of analysis for <code>unspec</code> and
|
||
|
<code>unspec_volatile</code> operations. You may call <code>may_trap_p_1</code>
|
||
|
to analyze inner elements of <var>x</var> in which case <var>flags</var> should be
|
||
|
passed along.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fSET_005fCURRENT_005fFUNCTION"></a>Target Hook: <em>void</em> <strong>TARGET_SET_CURRENT_FUNCTION</strong> <em>(tree <var>decl</var>)</em></dt>
|
||
|
<dd><p>The compiler invokes this hook whenever it changes its current function
|
||
|
context (<code>cfun</code>). You can define this function if
|
||
|
the back end needs to perform any initialization or reset actions on a
|
||
|
per-function basis. For example, it may be used to implement function
|
||
|
attributes that affect register usage or code generation patterns.
|
||
|
The argument <var>decl</var> is the declaration for the new function context,
|
||
|
and may be null to indicate that the compiler has left a function context
|
||
|
and is returning to processing at the top level.
|
||
|
The default hook function does nothing.
|
||
|
</p>
|
||
|
<p>GCC sets <code>cfun</code> to a dummy function context during initialization of
|
||
|
some parts of the back end. The hook function is not invoked in this
|
||
|
situation; you need not worry about the hook being invoked recursively,
|
||
|
or when the back end is in a partially-initialized state.
|
||
|
<code>cfun</code> might be <code>NULL</code> to indicate processing at top level,
|
||
|
outside of any function scope.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOBJECT_005fSUFFIX"></a>Macro: <strong>TARGET_OBJECT_SUFFIX</strong></dt>
|
||
|
<dd><p>Define this macro to be a C string representing the suffix for object
|
||
|
files on your target machine. If you do not define this macro, GCC will
|
||
|
use ‘<samp>.o</samp>’ as the suffix for object files.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fEXECUTABLE_005fSUFFIX"></a>Macro: <strong>TARGET_EXECUTABLE_SUFFIX</strong></dt>
|
||
|
<dd><p>Define this macro to be a C string representing the suffix to be
|
||
|
automatically added to executable files on your target machine. If you
|
||
|
do not define this macro, GCC will use the null string as the suffix for
|
||
|
executable files.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-COLLECT_005fEXPORT_005fLIST"></a>Macro: <strong>COLLECT_EXPORT_LIST</strong></dt>
|
||
|
<dd><p>If defined, <code>collect2</code> will scan the individual object files
|
||
|
specified on its command line and create an export list for the linker.
|
||
|
Define this macro for systems like AIX, where the linker discards
|
||
|
object files that are not referenced from <code>main</code> and uses export
|
||
|
lists.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-MODIFY_005fJNI_005fMETHOD_005fCALL"></a>Macro: <strong>MODIFY_JNI_METHOD_CALL</strong> <em>(<var>mdecl</var>)</em></dt>
|
||
|
<dd><p>Define this macro to a C expression representing a variant of the
|
||
|
method call <var>mdecl</var>, if Java Native Interface (JNI) methods
|
||
|
must be invoked differently from other methods on your target.
|
||
|
For example, on 32-bit Microsoft Windows, JNI methods must be invoked using
|
||
|
the <code>stdcall</code> calling convention and this macro is then
|
||
|
defined as this expression:
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">build_type_attribute_variant (<var>mdecl</var>,
|
||
|
build_tree_list
|
||
|
(get_identifier ("stdcall"),
|
||
|
NULL))
|
||
|
</pre></div>
|
||
|
</dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCANNOT_005fMODIFY_005fJUMPS_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_CANNOT_MODIFY_JUMPS_P</strong> <em>(void)</em></dt>
|
||
|
<dd><p>This target hook returns <code>true</code> past the point in which new jump
|
||
|
instructions could be created. On machines that require a register for
|
||
|
every jump such as the SHmedia ISA of SH5, this point would typically be
|
||
|
reload, so this target hook should be defined to a function such as:
|
||
|
</p>
|
||
|
<div class="smallexample">
|
||
|
<pre class="smallexample">static bool
|
||
|
cannot_modify_jumps_past_reload_p ()
|
||
|
{
|
||
|
return (reload_completed || reload_in_progress);
|
||
|
}
|
||
|
</pre></div>
|
||
|
</dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fBRANCH_005fTARGET_005fREGISTER_005fCLASS"></a>Target Hook: <em>reg_class_t</em> <strong>TARGET_BRANCH_TARGET_REGISTER_CLASS</strong> <em>(void)</em></dt>
|
||
|
<dd><p>This target hook returns a register class for which branch target register
|
||
|
optimizations should be applied. All registers in this class should be
|
||
|
usable interchangeably. After reload, registers in this class will be
|
||
|
re-allocated and loads will be hoisted out of loops and be subjected
|
||
|
to inter-block scheduling.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fBRANCH_005fTARGET_005fREGISTER_005fCALLEE_005fSAVED"></a>Target Hook: <em>bool</em> <strong>TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED</strong> <em>(bool <var>after_prologue_epilogue_gen</var>)</em></dt>
|
||
|
<dd><p>Branch target register optimization will by default exclude callee-saved
|
||
|
registers
|
||
|
that are not already live during the current function; if this target hook
|
||
|
returns true, they will be included. The target code must than make sure
|
||
|
that all target registers in the class returned by
|
||
|
‘<samp>TARGET_BRANCH_TARGET_REGISTER_CLASS</samp>’ that might need saving are
|
||
|
saved. <var>after_prologue_epilogue_gen</var> indicates if prologues and
|
||
|
epilogues have already been generated. Note, even if you only return
|
||
|
true when <var>after_prologue_epilogue_gen</var> is false, you still are likely
|
||
|
to have to make special provisions in <code>INITIAL_ELIMINATION_OFFSET</code>
|
||
|
to reserve space for caller-saved target registers.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fHAVE_005fCONDITIONAL_005fEXECUTION"></a>Target Hook: <em>bool</em> <strong>TARGET_HAVE_CONDITIONAL_EXECUTION</strong> <em>(void)</em></dt>
|
||
|
<dd><p>This target hook returns true if the target supports conditional execution.
|
||
|
This target hook is required only when the target has several different
|
||
|
modes and they have different conditional execution capability, such as ARM.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGEN_005fCCMP_005fFIRST"></a>Target Hook: <em>rtx</em> <strong>TARGET_GEN_CCMP_FIRST</strong> <em>(rtx *<var>prep_seq</var>, rtx *<var>gen_seq</var>, int <var>code</var>, tree <var>op0</var>, tree <var>op1</var>)</em></dt>
|
||
|
<dd><p>This function prepares to emit a comparison insn for the first compare in a
|
||
|
sequence of conditional comparisions. It returns an appropriate comparison
|
||
|
with <code>CC</code> for passing to <code>gen_ccmp_next</code> or <code>cbranch_optab</code>.
|
||
|
The insns to prepare the compare are saved in <var>prep_seq</var> and the compare
|
||
|
insns are saved in <var>gen_seq</var>. They will be emitted when all the
|
||
|
compares in the the conditional comparision are generated without error.
|
||
|
<var>code</var> is the <code>rtx_code</code> of the compare for <var>op0</var> and <var>op1</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGEN_005fCCMP_005fNEXT"></a>Target Hook: <em>rtx</em> <strong>TARGET_GEN_CCMP_NEXT</strong> <em>(rtx *<var>prep_seq</var>, rtx *<var>gen_seq</var>, rtx <var>prev</var>, int <var>cmp_code</var>, tree <var>op0</var>, tree <var>op1</var>, int <var>bit_code</var>)</em></dt>
|
||
|
<dd><p>This function prepares to emit a conditional comparison within a sequence
|
||
|
of conditional comparisons. It returns an appropriate comparison with
|
||
|
<code>CC</code> for passing to <code>gen_ccmp_next</code> or <code>cbranch_optab</code>.
|
||
|
The insns to prepare the compare are saved in <var>prep_seq</var> and the compare
|
||
|
insns are saved in <var>gen_seq</var>. They will be emitted when all the
|
||
|
compares in the conditional comparision are generated without error. The
|
||
|
<var>prev</var> expression is the result of a prior call to <code>gen_ccmp_first</code>
|
||
|
or <code>gen_ccmp_next</code>. It may return <code>NULL</code> if the combination of
|
||
|
<var>prev</var> and this comparison is not supported, otherwise the result must
|
||
|
be appropriate for passing to <code>gen_ccmp_next</code> or <code>cbranch_optab</code>.
|
||
|
<var>code</var> is the <code>rtx_code</code> of the compare for <var>op0</var> and <var>op1</var>.
|
||
|
<var>bit_code</var> is <code>AND</code> or <code>IOR</code>, which is the op on the compares.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fLOOP_005fUNROLL_005fADJUST"></a>Target Hook: <em>unsigned</em> <strong>TARGET_LOOP_UNROLL_ADJUST</strong> <em>(unsigned <var>nunroll</var>, struct loop *<var>loop</var>)</em></dt>
|
||
|
<dd><p>This target hook returns a new value for the number of times <var>loop</var>
|
||
|
should be unrolled. The parameter <var>nunroll</var> is the number of times
|
||
|
the loop is to be unrolled. The parameter <var>loop</var> is a pointer to
|
||
|
the loop, which is going to be checked for unrolling. This target hook
|
||
|
is required only when the target has special constraints like maximum
|
||
|
number of memory accesses.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-POWI_005fMAX_005fMULTS"></a>Macro: <strong>POWI_MAX_MULTS</strong></dt>
|
||
|
<dd><p>If defined, this macro is interpreted as a signed integer C expression
|
||
|
that specifies the maximum number of floating point multiplications
|
||
|
that should be emitted when expanding exponentiation by an integer
|
||
|
constant inline. When this value is defined, exponentiation requiring
|
||
|
more than this number of multiplications is implemented by calling the
|
||
|
system library’s <code>pow</code>, <code>powf</code> or <code>powl</code> routines.
|
||
|
The default value places no upper bound on the multiplication count.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fEXTRA_005fINCLUDES"></a>Macro: <em>void</em> <strong>TARGET_EXTRA_INCLUDES</strong> <em>(const char *<var>sysroot</var>, const char *<var>iprefix</var>, int <var>stdinc</var>)</em></dt>
|
||
|
<dd><p>This target hook should register any extra include files for the
|
||
|
target. The parameter <var>stdinc</var> indicates if normal include files
|
||
|
are present. The parameter <var>sysroot</var> is the system root directory.
|
||
|
The parameter <var>iprefix</var> is the prefix for the gcc directory.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fEXTRA_005fPRE_005fINCLUDES"></a>Macro: <em>void</em> <strong>TARGET_EXTRA_PRE_INCLUDES</strong> <em>(const char *<var>sysroot</var>, const char *<var>iprefix</var>, int <var>stdinc</var>)</em></dt>
|
||
|
<dd><p>This target hook should register any extra include files for the
|
||
|
target before any standard headers. The parameter <var>stdinc</var>
|
||
|
indicates if normal include files are present. The parameter
|
||
|
<var>sysroot</var> is the system root directory. The parameter
|
||
|
<var>iprefix</var> is the prefix for the gcc directory.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOPTF"></a>Macro: <em>void</em> <strong>TARGET_OPTF</strong> <em>(char *<var>path</var>)</em></dt>
|
||
|
<dd><p>This target hook should register special include paths for the target.
|
||
|
The parameter <var>path</var> is the include to register. On Darwin
|
||
|
systems, this is used for Framework includes, which have semantics
|
||
|
that are different from <samp>-I</samp>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-bool"></a>Macro: <strong>bool</strong> <em>TARGET_USE_LOCAL_THUNK_ALIAS_P (tree <var>fndecl</var>)</em></dt>
|
||
|
<dd><p>This target macro returns <code>true</code> if it is safe to use a local alias
|
||
|
for a virtual function <var>fndecl</var> when constructing thunks,
|
||
|
<code>false</code> otherwise. By default, the macro returns <code>true</code> for all
|
||
|
functions, if a target supports aliases (i.e. defines
|
||
|
<code>ASM_OUTPUT_DEF</code>), <code>false</code> otherwise,
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fFORMAT_005fTYPES"></a>Macro: <strong>TARGET_FORMAT_TYPES</strong></dt>
|
||
|
<dd><p>If defined, this macro is the name of a global variable containing
|
||
|
target-specific format checking information for the <samp>-Wformat</samp>
|
||
|
option. The default is to have no target-specific format checks.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fN_005fFORMAT_005fTYPES"></a>Macro: <strong>TARGET_N_FORMAT_TYPES</strong></dt>
|
||
|
<dd><p>If defined, this macro is the number of entries in
|
||
|
<code>TARGET_FORMAT_TYPES</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOVERRIDES_005fFORMAT_005fATTRIBUTES"></a>Macro: <strong>TARGET_OVERRIDES_FORMAT_ATTRIBUTES</strong></dt>
|
||
|
<dd><p>If defined, this macro is the name of a global variable containing
|
||
|
target-specific format overrides for the <samp>-Wformat</samp> option. The
|
||
|
default is to have no target-specific format overrides. If defined,
|
||
|
<code>TARGET_FORMAT_TYPES</code> must be defined, too.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOVERRIDES_005fFORMAT_005fATTRIBUTES_005fCOUNT"></a>Macro: <strong>TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT</strong></dt>
|
||
|
<dd><p>If defined, this macro specifies the number of entries in
|
||
|
<code>TARGET_OVERRIDES_FORMAT_ATTRIBUTES</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOVERRIDES_005fFORMAT_005fINIT"></a>Macro: <strong>TARGET_OVERRIDES_FORMAT_INIT</strong></dt>
|
||
|
<dd><p>If defined, this macro specifies the optional initialization
|
||
|
routine for target specific customizations of the system printf
|
||
|
and scanf formatter settings.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fARG_005fFOR_005fUNPROTOTYPED_005fFN"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN</strong> <em>(const_tree <var>typelist</var>, const_tree <var>funcdecl</var>, const_tree <var>val</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
illegal to pass argument <var>val</var> to function <var>funcdecl</var>
|
||
|
with prototype <var>typelist</var>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fCONVERSION"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_CONVERSION</strong> <em>(const_tree <var>fromtype</var>, const_tree <var>totype</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
invalid to convert from <var>fromtype</var> to <var>totype</var>, or <code>NULL</code>
|
||
|
if validity should be determined by the front end.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fUNARY_005fOP"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_UNARY_OP</strong> <em>(int <var>op</var>, const_tree <var>type</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
invalid to apply operation <var>op</var> (where unary plus is denoted by
|
||
|
<code>CONVERT_EXPR</code>) to an operand of type <var>type</var>, or <code>NULL</code>
|
||
|
if validity should be determined by the front end.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fBINARY_005fOP"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_BINARY_OP</strong> <em>(int <var>op</var>, const_tree <var>type1</var>, const_tree <var>type2</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
invalid to apply operation <var>op</var> to operands of types <var>type1</var>
|
||
|
and <var>type2</var>, or <code>NULL</code> if validity should be determined by
|
||
|
the front end.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fPARAMETER_005fTYPE"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_PARAMETER_TYPE</strong> <em>(const_tree <var>type</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
invalid for functions to include parameters of type <var>type</var>,
|
||
|
or <code>NULL</code> if validity should be determined by
|
||
|
the front end. This is currently used only by the C and C++ front ends.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fINVALID_005fRETURN_005fTYPE"></a>Target Hook: <em>const char *</em> <strong>TARGET_INVALID_RETURN_TYPE</strong> <em>(const_tree <var>type</var>)</em></dt>
|
||
|
<dd><p>If defined, this macro returns the diagnostic message when it is
|
||
|
invalid for functions to have return type <var>type</var>,
|
||
|
or <code>NULL</code> if validity should be determined by
|
||
|
the front end. This is currently used only by the C and C++ front ends.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fPROMOTED_005fTYPE"></a>Target Hook: <em>tree</em> <strong>TARGET_PROMOTED_TYPE</strong> <em>(const_tree <var>type</var>)</em></dt>
|
||
|
<dd><p>If defined, this target hook returns the type to which values of
|
||
|
<var>type</var> should be promoted when they appear in expressions,
|
||
|
analogous to the integer promotions, or <code>NULL_TREE</code> to use the
|
||
|
front end’s normal promotion rules. This hook is useful when there are
|
||
|
target-specific types with special promotion rules.
|
||
|
This is currently used only by the C and C++ front ends.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCONVERT_005fTO_005fTYPE"></a>Target Hook: <em>tree</em> <strong>TARGET_CONVERT_TO_TYPE</strong> <em>(tree <var>type</var>, tree <var>expr</var>)</em></dt>
|
||
|
<dd><p>If defined, this hook returns the result of converting <var>expr</var> to
|
||
|
<var>type</var>. It should return the converted expression,
|
||
|
or <code>NULL_TREE</code> to apply the front end’s normal conversion rules.
|
||
|
This hook is useful when there are target-specific types with special
|
||
|
conversion rules.
|
||
|
This is currently used only by the C and C++ front ends.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fUSE_005fJCR_005fSECTION"></a>Macro: <strong>TARGET_USE_JCR_SECTION</strong></dt>
|
||
|
<dd><p>This macro determines whether to use the JCR section to register Java
|
||
|
classes. By default, TARGET_USE_JCR_SECTION is defined to 1 if both
|
||
|
SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, else 0.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-OBJC_005fJBLEN"></a>Macro: <strong>OBJC_JBLEN</strong></dt>
|
||
|
<dd><p>This macro determines the size of the objective C jump buffer for the
|
||
|
NeXT runtime. By default, OBJC_JBLEN is defined to an innocuous value.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-LIBGCC2_005fUNWIND_005fATTRIBUTE"></a>Macro: <strong>LIBGCC2_UNWIND_ATTRIBUTE</strong></dt>
|
||
|
<dd><p>Define this macro if any target-specific attributes need to be attached
|
||
|
to the functions in <samp>libgcc</samp> that provide low-level support for
|
||
|
call stack unwinding. It is used in declarations in <samp>unwind-generic.h</samp>
|
||
|
and the associated definitions of those functions.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fUPDATE_005fSTACK_005fBOUNDARY"></a>Target Hook: <em>void</em> <strong>TARGET_UPDATE_STACK_BOUNDARY</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Define this macro to update the current function stack boundary if
|
||
|
necessary.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fGET_005fDRAP_005fRTX"></a>Target Hook: <em>rtx</em> <strong>TARGET_GET_DRAP_RTX</strong> <em>(void)</em></dt>
|
||
|
<dd><p>This hook should return an rtx for Dynamic Realign Argument Pointer (DRAP) if a
|
||
|
different argument pointer register is needed to access the function’s
|
||
|
argument list due to stack realignment. Return <code>NULL</code> if no DRAP
|
||
|
is needed.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fALLOCATE_005fSTACK_005fSLOTS_005fFOR_005fARGS"></a>Target Hook: <em>bool</em> <strong>TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS</strong> <em>(void)</em></dt>
|
||
|
<dd><p>When optimization is disabled, this hook indicates whether or not
|
||
|
arguments should be allocated to stack slots. Normally, GCC allocates
|
||
|
stacks slots for arguments when not optimizing in order to make
|
||
|
debugging easier. However, when a function is declared with
|
||
|
<code>__attribute__((naked))</code>, there is no stack frame, and the compiler
|
||
|
cannot safely move arguments from the registers in which they are passed
|
||
|
to the stack. Therefore, this hook should return true in general, but
|
||
|
false for naked functions. The default implementation always returns true.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fCONST_005fANCHOR"></a>Target Hook: <em>unsigned HOST_WIDE_INT</em> <strong>TARGET_CONST_ANCHOR</strong></dt>
|
||
|
<dd><p>On some architectures it can take multiple instructions to synthesize
|
||
|
a constant. If there is another constant already in a register that
|
||
|
is close enough in value then it is preferable that the new constant
|
||
|
is computed from this register using immediate addition or
|
||
|
subtraction. We accomplish this through CSE. Besides the value of
|
||
|
the constant we also add a lower and an upper constant anchor to the
|
||
|
available expressions. These are then queried when encountering new
|
||
|
constants. The anchors are computed by rounding the constant up and
|
||
|
down to a multiple of the value of <code>TARGET_CONST_ANCHOR</code>.
|
||
|
<code>TARGET_CONST_ANCHOR</code> should be the maximum positive value
|
||
|
accepted by immediate-add plus one. We currently assume that the
|
||
|
value of <code>TARGET_CONST_ANCHOR</code> is a power of 2. For example, on
|
||
|
MIPS, where add-immediate takes a 16-bit signed value,
|
||
|
<code>TARGET_CONST_ANCHOR</code> is set to ‘<samp>0x8000</samp>’. The default value
|
||
|
is zero, which disables this optimization.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fASAN_005fSHADOW_005fOFFSET"></a>Target Hook: <em>unsigned HOST_WIDE_INT</em> <strong>TARGET_ASAN_SHADOW_OFFSET</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Return the offset bitwise ored into shifted address to get corresponding
|
||
|
Address Sanitizer shadow memory address. NULL if Address Sanitizer is not
|
||
|
supported by the target.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fMEMMODEL_005fCHECK"></a>Target Hook: <em>unsigned HOST_WIDE_INT</em> <strong>TARGET_MEMMODEL_CHECK</strong> <em>(unsigned HOST_WIDE_INT <var>val</var>)</em></dt>
|
||
|
<dd><p>Validate target specific memory model mask bits. When NULL no target specific
|
||
|
memory model bits are allowed.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fATOMIC_005fTEST_005fAND_005fSET_005fTRUEVAL"></a>Target Hook: <em>unsigned char</em> <strong>TARGET_ATOMIC_TEST_AND_SET_TRUEVAL</strong></dt>
|
||
|
<dd><p>This value should be set if the result written by <code>atomic_test_and_set</code> is not exactly 1, i.e. the <code>bool</code> <code>true</code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fHAS_005fIFUNC_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_HAS_IFUNC_P</strong> <em>(void)</em></dt>
|
||
|
<dd><p>It returns true if the target supports GNU indirect functions.
|
||
|
The support includes the assembler, linker and dynamic linker.
|
||
|
The default value of this hook is based on target’s libc.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fATOMIC_005fALIGN_005fFOR_005fMODE"></a>Target Hook: <em>unsigned int</em> <strong>TARGET_ATOMIC_ALIGN_FOR_MODE</strong> <em>(machine_mode <var>mode</var>)</em></dt>
|
||
|
<dd><p>If defined, this function returns an appropriate alignment in bits for an atomic object of machine_mode <var>mode</var>. If 0 is returned then the default alignment for the specified mode is used.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fATOMIC_005fASSIGN_005fEXPAND_005fFENV"></a>Target Hook: <em>void</em> <strong>TARGET_ATOMIC_ASSIGN_EXPAND_FENV</strong> <em>(tree *<var>hold</var>, tree *<var>clear</var>, tree *<var>update</var>)</em></dt>
|
||
|
<dd><p>ISO C11 requires atomic compound assignments that may raise floating-point exceptions to raise exceptions corresponding to the arithmetic operation whose result was successfully stored in a compare-and-exchange sequence. This requires code equivalent to calls to <code>feholdexcept</code>, <code>feclearexcept</code> and <code>feupdateenv</code> to be generated at appropriate points in the compare-and-exchange sequence. This hook should set <code>*<var>hold</var></code> to an expression equivalent to the call to <code>feholdexcept</code>, <code>*<var>clear</var></code> to an expression equivalent to the call to <code>feclearexcept</code> and <code>*<var>update</var></code> to an expression equivalent to the call to <code>feupdateenv</code>. The three expressions are <code>NULL_TREE</code> on entry to the hook and may be left as <code>NULL_TREE</code> if no code is required in a particular place. The default implementation leaves all three expressions as <code>NULL_TREE</code>. The <code>__atomic_feraiseexcept</code> function from <code>libatomic</code> may be of use as part of the code generated in <code>*<var>update</var></code>.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fRECORD_005fOFFLOAD_005fSYMBOL"></a>Target Hook: <em>void</em> <strong>TARGET_RECORD_OFFLOAD_SYMBOL</strong> <em>(tree)</em></dt>
|
||
|
<dd><p>Used when offloaded functions are seen in the compilation unit and no named
|
||
|
sections are available. It is called once for each symbol that must be
|
||
|
recorded in the offload function and variable table.
|
||
|
</p></dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fOFFLOAD_005fOPTIONS"></a>Target Hook: <em>char *</em> <strong>TARGET_OFFLOAD_OPTIONS</strong> <em>(void)</em></dt>
|
||
|
<dd><p>Used when writing out the list of options into an LTO file. It should
|
||
|
translate any relevant target-specific options (such as the ABI in use)
|
||
|
into one of the <samp>-foffload</samp> options that exist as a common interface
|
||
|
to express such options. It should return a string containing these options,
|
||
|
separated by spaces, which the caller will free.
|
||
|
</p>
|
||
|
</dd></dl>
|
||
|
|
||
|
<dl>
|
||
|
<dt><a name="index-TARGET_005fSUPPORTS_005fWIDE_005fINT"></a>Macro: <strong>TARGET_SUPPORTS_WIDE_INT</strong></dt>
|
||
|
<dd>
|
||
|
<p>On older ports, large integers are stored in <code>CONST_DOUBLE</code> rtl
|
||
|
objects. Newer ports define <code>TARGET_SUPPORTS_WIDE_INT</code> to be nonzero
|
||
|
to indicate that large integers are stored in
|
||
|
<code>CONST_WIDE_INT</code> rtl objects. The <code>CONST_WIDE_INT</code> allows
|
||
|
very large integer constants to be represented. <code>CONST_DOUBLE</code>
|
||
|
is limited to twice the size of the host’s <code>HOST_WIDE_INT</code>
|
||
|
representation.
|
||
|
</p>
|
||
|
<p>Converting a port mostly requires looking for the places where
|
||
|
<code>CONST_DOUBLE</code>s are used with <code>VOIDmode</code> and replacing that
|
||
|
code with code that accesses <code>CONST_WIDE_INT</code>s. ‘<samp>"grep -i
|
||
|
const_double"</samp>’ at the port level gets you to 95% of the changes that
|
||
|
need to be made. There are a few places that require a deeper look.
|
||
|
</p>
|
||
|
<ul>
|
||
|
<li> There is no equivalent to <code>hval</code> and <code>lval</code> for
|
||
|
<code>CONST_WIDE_INT</code>s. This would be difficult to express in the md
|
||
|
language since there are a variable number of elements.
|
||
|
|
||
|
<p>Most ports only check that <code>hval</code> is either 0 or -1 to see if the
|
||
|
value is small. As mentioned above, this will no longer be necessary
|
||
|
since small constants are always <code>CONST_INT</code>. Of course there
|
||
|
are still a few exceptions, the alpha’s constraint used by the zap
|
||
|
instruction certainly requires careful examination by C code.
|
||
|
However, all the current code does is pass the hval and lval to C
|
||
|
code, so evolving the c code to look at the <code>CONST_WIDE_INT</code> is
|
||
|
not really a large change.
|
||
|
</p>
|
||
|
</li><li> Because there is no standard template that ports use to materialize
|
||
|
constants, there is likely to be some futzing that is unique to each
|
||
|
port in this code.
|
||
|
|
||
|
</li><li> The rtx costs may have to be adjusted to properly account for larger
|
||
|
constants that are represented as <code>CONST_WIDE_INT</code>.
|
||
|
</li></ul>
|
||
|
|
||
|
<p>All and all it does not take long to convert ports that the
|
||
|
maintainer is familiar with.
|
||
|
</p>
|
||
|
</dd></dl>
|
||
|
|
||
|
<hr>
|
||
|
<div class="header">
|
||
|
<p>
|
||
|
Previous: <a href="Named-Address-Spaces.html#Named-Address-Spaces" accesskey="p" rel="prev">Named Address Spaces</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</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>
|