<meta name="author" content="Chris Lattner">
<meta name="description"
content="LLVM Assembly Language Reference Manual.">
- <link rel="stylesheet" href="llvm.css" type="text/css">
+ <link rel="stylesheet" href="_static/llvm.css" type="text/css">
</head>
<body>
<li><a href="#linkage_externweak">'<tt>extern_weak</tt>' Linkage</a></li>
<li><a href="#linkage_linkonce_odr">'<tt>linkonce_odr</tt>' Linkage</a></li>
<li><a href="#linkage_weak">'<tt>weak_odr</tt>' Linkage</a></li>
- <li><a href="#linkage_external">'<tt>externally visible</tt>' Linkage</a></li>
+ <li><a href="#linkage_external">'<tt>external</tt>' Linkage</a></li>
<li><a href="#linkage_dllimport">'<tt>dllimport</tt>' Linkage</a></li>
<li><a href="#linkage_dllexport">'<tt>dllexport</tt>' Linkage</a></li>
</ol>
<li><a href="#complexconstants">Complex Constants</a></li>
<li><a href="#globalconstants">Global Variable and Function Addresses</a></li>
<li><a href="#undefvalues">Undefined Values</a></li>
- <li><a href="#trapvalues">Trap Values</a></li>
+ <li><a href="#poisonvalues">Poison Values</a></li>
<li><a href="#blockaddress">Addresses of Basic Blocks</a></li>
<li><a href="#constantexprs">Constant Expressions</a></li>
</ol>
<li><a href="#othervalues">Other Values</a>
<ol>
<li><a href="#inlineasm">Inline Assembler Expressions</a></li>
- <li><a href="#metadata">Metadata Nodes and Metadata Strings</a></li>
+ <li><a href="#metadata">Metadata Nodes and Metadata Strings</a>
+ <ol>
+ <li><a href="#tbaa">'<tt>tbaa</tt>' Metadata</a></li>
+ <li><a href="#fpmath">'<tt>fpmath</tt>' Metadata</a></li>
+ <li><a href="#range">'<tt>range</tt>' Metadata</a></li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+ <li><a href="#module_flags">Module Flags Metadata</a>
+ <ol>
+ <li><a href="#objc_gc_flags">Objective-C Garbage Collection Module Flags Metadata</a></li>
</ol>
</li>
<li><a href="#intrinsic_globals">Intrinsic Global Variables</a>
<li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li>
<li><a href="#i_indirectbr">'<tt>indirectbr</tt>' Instruction</a></li>
<li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li>
- <li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li>
<li><a href="#i_resume">'<tt>resume</tt>' Instruction</a></li>
<li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li>
</ol>
<li><a href="#int_exp">'<tt>llvm.exp.*</tt>' Intrinsic</a></li>
<li><a href="#int_log">'<tt>llvm.log.*</tt>' Intrinsic</a></li>
<li><a href="#int_fma">'<tt>llvm.fma.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_fabs">'<tt>llvm.fabs.*</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_manip">Bit Manipulation Intrinsics</a>
<li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li>
</ol>
</li>
+ <li><a href="#spec_arithmetic">Specialised Arithmetic Intrinsics</a>
+ <ol>
+ <li><a href="#fmuladd">'<tt>llvm.fmuladd</tt> Intrinsic</a></li>
+ </ol>
+ </li>
<li><a href="#int_fp16">Half Precision Floating Point Intrinsics</a>
<ol>
<li><a href="#int_convert_to_fp16">'<tt>llvm.convert.to.fp16</tt>' Intrinsic</a></li>
</li>
<li><a href="#int_debugger">Debugger intrinsics</a></li>
<li><a href="#int_eh">Exception Handling intrinsics</a></li>
- <li><a href="#int_trampoline">Trampoline Intrinsic</a>
+ <li><a href="#int_trampoline">Trampoline Intrinsics</a>
<ol>
<li><a href="#int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_atomics">Atomic intrinsics</a>
- <ol>
- <li><a href="#int_memory_barrier"><tt>llvm.memory_barrier</tt></a></li>
- <li><a href="#int_atomic_cmp_swap"><tt>llvm.atomic.cmp.swap</tt></a></li>
- <li><a href="#int_atomic_swap"><tt>llvm.atomic.swap</tt></a></li>
- <li><a href="#int_atomic_load_add"><tt>llvm.atomic.load.add</tt></a></li>
- <li><a href="#int_atomic_load_sub"><tt>llvm.atomic.load.sub</tt></a></li>
- <li><a href="#int_atomic_load_and"><tt>llvm.atomic.load.and</tt></a></li>
- <li><a href="#int_atomic_load_nand"><tt>llvm.atomic.load.nand</tt></a></li>
- <li><a href="#int_atomic_load_or"><tt>llvm.atomic.load.or</tt></a></li>
- <li><a href="#int_atomic_load_xor"><tt>llvm.atomic.load.xor</tt></a></li>
- <li><a href="#int_atomic_load_max"><tt>llvm.atomic.load.max</tt></a></li>
- <li><a href="#int_atomic_load_min"><tt>llvm.atomic.load.min</tt></a></li>
- <li><a href="#int_atomic_load_umax"><tt>llvm.atomic.load.umax</tt></a></li>
- <li><a href="#int_atomic_load_umin"><tt>llvm.atomic.load.umin</tt></a></li>
+ <li><a href="#int_at">'<tt>llvm.adjust.trampoline</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_memorymarkers">Memory Use Markers</a>
<ol>
- <li><a href="#int_lifetime_start"><tt>llvm.lifetime.start</tt></a></li>
- <li><a href="#int_lifetime_end"><tt>llvm.lifetime.end</tt></a></li>
- <li><a href="#int_invariant_start"><tt>llvm.invariant.start</tt></a></li>
- <li><a href="#int_invariant_end"><tt>llvm.invariant.end</tt></a></li>
+ <li><a href="#int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a></li>
+ <li><a href="#int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a></li>
+ <li><a href="#int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a></li>
+ <li><a href="#int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_general">General intrinsics</a>
'<tt>llvm.annotation.*</tt>' Intrinsic</a></li>
<li><a href="#int_trap">
'<tt>llvm.trap</tt>' Intrinsic</a></li>
+ <li><a href="#int_debugtrap">
+ '<tt>llvm.debugtrap</tt>' Intrinsic</a></li>
<li><a href="#int_stackprotector">
'<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
<li><a href="#int_objectsize">
'<tt>llvm.objectsize</tt>' Intrinsic</a></li>
+ <li><a href="#int_expect">
+ '<tt>llvm.expect</tt>' Intrinsic</a></li>
</ol>
</li>
</ol>
<div>
-<p>LLVM programs are composed of "Module"s, each of which is a translation unit
- of the input programs. Each module consists of functions, global variables,
- and symbol table entries. Modules may be combined together with the LLVM
- linker, which merges function (and global variable) definitions, resolves
- forward declarations, and merges symbol table entries. Here is an example of
- the "hello world" module:</p>
+<p>LLVM programs are composed of <tt>Module</tt>s, each of which is a
+ translation unit of the input programs. Each module consists of functions,
+ global variables, and symbol table entries. Modules may be combined together
+ with the LLVM linker, which merges function (and global variable)
+ definitions, resolves forward declarations, and merges symbol table
+ entries. Here is an example of the "hello world" module:</p>
<pre class="doc_code">
<i>; Declare the string constant as a global constant.</i>
-<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
+<a href="#identifiers">@.str</a> = <a href="#linkage_private">private</a> <a href="#globalvars">unnamed_addr</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00"
<i>; External declaration of the puts function</i>
-<a href="#functionstructure">declare</a> i32 @puts(i8*) <i>; i32 (i8*)* </i>
+<a href="#functionstructure">declare</a> i32 @puts(i8* <a href="#nocapture">nocapture</a>) <a href="#fnattrs">nounwind</a>
<i>; Definition of main function</i>
define i32 @main() { <i>; i32()* </i>
<i>; Convert [13 x i8]* to i8 *...</i>
- %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8*</i>
+ %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.str, i64 0, i64 0
<i>; Call puts function to write out the string to stdout.</i>
- <a href="#i_call">call</a> i32 @puts(i8* %cast210) <i>; i32</i>
+ <a href="#i_call">call</a> i32 @puts(i8* %cast210)
<a href="#i_ret">ret</a> i32 0
}
<i>; Named metadata</i>
-!1 = metadata !{i32 41}
+!1 = metadata !{i32 42}
!foo = !{!1, null}
</pre>
<p>This example is made up of a <a href="#globalvars">global variable</a> named
- "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>" function,
+ "<tt>.str</tt>", an external declaration of the "<tt>puts</tt>" function,
a <a href="#functionstructure">function definition</a> for
"<tt>main</tt>" and <a href="#namedmetadatastructure">named metadata</a>
- "<tt>foo"</tt>.</p>
+ "<tt>foo</tt>".</p>
-<p>In general, a module is made up of a list of global values, where both
- functions and global variables are global values. Global values are
+<p>In general, a module is made up of a list of global values (where both
+ functions and global variables are global values). Global values are
represented by a pointer to a memory location (in this case, a pointer to an
array of char, and a pointer to a function), and have one of the
following <a href="#linkage">linkage types</a>.</p>
be merged with equivalent globals. These linkage types are otherwise the
same as their non-<tt>odr</tt> versions.</dd>
- <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
+ <dt><tt><b><a name="linkage_external">external</a></b></tt></dt>
<dd>If none of the above identifiers are used, the global is externally
visible, meaning that it participates in linkage and can be used to
resolve external symbol references.</dd>
declarations), they are accessible outside of the current module.</p>
<p>It is illegal for a function <i>declaration</i> to have any linkage type
- other than "externally visible", <tt>dllimport</tt>
- or <tt>extern_weak</tt>.</p>
+ other than <tt>external</tt>, <tt>dllimport</tt>
+ or <tt>extern_weak</tt>.</p>
<p>Aliases can have only <tt>external</tt>, <tt>internal</tt>, <tt>weak</tt>
or <tt>weak_odr</tt> linkages.</p>
<p>Global variables define regions of memory allocated at compilation time
instead of run-time. Global variables may optionally be initialized, may
have an explicit section to be placed in, and may have an optional explicit
- alignment specified. A variable may be defined as "thread_local", which
+ alignment specified.</p>
+
+<p>A variable may be defined as <tt>thread_local</tt>, which
means that it will not be shared by threads (each thread will have a
- separated copy of the variable). A variable may be defined as a global
+ separated copy of the variable). Not all targets support thread-local
+ variables. Optionally, a TLS model may be specified:</p>
+
+<dl>
+ <dt><b><tt>localdynamic</tt></b>:</dt>
+ <dd>For variables that are only used within the current shared library.</dd>
+
+ <dt><b><tt>initialexec</tt></b>:</dt>
+ <dd>For variables in modules that will not be loaded dynamically.</dd>
+
+ <dt><b><tt>localexec</tt></b>:</dt>
+ <dd>For variables defined in the executable and only used within it.</dd>
+</dl>
+
+<p>The models correspond to the ELF TLS models; see
+ <a href="http://people.redhat.com/drepper/tls.pdf">ELF
+ Handling For Thread-Local Storage</a> for more information on under which
+ circumstances the different models may be used. The target may choose a
+ different TLS model if the specified model is not supported, or if a better
+ choice of model can be made.</p>
+
+<p>A variable may be defined as a global
"constant," which indicates that the contents of the variable
will <b>never</b> be modified (enabling better optimization, allowing the
global data to be placed in the read-only section of an executable, etc).
@G = addrspace(5) constant float 1.0, section "foo", align 4
</pre>
+<p>The following example defines a thread-local global with
+ the <tt>initialexec</tt> TLS model:</p>
+
+<pre class="doc_code">
+@G = thread_local(initialexec) global i32 0, align 4
+</pre>
+
</div>
alignments must be a power of 2.</p>
<p>If the <tt>unnamed_addr</tt> attribute is given, the address is know to not
- be significant and two identical functions can be merged</p>.
+ be significant and two identical functions can be merged.</p>
<h5>Syntax:</h5>
<pre class="doc_code">
value to the function. The attribute implies that a hidden copy of the
pointee
is made between the caller and the callee, so the callee is unable to
- modify the value in the callee. This attribute is only valid on LLVM
+ modify the value in the caller. This attribute is only valid on LLVM
pointer arguments. It is generally used to pass structs and arrays by
value, but is also valid on pointers to scalars. The copy is considered
to belong to the caller not the callee (for example,
</pre>
<dl>
+ <dt><tt><b>address_safety</b></tt></dt>
+ <dd>This attribute indicates that the address safety analysis
+ is enabled for this function. </dd>
+
<dt><tt><b>alignstack(<<em>n</em>>)</b></tt></dt>
<dd>This attribute indicates that, when emitting the prologue and epilogue,
the backend should forcibly align the stack pointer. Specify the
function into callers whenever possible, ignoring any active inlining size
threshold for this caller.</dd>
- <dt><tt><b>hotpatch</b></tt></dt>
- <dd>This attribute indicates that the function should be 'hotpatchable',
- meaning the function can be patched and/or hooked even while it is
- loaded into memory. On x86, the function prologue will be preceded
- by six bytes of padding and will begin with a two-byte instruction.
- Most of the functions in the Windows system DLLs in Windows XP SP2 or
- higher were compiled in this fashion.</dd>
-
<dt><tt><b>nonlazybind</b></tt></dt>
<dd>This attribute suppresses lazy symbol binding for the function. This
may make calls to the function faster, at the cost of extra program
It does not write through any pointer arguments
(including <tt><a href="#byval">byval</a></tt> arguments) and never
changes any state visible to callers. This means that it cannot unwind
- exceptions by calling the <tt>C++</tt> exception throwing methods, but
- could use the <tt>unwind</tt> instruction.</dd>
+ exceptions by calling the <tt>C++</tt> exception throwing methods.</dd>
<dt><tt><b><a name="readonly">readonly</a></b></tt></dt>
<dd>This attribute indicates that the function does not write through any
and read state that may be set in the caller. A readonly function always
returns the same value (or unwinds an exception identically) when called
with the same set of arguments and global state. It cannot unwind an
- exception by calling the <tt>C++</tt> exception throwing methods, but may
- use the <tt>unwind</tt> instruction.</dd>
+ exception by calling the <tt>C++</tt> exception throwing methods.</dd>
+
+ <dt><tt><b><a name="returns_twice">returns_twice</a></b></tt></dt>
+ <dd>This attribute indicates that this function can return twice. The
+ C <code>setjmp</code> is an example of such a function. The compiler
+ disables some optimizations (like tail calls) in the caller of these
+ functions.</dd>
<dt><tt><b><a name="ssp">ssp</a></b></tt></dt>
<dd>This attribute indicates that the function should emit a stack smashing
show that no exceptions passes by it. This is normally the case for
the ELF x86-64 abi, but it can be disabled for some compilation
units.</dd>
-
</dl>
</div>
the bits with the least significance have the lowest address
location.</dd>
+ <dt><tt>S<i>size</i></tt></dt>
+ <dd>Specifies the natural alignment of the stack in bits. Alignment promotion
+ of stack variables is limited to the natural stack alignment to avoid
+ dynamic stack realignment. The stack alignment must be a multiple of
+ 8-bits. If omitted, the natural stack alignment defaults to "unspecified",
+ which does not prevent any alignment promotions.</dd>
+
<dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
<i>preferred</i> alignments. All sizes are in bits. Specifying
implemented in terms of 64 <2 x double>, for example.</li>
</ol>
+<p>The function of the data layout string may not be what you expect. Notably,
+ this is not a specification from the frontend of what alignment the code
+ generator should use.</p>
+
+<p>Instead, if specified, the target data layout is required to match what the
+ ultimate <em>code generator</em> expects. This string is used by the
+ mid-level optimizers to
+ improve code, and this only works if it matches what the ultimate code
+ generator uses. If you would like to generate IR that does not embed this
+ target-specific detail into the IR, then you don't have to specify the
+ string. This will disable some optimizations that require precise layout
+ information, but this also prevents those optimizations from introducing
+ target specificity into the IR.</p>
+
+
+
</div>
<!-- ======================================================================= -->
ways to create them, and we define LLVM IR's behavior in their presence. This
model is inspired by the C++0x memory model.</p>
+<p>For a more informal introduction to this model, see the
+<a href="Atomics.html">LLVM Atomic Instructions and Concurrency Guide</a>.
+
<p>We define a <i>happens-before</i> partial order as the least partial order
that</p>
<ul>
<p>Given that definition, <var>R<sub>byte</sub></var> is defined as follows:
<ul>
- <li>If there is no write to the same byte that happens before
+ <li>If <var>R</var> is volatile, the result is target-dependent. (Volatile
+ is supposed to give guarantees which can support
+ <code>sig_atomic_t</code> in C/C++, and may be used for accesses to
+ addresses which do not behave like normal memory. It does not generally
+ provide cross-thread synchronization.)
+ <li>Otherwise, if there is no write to the same byte that happens before
<var>R<sub>byte</sub></var>, <var>R<sub>byte</sub></var> returns
<tt>undef</tt> for that byte.
<li>Otherwise, if <var>R<sub>byte</sub></var> may see exactly one write,
that determines which other atomic instructions on the same address they
<i>synchronize with</i>. These semantics are borrowed from Java and C++0x,
but are somewhat more colloquial. If these descriptions aren't precise enough,
-check those specs. <a href="#i_fence"><code>fence</code></a> instructions
+check those specs (see spec references in the
+<a href="Atomics.html#introduction">atomics guide</a>).
+<a href="#i_fence"><code>fence</code></a> instructions
treat these orderings somewhat differently since they don't take an address.
See that instruction's documentation for details.</p>
+<p>For a simpler introduction to the ordering constraints, see the
+<a href="Atomics.html">LLVM Atomic Instructions and Concurrency Guide</a>.</p>
+
<dl>
<dt><code>unordered</code></dt>
<dd>The set of values that can be read is governed by the happens-before
<code>monotonic</code> (or stronger) operations on the same address. If an
address is written <code>monotonic</code>ally by one thread, and other threads
<code>monotonic</code>ally read that address repeatedly, the other threads must
-eventually see the write. This is intended to model C++'s relaxed atomic
-variables.</dd>
+eventually see the write. This corresponds to the C++0x/C1x
+<code>memory_order_relaxed</code>.</dd>
<dt><code>acquire</code></dt>
-<dd>In addition to the guarantees of <code>monotonic</code>, if this operation
-reads a value written by a <code>release</code> atomic operation, it
-<i>synchronizes-with</i> that operation.</dd>
-<dt><code>release</code></dt>
<dd>In addition to the guarantees of <code>monotonic</code>,
-a <i>synchronizes-with</i> edge may be formed by an <code>acquire</code>
-operation.</dd>
+a <i>synchronizes-with</i> edge may be formed with a <code>release</code>
+operation. This is intended to model C++'s <code>memory_order_acquire</code>.</dd>
+<dt><code>release</code></dt>
+<dd>In addition to the guarantees of <code>monotonic</code>, if this operation
+writes a value which is subsequently read by an <code>acquire</code> operation,
+it <i>synchronizes-with</i> that operation. (This isn't a complete
+description; see the C++0x definition of a release sequence.) This corresponds
+to the C++0x/C1x <code>memory_order_release</code>.</dd>
<dt><code>acq_rel</code> (acquire+release)</dt><dd>Acts as both an
-<code>acquire</code> and <code>release</code> operation on its address.</dd>
+<code>acquire</code> and <code>release</code> operation on its address.
+This corresponds to the C++0x/C1x <code>memory_order_acq_rel</code>.</dd>
<dt><code>seq_cst</code> (sequentially consistent)</dt><dd>
<dd>In addition to the guarantees of <code>acq_rel</code>
(<code>acquire</code> for an operation which only reads, <code>release</code>
sequentially-consistent operations on all addresses, which is consistent with
the <i>happens-before</i> partial order and with the modification orders of
all the affected addresses. Each sequentially-consistent read sees the last
-preceding write to the same address in this global order. This is intended
-to model C++'s sequentially-consistent atomic variables and Java's volatile
-shared variables.</dd>
+preceding write to the same address in this global order. This corresponds
+to the C++0x/C1x <code>memory_order_seq_cst</code> and Java volatile.</dd>
</dl>
<p id="singlethread">If an atomic operation is marked <code>singlethread</code>,
</tr>
<tr>
<td><a href="#t_floating">floating point</a></td>
- <td><tt>float, double, x86_fp80, fp128, ppc_fp128</tt></td>
+ <td><tt>half, float, double, x86_fp80, fp128, ppc_fp128</tt></td>
</tr>
<tr>
<td><a name="t_firstclass">first class</a></td>
<table>
<tbody>
<tr><th>Type</th><th>Description</th></tr>
+ <tr><td><tt>half</tt></td><td>16-bit floating point value</td></tr>
<tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
<tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
<tr><td><tt>fp128</tt></td><td>128-bit floating point value (112-bit mantissa)</td></tr>
possible to have a two dimensional array, using an array as the element type
of another array.</p>
-</div>
-
-
<!-- _______________________________________________________________________ -->
<h4>
<a name="t_aggregate">Aggregate Types</a>
<div>
<p>Aggregate Types are a subset of derived types that can contain multiple
- member types. <a href="#t_array">Arrays</a>,
- <a href="#t_struct">structs</a>, and <a href="#t_vector">vectors</a> are
- aggregate types.</p>
+ member types. <a href="#t_array">Arrays</a> and
+ <a href="#t_struct">structs</a> are aggregate types.
+ <a href="#t_vector">Vectors</a> are not considered to be aggregate types.</p>
</div>
alignment of the struct is one byte, and that there is no padding between
the elements. In non-packed structs, padding between field types is inserted
as defined by the TargetData string in the module, which is required to match
- what the underlying processor expects.</p>
+ what the underlying code generator expects.</p>
<p>Structures can either be "literal" or "identified". A literal structure is
defined inline with other types (e.g. <tt>{i32, i32}*</tt>) whereas identified
</pre>
<p>The number of elements is a constant integer value larger than 0; elementtype
- may be any integer or floating point type. Vectors of size zero are not
- allowed, and pointers are not allowed as the element type.</p>
+ may be any integer or floating point type, or a pointer to these types.
+ Vectors of size zero are not allowed. </p>
<h5>Examples:</h5>
<table class="layout">
<td class="left"><tt><2 x i64></tt></td>
<td class="left">Vector of 2 64-bit integer values.</td>
</tr>
+ <tr class="layout">
+ <td class="left"><tt><4 x i64*></tt></td>
+ <td class="left">Vector of 4 pointers to 64-bit integer values.</td>
+ </tr>
</table>
</div>
</div>
+</div>
+
<!-- *********************************************************************** -->
<h2><a name="constants">Constants</a></h2>
<!-- *********************************************************************** -->
represented in their IEEE hexadecimal format so that assembly and disassembly
do not cause any bits to change in the constants.</p>
-<p>When using the hexadecimal form, constants of types float and double are
+<p>When using the hexadecimal form, constants of types half, float, and double are
represented using the 16-digit form shown above (which matches the IEEE754
- representation for double); float values must, however, be exactly
- representable as IEE754 single precision. Hexadecimal format is always used
+ representation for double); half and float values must, however, be exactly
+ representable as IEE754 half and single precision, respectively.
+ Hexadecimal format is always used
for long double, and there are three forms of long double. The 80-bit format
used by x86 is represented as <tt>0xK</tt> followed by 20 hexadecimal digits.
The 128-bit format used by PowerPC (two adjacent doubles) is represented
by <tt>0xM</tt> followed by 32 hexadecimal digits. The IEEE 128-bit format
is represented by <tt>0xL</tt> followed by 32 hexadecimal digits; no
currently supported target uses this format. Long doubles will only work if
- they match the long double format on your target. All hexadecimal formats
- are big-endian (sign bit at the left).</p>
+ they match the long double format on your target. The IEEE 16-bit format
+ (half precision) is represented by <tt>0xH</tt> followed by 4 hexadecimal
+ digits. All hexadecimal formats are big-endian (sign bit at the left).</p>
<p>There are no constants of type x86mmx.</p>
</div>
<!-- ======================================================================= -->
<h3>
- <a name="trapvalues">Trap Values</a>
+ <a name="poisonvalues">Poison Values</a>
</h3>
<div>
-<p>Trap values are similar to <a href="#undefvalues">undef values</a>, however
- instead of representing an unspecified bit pattern, they represent the
- fact that an instruction or constant expression which cannot evoke side
- effects has nevertheless detected a condition which results in undefined
- behavior.</p>
+<p>Poison values are similar to <a href="#undefvalues">undef values</a>, however
+ they also represent the fact that an instruction or constant expression which
+ cannot evoke side effects has nevertheless detected a condition which results
+ in undefined behavior.</p>
-<p>There is currently no way of representing a trap value in the IR; they
+<p>There is currently no way of representing a poison value in the IR; they
only exist when produced by operations such as
<a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag.</p>
-<p>Trap value behavior is defined in terms of value <i>dependence</i>:</p>
+<p>Poison value behavior is defined in terms of value <i>dependence</i>:</p>
<ul>
<li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on
control back to them.</li>
<li><a href="#i_invoke"><tt>Invoke</tt></a> instructions depend on the
- <a href="#i_ret"><tt>ret</tt></a>, <a href="#i_unwind"><tt>unwind</tt></a>,
+ <a href="#i_ret"><tt>ret</tt></a>, <a href="#i_resume"><tt>resume</tt></a>,
or exception-throwing call instructions that dynamically transfer control
back to them.</li>
</ul>
-<p>Whenever a trap value is generated, all values which depend on it evaluate
- to trap. If they have side effects, the evoke their side effects as if each
- operand with a trap value were undef. If they have externally-visible side
- effects, the behavior is undefined.</p>
+<p>Poison Values have the same behavior as <a href="#undefvalues">undef values</a>,
+ with the additional affect that any instruction which has a <i>dependence</i>
+ on a poison value has undefined behavior.</p>
<p>Here are some examples:</p>
<pre class="doc_code">
entry:
- %trap = sub nuw i32 0, 1 ; Results in a trap value.
- %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
- %trap_yet_again = getelementptr i32* @h, i32 %still_trap
- store i32 0, i32* %trap_yet_again ; undefined behavior
+ %poison = sub nuw i32 0, 1 ; Results in a poison value.
+ %still_poison = and i32 %poison, 0 ; 0, but also poison.
+ %poison_yet_again = getelementptr i32* @h, i32 %still_poison
+ store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned
- store i32 %trap, i32* @g ; Trap value conceptually stored to memory.
- %trap2 = load i32* @g ; Returns a trap value, not just undef.
+ store i32 %poison, i32* @g ; Poison value stored to memory.
+ %poison2 = load i32* @g ; Poison value loaded back from memory.
- volatile store i32 %trap, i32* @g ; External observation; undefined behavior.
+ store volatile i32 %poison, i32* @g ; External observation; undefined behavior.
%narrowaddr = bitcast i32* @g to i16*
%wideaddr = bitcast i32* @g to i64*
- %trap3 = load i16* %narrowaddr ; Returns a trap value.
- %trap4 = load i64* %wideaddr ; Returns a trap value.
+ %poison3 = load i16* %narrowaddr ; Returns a poison value.
+ %poison4 = load i64* %wideaddr ; Returns a poison value.
- %cmp = icmp slt i32 %trap, 0 ; Returns a trap value.
- br i1 %cmp, label %true, label %end ; Branch to either destination.
+ %cmp = icmp slt i32 %poison, 0 ; Returns a poison value.
+ br i1 %cmp, label %true, label %end ; Branch to either destination.
true:
- volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so
- ; it has undefined behavior.
+ store volatile i32 0, i32* @g ; This is control-dependent on %cmp, so
+ ; it has undefined behavior.
br label %end
end:
%p = phi i32 [ 0, %entry ], [ 1, %true ]
- ; Both edges into this PHI are
- ; control-dependent on %cmp, so this
- ; always results in a trap value.
+ ; Both edges into this PHI are
+ ; control-dependent on %cmp, so this
+ ; always results in a poison value.
- volatile store i32 0, i32* @g ; This would depend on the store in %true
- ; if %cmp is true, or the store in %entry
- ; otherwise, so this is undefined behavior.
+ store volatile i32 0, i32* @g ; This would depend on the store in %true
+ ; if %cmp is true, or the store in %entry
+ ; otherwise, so this is undefined behavior.
br i1 %cmp, label %second_true, label %second_end
- ; The same branch again, but this time the
- ; true block doesn't have side effects.
+ ; The same branch again, but this time the
+ ; true block doesn't have side effects.
second_true:
; No side effects!
ret void
second_end:
- volatile store i32 0, i32* @g ; This time, the instruction always depends
- ; on the store in %end. Also, it is
- ; control-equivalent to %end, so this is
- ; well-defined (again, ignoring earlier
- ; undefined behavior in this example).
+ store volatile i32 0, i32* @g ; This time, the instruction always depends
+ ; on the store in %end. Also, it is
+ ; control-equivalent to %end, so this is
+ ; well-defined (ignoring earlier undefined
+ ; behavior in this example).
</pre>
</div>
<div>
<p>LLVM supports inline assembler expressions (as opposed
- to <a href="#moduleasm"> Module-Level Inline Assembly</a>) through the use of
+ to <a href="#moduleasm">Module-Level Inline Assembly</a>) through the use of
a special value. This value represents the inline assembler as a string
(containing the instructions to emit), a list of operand constraints (stored
as a string), a flag that indicates whether or not the inline asm
<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come
first.</p>
+<!--
<p>TODO: The format of the asm and constraints string still need to be
documented here. Constraints on what can be done (e.g. duplication, moving,
etc need to be documented). This is probably best done by reference to
another document that covers inline asm from a holistic perspective.</p>
+ -->
+<!-- _______________________________________________________________________ -->
<h4>
-<a name="inlineasm_md">Inline Asm Metadata</a>
+
<a name="inlineasm_md">Inline Asm Metadata</a>
</h4>
<div>
-<p>The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode
- attached to it that contains a list of constant integers. If present, the
- code generator will use the integer as the location cookie value when report
- errors through the LLVMContext error reporting mechanisms. This allows a
- front-end to correlate backend errors that occur with inline asm back to the
- source code that produced it. For example:</p>
+<p>The call instructions that wrap inline asm nodes may have a
+ "<tt>!srcloc</tt>" MDNode attached to it that contains a list of constant
+ integers. If present, the code generator will use the integer as the
+ location cookie value when report errors through the <tt>LLVMContext</tt>
+ error reporting mechanisms. This allows a front-end to correlate backend
+ errors that occur with inline asm back to the source code that produced it.
+ For example:</p>
<pre class="doc_code">
call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b>
</pre>
<p>It is up to the front-end to make sense of the magic numbers it places in the
- IR. If the MDNode contains multiple constants, the code generator will use
+ IR. If the MDNode contains multiple constants, the code generator will use
the one that corresponds to the line of the asm that the error occurs on.</p>
</div>
preceding exclamation point ('<tt>!</tt>').</p>
<p>A metadata string is a string surrounded by double quotes. It can contain
- any character by escaping non-printable characters with "\xx" where "xx" is
- the two digit hex code. For example: "<tt>!"test\00"</tt>".</p>
+ any character by escaping non-printable characters with "<tt>\xx</tt>" where
+ "<tt>xx</tt>" is the two digit hex code. For example:
+ "<tt>!"test\00"</tt>".</p>
<p>Metadata nodes are represented with notation similar to structure constants
(a comma separated list of elements, surrounded by braces and preceded by an
- exclamation point). For example: "<tt>!{ metadata !"test\00", i32
- 10}</tt>". Metadata nodes can have any values as their operand.</p>
+ exclamation point). Metadata nodes can have any values as their operand. For
+ example:</p>
+
+<div class="doc_code">
+<pre>
+!{ metadata !"test\00", i32 10}
+</pre>
+</div>
<p>A <a href="#namedmetadatastructure">named metadata</a> is a collection of
metadata nodes, which can be looked up in the module symbol table. For
- example: "<tt>!foo = metadata !{!4, !3}</tt>".
+ example:</p>
+
+<div class="doc_code">
+<pre>
+!foo = metadata !{!4, !3}
+</pre>
+</div>
<p>Metadata can be used as function arguments. Here <tt>llvm.dbg.value</tt>
- function is using two metadata arguments.</p>
+ function is using two metadata arguments:</p>
<div class="doc_code">
<pre>
</div>
<p>Metadata can be attached with an instruction. Here metadata <tt>!21</tt> is
- attached with <tt>add</tt> instruction using <tt>!dbg</tt> identifier.</p>
+ attached to the <tt>add</tt> instruction using the <tt>!dbg</tt>
+ identifier:</p>
<div class="doc_code">
<pre>
</pre>
</div>
+<p>More information about specific metadata nodes recognized by the optimizers
+ and code generator is found below.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="tbaa">'<tt>tbaa</tt>' Metadata</a>
+</h4>
+
+<div>
+
+<p>In LLVM IR, memory does not have types, so LLVM's own type system is not
+ suitable for doing TBAA. Instead, metadata is added to the IR to describe
+ a type system of a higher level language. This can be used to implement
+ typical C/C++ TBAA, but it can also be used to implement custom alias
+ analysis behavior for other languages.</p>
+
+<p>The current metadata format is very simple. TBAA metadata nodes have up to
+ three fields, e.g.:</p>
+
+<div class="doc_code">
+<pre>
+!0 = metadata !{ metadata !"an example type tree" }
+!1 = metadata !{ metadata !"int", metadata !0 }
+!2 = metadata !{ metadata !"float", metadata !0 }
+!3 = metadata !{ metadata !"const float", metadata !2, i64 1 }
+</pre>
+</div>
+
+<p>The first field is an identity field. It can be any value, usually
+ a metadata string, which uniquely identifies the type. The most important
+ name in the tree is the name of the root node. Two trees with
+ different root node names are entirely disjoint, even if they
+ have leaves with common names.</p>
+
+<p>The second field identifies the type's parent node in the tree, or
+ is null or omitted for a root node. A type is considered to alias
+ all of its descendants and all of its ancestors in the tree. Also,
+ a type is considered to alias all types in other trees, so that
+ bitcode produced from multiple front-ends is handled conservatively.</p>
+
+<p>If the third field is present, it's an integer which if equal to 1
+ indicates that the type is "constant" (meaning
+ <tt>pointsToConstantMemory</tt> should return true; see
+ <a href="AliasAnalysis.html#OtherItfs">other useful
+ <tt>AliasAnalysis</tt> methods</a>).</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="fpmath">'<tt>fpmath</tt>' Metadata</a>
+</h4>
+
+<div>
+
+<p><tt>fpmath</tt> metadata may be attached to any instruction of floating point
+ type. It can be used to express the maximum acceptable error in the result of
+ that instruction, in ULPs, thus potentially allowing the compiler to use a
+ more efficient but less accurate method of computing it. ULP is defined as
+ follows:</p>
+
+<blockquote>
+
+<p>If <tt>x</tt> is a real number that lies between two finite consecutive
+ floating-point numbers <tt>a</tt> and <tt>b</tt>, without being equal to one
+ of them, then <tt>ulp(x) = |b - a|</tt>, otherwise <tt>ulp(x)</tt> is the
+ distance between the two non-equal finite floating-point numbers nearest
+ <tt>x</tt>. Moreover, <tt>ulp(NaN)</tt> is <tt>NaN</tt>.</p>
+
+</blockquote>
+
+<p>The metadata node shall consist of a single positive floating point number
+ representing the maximum relative error, for example:</p>
+
+<div class="doc_code">
+<pre>
+!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
+</pre>
+</div>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="range">'<tt>range</tt>' Metadata</a>
+</h4>
+
+<div>
+<p><tt>range</tt> metadata may be attached only to loads of integer types. It
+ expresses the possible ranges the loaded value is in. The ranges are
+ represented with a flattened list of integers. The loaded value is known to
+ be in the union of the ranges defined by each consecutive pair. Each pair
+ has the following properties:</p>
+<ul>
+ <li>The type must match the type loaded by the instruction.</li>
+ <li>The pair <tt>a,b</tt> represents the range <tt>[a,b)</tt>.</li>
+ <li>Both <tt>a</tt> and <tt>b</tt> are constants.</li>
+ <li>The range is allowed to wrap.</li>
+ <li>The range should not represent the full or empty set. That is,
+ <tt>a!=b</tt>. </li>
+</ul>
+<p> In addition, the pairs must be in signed order of the lower bound and
+ they must be non-contiguous.</p>
+
+<p>Examples:</p>
+<div class="doc_code">
+<pre>
+ %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1
+ %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
+ %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5
+ %d = load i8* %z, align 1, !range !3 ; Can only be -2, -1, 3, 4 or 5
+...
+!0 = metadata !{ i8 0, i8 2 }
+!1 = metadata !{ i8 255, i8 2 }
+!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 }
+!3 = metadata !{ i8 -2, i8 0, i8 3, i8 6 }
+</pre>
+</div>
+</div>
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="module_flags">Module Flags Metadata</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Information about the module as a whole is difficult to convey to LLVM's
+ subsystems. The LLVM IR isn't sufficient to transmit this
+ information. The <tt>llvm.module.flags</tt> named metadata exists in order to
+ facilitate this. These flags are in the form of key / value pairs —
+ much like a dictionary — making it easy for any subsystem who cares
+ about a flag to look it up.</p>
+
+<p>The <tt>llvm.module.flags</tt> metadata contains a list of metadata
+ triplets. Each triplet has the following form:</p>
+
+<ul>
+ <li>The first element is a <i>behavior</i> flag, which specifies the behavior
+ when two (or more) modules are merged together, and it encounters two (or
+ more) metadata with the same ID. The supported behaviors are described
+ below.</li>
+
+ <li>The second element is a metadata string that is a unique ID for the
+ metadata. How each ID is interpreted is documented below.</li>
+
+ <li>The third element is the value of the flag.</li>
+</ul>
+
+<p>When two (or more) modules are merged together, the resulting
+ <tt>llvm.module.flags</tt> metadata is the union of the
+ modules' <tt>llvm.module.flags</tt> metadata. The only exception being a flag
+ with the <i>Override</i> behavior, which may override another flag's value
+ (see below).</p>
+
+<p>The following behaviors are supported:</p>
+
+<table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr>
+ <th>Value</th>
+ <th>Behavior</th>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td align="left">
+ <dl>
+ <dt><b>Error</b></dt>
+ <dd>Emits an error if two values disagree. It is an error to have an ID
+ with both an Error and a Warning behavior.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td align="left">
+ <dl>
+ <dt><b>Warning</b></dt>
+ <dd>Emits a warning if two values disagree.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td align="left">
+ <dl>
+ <dt><b>Require</b></dt>
+ <dd>Emits an error when the specified value is not present or doesn't
+ have the specified value. It is an error for two (or more)
+ <tt>llvm.module.flags</tt> with the same ID to have the Require
+ behavior but different values. There may be multiple Require flags
+ per ID.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td align="left">
+ <dl>
+ <dt><b>Override</b></dt>
+ <dd>Uses the specified value if the two values disagree. It is an
+ error for two (or more) <tt>llvm.module.flags</tt> with the same
+ ID to have the Override behavior but different values.</dd>
+ </dl>
+ </td>
+ </tr>
+ </tbody>
+</table>
+
+<p>An example of module flags:</p>
+
+<pre class="doc_code">
+!0 = metadata !{ i32 1, metadata !"foo", i32 1 }
+!1 = metadata !{ i32 4, metadata !"bar", i32 37 }
+!2 = metadata !{ i32 2, metadata !"qux", i32 42 }
+!3 = metadata !{ i32 3, metadata !"qux",
+ metadata !{
+ metadata !"foo", i32 1
+ }
+}
+!llvm.module.flags = !{ !0, !1, !2, !3 }
+</pre>
+
+<ul>
+ <li><p>Metadata <tt>!0</tt> has the ID <tt>!"foo"</tt> and the value '1'. The
+ behavior if two or more <tt>!"foo"</tt> flags are seen is to emit an
+ error if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!1</tt> has the ID <tt>!"bar"</tt> and the value '37'. The
+ behavior if two or more <tt>!"bar"</tt> flags are seen is to use the
+ value '37' if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!2</tt> has the ID <tt>!"qux"</tt> and the value '42'. The
+ behavior if two or more <tt>!"qux"</tt> flags are seen is to emit a
+ warning if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!3</tt> has the ID <tt>!"qux"</tt> and the value:</p>
+
+<pre class="doc_code">
+metadata !{ metadata !"foo", i32 1 }
+</pre>
+
+ <p>The behavior is to emit an error if the <tt>llvm.module.flags</tt> does
+ not contain a flag with the ID <tt>!"foo"</tt> that has the value
+ '1'. If two or more <tt>!"qux"</tt> flags exist, then they must have
+ the same value or an error will be issued.</p></li>
+</ul>
+
+
+<!-- ======================================================================= -->
+<h3>
+<a name="objc_gc_flags">Objective-C Garbage Collection Module Flags Metadata</a>
+</h3>
+
+<div>
+
+<p>On the Mach-O platform, Objective-C stores metadata about garbage collection
+ in a special section called "image info". The metadata consists of a version
+ number and a bitmask specifying what types of garbage collection are
+ supported (if any) by the file. If two or more modules are linked together
+ their garbage collection metadata needs to be merged rather than appended
+ together.</p>
+
+<p>The Objective-C garbage collection module flags metadata consists of the
+ following key-value pairs:</p>
+
+<table border="1" cellspacing="0" cellpadding="4">
+ <col width="30%">
+ <tbody>
+ <tr>
+ <th>Key</th>
+ <th>Value</th>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Version</tt></td>
+ <td align="left"><b>[Required]</b> — The Objective-C ABI
+ version. Valid values are 1 and 2.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Image Info Version</tt></td>
+ <td align="left"><b>[Required]</b> — The version of the image info
+ section. Currently always 0.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Image Info Section</tt></td>
+ <td align="left"><b>[Required]</b> — The section to place the
+ metadata. Valid values are <tt>"__OBJC, __image_info, regular"</tt> for
+ Objective-C ABI version 1, and <tt>"__DATA,__objc_imageinfo, regular,
+ no_dead_strip"</tt> for Objective-C ABI version 2.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Garbage Collection</tt></td>
+ <td align="left"><b>[Required]</b> — Specifies whether garbage
+ collection is supported or not. Valid values are 0, for no garbage
+ collection, and 2, for garbage collection supported.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C GC Only</tt></td>
+ <td align="left"><b>[Optional]</b> — Specifies that only garbage
+ collection is supported. If present, its value must be 6. This flag
+ requires that the <tt>Objective-C Garbage Collection</tt> flag have the
+ value 2.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Some important flag interactions:</p>
+
+<ul>
+ <li>If a module with <tt>Objective-C Garbage Collection</tt> set to 0 is
+ merged with a module with <tt>Objective-C Garbage Collection</tt> set to
+ 2, then the resulting module has the <tt>Objective-C Garbage
+ Collection</tt> flag set to 0.</li>
+
+ <li>A module with <tt>Objective-C Garbage Collection</tt> set to 0 cannot be
+ merged with a module with <tt>Objective-C GC Only</tt> set to 6.</li>
+</ul>
+
</div>
</div>
pointers to global variables and functions which may optionally have a pointer
cast formed of bitcast or getelementptr. For example, a legal use of it is:</p>
+<div class="doc_code">
<pre>
- @X = global i8 4
- @Y = global i32 123
+@X = global i8 4
+@Y = global i32 123
- @llvm.used = appending global [2 x i8*] [
- i8* @X,
- i8* bitcast (i32* @Y to i8*)
- ], section "llvm.metadata"
+@llvm.used = appending global [2 x i8*] [
+ i8* @X,
+ i8* bitcast (i32* @Y to i8*)
+], section "llvm.metadata"
</pre>
+</div>
<p>If a global variable appears in the <tt>@llvm.used</tt> list, then the
-compiler, assembler, and linker are required to treat the symbol as if there is
-a reference to the global that it cannot see. For example, if a variable has
-internal linkage and no references other than that from the <tt>@llvm.used</tt>
-list, it cannot be deleted. This is commonly used to represent references from
-inline asms and other things the compiler cannot "see", and corresponds to
-"attribute((used))" in GNU C.</p>
+ compiler, assembler, and linker are required to treat the symbol as if there
+ is a reference to the global that it cannot see. For example, if a variable
+ has internal linkage and no references other than that from
+ the <tt>@llvm.used</tt> list, it cannot be deleted. This is commonly used to
+ represent references from inline asms and other things the compiler cannot
+ "see", and corresponds to "<tt>attribute((used))</tt>" in GNU C.</p>
<p>On some targets, the code generator must emit a directive to the assembler or
-object file to prevent the assembler and linker from molesting the symbol.</p>
+ object file to prevent the assembler and linker from molesting the
+ symbol.</p>
</div>
<div>
<p>The <tt>@llvm.compiler.used</tt> directive is the same as the
-<tt>@llvm.used</tt> directive, except that it only prevents the compiler from
-touching the symbol. On targets that support it, this allows an intelligent
-linker to optimize references to the symbol without being impeded as it would be
-by <tt>@llvm.used</tt>.</p>
+ <tt>@llvm.used</tt> directive, except that it only prevents the compiler from
+ touching the symbol. On targets that support it, this allows an intelligent
+ linker to optimize references to the symbol without being impeded as it would
+ be by <tt>@llvm.used</tt>.</p>
<p>This is a rare construct that should only be used in rare circumstances, and
-should not be exposed to source languages.</p>
+ should not be exposed to source languages.</p>
</div>
</h3>
<div>
+
+<div class="doc_code">
<pre>
%0 = type { i32, void ()* }
@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
</pre>
-<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined.
-</p>
+</div>
+
+<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor
+ functions and associated priorities. The functions referenced by this array
+ will be called in ascending order of priority (i.e. lowest first) when the
+ module is loaded. The order of functions with the same priority is not
+ defined.</p>
</div>
</h3>
<div>
+
+<div class="doc_code">
<pre>
%0 = type { i32, void ()* }
@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
</pre>
+</div>
-<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined.
-</p>
+<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions
+ and associated priorities. The functions referenced by this array will be
+ called in descending order of priority (i.e. highest first) when the module
+ is loaded. The order of functions with the same priority is not defined.</p>
</div>
'<a href="#i_switch"><tt>switch</tt></a>',
'<a href="#i_indirectbr"><tt>indirectbr</tt></a>',
'<a href="#i_invoke"><tt>invoke</tt></a>',
- '<a href="#i_unwind"><tt>unwind</tt></a>',
'<a href="#i_resume"><tt>resume</tt></a>', and
'<a href="#i_unreachable"><tt>unreachable</tt></a>'.</p>
'<tt>normal</tt>' label or the '<tt>exception</tt>' label. If the callee
function returns with the "<tt><a href="#i_ret">ret</a></tt>" instruction,
control flow will return to the "normal" label. If the callee (or any
- indirect callees) returns with the "<a href="#i_unwind"><tt>unwind</tt></a>"
- instruction, control is interrupted and continued at the dynamically nearest
- "exception" label.</p>
+ indirect callees) returns via the "<a href="#i_resume"><tt>resume</tt></a>"
+ instruction or other exception handling mechanism, control is interrupted and
+ continued at the dynamically nearest "exception" label.</p>
<p>The '<tt>exception</tt>' label is a
<i><a href="ExceptionHandling.html#overview">landing pad</a></i> for the
exception. As such, '<tt>exception</tt>' label is required to have the
"<a href="#i_landingpad"><tt>landingpad</tt></a>" instruction, which contains
- the information about about the behavior of the program after unwinding
+ the information about the behavior of the program after unwinding
happens, as its first non-PHI instruction. The restrictions on the
"<tt>landingpad</tt>" instruction's tightly couples it to the
"<tt>invoke</tt>" instruction, so that the important information contained
<li>'<tt>normal label</tt>': the label reached when the called function
executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li>
- <li>'<tt>exception label</tt>': the label reached when a callee returns with
- the <a href="#i_unwind"><tt>unwind</tt></a> instruction. </li>
+ <li>'<tt>exception label</tt>': the label reached when a callee returns via
+ the <a href="#i_resume"><tt>resume</tt></a> instruction or other exception
+ handling mechanism.</li>
<li>The optional <a href="#fnattrs">function attributes</a> list. Only
'<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and
block to the "normal" label. If the callee unwinds then no return value is
available.</p>
-<p>Note that the code generator does not yet completely support unwind, and
-that the invoke/unwind semantics are likely to change in future versions.</p>
-
<h5>Example:</h5>
<pre>
%retval = invoke i32 @Test(i32 15) to label %Continue
unwind label %TestCleanup <i>; {i32}:retval set</i>
</pre>
-</div>
-
-<!-- _______________________________________________________________________ -->
-
-<h4>
- <a name="i_unwind">'<tt>unwind</tt>' Instruction</a>
-</h4>
-
-<div>
-
-<h5>Syntax:</h5>
-<pre>
- unwind
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow
- at the first callee in the dynamic call stack which used
- an <a href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call.
- This is primarily used to implement exception handling.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>unwind</tt>' instruction causes execution of the current function to
- immediately halt. The dynamic call stack is then searched for the
- first <a href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack.
- Once found, execution continues at the "exceptional" destination block
- specified by the <tt>invoke</tt> instruction. If there is no <tt>invoke</tt>
- instruction in the dynamic call chain, undefined behavior results.</p>
-
-<p>Note that the code generator does not yet completely support unwind, and
-that the invoke/unwind semantics are likely to change in future versions.</p>
-
</div>
<!-- _______________________________________________________________________ -->
<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
<tt>nsw</tt> keywords are present, the result value of the <tt>add</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
+ is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow,
respectively, occurs.</p>
<h5>Example:</h5>
<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
<tt>nsw</tt> keywords are present, the result value of the <tt>sub</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
+ is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow,
respectively, occurs.</p>
<h5>Example:</h5>
<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
<tt>nsw</tt> keywords are present, the result value of the <tt>mul</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
+ is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow,
respectively, occurs.</p>
<h5>Example:</h5>
<p>Division by zero leads to undefined behavior.</p>
<p>If the <tt>exact</tt> keyword is present, the result value of the
- <tt>udiv</tt> is a <a href="#trapvalues">trap value</a> if %op1 is not a
+ <tt>udiv</tt> is a <a href="#poisonvalues">poison value</a> if %op1 is not a
multiple of %op2 (as such, "((a udiv exact b) mul b) == a").</p>
a 32-bit division of -2147483648 by -1.</p>
<p>If the <tt>exact</tt> keyword is present, the result value of the
- <tt>sdiv</tt> is a <a href="#trapvalues">trap value</a> if the result would
+ <tt>sdiv</tt> is a <a href="#poisonvalues">poison value</a> if the result would
be rounded.</p>
<h5>Example:</h5>
shift amount in <tt>op2</tt>.</p>
<p>If the <tt>nuw</tt> keyword is present, then the shift produces a
- <a href="#trapvalues">trap value</a> if it shifts out any non-zero bits. If
+ <a href="#poisonvalues">poison value</a> if it shifts out any non-zero bits. If
the <tt>nsw</tt> keyword is present, then the shift produces a
- <a href="#trapvalues">trap value</a> if it shifts out any bits that disagree
+ <a href="#poisonvalues">poison value</a> if it shifts out any bits that disagree
with the resultant sign bit. As such, NUW/NSW have the same semantics as
they would if the shift were expressed as a mul instruction with the same
nsw/nuw bits in (mul %op1, (shl 1, %op2)).</p>
shift amount in <tt>op2</tt>.</p>
<p>If the <tt>exact</tt> keyword is present, the result value of the
- <tt>lshr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits
+ <tt>lshr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits
shifted out are non-zero.</p>
the corresponding shift amount in <tt>op2</tt>.</p>
<p>If the <tt>exact</tt> keyword is present, the result value of the
- <tt>ashr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits
+ <tt>ashr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits
shifted out are non-zero.</p>
<h5>Example:</h5>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
+ <th>In0</th>
+ <th>In1</th>
+ <th>Out</th>
</tr>
<tr>
<td>0</td>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
+ <th>In0</th>
+ <th>In1</th>
+ <th>Out</th>
</tr>
<tr>
<td>0</td>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
+ <th>In0</th>
+ <th>In1</th>
+ <th>Out</th>
</tr>
<tr>
<td>0</td>
<h5>Arguments:</h5>
<p>The first two operands of a '<tt>shufflevector</tt>' instruction are vectors
- with types that match each other. The third argument is a shuffle mask whose
+ with the same type. The third argument is a shuffle mask whose
element type is always 'i32'. The result of the instruction is a vector
whose length is the same as the shuffle mask and whose element type is the
same as the element type of the first two operands.</p>
'<tt>alloca</tt>' instruction is commonly used to represent automatic
variables that must have an address available. When the function returns
(either with the <tt><a href="#i_ret">ret</a></tt>
- or <tt><a href="#i_unwind">unwind</a></tt> instructions), the memory is
- reclaimed. Allocating zero bytes is legal, but the result is undefined.</p>
+ or <tt><a href="#i_resume">resume</a></tt> instructions), the memory is
+ reclaimed. Allocating zero bytes is legal, but the result is undefined.
+ The order in which memory is allocated (ie., which way the stack grows) is
+ not specified.</p>
+
+<p>
<h5>Example:</h5>
<pre>
<h5>Syntax:</h5>
<pre>
- <result> = [volatile] load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
- <result> = atomic [volatile] load <ty>* <pointer> [singlethread] <ordering>, align <alignment>
+ <result> = load [volatile] <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>]
+ <result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment>
!<index> = !{ i32 1 }
</pre>
The code generator may select special instructions to save cache bandwidth,
such as the <tt>MOVNT</tt> instruction on x86.</p>
+<p>The optional <tt>!invariant.load</tt> metadata must reference a single
+ metatadata name <index> corresponding to a metadata node with no
+ entries. The existence of the <tt>!invariant.load</tt> metatadata on the
+ instruction tells the optimizer and code generator that this load address
+ points to memory which does not change value during program execution.
+ The optimizer may then move this load around, for example, by hoisting it
+ out of loops using loop invariant code motion.</p>
+
<h5>Semantics:</h5>
<p>The location of memory pointed to is loaded. If the value being loaded is of
scalar type then the number of bytes read does not exceed the minimum number
<h5>Syntax:</h5>
<pre>
- [volatile] store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
- atomic [volatile] store <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i>
+ store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
+ store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- [volatile] cmpxchg <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i>
+ cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i>
</pre>
<h5>Overview:</h5>
<h5>Example:</h5>
<pre>
entry:
- %orig = atomic <a href="#i_load">load</a> i32* %ptr unordered <i>; yields {i32}</i>
+ %orig = atomic <a href="#i_load">load</a> i32* %ptr unordered <i>; yields {i32}</i>
<a href="#i_br">br</a> label %loop
loop:
%cmp = <a href="#i_phi">phi</a> i32 [ %orig, %entry ], [%old, %loop]
%squared = <a href="#i_mul">mul</a> i32 %cmp, %cmp
- %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared <i>; yields {i32}</i>
+ %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared <i>; yields {i32}</i>
%success = <a href="#i_icmp">icmp</a> eq i32 %cmp, %old
<a href="#i_br">br</a> i1 %success, label %done, label %loop
<h5>Syntax:</h5>
<pre>
- [volatile] atomicrmw <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> <i>; yields {ty}</i>
+ atomicrmw [volatile] <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> <i>; yields {ty}</i>
</pre>
<h5>Overview:</h5>
<pre>
<result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
<result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}*
+ <result> = getelementptr <ptr vector> ptrval, <vector index type> idx
</pre>
<h5>Overview:</h5>
It performs address calculation only and does not access memory.</p>
<h5>Arguments:</h5>
-<p>The first argument is always a pointer, and forms the basis of the
+<p>The first argument is always a pointer or a vector of pointers,
+ and forms the basis of the
calculation. The remaining arguments are indices that indicate which of the
elements of the aggregate object are indexed. The interpretation of each
index is dependent on the type being indexed into. The first index always
When indexing into a (optionally packed) structure, only <tt>i32</tt>
integer <b>constants</b> are allowed. When indexing into an array, pointer
or vector, integers of any width are allowed, and they are not required to be
- constant.</p>
+ constant. These integers are treated as signed values where relevant.</p>
<p>For example, let's consider a C code fragment and how it gets compiled to
LLVM:</p>
}
</pre>
-<p>The LLVM code generated by the GCC frontend is:</p>
+<p>The LLVM code generated by Clang is:</p>
<pre class="doc_code">
-%RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 }
-%ST = <a href="#namedtypes">type</a> { i32, double, %RT }
+%struct.RT = <a href="#namedtypes">type</a> { i8, [10 x [20 x i32]], i8 }
+%struct.ST = <a href="#namedtypes">type</a> { i32, double, %struct.RT }
-define i32* @foo(%ST* %s) {
+define i32* @foo(%struct.ST* %s) nounwind uwtable readnone optsize ssp {
entry:
- %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
- ret i32* %reg
+ %arrayidx = getelementptr inbounds %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13
+ ret i32* %arrayidx
}
</pre>
<h5>Semantics:</h5>
-<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
- type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT
- }</tt>' type, a structure. The second index indexes into the third element
- of the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]],
- i8 }</tt>' type, another structure. The third index indexes into the second
- element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an
- array. The two dimensions of the array are subscripted into, yielding an
- '<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a
- pointer to this element, thus computing a value of '<tt>i32*</tt>' type.</p>
+<p>In the example above, the first index is indexing into the
+ '<tt>%struct.ST*</tt>' type, which is a pointer, yielding a
+ '<tt>%struct.ST</tt>' = '<tt>{ i32, double, %struct.RT }</tt>' type, a
+ structure. The second index indexes into the third element of the structure,
+ yielding a '<tt>%struct.RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]], i8 }</tt>'
+ type, another structure. The third index indexes into the second element of
+ the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an array. The
+ two dimensions of the array are subscripted into, yielding an '<tt>i32</tt>'
+ type. The '<tt>getelementptr</tt>' instruction returns a pointer to this
+ element, thus computing a value of '<tt>i32*</tt>' type.</p>
<p>Note that it is perfectly legal to index partially through a structure,
returning a pointer to an inner element. Because of this, the LLVM code for
the given testcase is equivalent to:</p>
-<pre>
- define i32* @foo(%ST* %s) {
- %t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i>
- %t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i>
- %t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i>
- %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i>
- %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i>
- ret i32* %t5
- }
+<pre class="doc_code">
+define i32* @foo(%struct.ST* %s) {
+ %t1 = getelementptr %struct.ST* %s, i32 1 <i>; yields %struct.ST*:%t1</i>
+ %t2 = getelementptr %struct.ST* %t1, i32 0, i32 2 <i>; yields %struct.RT*:%t2</i>
+ %t3 = getelementptr %struct.RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i>
+ %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i>
+ %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i>
+ ret i32* %t5
+}
</pre>
<p>If the <tt>inbounds</tt> keyword is present, the result value of the
- <tt>getelementptr</tt> is a <a href="#trapvalues">trap value</a> if the
+ <tt>getelementptr</tt> is a <a href="#poisonvalues">poison value</a> if the
base pointer is not an <i>in bounds</i> address of an allocated object,
or if any of the addresses that would be formed by successive addition of
the offsets implied by the indices to the base address with infinitely
- precise arithmetic are not an <i>in bounds</i> address of that allocated
- object. The <i>in bounds</i> addresses for an allocated object are all
- the addresses that point into the object, plus the address one byte past
- the end.</p>
+ precise signed arithmetic are not an <i>in bounds</i> address of that
+ allocated object. The <i>in bounds</i> addresses for an allocated object
+ are all the addresses that point into the object, plus the address one
+ byte past the end.
+ In cases where the base is a vector of pointers the <tt>inbounds</tt> keyword
+ applies to each of the computations element-wise. </p>
<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to
- the base address with silently-wrapping two's complement arithmetic, and
- the result value of the <tt>getelementptr</tt> may be outside the object
- pointed to by the base pointer. The result value may not necessarily be
- used to access memory though, even if it happens to point into allocated
- storage. See the <a href="#pointeraliasing">Pointer Aliasing Rules</a>
- section for more information.</p>
+ the base address with silently-wrapping two's complement arithmetic. If the
+ offsets have a different width from the pointer, they are sign-extended or
+ truncated to the width of the pointer. The result value of the
+ <tt>getelementptr</tt> may be outside the object pointed to by the base
+ pointer. The result value may not necessarily be used to access memory
+ though, even if it happens to point into allocated storage. See the
+ <a href="#pointeraliasing">Pointer Aliasing Rules</a> section for more
+ information.</p>
<p>The getelementptr instruction is often confusing. For some more insight into
how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p>
%iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
</pre>
+<p>In cases where the pointer argument is a vector of pointers, only a
+ single index may be used, and the number of vector elements has to be
+ the same. For example: </p>
+<pre class="doc_code">
+ %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets,
+</pre>
+
</div>
</div>
</pre>
<h5>Overview:</h5>
-<p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to
- the integer type <tt>ty2</tt>.</p>
+<p>The '<tt>ptrtoint</tt>' instruction converts the pointer or a vector of
+ pointers <tt>value</tt> to
+ the integer (or vector of integers) type <tt>ty2</tt>.</p>
<h5>Arguments:</h5>
<p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which
- must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to
- <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type.</p>
+ must be a a value of type <a href="#t_pointer">pointer</a> or a vector of
+ pointers, and a type to cast it to
+ <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> or a vector
+ of integers type.</p>
<h5>Semantics:</h5>
<p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type
<h5>Example:</h5>
<pre>
- %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i>
- %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i>
+ %X = ptrtoint i32* %P to i8 <i>; yields truncation on 32-bit architecture</i>
+ %Y = ptrtoint i32* %P to i64 <i>; yields zero extension on 32-bit architecture</i>
+ %Z = ptrtoint <4 x i32*> %P to <4 x i64><i>; yields vector zero extension for a vector of addresses on 32-bit architecture</i>
</pre>
</div>
%X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
%Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
%Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
+ %Z = inttoptr <4 x i32> %G to <4 x i8*><i>; yields truncation of vector G to four pointers</i>
</pre>
</div>
<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
<tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with
this conversion. The conversion is done as if the <tt>value</tt> had been
- stored to memory and read back as type <tt>ty2</tt>. Pointer types may only
- be converted to other pointer types with this instruction. To convert
+ stored to memory and read back as type <tt>ty2</tt>.
+ Pointer (or vector of pointers) types may only be converted to other pointer
+ (or vector of pointers) types with this instruction. To convert
pointers to other types, use the <a href="#i_inttoptr">inttoptr</a> or
<a href="#i_ptrtoint">ptrtoint</a> instructions first.</p>
<pre>
%X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
%Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
- %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
+ %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
+ %Z = bitcast <2 x i32*> %V to <2 x i64*> <i>; yields <2 x i64*></i>
</pre>
</div>
<h5>Overview:</h5>
<p>The '<tt>icmp</tt>' instruction returns a boolean value or a vector of
- boolean values based on comparison of its two integer, integer vector, or
- pointer operands.</p>
+ boolean values based on comparison of its two integer, integer vector,
+ pointer, or pointer vector operands.</p>
<h5>Arguments:</h5>
<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
%X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
</pre>
-<p>Note that the code generator does not yet support conditions
- with vector type.</p>
-
</div>
<!-- _______________________________________________________________________ -->
<h5>Syntax:</h5>
<pre>
- <resultval> = landingpad <somety> personality <type> <pers_fn> <clause>+
- <resultval> = landingpad <somety> personality <type> <pers_fn> cleanup <clause>*
+ <resultval> = landingpad <resultty> personality <type> <pers_fn> <clause>+
+ <resultval> = landingpad <resultty> personality <type> <pers_fn> cleanup <clause>*
<clause> := catch <type> <value>
<clause> := filter <array constant type> <array constant>
<i><tt>catch</tt></i> portion of a <i><tt>try/catch</tt></i> sequence. It
defines values supplied by the personality function (<tt>pers_fn</tt>) upon
re-entry to the function. The <tt>resultval</tt> has the
- type <tt>somety</tt>.</p>
+ type <tt>resultty</tt>.</p>
<h5>Arguments:</h5>
<p>This instruction takes a <tt>pers_fn</tt> value. This is the personality
<p>The clauses are applied in order from top to bottom. If two
<tt>landingpad</tt> instructions are merged together through inlining, the
- clauses from the calling function are appended to the list of clauses.</p>
+ clauses from the calling function are appended to the list of clauses.
+ When the call stack is being unwound due to an exception being thrown, the
+ exception is compared against each <tt>clause</tt> in turn. If it doesn't
+ match any of the clauses, and the <tt>cleanup</tt> flag is not set, then
+ unwinding continues further up the call stack.</p>
<p>The <tt>landingpad</tt> instruction has several restrictions:</p>
</div>
-</div>
-
<!-- ======================================================================= -->
<h3>
<a name="int_gc">Accurate Garbage Collection Intrinsics</a>
</div>
-</div>
-
<!-- _______________________________________________________________________ -->
<h4>
<a name="int_exp">'<tt>llvm.exp.*</tt>' Intrinsic</a>
<p>This function returns the same values as the libm <tt>log</tt> functions
would, and handles error conditions in the same way.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
<h4>
<a name="int_fma">'<tt>llvm.fma.*</tt>' Intrinsic</a>
</h4>
</div>
-<!-- ======================================================================= -->
-<h3>
- <a name="int_manip">Bit Manipulation Intrinsics</a>
-</h3>
-
-<div>
-
-<p>LLVM provides intrinsics for a few important bit manipulation operations.
- These allow efficient code generation for some algorithms.</p>
-
<!-- _______________________________________________________________________ -->
<h4>
- <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a>
+ <a name="int_fabs">'<tt>llvm.fabs.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.fabs</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.fabs.f32(float %Val)
+ declare double @llvm.fabs.f64(double %Val)
+ declare x86_fp80 @llvm.fabs.f80(x86_fp80 %Val)
+ declare fp128 @llvm.fabs.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.fabs.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.fabs.*</tt>' intrinsics return the absolute value of
+ the operand.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>fabs</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="int_manip">Bit Manipulation Intrinsics</a>
+</h3>
+
+<div>
+
+<p>LLVM provides intrinsics for a few important bit manipulation operations.
+ These allow efficient code generation for some algorithms.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a>
</h4>
<div>
targets support all bit widths or vector types, however.</p>
<pre>
- declare i8 @llvm.ctlz.i8 (i8 <src>)
- declare i16 @llvm.ctlz.i16(i16 <src>)
- declare i32 @llvm.ctlz.i32(i32 <src>)
- declare i64 @llvm.ctlz.i64(i64 <src>)
- declare i256 @llvm.ctlz.i256(i256 <src>)
- declare <2 x i32> @llvm.ctlz.v2i32(<2 x i32> <src;gt)
+ declare i8 @llvm.ctlz.i8 (i8 <src>, i1 <is_zero_undef>)
+ declare i16 @llvm.ctlz.i16 (i16 <src>, i1 <is_zero_undef>)
+ declare i32 @llvm.ctlz.i32 (i32 <src>, i1 <is_zero_undef>)
+ declare i64 @llvm.ctlz.i64 (i64 <src>, i1 <is_zero_undef>)
+ declare i256 @llvm.ctlz.i256(i256 <src>, i1 <is_zero_undef>)
+ declase <2 x i32> @llvm.ctlz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>)
</pre>
<h5>Overview:</h5>
leading zeros in a variable.</p>
<h5>Arguments:</h5>
-<p>The only argument is the value to be counted. The argument may be of any
- integer type, or any vector type with integer element type.
- The return type must match the argument type.</p>
+<p>The first argument is the value to be counted. This argument may be of any
+ integer type, or a vectory with integer element type. The return type
+ must match the first argument type.</p>
+
+<p>The second argument must be a constant and is a flag to indicate whether the
+ intrinsic should ensure that a zero as the first argument produces a defined
+ result. Historically some architectures did not provide a defined result for
+ zero values as efficiently, and many algorithms are now predicated on
+ avoiding zero-value inputs.</p>
<h5>Semantics:</h5>
<p>The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant)
- zeros in a variable, or within each element of the vector if the operation
- is of vector type. If the src == 0 then the result is the size in bits of
- the type of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p>
+ zeros in a variable, or within each element of the vector.
+ If <tt>src == 0</tt> then the result is the size in bits of the type of
+ <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise.
+ For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p>
</div>
support all bit widths or vector types, however.</p>
<pre>
- declare i8 @llvm.cttz.i8 (i8 <src>)
- declare i16 @llvm.cttz.i16(i16 <src>)
- declare i32 @llvm.cttz.i32(i32 <src>)
- declare i64 @llvm.cttz.i64(i64 <src>)
- declare i256 @llvm.cttz.i256(i256 <src>)
- declase <2 x i32> @llvm.cttz.v2i32(<2 x i32> <src>)
+ declare i8 @llvm.cttz.i8 (i8 <src>, i1 <is_zero_undef>)
+ declare i16 @llvm.cttz.i16 (i16 <src>, i1 <is_zero_undef>)
+ declare i32 @llvm.cttz.i32 (i32 <src>, i1 <is_zero_undef>)
+ declare i64 @llvm.cttz.i64 (i64 <src>, i1 <is_zero_undef>)
+ declare i256 @llvm.cttz.i256(i256 <src>, i1 <is_zero_undef>)
+ declase <2 x i32> @llvm.cttz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>)
</pre>
<h5>Overview:</h5>
trailing zeros.</p>
<h5>Arguments:</h5>
-<p>The only argument is the value to be counted. The argument may be of any
- integer type, or a vectory with integer element type.. The return type
- must match the argument type.</p>
+<p>The first argument is the value to be counted. This argument may be of any
+ integer type, or a vectory with integer element type. The return type
+ must match the first argument type.</p>
+
+<p>The second argument must be a constant and is a flag to indicate whether the
+ intrinsic should ensure that a zero as the first argument produces a defined
+ result. Historically some architectures did not provide a defined result for
+ zero values as efficiently, and many algorithms are now predicated on
+ avoiding zero-value inputs.</p>
<h5>Semantics:</h5>
<p>The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant)
zeros in a variable, or within each element of a vector.
- If the src == 0 then the result is the size in bits of
- the type of src. For example, <tt>llvm.cttz(2) = 1</tt>.</p>
+ If <tt>src == 0</tt> then the result is the size in bits of the type of
+ <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise.
+ For example, <tt>llvm.cttz(2) = 1</tt>.</p>
</div>
</div>
+<!-- ======================================================================= -->
+<h3>
+ <a name="spec_arithmetic">Specialised Arithmetic Intrinsics</a>
+</h3>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="fmuladd">'<tt>llvm.fmuladd.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare float @llvm.fmuladd.f32(float %a, float %b, float %c)
+ declare double @llvm.fmuladd.f64(double %a, double %b, double %c)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.fmuladd.*</tt>' intrinsic functions represent multiply-add
+expressions that can be fused if the code generator determines that the fused
+expression would be legal and efficient.</p>
+
+<h5>Arguments:</h5>
+<p>The '<tt>llvm.fmuladd.*</tt>' intrinsics each take three arguments: two
+multiplicands, a and b, and an addend c.</p>
+
+<h5>Semantics:</h5>
+<p>The expression:</p>
+<pre>
+ %0 = call float @llvm.fmuladd.f32(%a, %b, %c)
+</pre>
+<p>is equivalent to the expression a * b + c, except that rounding will not be
+performed between the multiplication and addition steps if the code generator
+fuses the operations. Fusion is not guaranteed, even if the target platform
+supports it. If a fused multiply-add is required the corresponding llvm.fma.*
+intrinsic function should be used instead.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %r2 = call float @llvm.fmuladd.f32(float %a, float %b, float %c) ; yields {float}:r2 = (a * b) + c
+</pre>
+
+</div>
+
<!-- ======================================================================= -->
<h3>
<a name="int_fp16">Half Precision Floating Point Intrinsics</a>
<div>
-<p>Half precision floating point is a storage-only format. This means that it is
+<p>For most target platforms, half precision floating point is a storage-only
+ format. This means that it is
a dense encoding (in memory) but does not support computation in the
format.</p>
<!-- ======================================================================= -->
<h3>
- <a name="int_trampoline">Trampoline Intrinsic</a>
+ <a name="int_trampoline">Trampoline Intrinsics</a>
</h3>
<div>
-<p>This intrinsic makes it possible to excise one parameter, marked with
+<p>These intrinsics make it possible to excise one parameter, marked with
the <a href="#nest"><tt>nest</tt></a> attribute, from a function.
The result is a callable
function pointer lacking the nest parameter - the caller does not need to
<pre class="doc_code">
%tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
%tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
- %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval)
+ call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval)
+ %p = call i8* @llvm.adjust.trampoline(i8* %tramp1)
%fp = bitcast i8* %p to i32 (i32, i32)*
</pre>
<h5>Syntax:</h5>
<pre>
- declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
+ declare void @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
</pre>
<h5>Overview:</h5>
-<p>This fills the memory pointed to by <tt>tramp</tt> with code and returns a
- function pointer suitable for executing it.</p>
+<p>This fills the memory pointed to by <tt>tramp</tt> with executable code,
+ turning it into a trampoline.</p>
<h5>Arguments:</h5>
<p>The <tt>llvm.init.trampoline</tt> intrinsic takes three arguments, all
<h5>Semantics:</h5>
<p>The block of memory pointed to by <tt>tramp</tt> is filled with target
- dependent code, turning it into a function. A pointer to this function is
- returned, but needs to be bitcast to an <a href="#int_trampoline">appropriate
- function pointer type</a> before being called. The new function's signature
- is the same as that of <tt>func</tt> with any arguments marked with
- the <tt>nest</tt> attribute removed. At most one such <tt>nest</tt> argument
- is allowed, and it must be of pointer type. Calling the new function is
- equivalent to calling <tt>func</tt> with the same argument list, but
- with <tt>nval</tt> used for the missing <tt>nest</tt> argument. If, after
- calling <tt>llvm.init.trampoline</tt>, the memory pointed to
- by <tt>tramp</tt> is modified, then the effect of any later call to the
- returned function pointer is undefined.</p>
-
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<h3>
- <a name="int_atomics">Atomic Operations and Synchronization Intrinsics</a>
-</h3>
-
-<div>
-
-<p>These intrinsic functions expand the "universal IR" of LLVM to represent
- hardware constructs for atomic operations and memory synchronization. This
- provides an interface to the hardware, not an interface to the programmer. It
- is aimed at a low enough level to allow any programming models or APIs
- (Application Programming Interfaces) which need atomic behaviors to map
- cleanly onto it. It is also modeled primarily on hardware behavior. Just as
- hardware provides a "universal IR" for source languages, it also provides a
- starting point for developing a "universal" atomic operation and
- synchronization IR.</p>
-
-<p>These do <em>not</em> form an API such as high-level threading libraries,
- software transaction memory systems, atomic primitives, and intrinsic
- functions as found in BSD, GNU libc, atomic_ops, APR, and other system and
- application libraries. The hardware interface provided by LLVM should allow
- a clean implementation of all of these APIs and parallel programming models.
- No one model or paradigm should be selected above others unless the hardware
- itself ubiquitously does so.</p>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_memory_barrier">'<tt>llvm.memory.barrier</tt>' Intrinsic</a>
-</h4>
-
-<div>
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The <tt>llvm.memory.barrier</tt> intrinsic guarantees ordering between
- specific pairs of memory access types.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.memory.barrier</tt> intrinsic requires five boolean arguments.
- The first four arguments enables a specific barrier as listed below. The
- fifth argument specifies that the barrier applies to io or device or uncached
- memory.</p>
-
-<ul>
- <li><tt>ll</tt>: load-load barrier</li>
- <li><tt>ls</tt>: load-store barrier</li>
- <li><tt>sl</tt>: store-load barrier</li>
- <li><tt>ss</tt>: store-store barrier</li>
- <li><tt>device</tt>: barrier applies to device and uncached memory also.</li>
-</ul>
-
-<h5>Semantics:</h5>
-<p>This intrinsic causes the system to enforce some ordering constraints upon
- the loads and stores of the program. This barrier does not
- indicate <em>when</em> any events will occur, it only enforces
- an <em>order</em> in which they occur. For any of the specified pairs of load
- and store operations (f.ex. load-load, or store-load), all of the first
- operations preceding the barrier will complete before any of the second
- operations succeeding the barrier begin. Specifically the semantics for each
- pairing is as follows:</p>
-
-<ul>
- <li><tt>ll</tt>: All loads before the barrier must complete before any load
- after the barrier begins.</li>
- <li><tt>ls</tt>: All loads before the barrier must complete before any
- store after the barrier begins.</li>
- <li><tt>ss</tt>: All stores before the barrier must complete before any
- store after the barrier begins.</li>
- <li><tt>sl</tt>: All stores before the barrier must complete before any
- load after the barrier begins.</li>
-</ul>
-
-<p>These semantics are applied with a logical "and" behavior when more than one
- is enabled in a single memory barrier intrinsic.</p>
-
-<p>Backends may implement stronger barriers than those requested when they do
- not support as fine grained a barrier as requested. Some architectures do
- not need all types of barriers and on such architectures, these become
- noops.</p>
-
-<h5>Example:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%result1 = load i32* %ptr <i>; yields {i32}:result1 = 4</i>
- call void @llvm.memory.barrier(i1 false, i1 true, i1 false, i1 false, i1 true)
- <i>; guarantee the above finishes</i>
- store i32 8, %ptr <i>; before this begins</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_atomic_cmp_swap">'<tt>llvm.atomic.cmp.swap.*</tt>' Intrinsic</a>
-</h4>
-
-<div>
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.cmp.swap</tt> on
- any integer bit width and for different address spaces. Not all targets
- support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.cmp.swap.i8.p0i8(i8* <ptr>, i8 <cmp>, i8 <val>)
- declare i16 @llvm.atomic.cmp.swap.i16.p0i16(i16* <ptr>, i16 <cmp>, i16 <val>)
- declare i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* <ptr>, i32 <cmp>, i32 <val>)
- declare i64 @llvm.atomic.cmp.swap.i64.p0i64(i64* <ptr>, i64 <cmp>, i64 <val>)
-</pre>
-
-<h5>Overview:</h5>
-<p>This loads a value in memory and compares it to a given value. If they are
- equal, it stores a new value into the memory.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.atomic.cmp.swap</tt> intrinsic takes three arguments. The result
- as well as both <tt>cmp</tt> and <tt>val</tt> must be integer values with the
- same bit width. The <tt>ptr</tt> argument must be a pointer to a value of
- this integer type. While any bit width integer may be used, targets may only
- lower representations they support in hardware.</p>
-
-<h5>Semantics:</h5>
-<p>This entire intrinsic must be executed atomically. It first loads the value
- in memory pointed to by <tt>ptr</tt> and compares it with the
- value <tt>cmp</tt>. If they are equal, <tt>val</tt> is stored into the
- memory. The loaded value is yielded in all cases. This provides the
- equivalent of an atomic compare-and-swap operation within the SSA
- framework.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 4, %val1)
- <i>; yields {i32}:result1 = 4</i>
-%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 5, %val2)
- <i>; yields {i32}:result2 = 8</i>
-%stored2 = icmp eq i32 %result2, 5 <i>; yields {i1}:stored2 = false</i>
-
-%memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 8</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_atomic_swap">'<tt>llvm.atomic.swap.*</tt>' Intrinsic</a>
-</h4>
-
-<div>
-<h5>Syntax:</h5>
-
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.swap</tt> on any
- integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.swap.i8.p0i8(i8* <ptr>, i8 <val>)
- declare i16 @llvm.atomic.swap.i16.p0i16(i16* <ptr>, i16 <val>)
- declare i32 @llvm.atomic.swap.i32.p0i32(i32* <ptr>, i32 <val>)
- declare i64 @llvm.atomic.swap.i64.p0i64(i64* <ptr>, i64 <val>)
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic loads the value stored in memory at <tt>ptr</tt> and yields
- the value from memory. It then stores the value in <tt>val</tt> in the memory
- at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.atomic.swap</tt> intrinsic takes two arguments. Both
- the <tt>val</tt> argument and the result must be integers of the same bit
- width. The first argument, <tt>ptr</tt>, must be a pointer to a value of this
- integer type. The targets may only lower integer representations they
- support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic loads the value pointed to by <tt>ptr</tt>, yields it, and
- stores <tt>val</tt> back into <tt>ptr</tt> atomically. This provides the
- equivalent of an atomic swap operation within the SSA framework.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val1)
- <i>; yields {i32}:result1 = 4</i>
-%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val2)
- <i>; yields {i32}:result2 = 8</i>
-
-%stored2 = icmp eq i32 %result2, 8 <i>; yields {i1}:stored2 = true</i>
-%memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 2</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_atomic_load_add">'<tt>llvm.atomic.load.add.*</tt>' Intrinsic</a>
-</h4>
-
-<div>
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.add</tt> on
- any integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.add.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.add.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.add.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.add.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic adds <tt>delta</tt> to the value stored in memory
- at <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic takes two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does a series of operations atomically. It first loads the
- value stored at <tt>ptr</tt>. It then adds <tt>delta</tt>, stores the result
- to <tt>ptr</tt>. It yields the original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-%result1 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 4)
- <i>; yields {i32}:result1 = 4</i>
-%result2 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 2)
- <i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 5)
- <i>; yields {i32}:result3 = 10</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 15</i>
-</pre>
-
+ dependent code, turning it into a function. Then <tt>tramp</tt> needs to be
+ passed to <a href="#int_at">llvm.adjust.trampoline</a> to get a pointer
+ which can be <a href="#int_trampoline">bitcast (to a new function) and
+ called</a>. The new function's signature is the same as that of
+ <tt>func</tt> with any arguments marked with the <tt>nest</tt> attribute
+ removed. At most one such <tt>nest</tt> argument is allowed, and it must be of
+ pointer type. Calling the new function is equivalent to calling <tt>func</tt>
+ with the same argument list, but with <tt>nval</tt> used for the missing
+ <tt>nest</tt> argument. If, after calling <tt>llvm.init.trampoline</tt>, the
+ memory pointed to by <tt>tramp</tt> is modified, then the effect of any later call
+ to the returned function pointer is undefined.</p>
</div>
<!-- _______________________________________________________________________ -->
<h4>
- <a name="int_atomic_load_sub">'<tt>llvm.atomic.load.sub.*</tt>' Intrinsic</a>
-</h4>
-
-<div>
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.sub</tt> on
- any integer bit width and for different address spaces. Not all targets
- support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.sub.i8.p0i32(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.sub.i16.p0i32(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.sub.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.sub.i64.p0i32(i64* <ptr>, i64 <delta>)
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic subtracts <tt>delta</tt> to the value stored in memory at
- <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic takes two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does a series of operations atomically. It first loads the
- value stored at <tt>ptr</tt>. It then subtracts <tt>delta</tt>, stores the
- result to <tt>ptr</tt>. It yields the original value stored
- at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 8, %ptr
-%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 4)
- <i>; yields {i32}:result1 = 8</i>
-%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 2)
- <i>; yields {i32}:result2 = 4</i>
-%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 5)
- <i>; yields {i32}:result3 = 2</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = -3</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_atomic_load_and">
- '<tt>llvm.atomic.load.and.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_nand">
- '<tt>llvm.atomic.load.nand.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_or">
- '<tt>llvm.atomic.load.or.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_xor">
- '<tt>llvm.atomic.load.xor.*</tt>' Intrinsic
+ <a name="int_at">
+ '<tt>llvm.adjust.trampoline</tt>' Intrinsic
</a>
</h4>
<div>
<h5>Syntax:</h5>
-<p>These are overloaded intrinsics. You can
- use <tt>llvm.atomic.load_and</tt>, <tt>llvm.atomic.load_nand</tt>,
- <tt>llvm.atomic.load_or</tt>, and <tt>llvm.atomic.load_xor</tt> on any integer
- bit width and for different address spaces. Not all targets support all bit
- widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.and.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.and.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.and.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.and.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.or.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.or.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.or.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.or.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
<pre>
- declare i8 @llvm.atomic.load.nand.i8.p0i32(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.nand.i16.p0i32(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.nand.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.nand.i64.p0i32(i64* <ptr>, i64 <delta>)
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.xor.i8.p0i32(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.xor.i16.p0i32(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.xor.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.xor.i64.p0i32(i64* <ptr>, i64 <delta>)
+ declare i8* @llvm.adjust.trampoline(i8* <tramp>)
</pre>
<h5>Overview:</h5>
-<p>These intrinsics bitwise the operation (and, nand, or, xor) <tt>delta</tt> to
- the value stored in memory at <tt>ptr</tt>. It yields the original value
- at <tt>ptr</tt>.</p>
+<p>This performs any required machine-specific adjustment to the address of a
+ trampoline (passed as <tt>tramp</tt>).</p>
<h5>Arguments:</h5>
-<p>These intrinsics take two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
+<p><tt>tramp</tt> must point to a block of memory which already has trampoline code
+ filled in by a previous call to <a href="#int_it"><tt>llvm.init.trampoline</tt>
+ </a>.</p>
<h5>Semantics:</h5>
-<p>These intrinsics does a series of operations atomically. They first load the
- value stored at <tt>ptr</tt>. They then do the bitwise
- operation <tt>delta</tt>, store the result to <tt>ptr</tt>. They yield the
- original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 0x0F0F, %ptr
-%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32(i32* %ptr, i32 0xFF)
- <i>; yields {i32}:result0 = 0x0F0F</i>
-%result1 = call i32 @llvm.atomic.load.and.i32.p0i32(i32* %ptr, i32 0xFF)
- <i>; yields {i32}:result1 = 0xFFFFFFF0</i>
-%result2 = call i32 @llvm.atomic.load.or.i32.p0i32(i32* %ptr, i32 0F)
- <i>; yields {i32}:result2 = 0xF0</i>
-%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32(i32* %ptr, i32 0F)
- <i>; yields {i32}:result3 = FF</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = F0</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<h4>
- <a name="int_atomic_load_max">
- '<tt>llvm.atomic.load.max.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_min">
- '<tt>llvm.atomic.load.min.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_umax">
- '<tt>llvm.atomic.load.umax.*</tt>' Intrinsic
- </a>
- <br>
- <a name="int_atomic_load_umin">
- '<tt>llvm.atomic.load.umin.*</tt>' Intrinsic
- </a>
-</h4>
-
-<div>
-
-<h5>Syntax:</h5>
-<p>These are overloaded intrinsics. You can use <tt>llvm.atomic.load_max</tt>,
- <tt>llvm.atomic.load_min</tt>, <tt>llvm.atomic.load_umax</tt>, and
- <tt>llvm.atomic.load_umin</tt> on any integer bit width and for different
- address spaces. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.max.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.max.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.max.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.max.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.min.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.min.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.min.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.min.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.umax.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.umax.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.umax.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.umax.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.umin.i8.p0i8(i8* <ptr>, i8 <delta>)
- declare i16 @llvm.atomic.load.umin.i16.p0i16(i16* <ptr>, i16 <delta>)
- declare i32 @llvm.atomic.load.umin.i32.p0i32(i32* <ptr>, i32 <delta>)
- declare i64 @llvm.atomic.load.umin.i64.p0i64(i64* <ptr>, i64 <delta>)
-</pre>
-
-<h5>Overview:</h5>
-<p>These intrinsics takes the signed or unsigned minimum or maximum of
- <tt>delta</tt> and the value stored in memory at <tt>ptr</tt>. It yields the
- original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>These intrinsics take two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>These intrinsics does a series of operations atomically. They first load the
- value stored at <tt>ptr</tt>. They then do the signed or unsigned min or
- max <tt>delta</tt> and the value, store the result to <tt>ptr</tt>. They
- yield the original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 7, %ptr
-%result0 = call i32 @llvm.atomic.load.min.i32.p0i32(i32* %ptr, i32 -2)
- <i>; yields {i32}:result0 = 7</i>
-%result1 = call i32 @llvm.atomic.load.max.i32.p0i32(i32* %ptr, i32 8)
- <i>; yields {i32}:result1 = -2</i>
-%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32(i32* %ptr, i32 10)
- <i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32(i32* %ptr, i32 30)
- <i>; yields {i32}:result3 = 8</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 30</i>
-</pre>
+<p>On some architectures the address of the code to be executed needs to be
+ different to the address where the trampoline is actually stored. This
+ intrinsic returns the executable address corresponding to <tt>tramp</tt>
+ after performing the required machine specific adjustments.
+ The pointer returned can then be <a href="#int_trampoline"> bitcast and
+ executed</a>.
+</p>
</div>
<h5>Semantics:</h5>
<p>This intrinsic allows annotation of local variables with arbitrary strings.
This can be useful for special purpose optimizations that want to look for
- these annotations. These have no other defined use, they are ignored by code
+ these annotations. These have no other defined use; they are ignored by code
generation and optimization.</p>
</div>
<h5>Semantics:</h5>
<p>This intrinsic allows annotations to be put on arbitrary expressions with
arbitrary strings. This can be useful for special purpose optimizations that
- want to look for these annotations. These have no other defined use, they
+ want to look for these annotations. These have no other defined use; they
are ignored by code generation and optimization.</p>
</div>
<h5>Syntax:</h5>
<pre>
- declare void @llvm.trap()
+ declare void @llvm.trap() noreturn nounwind
</pre>
<h5>Overview:</h5>
<p>None.</p>
<h5>Semantics:</h5>
-<p>This intrinsics is lowered to the target dependent trap instruction. If the
+<p>This intrinsic is lowered to the target dependent trap instruction. If the
target does not have a trap instruction, this intrinsic will be lowered to
- the call of the <tt>abort()</tt> function.</p>
+ a call of the <tt>abort()</tt> function.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_debugtrap">'<tt>llvm.debugtrap</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare void @llvm.debugtrap() nounwind
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.debugtrap</tt>' intrinsic.</p>
+
+<h5>Arguments:</h5>
+<p>None.</p>
+
+<h5>Semantics:</h5>
+<p>This intrinsic is lowered to code which is intended to cause an execution
+ trap with the intention of requesting the attention of a debugger.</p>
</div>
<h5>Syntax:</h5>
<pre>
- declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>)
- declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>)
+ declare i32 @llvm.objectsize.i32(i8* <object>, i1 <min>)
+ declare i64 @llvm.objectsize.i64(i8* <object>, i1 <min>)
</pre>
<h5>Overview:</h5>
<h5>Arguments:</h5>
<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first
argument is a pointer to or into the <tt>object</tt>. The second argument
- is a boolean 0 or 1. This argument determines whether you want the
- maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
- 1, variables are not allowed.</p>
+ is a boolean and determines whether <tt>llvm.objectsize</tt> returns 0 (if
+ true) or -1 (if false) when the object size is unknown.
+ The second argument only accepts constants.</p>
<h5>Semantics:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant
- representing the size of the object concerned, or <tt>i32/i64 -1 or 0</tt>,
- depending on the <tt>type</tt> argument, if the size cannot be determined at
- compile time.</p>
+<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to a constant representing
+ the size of the object concerned. If the size cannot be determined at compile
+ time, <tt>llvm.objectsize</tt> returns <tt>i32/i64 -1 or 0</tt>
+ (depending on the <tt>min</tt> argument).</p>
</div>
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_expect">'<tt>llvm.expect</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>)
+ declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>)
+</pre>
+
+<h5>Overview:</h5>
+<p>The <tt>llvm.expect</tt> intrinsic provides information about expected (the
+ most probable) value of <tt>val</tt>, which can be used by optimizers.</p>
+<h5>Arguments:</h5>
+<p>The <tt>llvm.expect</tt> intrinsic takes two arguments. The first
+ argument is a value. The second argument is an expected value, this needs to
+ be a constant value, variables are not allowed.</p>
+
+<h5>Semantics:</h5>
+<p>This intrinsic is lowered to the <tt>val</tt>.</p>
</div>
</div>
+</div>
<!-- *********************************************************************** -->
<hr>
<address>
projects / oota-llvm.git / blobdiff