<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="#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="#fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a></li>
+ </ol>
+ </li>
</ol>
</li>
<li><a href="#intrinsic_globals">Intrinsic Global Variables</a>
</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>
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>
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">
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
the ELF x86-64 abi, but it can be disabled for some compilation
units.</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>
</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>
<!-- ======================================================================= -->
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. This corresponds to the C++0x/C1x
-<code>memory_order_acquire</code>.</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 with an <code>acquire</code>
-operation. This is intended to model C++'s <code>memory_order_release</code>.</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.
This corresponds to the C++0x/C1x <code>memory_order_acq_rel</code>.</dd>
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>
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
</div>
+</div>
+
<!-- *********************************************************************** -->
<h2><a name="constants">Constants</a></h2>
<!-- *********************************************************************** -->
</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
+ to trap. If they have side effects, they 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>
</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="fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a>
+</h4>
+
+<div>
+
+<p><tt>fpaccuracy</tt> metadata may be attached to any instruction of floating
+ point type. It expresses the maximum relative error of the result of
+ that instruction, in ULPs. ULP is defined as follows:</p>
+
+<blockquote><p>
+If x is a real number that lies between two finite consecutive floating-point
+numbers a and b, without being equal to one of them, then ulp(x) = |b - a|,
+otherwise ulp(x) is the distance between the two non-equal finite
+floating-point numbers nearest x. Moreover, ulp(NaN) is NaN.
+</p></blockquote>
+
+<p>The maximum relative error may be any rational number. The metadata node
+ shall consist of a pair of unsigned integers respectively representing
+ the numerator and denominator. For example, 2.5 ULP:</p>
+
+<div class="doc_code">
+<pre>
+!0 = metadata !{ i32 5, i32 2 }
+</pre>
+</div>
+
+</div>
+
</div>
</div>
</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>
+</div>
+
<!-- ======================================================================= -->
<h3>
<a name="int_manip">Bit Manipulation Intrinsics</a>
<!-- ======================================================================= -->
<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>
-
-</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>
-</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>)
-</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>
-
-<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 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>
-
+ 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_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 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_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>)
+ declare i8* @llvm.adjust.trampoline(i8* <tramp>)
</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>
+<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 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>