<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>
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>
</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*, 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>
-
+ 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>
-</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>
-
-</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>
projects / oota-llvm.git / blobdiff