LangRef.html

<h5>Arguments:</h5>
<p>This instruction requires several arguments:</p>
<ol>
  <li>
    <p>'<tt>ty</tt>': shall be the signature of the pointer to function
value   being invoked.  The argument types must match the types implied
by this   signature.</p>
  </li>
  <li>
    <p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a
function   to be invoked. In most cases, this is a direct function
invocation, but   indirect <tt>call</tt>s are just as possible,
calling an arbitrary pointer to   function values.</p>
  </li>
  <li>
    <p>'<tt>function args</tt>': argument list whose types match the
function   signature argument types.  If the function signature
indicates the function   accepts a variable number of arguments, the
extra arguments can be   specified.</p>
  </li>
</ol>
<h5>Semantics:</h5>
<p>The '<tt>call</tt>' instruction is used to cause control flow to
transfer to a specified function, with its incoming arguments bound to
the specified values. Upon a '<tt><a href="#i_ret">ret</a></tt>'
instruction in the called function, control flow continues with the
instruction after the function call, and the return value of the
function is bound to the result argument.  This is a simpler case of
the <a href="#i_invoke">invoke</a> instruction.</p>
<h5>Example:</h5>
<pre>  %retval = call int %test(int %argc)<br>  call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);<br></pre>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_vanext">'<tt>vanext</tt>' Instruction</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  &lt;resultarglist&gt; = vanext &lt;va_list&gt; &lt;arglist&gt;, &lt;argty&gt;
</pre>

<h5>Overview:</h5>

<p>The '<tt>vanext</tt>' instruction is used to access arguments passed
through the "variable argument" area of a function call.  It is used to
implement the <tt>va_arg</tt> macro in C.</p>

<h5>Arguments:</h5>

<p>This instruction takes a <tt>va_list</tt> value and the type of the
argument. It returns another <tt>va_list</tt>. The actual type of
<tt>va_list</tt> may be defined differently for different targets.  Most targets
use a <tt>va_list</tt> type of <tt>sbyte*</tt> or some other pointer type.</p>

<h5>Semantics:</h5>

<p>The '<tt>vanext</tt>' instruction advances the specified <tt>va_list</tt>
past an argument of the specified type.  In conjunction with the <a
 href="#i_vaarg"><tt>vaarg</tt></a> instruction, it is used to implement
the <tt>va_arg</tt> macro available in C.  For more information, see
the variable argument handling <a href="#int_varargs">Intrinsic
Functions</a>.</p>

<p>It is legal for this instruction to be called in a function which
does not take a variable number of arguments, for example, the <tt>vfprintf</tt>
function.</p>

<p><tt>vanext</tt> is an LLVM instruction instead of an <a
href="#intrinsics">intrinsic function</a> because it takes a type as an
argument.  The type refers to the current argument in the <tt>va_list</tt>, it
tells the compiler how far on the stack it needs to advance to find the next
argument</p>

<h5>Example:</h5>

<p>See the <a href="#int_varargs">variable argument processing</a>
section.</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_vaarg">'<tt>vaarg</tt>' Instruction</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  &lt;resultval&gt; = vaarg &lt;va_list&gt; &lt;arglist&gt;, &lt;argty&gt;
</pre>

<h5>Overview:</h5>

<p>The '<tt>vaarg</tt>' instruction is used to access arguments passed through
the "variable argument" area of a function call.  It is used to implement the
<tt>va_arg</tt> macro in C.</p>

<h5>Arguments:</h5>

<p>This instruction takes a <tt>va_list</tt> value and the type of the
argument. It returns a value of the specified argument type.  Again, the actual
type of <tt>va_list</tt> is target specific.</p>

<h5>Semantics:</h5>

<p>The '<tt>vaarg</tt>' instruction loads an argument of the specified type from
the specified <tt>va_list</tt>.  In conjunction with the <a
href="#i_vanext"><tt>vanext</tt></a> instruction, it is used to implement the
<tt>va_arg</tt> macro available in C.  For more information, see the variable
argument handling <a href="#int_varargs">Intrinsic Functions</a>.</p>

<p>It is legal for this instruction to be called in a function which does not
take a variable number of arguments, for example, the <tt>vfprintf</tt>
function.</p>

<p><tt>vaarg</tt> is an LLVM instruction instead of an <a
href="#intrinsics">intrinsic function</a> because it takes an type as an
argument.</p>

<h5>Example:</h5>

<p>See the <a href="#int_varargs">variable argument processing</a> section.</p>

