</li>
<li><a href="#typesystem">Type System</a>
<ol>
- <li><a href="#t_primitive">Primitive Types</a>
+ <li><a href="#t_primitive">Primitive Types</a>
<ol>
<li><a href="#t_classifications">Type Classifications</a></li>
</ol>
<li><a href="#constantexprs">Constant Expressions</a>
</ol>
</li>
+ <li><a href="#othervalues">Other Values</a>
+ <ol>
+ <li><a href="#inlineasm">Inline Assembler Expressions</a>
+ </ol>
+ </li>
<li><a href="#instref">Instruction Reference</a>
<ol>
<li><a href="#terminators">Terminator Instructions</a>
<li><a href="#i_malloc">'<tt>malloc</tt>' Instruction</a></li>
<li><a href="#i_free">'<tt>free</tt>' Instruction</a></li>
<li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li>
- <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li>
- <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li>
- <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li>
+
<li><a href="#i_load">'<tt>load</tt>' Instruction</a></li>
+
<li><a href="#i_store">'<tt>store</tt>' Instruction</a></li>
+
<li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li>
</ol>
</li>
<li><a href="#otherops">Other Operations</a>
<li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li>
<li><a href="#i_cast">'<tt>cast .. to</tt>' Instruction</a></li>
<li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
+ <li><a href="#i_vsetint">'<tt>vsetint</tt>' Instruction</a></li>
+ <li><a href="#i_vsetfp">'<tt>vsetfp</tt>' Instruction</a></li>
+ <li><a href="#i_vselect">'<tt>vselect</tt>' Instruction</a></li>
<li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li>
<li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li>
<li><a href="#i_call">'<tt>call</tt>' Instruction</a></li>
<li><a href="#i_readcyclecounter"><tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
</ol>
</li>
- <li><a href="#int_os">Operating System Intrinsics</a>
- <ol>
- <li><a href="#i_readport">'<tt>llvm.readport</tt>' Intrinsic</a></li>
- <li><a href="#i_writeport">'<tt>llvm.writeport</tt>' Intrinsic</a></li>
- <li><a href="#i_readio">'<tt>llvm.readio</tt>' Intrinsic</a></li>
- <li><a href="#i_writeio">'<tt>llvm.writeio</tt>' Intrinsic</a></li>
- </ol>
<li><a href="#int_libc">Standard C Library Intrinsics</a>
<ol>
- <li><a href="#i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a></li>
- <li><a href="#i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a></li>
- <li><a href="#i_memset">'<tt>llvm.memset</tt>' Intrinsic</a></li>
+ <li><a href="#i_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li>
+ <li><a href="#i_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li>
+ <li><a href="#i_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li>
<li><a href="#i_isunordered">'<tt>llvm.isunordered.*</tt>' Intrinsic</a></li>
<li><a href="#i_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li>
</dl>
</div>
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="othervalues">Other Values</a> </div>
+<!-- *********************************************************************** -->
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+<a name="inlineasm">Inline Assembler Expressions</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+LLVM supports inline assembler expressions (as opposed to <a href="#moduleasm">
+Module-Level Inline Assembly</a>) through the use of a special value. This
+value represents the inline assembler as a string (containing the instructions
+to emit), a list of operand constraints (stored as a string), and a flag that
+indicates whether or not the inline asm expression has side effects. An example
+inline assembler expression is:
+</p>
+
+<pre>
+ int(int) asm "bswap $0", "=r,r"
+</pre>
+
+<p>
+Inline assembler expressions may <b>only</b> be used as the callee operand of
+a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we have:
+</p>
+
+<pre>
+ %X = call int asm "<a href="#i_bswap">bswap</a> $0", "=r,r"(int %Y)
+</pre>
+
+<p>
+Inline asms with side effects not visible in the constraint list must be marked
+as having side effects. This is done through the use of the
+'<tt>sideeffect</tt>' keyword, like so:
+</p>
+
+<pre>
+ call void asm sideeffect "eieio", ""()
+</pre>
+
+<p>TODO: The format of the asm and constraints string still need to be
+documented here. Constraints on what can be done (e.g. duplication, moving, etc
+need to be documented).
+</p>
+
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="instref">Instruction Reference</a> </div>
<!-- *********************************************************************** -->
<h5>Example:</h5>
<pre> <result> = rem int 4, %var <i>; yields {int}:result = 4 % %var</i>
</pre>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_setcc">'<tt>set<i>cc</i></tt>'
<result> = setge sbyte 4, 5 <i>; yields {bool}:result = false</i>
</pre>
</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection"> <a name="bitwiseops">Bitwise Binary
Operations</a> </div>
</pre>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="i_vsetint">'<tt>vsetint</tt>'
+Instruction</a> </div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+<pre><result> = vsetint <op>, <n x <ty>> <var1>, <var2> <i>; yields <n x bool></i>
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>vsetint</tt>' instruction takes two integer vectors and
+returns a vector of boolean values representing, at each position, the
+result of the comparison between the values at that position in the
+two operands.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments to a '<tt>vsetint</tt>' instruction are a comparison
+operation and two value arguments. The value arguments must be of <a
+href="#t_integral">integral</a> <a href="#t_packed">packed</a> type,
+and they must have identical types. The operation argument must be
+one of <tt>eq</tt>, <tt>ne</tt>, <tt>slt</tt>, <tt>sgt</tt>,
+<tt>sle</tt>, <tt>sge</tt>, <tt>ult</tt>, <tt>ugt</tt>, <tt>ule</tt>,
+<tt>uge</tt>, <tt>true</tt>, and <tt>false</tt>. The result is a
+packed <tt>bool</tt> value with the same length as each operand.</p>
+
+<h5>Semantics:</h5>
+
+<p>The following table shows the semantics of '<tt>vsetint</tt>'. For
+each position of the result, the comparison is done on the
+corresponding positions of the two value arguments. Note that the
+signedness of the comparison depends on the comparison opcode and
+<i>not</i> on the signedness of the value operands. E.g., <tt>vsetint
+slt <4 x unsigned> %x, %y</tt> does an elementwise <i>signed</i>
+comparison of <tt>%x</tt> and <tt>%y</tt>.</p>
+
+<table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr><th>Operation</th><th>Result is true iff</th><th>Comparison is</th></tr>
+ <tr><td><tt>eq</tt></td><td>var1 == var2</td><td>--</td></tr>
+ <tr><td><tt>ne</tt></td><td>var1 != var2</td><td>--</td></tr>
+ <tr><td><tt>slt</tt></td><td>var1 < var2</td><td>signed</td></tr>
+ <tr><td><tt>sgt</tt></td><td>var1 > var2</td><td>signed</td></tr>
+ <tr><td><tt>sle</tt></td><td>var1 <= var2</td><td>signed</td></tr>
+ <tr><td><tt>sge</tt></td><td>var1 >= var2</td><td>signed</td></tr>
+ <tr><td><tt>ult</tt></td><td>var1 < var2</td><td>unsigned</td></tr>
+ <tr><td><tt>ugt</tt></td><td>var1 > var2</td><td>unsigned</td></tr>
+ <tr><td><tt>ule</tt></td><td>var1 <= var2</td><td>unsigned</td></tr>
+ <tr><td><tt>uge</tt></td><td>var1 >= var2</td><td>unsigned</td></tr>
+ <tr><td><tt>true</tt></td><td>always</td><td>--</td></tr>
+ <tr><td><tt>false</tt></td><td>never</td><td>--</td></tr>
+ </tbody>
+</table>
+
+<h5>Example:</h5>
+<pre> <result> = vsetint eq <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = false, false</i>
+ <result> = vsetint ne <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = true, true</i>
+ <result> = vsetint slt <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = true, false</i>
+ <result> = vsetint sgt <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = false, true</i>
+ <result> = vsetint sle <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = true, false</i>
+ <result> = vsetint sge <2 x int> <int 0, int 1>, <int 1, int 0> <i>; yields {<2 x bool>}:result = false, true</i>
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="i_vsetfp">'<tt>vsetfp</tt>'
+Instruction</a> </div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+<pre><result> = vsetfp <op>, <n x <ty>> <var1>, <var2> <i>; yields <n x bool></i>
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>vsetfp</tt>' instruction takes two floating point vector
+arguments and returns a vector of boolean values representing, at each
+position, the result of the comparison between the values at that
+position in the two operands.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments to a '<tt>vsetfp</tt>' instruction are a comparison
+operation and two value arguments. The value arguments must be of <a
+href="t_floating">floating point</a> <a href="#t_packed">packed</a>
+type, and they must have identical types. The operation argument must
+be one of <tt>eq</tt>, <tt>ne</tt>, <tt>lt</tt>, <tt>gt</tt>,
+<tt>le</tt>, <tt>ge</tt>, <tt>oeq</tt>, <tt>one</tt>, <tt>olt</tt>,
+<tt>ogt</tt>, <tt>ole</tt>, <tt>oge</tt>, <tt>ueq</tt>, <tt>une</tt>,
+<tt>ult</tt>, <tt>ugt</tt>, <tt>ule</tt>, <tt>uge</tt>, <tt>o</tt>,
+<tt>u</tt>, <tt>true</tt>, and <tt>false</tt>. The result is a packed
+<tt>bool</tt> value with the same length as each operand.</p>
+
+<h5>Semantics:</h5>
+
+<p>The following table shows the semantics of '<tt>vsetfp</tt>' for
+floating point types. If either operand is a floating point Not a
+Number (NaN) value, the operation is unordered, and the value in the
+first column below is produced at that position. Otherwise, the
+operation is ordered, and the value in the second column is
+produced.</p>
+
+<table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr><th>Operation</th><th>If unordered<th>Otherwise true iff</th></tr>
+ <tr><td><tt>eq</tt></td><td>undefined</td><td>var1 == var2</td></tr>
+ <tr><td><tt>ne</tt></td><td>undefined</td><td>var1 != var2</td></tr>
+ <tr><td><tt>lt</tt></td><td>undefined</td><td>var1 < var2</td></tr>
+ <tr><td><tt>gt</tt></td><td>undefined</td><td>var1 > var2</td></tr>
+ <tr><td><tt>le</tt></td><td>undefined</td><td>var1 <= var2</td></tr>
+ <tr><td><tt>ge</tt></td><td>undefined</td><td>var1 >= var2</td></tr>
+ <tr><td><tt>oeq</tt></td><td>false</td><td>var1 == var2</td></tr>
+ <tr><td><tt>one</tt></td><td>false</td><td>var1 != var2</td></tr>
+ <tr><td><tt>olt</tt></td><td>false</td><td>var1 < var2</td></tr>
+ <tr><td><tt>ogt</tt></td><td>false</td><td>var1 > var2</td></tr>
+ <tr><td><tt>ole</tt></td><td>false</td><td>var1 <= var2</td></tr>
+ <tr><td><tt>oge</tt></td><td>false</td><td>var1 >= var2</td></tr>
+ <tr><td><tt>ueq</tt></td><td>true</td><td>var1 == var2</td></tr>
+ <tr><td><tt>une</tt></td><td>true</td><td>var1 != var2</td></tr>
+ <tr><td><tt>ult</tt></td><td>true</td><td>var1 < var2</td></tr>
+ <tr><td><tt>ugt</tt></td><td>true</td><td>var1 > var2</td></tr>
+ <tr><td><tt>ule</tt></td><td>true</td><td>var1 <= var2</td></tr>
+ <tr><td><tt>uge</tt></td><td>true</td><td>var1 >= var2</td></tr>
+ <tr><td><tt>o</tt></td><td>false</td><td>always</td></tr>
+ <tr><td><tt>u</tt></td><td>true</td><td>never</td></tr>
+ <tr><td><tt>true</tt></td><td>true</td><td>always</td></tr>
+ <tr><td><tt>false</tt></td><td>false</td><td>never</td></tr>
+ </tbody>
+</table>
+
+<h5>Example:</h5>
+<pre> <result> = vsetfp eq <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = false, false</i>
+ <result> = vsetfp ne <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = true, true</i>
+ <result> = vsetfp lt <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = true, false</i>
+ <result> = vsetfp gt <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = false, true</i>
+ <result> = vsetfp le <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = true, false</i>
+ <result> = vsetfp ge <2 x float> <float 0.0, float 1.0>, <float 1.0, float 0.0> <i>; yields {<2 x bool>}:result = false, true</i>
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_vselect">'<tt>vselect</tt>' Instruction</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<pre>
+ <result> = vselect <n x bool> <cond>, <n x <ty>> <val1>, <n x <ty>> <val2> <i>; yields <n x <ty>></i>
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>vselect</tt>' instruction chooses one value at each position
+of a vector based on a condition.
+</p>
+
+
+<h5>Arguments:</h5>
+
+<p>
+The '<tt>vselect</tt>' instruction requires a <a
+href="#t_packed">packed</a> <tt>bool</tt> value indicating the
+condition at each vector position, and two values of the same packed
+type. All three operands must have the same length. The type of the
+result is the same as the type of the two value operands.</p>
+
+<h5>Semantics:</h5>
+
+<p>
+At each position where the <tt>bool</tt> vector is true, that position
+of the result gets its value from the first value argument; otherwise,
+it gets its value from the second value argument.
+</p>
+
+<h5>Example:</h5>
+
+<pre>
+ %X = vselect bool <2 x bool> <bool true, bool false>, <2 x ubyte> <ubyte 17, ubyte 17>,
+ <2 x ubyte> <ubyte 42, ubyte 42> <i>; yields <2 x ubyte>:17, 42</i>
+</pre>
+</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<h5>Syntax:</h5>
<pre>
- declare sbyte* %llvm.gcread(sbyte** %Ptr)
+ declare sbyte* %llvm.gcread(sbyte* %ObjPtr, sbyte** %Ptr)
</pre>
<h5>Overview:</h5>
<h5>Arguments:</h5>
-<p>The argument is the address to read from, which should be an address
-allocated from the garbage collector.</p>
+<p>The second argument is the address to read from, which should be an address
+allocated from the garbage collector. The first object is a pointer to the
+start of the referenced object, if needed by the language runtime (otherwise
+null).</p>
<h5>Semantics:</h5>
<h5>Syntax:</h5>
<pre>
- declare void %llvm.gcwrite(sbyte* %P1, sbyte** %P2)
+ declare void %llvm.gcwrite(sbyte* %P1, sbyte* %Obj, sbyte** %P2)
</pre>
<h5>Overview:</h5>
<h5>Arguments:</h5>
-<p>The first argument is the reference to store, and the second is the heap
-location to store to.</p>
+<p>The first argument is the reference to store, the second is the start of the
+object to store it to, and the third is the address of the field of Obj to
+store to. If the runtime does not require a pointer to the object, Obj may be
+null.</p>
<h5>Semantics:</h5>
</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>
- declare <integer type> %llvm.readport (<integer type> <address>)
-</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 (<integer type>, <integer type>)*
- %llvm.writeport (<integer type> <value>,
- <integer type> <address>)
-</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>
- declare <result> %llvm.readio (<ty> * <pointer>)
-</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>
- declare void %llvm.writeio (<ty1> <value>, <ty2> * <pointer>)
-</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>
<h5>Syntax:</h5>
<pre>
- declare void %llvm.memcpy(sbyte* <dest>, sbyte* <src>,
- uint <len>, uint <align>)
+ declare void %llvm.memcpy.i32(sbyte* <dest>, sbyte* <src>,
+ uint <len>, uint <align>)
+ declare void %llvm.memcpy.i64(sbyte* <dest>, sbyte* <src>,
+ ulong <len>, uint <align>)
</pre>
<h5>Overview:</h5>
<p>
-The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
+The '<tt>llvm.memcpy.*</tt>' intrinsics copy 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.
+Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt>
+intrinsics do 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
+the source. The third argument is an 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.
+the caller guarantees 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
+The '<tt>llvm.memcpy.*</tt>' intrinsics copy 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
<h5>Syntax:</h5>
<pre>
- declare void %llvm.memmove(sbyte* <dest>, sbyte* <src>,
- uint <len>, uint <align>)
+ declare void %llvm.memmove.i32(sbyte* <dest>, sbyte* <src>,
+ uint <len>, uint <align>)
+ declare void %llvm.memmove.i64(sbyte* <dest>, sbyte* <src>,
+ ulong <len>, uint <align>)
</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.
+The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the source
+location to the destination location. It is similar to the
+'<tt>llvm.memcmp</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.
+Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt>
+intrinsics do 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
+the source. The third argument is an 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.
+the caller guarantees that 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
+The '<tt>llvm.memmove.*</tt>' intrinsics copy 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
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="i_memset">'<tt>llvm.memset</tt>' Intrinsic</a>
+ <a name="i_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
- declare void %llvm.memset(sbyte* <dest>, ubyte <val>,
- uint <len>, uint <align>)
+ declare void %llvm.memset.i32(sbyte* <dest>, ubyte <val>,
+ uint <len>, uint <align>)
+ declare void %llvm.memset.i64(sbyte* <dest>, ubyte <val>,
+ ulong <len>, uint <align>)
</pre>
<h5>Overview:</h5>
<p>
-The '<tt>llvm.memset</tt>' intrinsic fills a block of memory with a particular
+The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a particular
byte value.
</p>
<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
+byte value to fill it with, the third argument is an 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.
+the caller guarantees 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
+The '<tt>llvm.memset.*</tt>' intrinsics fill "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.
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>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
projects / oota-llvm.git / blobdiff