<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>
<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>
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>
<!-- ======================================================================= -->
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
</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>
<!-- ======================================================================= -->
<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>
-
-</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>)
-</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>
-</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