</div>

<!-- *********************************************************************** -->
<div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
<!-- *********************************************************************** -->

<div class="doc_text">

<p>LLVM supports the notion of an "intrinsic function".  These functions have
well known names and semantics, and are required to follow certain
restrictions. Overall, these instructions represent an extension mechanism for
the LLVM language that does not require changing all of the transformations in
LLVM to add to the language (or the bytecode reader/writer, the parser,
etc...).</p>

<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
prefix is reserved in LLVM for intrinsic names, thus functions may not be named
this.  Intrinsic functions must always be external functions: you cannot define
the body of intrinsic functions.  Intrinsic functions may only be used in call
or invoke instructions: it is illegal to take the address of an intrinsic
function.  Additionally, because intrinsic functions are part of the LLVM
language, it is required that they all be documented here if any are added.</p>


<p>
Adding an intrinsic to LLVM is straight-forward if it is possible to express the
concept in LLVM directly (ie, code generator support is not _required_).  To do
this, extend the default implementation of the IntrinsicLowering class to handle
the intrinsic.  Code generators use this class to lower intrinsics they do not
understand to raw LLVM instructions that they do.
</p>

</div>

<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_varargs">Variable Argument Handling Intrinsics</a>
</div>

<div class="doc_text">

<p>Variable argument support is defined in LLVM with the <a
 href="#i_vanext"><tt>vanext</tt></a> instruction and these three
intrinsic functions.  These functions are related to the similarly
named macros defined in the <tt>&lt;stdarg.h&gt;</tt> header file.</p>

<p>All of these functions operate on arguments that use a
target-specific value type "<tt>va_list</tt>".  The LLVM assembly
language reference manual does not define what this type is, so all
transformations should be prepared to handle intrinsics with any type
used.</p>

<p>This example shows how the <a href="#i_vanext"><tt>vanext</tt></a>
instruction and the variable argument handling intrinsic functions are
used.</p>

<pre>
int %test(int %X, ...) {
  ; Initialize variable argument processing
  %ap = call sbyte* %<a href="#i_va_start">llvm.va_start</a>()

  ; Read a single integer argument
  %tmp = vaarg sbyte* %ap, int

  ; Advance to the next argument
  %ap2 = vanext sbyte* %ap, int

  ; Demonstrate usage of llvm.va_copy and llvm.va_end
  %aq = call sbyte* %<a href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)
  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %aq)

  ; Stop processing of arguments.
  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)
  ret int %tmp
}
</pre>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
</div>


<div class="doc_text">
<h5>Syntax:</h5>
<pre>  call &lt;va_list&gt; ()* %llvm.va_start()<br></pre>
<h5>Overview:</h5>
<p>The '<tt>llvm.va_start</tt>' intrinsic returns a new <tt>&lt;arglist&gt;</tt>
for subsequent use by the variable argument intrinsics.</p>
<h5>Semantics:</h5>
<p>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt>
macro available in C.  In a target-dependent way, it initializes and
returns a <tt>va_list</tt> element, so that the next <tt>vaarg</tt>
will produce the first variable argument passed to the function.  Unlike
the C <tt>va_start</tt> macro, this intrinsic does not need to know the
last argument of the function, the compiler can figure that out.</p>
<p>Note that this intrinsic function is only legal to be called from
within the body of a variable argument function.</p>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
 <a name="i_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a>
</div>

<div class="doc_text">
<h5>Syntax:</h5>
<pre>  call void (&lt;va_list&gt;)* %llvm.va_end(&lt;va_list&gt; &lt;arglist&gt;)<br></pre>
<h5>Overview:</h5>
<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>&lt;arglist&gt;</tt>
which has been initialized previously with <tt><a href="#i_va_start">llvm.va_start</a></tt>
or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p>
<h5>Arguments:</h5>
<p>The argument is a <tt>va_list</tt> to destroy.</p>
<h5>Semantics:</h5>
<p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt>
macro available in C.  In a target-dependent way, it destroys the <tt>va_list</tt>.
Calls to <a href="#i_va_start"><tt>llvm.va_start</tt></a> and <a
 href="#i_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly
with calls to <tt>llvm.va_end</tt>.</p>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  call  &lt;va_list&gt; (&lt;va_list&gt;)* %llvm.va_copy(&lt;va_list&gt; &lt;destarglist&gt;)
</pre>

<h5>Overview:</h5>

<p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position
from the source argument list to the destination argument list.</p>

<h5>Arguments:</h5>

<p>The argument is the <tt>va_list</tt> to copy.</p>

<h5>Semantics:</h5>

<p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt>
macro available in C.  In a target-dependent way, it copies the source
<tt>va_list</tt> element into the returned list.  This intrinsic is necessary
because the <tt><a href="#i_va_start">llvm.va_start</a></tt> intrinsic may be
arbitrarily complex and require memory allocation, for example.</p>

</div>

<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_gc">Accurate Garbage Collection Intrinsics</a>
</div>

<div class="doc_text">

<p>
LLVM support for <a href="GarbageCollection.html">Accurate Garbage
Collection</a> requires the implementation and generation of these intrinsics.
These intrinsics allow identification of <a href="#i_gcroot">GC roots on the
stack</a>, as well as garbage collector implementations that require <a
href="#i_gcread">read</a> and <a href="#i_gcwrite">write</a> barriers.
Front-ends for type-safe garbage collected languages should generate these
intrinsics to make use of the LLVM garbage collectors.  For more details, see <a
href="GarbageCollection.html">Accurate Garbage Collection with LLVM</a>.
</p>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  call void (&lt;ty&gt;**, &lt;ty2&gt;*)* %llvm.gcroot(&lt;ty&gt;** %ptrloc, &lt;ty2&gt;* %metadata)
</pre>

<h5>Overview:</h5>

<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to
the code generator, and allows some metadata to be associated with it.</p>

<h5>Arguments:</h5>

<p>The first argument specifies the address of a stack object that contains the
root pointer.  The second pointer (which must be either a constant or a global
value address) contains the meta-data to be associated with the root.</p>

<h5>Semantics:</h5>

<p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
location.  At compile-time, the code generator generates information to allow
the runtime to find the pointer at GC safe points.
</p>

</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  call sbyte* (sbyte**)* %llvm.gcread(sbyte** %Ptr)
</pre>

<h5>Overview:</h5>

<p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap
locations, allowing garbage collector implementations that require read
barriers.</p>

<h5>Arguments:</h5>

<p>The argument is the address to read from, which should be an address
allocated from the garbage collector.</p>

<h5>Semantics:</h5>

<p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load
instruction, but may be replaced with substantially more complex code by the
garbage collector runtime, as needed.</p>

</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>

<pre>
  call void (sbyte*, sbyte**)* %llvm.gcwrite(sbyte* %P1, sbyte** %P2)
</pre>

<h5>Overview:</h5>

<p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap
locations, allowing garbage collector implementations that require write
barriers (such as generational or reference counting collectors).</p>

<h5>Arguments:</h5>

<p>The first argument is the reference to store, and the second is the heap
location to store to.</p>

<h5>Semantics:</h5>

<p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store
instruction, but may be replaced with substantially more complex code by the
garbage collector runtime, as needed.</p>

</div>



<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_codegen">Code Generator Intrinsics</a>
</div>

<div class="doc_text">
<p>
These intrinsics are provided by LLVM to expose special features that may only
be implemented with code generator support.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void* ()* %llvm.returnaddress(uint &lt;level&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.returnaddress</tt>' intrinsic returns a target-specific value
indicating the return address of the current function or one of its callers.
</p>

<h5>Arguments:</h5>

<p>
The argument to this intrinsic indicates which function to return the address
for.  Zero indicates the calling function, one indicates its caller, etc.  The
argument is <b>required</b> to be a constant integer value.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating
the return address of the specified call frame, or zero if it cannot be
identified.  The value returned by this intrinsic is likely to be incorrect or 0
for arguments other than zero, so it should only be used for debugging purposes.
</p>

<p>
Note that calling this intrinsic does not prevent function inlining or other
aggressive transformations, so the value returned may not be that of the obvious
source-language caller.
</p>
</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void* ()* %llvm.frameaddress(uint &lt;level&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.frameaddress</tt>' intrinsic returns the target-specific frame
pointer value for the specified stack frame.
</p>

<h5>Arguments:</h5>

<p>
The argument to this intrinsic indicates which function to return the frame
pointer for.  Zero indicates the calling function, one indicates its caller,
etc.  The argument is <b>required</b> to be a constant integer value.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating
the frame address of the specified call frame, or zero if it cannot be
identified.  The value returned by this intrinsic is likely to be incorrect or 0
for arguments other than zero, so it should only be used for debugging purposes.
</p>

<p>
Note that calling this intrinsic does not prevent function inlining or other
aggressive transformations, so the value returned may not be that of the obvious
source-language caller.
</p>
</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (sbyte *, uint, uint)* %llvm.prefetch(sbyte * &lt;address&gt;,
                                                  uint &lt;rw&gt;, 
                                                  uint &lt;locality&gt;)
</pre>

<h5>Overview:</h5>


<p>
The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert
a prefetch instruction if supported, otherwise it is a noop.  Prefetches have no
effect on the behavior of the program, but can change its performance
characteristics.
</p>

<h5>Arguments:</h5>

<p>
<tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the specifier
determining if the fetch should be for a read (0) or write (1), and
<tt>locality</tt> is a temporal locality specifier ranging from (0) - no
locality, to (3) - extremely local keep in cache.  The <tt>rw</tt> and
<tt>locality</tt> arguments must be constant integers.
</p>

<h5>Semantics:</h5>

<p>
This intrinsic does not modify the behavior of the program.  In particular,
prefetches cannot trap and do not produce a value.  On targets that support this
intrinsic, the prefetch can provide hints to the processor cache for better
performance.
</p>

</div>


<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_os">Operating System Intrinsics</a>
</div>

<div class="doc_text">
<p>
These intrinsics are provided by LLVM to support the implementation of
operating system level code.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_readport">'<tt>llvm.readport</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call &lt;integer type&gt; (&lt;integer type&gt;)* %llvm.readport (&lt;integer type&gt; &lt;address&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.readport</tt>' intrinsic reads data from the specified hardware
I/O port.
</p>

<h5>Arguments:</h5>

<p>
The argument to this intrinsic indicates the hardware I/O address from which
to read the data.  The address is in the hardware I/O address namespace (as
opposed to being a memory location for memory mapped I/O).
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.readport</tt>' intrinsic reads data from the hardware I/O port
specified by <i>address</i> and returns the value.  The address and return
value must be integers, but the size is dependent upon the platform upon which
the program is code generated.  For example, on x86, the address must be an
unsigned 16 bit value, and the return value must be 8, 16, or 32 bits.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_writeport">'<tt>llvm.writeport</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (&lt;integer type&gt;, &lt;integer type&gt;)*
            %llvm.writeport (&lt;integer type&gt; &lt;value&gt;,
                             &lt;integer type&gt; &lt;address&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.writeport</tt>' intrinsic writes data to the specified hardware
I/O port.
</p>

<h5>Arguments:</h5>

<p>
The first argument is the value to write to the I/O port.
</p>

<p>
The second argument indicates the hardware I/O address to which data should be
written.  The address is in the hardware I/O address namespace (as opposed to
being a memory location for memory mapped I/O).
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.writeport</tt>' intrinsic writes <i>value</i> to the I/O port
specified by <i>address</i>.  The address and value must be integers, but the
size is dependent upon the platform upon which the program is code generated.
For example, on x86, the address must be an unsigned 16 bit value, and the
value written must be 8, 16, or 32 bits in length.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_readio">'<tt>llvm.readio</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call &lt;result&gt; (&lt;ty&gt;*)* %llvm.readio (&lt;ty&gt; * &lt;pointer&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O
address.
</p>

<h5>Arguments:</h5>

<p>
The argument to this intrinsic is a pointer indicating the memory address from
which to read the data.  The data must be a
<a href="#t_firstclass">first class</a> type.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O
location specified by <i>pointer</i> and returns the value.  The argument must
be a pointer, and the return value must be a
<a href="#t_firstclass">first class</a> type.  However, certain architectures
may not support I/O on all first class types.  For example, 32 bit processors
may only support I/O on data types that are 32 bits or less.
</p>

<p>
This intrinsic enforces an in-order memory model for llvm.readio and
llvm.writeio calls on machines that use dynamic scheduling.  Dynamically
scheduled processors may execute loads and stores out of order, re-ordering at
run time accesses to memory mapped I/O registers.  Using these intrinsics
ensures that accesses to memory mapped I/O registers occur in program order.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_writeio">'<tt>llvm.writeio</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (&lt;ty1&gt;, &lt;ty2&gt;*)* %llvm.writeio (&lt;ty1&gt; &lt;value&gt;, &lt;ty2&gt; * &lt;pointer&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.writeio</tt>' intrinsic writes data to the specified memory
mapped I/O address.
</p>

<h5>Arguments:</h5>

<p>
The first argument is the value to write to the memory mapped I/O location.
The second argument is a pointer indicating the memory address to which the
data should be written.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.writeio</tt>' intrinsic writes <i>value</i> to the memory mapped
I/O address specified by <i>pointer</i>.  The value must be a
<a href="#t_firstclass">first class</a> type.  However, certain architectures
may not support I/O on all first class types.  For example, 32 bit processors
may only support I/O on data types that are 32 bits or less.
</p>

<p>
This intrinsic enforces an in-order memory model for llvm.readio and
llvm.writeio calls on machines that use dynamic scheduling.  Dynamically
scheduled processors may execute loads and stores out of order, re-ordering at
run time accesses to memory mapped I/O registers.  Using these intrinsics
ensures that accesses to memory mapped I/O registers occur in program order.
</p>

</div>

<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_libc">Standard C Library Intrinsics</a>
</div>

<div class="doc_text">
<p>
LLVM provides intrinsics for a few important standard C library functions.
These intrinsics allow source-language front-ends to pass information about the
alignment of the pointer arguments to the code generator, providing opportunity
for more efficient code generation.
</p>

</div>

<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* &lt;dest&gt;, sbyte* &lt;src&gt;,
                                                       uint &lt;len&gt;, uint &lt;align&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location.
</p>

<p>
Note that, unlike the standard libc function, the <tt>llvm.memcpy</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>

<h5>Arguments:</h5>

<p>
The first argument is a pointer to the destination, the second is a pointer to
the source.  The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>

<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location, which are not allowed to overlap.  It
copies "len" bytes of memory over.  If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* &lt;dest&gt;, sbyte* &lt;src&gt;,
                                                       uint &lt;len&gt;, uint &lt;align&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.memmove</tt>' intrinsic moves a block of memory from the source
location to the destination location. It is similar to the '<tt>llvm.memcpy</tt>' 
intrinsic but allows the two memory locations to overlap.
</p>

<p>
Note that, unlike the standard libc function, the <tt>llvm.memmove</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>

<h5>Arguments:</h5>

<p>
The first argument is a pointer to the destination, the second is a pointer to
the source.  The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>

<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.memmove</tt>' intrinsic copies a block of memory from the source
location to the destination location, which may overlap.  It
copies "len" bytes of memory over.  If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_memset">'<tt>llvm.memset</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* &lt;dest&gt;, ubyte &lt;val&gt;,
                                                      uint &lt;len&gt;, uint &lt;align&gt;)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.memset</tt>' intrinsic fills a block of memory with a particular
byte value.
</p>

<p>
Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>

<h5>Arguments:</h5>

<p>
The first argument is a pointer to the destination to fill, the second is the
byte value to fill it with, the third argument is an (arbitrarily sized) integer
argument specifying the number of bytes to fill, and the fourth argument is the
known alignment of destination location.
</p>

<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that the destination pointer is aligned to that boundary.
</p>

<h5>Semantics:</h5>

<p>
The '<tt>llvm.memset</tt>' intrinsic fills "len" bytes of memory starting at the
destination location.  If the argument is known to be aligned to some boundary,
this can be specified as the fourth argument, otherwise it should be set to 0 or
1.
</p>
</div>


<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
  <a name="i_isunordered">'<tt>llvm.isunordered</tt>' Intrinsic</a>
</div>

<div class="doc_text">

<h5>Syntax:</h5>
<pre>
  call bool (&lt;float or double&gt;, &lt;float or double&gt;)* %llvm.isunordered(&lt;float or double&gt; Val1,
                                                                      &lt;float or double&gt; Val2)
</pre>

<h5>Overview:</h5>

<p>
The '<tt>llvm.isunordered</tt>' intrinsic returns true if either or both of the
specified floating point values is a NAN.
</p>

<h5>Arguments:</h5>

<p>
The arguments are floating point numbers of the same type.
</p>

<h5>Semantics:</h5>

<p>
If either or both of the arguments is a SNAN or QNAN, it returns true, otherwise
false.
</p>
</div>




<!-- ======================================================================= -->
<div class="doc_subsection">
  <a name="int_debugger">Debugger Intrinsics</a>
</div>

<div class="doc_text">
<p>
The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix),
are described in the <a
href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level
Debugging</a> document.
</p>
</div>


<!-- *********************************************************************** -->
<hr>
<address>
  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
  <a href="http://validator.w3.org/check/referer"><img
  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>

  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
  Last modified: $Date$
</address>
</body>
</html>