<li><a href="#callingconv">Calling Conventions</a></li>
<li><a href="#globalvars">Global Variables</a></li>
<li><a href="#functionstructure">Functions</a></li>
+ <li><a href="#aliasstructure">Aliases</a>
<li><a href="#paramattrs">Parameter Attributes</a></li>
<li><a href="#moduleasm">Module-Level Inline Assembly</a></li>
<li><a href="#datalayout">Data Layout</a></li>
</li>
<li><a href="#int_debugger">Debugger intrinsics</a></li>
<li><a href="#int_eh">Exception Handling intrinsics</a></li>
+ <li><a href="#int_general">General intrinsics</a></li>
+ <ol>
+ <li><a href="#int_var_annotation">'<tt>llvm.var.annotation</tt>'
+ Intrinsic</a></li>
+ </ol>
+ </li>
</ol>
</li>
</ol>
accepts and what is considered 'well formed'. For example, the
following instruction is syntactically okay, but not well formed:</p>
+<div class="doc_code">
<pre>
-
%x = <a href="#i_add">add</a> i32 1, %x
+%x = <a href="#i_add">add</a> i32 1, %x
</pre>
+</div>
<p>...because the definition of <tt>%x</tt> does not dominate all of
its uses. The LLVM infrastructure provides a verification pass that may
the optimizer before it outputs bytecode. The violations pointed out
by the verifier pass indicate bugs in transformation passes or input to
the parser.</p>
+</div>
<!-- Describe the typesetting conventions here. --> </div>
<p>The easy way:</p>
+<div class="doc_code">
<pre>
-
%result = <a href="#i_mul">mul</a> i32 %X, 8
+%result = <a href="#i_mul">mul</a> i32 %X, 8
</pre>
+</div>
<p>After strength reduction:</p>
+<div class="doc_code">
<pre>
-
%result = <a href="#i_shl">shl</a> i32 %X, i8 3
+%result = <a href="#i_shl">shl</a> i32 %X, i8 3
</pre>
+</div>
<p>And the hard way:</p>
+<div class="doc_code">
<pre>
-
<a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
-
<a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
-
%result = <a href="#i_add">add</a> i32 %1, %1
+<a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
+<a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
+%result = <a href="#i_add">add</a> i32 %1, %1
</pre>
+</div>
<p>This last way of multiplying <tt>%X</tt> by 8 illustrates several
important lexical features of LLVM:</p>
global variable) definitions, resolves forward declarations, and merges
symbol table entries. Here is an example of the "hello world" module:</p>
+<div class="doc_code">
<pre><i>; Declare the string constant as a global constant...</i>
-<a href="#identifiers">
%.LC0</a> = <a href="#linkage_internal">internal</a> <a
- href="#globalvars">constant</a> <a href="#t_array">[13 x i8 ]</a> c"hello world\0A\00" <i>; [13 x i8 ]*</i>
+<a href="#identifiers">
@.LC0</a> = <a href="#linkage_internal">internal</a> <a
+ href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
<i>; External declaration of the puts function</i>
-<a href="#functionstructure">declare</a> i32 %puts(i8 *) <i>; i32(i8 *)* </i>
+<a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i>
<i>; Definition of main function</i>
-define i32 %main() { <i>; i32()* </i>
+define i32 @main() { <i>; i32()* </i>
<i>; Convert [13x i8 ]* to i8 *...</i>
%cast210 = <a
- href="#i_getelementptr">getelementptr</a> [13 x i8 ]* %.LC0, i64 0, i64 0 <i>; i8 *</i>
+ href="#i_getelementptr">getelementptr</a> [13 x i8 ]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
<i>; Call puts function to write out the string to stdout...</i>
<a
- href="#i_call">call</a> i32 %puts(i8 * %cast210) <i>; i32</i>
+ href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i>
<a
- href="#i_ret">ret</a> i32 0<br>}<br></pre>
+ href="#i_ret">ret</a> i32 0<br>}<br>
+</pre>
+</div>
<p>This example is made up of a <a href="#globalvars">global variable</a>
named "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>"
<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>
-
+<p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt>
+linkages.
</div>
<!-- ======================================================================= -->
directly.
</dd>
+ <dt><b>"<tt>protected</tt>" - Protected style</b>:</dt>
+
+ <dd>On ELF, protected visibility indicates that the symbol will be placed in
+ the dynamic symbol table, but that references within the defining module will
+ bind to the local symbol. That is, the symbol cannot be overridden by another
+ module.
+ </dd>
</dl>
</div>
<p>Global variables define regions of memory allocated at compilation time
instead of run-time. Global variables may optionally be initialized, may have
-an explicit section to be placed in, and may
-have an optional explicit alignment specified. A variable may be defined as
-"thread_local", which means that it will not be shared by threads (each thread
-will have a separated copy of the variable).
-A variable may be defined as a global "constant," which indicates that the
-contents of the variable will <b>never</b> be modified (enabling better
+an explicit section to be placed in, and may have an optional explicit alignment
+specified. A variable may be defined as "thread_local", which means that it
+will not be shared by threads (each thread will have a separated copy of the
+variable). A variable may be defined as a global "constant," which indicates
+that the contents of the variable will <b>never</b> be modified (enabling better
optimization, allowing the global data to be placed in the read-only section of
an executable, etc). Note that variables that need runtime initialization
cannot be marked "constant" as there is a store to the variable.</p>
<p>For example, the following defines a global with an initializer, section,
and alignment:</p>
+<div class="doc_code">
<pre>
- %G = constant float 1.0, section "foo", align 4
+%G = constant float 1.0, section "foo", align 4
</pre>
+</div>
</div>
with a <a href="#terminators">terminator</a> instruction (such as a branch or
function return).</p>
-<p>The first basic block in a program is special in two ways: it is immediately
+<p>The first basic block in a function is special in two ways: it is immediately
executed on entrance to the function, and it is not allowed to have predecessor
basic blocks (i.e. there can not be any branches to the entry block of a
function). Because the block can have no predecessors, it also cannot have any
</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="aliasstructure">Aliases</a>
+</div>
+<div class="doc_text">
+ <p>Aliases act as "second name" for the aliasee value (which can be either
+ function or global variable or bitcast of global value). Aliases may have an
+ optional <a href="#linkage">linkage type</a>, and an
+ optional <a href="#visibility">visibility style</a>.</p>
+
+ <h5>Syntax:</h5>
+
+<div class="doc_code">
+<pre>
+@<Name> = [Linkage] [Visibility] alias <AliaseeTy> @<Aliasee>
+</pre>
+</div>
+
+</div>
+
+
+
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div>
<div class="doc_text">
<p>Parameter attributes are simple keywords that follow the type specified. If
multiple parameter attributes are needed, they are space separated. For
- example:</p><pre>
- %someFunc = i16 (i8 sext %someParam) zext
- %someFunc = i16 (i8 zext %someParam) zext</pre>
+ example:</p>
+
+<div class="doc_code">
+<pre>
+%someFunc = i16 (i8 sext %someParam) zext
+%someFunc = i16 (i8 zext %someParam) zext
+</pre>
+</div>
+
<p>Note that the two function types above are unique because the parameter has
a different attribute (sext in the first one, zext in the second). Also note
that the attribute for the function result (zext) comes immediately after the
<dt><tt>sret</tt></dt>
<dd>This indicates that the parameter specifies the address of a structure
that is the return value of the function in the source program.</dd>
+ <dt><tt>noalias</tt></dt>
+ <dd>This indicates that the parameter not alias any other object or any
+ other "noalias" objects during the function call.
<dt><tt>noreturn</tt></dt>
<dd>This function attribute indicates that the function never returns. This
indicates to LLVM that every call to this function should be treated as if
desired. The syntax is very simple:
</p>
-<div class="doc_code"><pre>
- module asm "inline asm code goes here"
- module asm "more can go here"
-</pre></div>
+<div class="doc_code">
+<pre>
+module asm "inline asm code goes here"
+module asm "more can go here"
+</pre>
+</div>
<p>The strings can contain any character by escaping non-printable characters.
The escape sequence used is simply "\xx" where "xx" is the two digit hex code
<tbody>
<tr><th>Type</th><th>Description</th></tr>
<tr><td><tt><a name="t_void">void</a></tt></td><td>No value</td></tr>
- <tr><td><tt>i8</tt></td><td>8-bit value</td></tr>
- <tr><td><tt>i32</tt></td><td>32-bit value</td></tr>
- <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
<tr><td><tt>label</tt></td><td>Branch destination</td></tr>
</tbody>
</table>
<table>
<tbody>
<tr><th>Type</th><th>Description</th></tr>
- <tr><td><tt>i1</tt></td><td>True or False value</td></tr>
- <tr><td><tt>i16</tt></td><td>16-bit value</td></tr>
- <tr><td><tt>i64</tt></td><td>64-bit value</td></tr>
+ <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
<tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
</tbody>
</table>
<tr><th>Classification</th><th>Types</th></tr>
<tr>
<td><a name="t_integer">integer</a></td>
- <td><tt>i1, i8, i16, i32, i64</tt></td>
+ <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td>
</tr>
<tr>
<td><a name="t_floating">floating point</a></td>
</tr>
<tr>
<td><a name="t_firstclass">first class</a></td>
- <td><tt>i1, i8, i16, i32, i64, float, double, <br/>
+ <td><tt>i1, ..., float, double, <br/>
<a href="#t_pointer">pointer</a>,<a href="#t_vector">vector</a></tt>
</td>
</tr>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_integer">Integer Type</a> </div>
+
+<div class="doc_text">
+
+<h5>Overview:</h5>
+<p>The integer type is a very simple derived type that simply specifies an
+arbitrary bit width for the integer type desired. Any bit width from 1 bit to
+2^23-1 (about 8 million) can be specified.</p>
+
+<h5>Syntax:</h5>
+
+<pre>
+ iN
+</pre>
+
+<p>The number of bits the integer will occupy is specified by the <tt>N</tt>
+value.</p>
+
+<h5>Examples:</h5>
+<table class="layout">
+ <tr class="layout">
+ <td class="left">
+ <tt>i1</tt><br/>
+ <tt>i4</tt><br/>
+ <tt>i8</tt><br/>
+ <tt>i16</tt><br/>
+ <tt>i32</tt><br/>
+ <tt>i42</tt><br/>
+ <tt>i64</tt><br/>
+ <tt>i1942652</tt><br/>
+ </td>
+ <td class="left">
+ A boolean integer of 1 bit<br/>
+ A nibble sized integer of 4 bits.<br/>
+ A byte sized integer of 8 bits.<br/>
+ A half word sized integer of 16 bits.<br/>
+ A word sized integer of 32 bits.<br/>
+ An integer whose bit width is the answer. <br/>
+ A double word sized integer of 64 bits.<br/>
+ A really big integer of over 1 million bits.<br/>
+ </td>
+ </tr>
+</table>
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_array">Array Type</a> </div>
href="#t_pointer">pointer</a> type. For example, the following is a legal LLVM
file:</p>
+<div class="doc_code">
<pre>
- %X = global i32 17
- %Y = global i32 42
- %Z = global [2 x i32*] [ i32* %X, i32* %Y ]
+@X = global i32 17
+@Y = global i32 42
+@Z = global [2 x i32*] [ i32* @X, i32* @Y ]
</pre>
+</div>
</div>
<dt><b><tt>uitofp ( CST to TYPE )</tt></b></dt>
<dd>Convert an unsigned integer constant to the corresponding floating point
constant. TYPE must be floating point. CST must be of integer type. If the
- value won't fit in the floating point type, precision may be lost.</dd>
+ value won't fit in the floating point type, the results are undefined.</dd>
<dt><b><tt>sitofp ( CST to TYPE )</tt></b></dt>
<dd>Convert a signed integer constant to the corresponding floating point
constant. TYPE must be floating point. CST must be of integer type. If the
- value won't fit in the floating point type, precision may be lost.</dd>
+ value won't fit in the floating point type, the results are undefined.</dd>
<dt><b><tt>ptrtoint ( CST to TYPE )</tt></b></dt>
<dd>Convert a pointer typed constant to the corresponding integer constant
inline assembler expression is:
</p>
+<div class="doc_code">
<pre>
- i32 (i32) asm "bswap $0", "=r,r"
+i32 (i32) asm "bswap $0", "=r,r"
</pre>
+</div>
<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>
+<div class="doc_code">
<pre>
-
%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
+%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
</pre>
+</div>
<p>
Inline asms with side effects not visible in the constraint list must be marked
'<tt>sideeffect</tt>' keyword, like so:
</p>
+<div class="doc_code">
<pre>
- call void asm sideeffect "eieio", ""()
+call void asm sideeffect "eieio", ""()
</pre>
+</div>
<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
<p>The value produced is the integer or floating point difference of
the two operands.</p>
<h5>Example:</h5>
-<pre> <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i>
+<pre>
+ <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i>
<result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i>
</pre>
</div>
<pre>
%array = malloc [4 x i8 ] <i>; yields {[%4 x i8]*}:array</i>
- %size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i>
- %array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i>
- %array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i>
- %array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
- %array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
+ %size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i>
+ %array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i>
+ %array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i>
+ %array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
+ %array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
</pre>
</div>
<pre>
%ptr = alloca i32 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
%ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
</pre>
</div>
<p>For example, let's consider a C code fragment and how it gets
compiled to LLVM:</p>
+<div class="doc_code">
<pre>
- struct RT {
- char A;
- i32 B[10][20];
- char C;
- };
- struct ST {
- i32 X;
- double Y;
- struct RT Z;
- };
-
- define i32 *foo(struct ST *s) {
- return &s[1].Z.B[5][13];
- }
+struct RT {
+ char A;
+ int B[10][20];
+ char C;
+};
+struct ST {
+ int X;
+ double Y;
+ struct RT Z;
+};
+
+int *foo(struct ST *s) {
+ return &s[1].Z.B[5][13];
+}
</pre>
+</div>
<p>The LLVM code generated by the GCC frontend is:</p>
+<div class="doc_code">
<pre>
- %RT = type { i8 , [10 x [20 x i32]], i8 }
- %ST = type { i32, double, %RT }
+%RT = type { i8 , [10 x [20 x i32]], i8 }
+%ST = type { i32, double, %RT }
- define i32* %foo(%ST* %s) {
- entry:
- %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
- ret i32* %reg
- }
+define i32* %foo(%ST* %s) {
+entry:
+ %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
+ ret i32* %reg
+}
</pre>
+</div>
<h5>Semantics:</h5>
<h5>Semantics:</h5>
<p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero
-bits until it reaches the size of the destination type, <tt>ty2</tt>. When the
-the operand and the type are the same size, no bit filling is done and the
-cast is considered a <i>no-op cast</i> because no bits change (only the type
-changes).</p>
+bits until it reaches the size of the destination type, <tt>ty2</tt>.</p>
<p>When zero extending from i1, the result will always be either 0 or 1.</p>
<p>
The '<tt>sext</tt>' instruction performs a sign extension by copying the sign
bit (highest order bit) of the <tt>value</tt> until it reaches the bit size of
-the type <tt>ty2</tt>. When the the operand and the type are the same size,
-no bit filling is done and the cast is considered a <i>no-op cast</i> because
-no bits change (only the type changes).</p>
+the type <tt>ty2</tt>.</p>
<p>When sign extending from i1, the extension always results in -1 or 0.</p>
<h5>Semantics:</h5>
<p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned
integer quantity and converts it to the corresponding floating point value. If
-the value cannot fit in the floating point value, precision may be lost.</p>
+the value cannot fit in the floating point value, the results are undefined.</p>
<h5>Example:</h5>
<pre>
%X = uitofp i32 257 to float <i>; yields float:257.0</i>
- %Y = uitofp i8 -1 to double <i>; yields double:255.0</i>
+ %Y = uitofp i8 -1 to double <i>; yields double:255.0</i>
</pre>
</div>
<h5>Semantics:</h5>
<p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed
integer quantity and converts it to the corresponding floating point value. If
-the value cannot fit in the floating point value, precision may be lost.</p>
+the value cannot fit in the floating point value, the results are undefined.</p>
<h5>Example:</h5>
<pre>
%X = sitofp i32 257 to float <i>; yields float:257.0</i>
- %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i>
+ %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i>
</pre>
</div>
truncating or zero extending that value to the size of the integer type. If
<tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If
<tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they
-are the same size, then nothing is done (<i>no-op cast</i>).</p>
+are the same size, then nothing is done (<i>no-op cast</i>) other than a type
+change.</p>
<h5>Example:</h5>
<pre>
- %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit</i>
- %Y = ptrtoint i32* %x to i64 <i>; yields zero extend on 32-bit</i>
+ %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i>
+ %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i>
</pre>
</div>
<h5>Example:</h5>
<pre>
- %X = inttoptr i32 255 to i32* <i>; yields zero extend on 64-bit</i>
- %X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit </i>
- %Y = inttoptr i16 0 to i32* <i>; yields zero extend on 32-bit</i>
+ %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
+ %X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
+ %Y = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
</pre>
</div>
<h5>Example:</h5>
<pre>
- %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
+ %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
%Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
%Z = bitcast <2xint> %V to i64; <i>; yields i64: %V</i>
</pre>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
-<pre> <result> = icmp <cond> <ty> <var1>, <var2>
-<i>; yields {i1}:result</i>
+<pre> <result> = icmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i>
</pre>
<h5>Overview:</h5>
<p>The '<tt>icmp</tt>' instruction returns a boolean value based on comparison
of its two integer operands.</p>
<h5>Arguments:</h5>
<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
-the condition code which indicates the kind of comparison to perform. It is not
-a value, just a keyword. The possibilities for the condition code are:
+the condition code indicating the kind of comparison to perform. It is not
+a value, just a keyword. The possible condition code are:
<ol>
<li><tt>eq</tt>: equal</li>
<li><tt>ne</tt>: not equal </li>
<tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
</ol>
<p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer
-values are treated as integers and then compared.</p>
+values are compared as if they were integers.</p>
<h5>Example:</h5>
<pre> <result> = icmp eq i32 4, 5 <i>; yields: result=false</i>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
-<pre> <result> = fcmp <cond> <ty> <var1>, <var2>
-<i>; yields {i1}:result</i>
+<pre> <result> = fcmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i>
</pre>
<h5>Overview:</h5>
<p>The '<tt>fcmp</tt>' instruction returns a boolean value based on comparison
of its floating point operands.</p>
<h5>Arguments:</h5>
<p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is
-the condition code which indicates the kind of comparison to perform. It is not
-a value, just a keyword. The possibilities for the condition code are:
+the condition code indicating the kind of comparison to perform. It is not
+a value, just a keyword. The possible condition code are:
<ol>
<li><tt>false</tt>: no comparison, always returns false</li>
<li><tt>oeq</tt>: ordered and equal</li>
<li><tt>uno</tt>: unordered (either nans)</li>
<li><tt>true</tt>: no comparison, always returns true</li>
</ol>
-<p>In the preceding, <i>ordered</i> means that neither operand is a QNAN while
+<p><i>Ordered</i> means that neither operand is a QNAN while
<i>unordered</i> means that either operand may be a QNAN.</p>
<p>The <tt>val1</tt> and <tt>val2</tt> arguments must be
<a href="#t_floating">floating point</a> typed. They must have identical
types.</p>
-<p>In the foregoing, <i>ordered</i> means that neither operand is a QNAN and
-<i>unordered</i> means that either operand is a QNAN.</p>
<h5>Semantics:</h5>
<p>The '<tt>fcmp</tt>' compares <tt>var1</tt> and <tt>var2</tt> according to
the condition code given as <tt>cond</tt>. The comparison performed always
<p>The '<tt>phi</tt>' instruction is used to implement the φ node in
the SSA graph representing the function.</p>
<h5>Arguments:</h5>
-<p>The type of the incoming values are specified with the first type
+<p>The type of the incoming values is specified with the first type
field. After this, the '<tt>phi</tt>' instruction takes a list of pairs
as arguments, with one pair for each predecessor basic block of the
current block. Only values of <a href="#t_firstclass">first class</a>
block and the PHI instructions: i.e. PHI instructions must be first in
a basic block.</p>
<h5>Semantics:</h5>
-<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the
-value specified by the parameter, depending on which basic block we
-came from in the last <a href="#terminators">terminator</a> instruction.</p>
+<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value
+specified by the pair corresponding to the predecessor basic block that executed
+just prior to the current block.</p>
<h5>Example:</h5>
<pre>Loop: ; Infinite loop that counts from 0 on up...<br> %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]<br> %nextindvar = add i32 %indvar, 1<br> br label %Loop<br></pre>
</div>
<pre>
%retval = call i32 %test(i32 %argc)
- call i32(i8 *, ...) *%printf(i8 * %msg, i32 12, i8 42);
+ call i32(i8 *, ...) *%printf(i8 * %msg, i32 12, i8 42);
%X = tail call i32 %foo()
%Y = tail call <a href="#callingconv">fastcc</a> i32 %foo()
</pre>
<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 and
-increments the <tt>va_list</tt> to point to the next argument. Again, the
+increments the <tt>va_list</tt> to point to the next argument. The
actual type of <tt>va_list</tt> is target specific.</p>
<h5>Semantics:</h5>
<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 intrinsics 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>
+language that does not require changing all of the transformations in LLVM when
+adding 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>Some intrinsic functions can be overloaded. That is, the intrinsic represents
+prefix is reserved in LLVM for intrinsic names; thus, function names may not
+begin with this prefix. 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 if any are added that they be documented
+here.</p>
+
+<p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents
a family of functions that perform the same operation but on different data
types. This is most frequent with the integer types. Since LLVM can represent
over 8 million different integer types, there is a way to declare an intrinsic
-that can be overloaded based on its arguments. Such intrinsics will have the
-names of the arbitrary types encoded into the intrinsic function name, each
+that can be overloaded based on its arguments. Such an intrinsic will have the
+names of its argument types encoded into its function name, each
preceded by a period. For example, the <tt>llvm.ctpop</tt> function can take an
integer of any width. This leads to a family of functions such as
<tt>i32 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i32 @llvm.ctpop.i29(i29 %val)</tt>.
<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>
+transformations should be prepared to handle these functions regardless of
+the type used.</p>
<p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a>
instruction and the variable argument handling intrinsic functions are
used.</p>
+<div class="doc_code">
<pre>
define i32 @test(i32 %X, ...) {
; Initialize variable argument processing
- %ap = alloca i8 *
+ %ap = alloca i8*
%ap2 = bitcast i8** %ap to i8*
call void @llvm.va_start(i8* %ap2)
; Read a single integer argument
- %tmp = va_arg i8 ** %ap, i32
+ %tmp = va_arg i8** %ap, i32
; Demonstrate usage of llvm.va_copy and llvm.va_end
- %aq = alloca i8 *
+ %aq = alloca i8*
%aq2 = bitcast i8** %aq to i8*
- call void @llvm.va_copy(i8 *%aq2, i8* %ap2)
+ call void @llvm.va_copy(i8* %aq2, i8* %ap2)
call void @llvm.va_end(i8* %aq2)
; Stop processing of arguments.
</pre>
</div>
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
<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 the
-<tt>va_list</tt> element the argument points to, so that the next call to
+<tt>va_list</tt> element to which the argument points, so that the next call to
<tt>va_arg</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>
+last argument of the function as the compiler can figure that out.</p>
</div>
<pre> declare void @llvm.va_end(i8* <arglist>)<br></pre>
<h5>Overview:</h5>
-<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt><arglist></tt>
+<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>,
which has been initialized previously with <tt><a href="#int_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>
+<p>The argument is a pointer to 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="#int_va_start"><tt>llvm.va_start</tt></a> and <a
- href="#int_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly
-with calls to <tt>llvm.va_end</tt>.</p>
+macro available in C. In a target-dependent way, it destroys the
+<tt>va_list</tt> element to which the argument points. Calls to <a
+href="#int_va_start"><tt>llvm.va_start</tt></a> and <a href="#int_va_copy">
+<tt>llvm.va_copy</tt></a> must be matched exactly with calls to
+<tt>llvm.va_end</tt>.</p>
</div>
<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>
+<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>
<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 destination list. This intrinsic is necessary
-because the <tt><a href="#int_va_start">llvm.va_start</a></tt> intrinsic may be
-arbitrarily complex and require memory allocation, for example.</p>
+<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 destination <tt>va_list</tt> element. This
+intrinsic is necessary because the <tt><a href="#int_va_start">
+llvm.va_start</a></tt> intrinsic may be arbitrarily complex and require, for
+example, memory allocation.</p>
</div>
<li>A mask of the retained bits is created by shifting a -1 value.</li>
<li>The mask is ANDed with <tt>%val</tt> to produce the result.
</ol>
-<p>In reverse mode, a similar computation is made except that:</p>
-<ol>
- <li>The bits selected wrap around to include both the highest and lowest bits.
- For example, part.select(i16 X, 4, 7) selects bits from X with a mask of
- 0x00F0 (forwards case) while part.select(i16 X, 8, 3) selects bits from X
- with a mask of 0xFF0F.</li>
- <li>The bits returned in the reverse case are reversed. So, if X has the value
- 0x6ACF and we apply part.select(i16 X, 8, 3) to it, we get back the value
- 0x0A6F.</li>
-</ol>
+<p>In reverse mode, a similar computation is made except that the bits are
+returned in the reverse order. So, for example, if <tt>X</tt> has the value
+<tt>i16 0x0ACF (101011001111)</tt> and we apply
+<tt>part.select(i16 X, 8, 3)</tt> to it, we get back the value
+<tt>i16 0x0026 (000000100110)</tt>.</p>
</div>
<div class="doc_subsubsection">
are replaced with corresponding bits from <tt>%repl</tt>. That is the 0th bit
in <tt>%repl</tt> replaces the <tt>%lo</tt>th bit in <tt>%val</tt> and etc. up
to the <tt>%hi</tt>th bit.
-<p>In reverse mode, a similar computation is made except that the bits replaced
-wrap around to include both the highest and lowest bits. For example, if a
-16 bit value is being replaced then <tt>%lo=8</tt> and <tt>%hi=4</tt> would
-cause these bits to be set: <tt>0xFF1F</tt>.</p>
+<p>In reverse mode, a similar computation is made except that the bits are
+reversed. That is, the <tt>0</tt>th bit in <tt>%repl</tt> replaces the
+<tt>%hi</tt> bit in <tt>%val</tt> and etc. down to the <tt>%lo</tt>th bit.
<h5>Examples:</h5>
<pre>
llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
- llvm.part.set(0xFFFF, 0, 7, 4) -> 0x0060
- llvm.part.set(0xFFFF, 0, 8, 3) -> 0x00F0
+ llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
+ llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
+ llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
</pre>
</div>
Handling</a> document. </p>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="int_general">General Intrinsics</a>
+</div>
+
+<div class="doc_text">
+<p> This class of intrinsics is designed to be generic and has
+no specific purpose. </p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> )
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.var.annotation</tt>' intrinsic
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The first argument is a pointer to a value, the second is a pointer to a
+global string, the third is a pointer to a global string which is the source
+file name, and the last argument is the line number.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+This intrinsic allows annotation of local variables with arbitrary strings.
+This can be useful for special purpose optimizations that want to look for these
+ annotations. These have no other defined use, they are ignored by code
+ generation and optimization.
+</div>
+
<!-- *********************************************************************** -->
<hr>
projects / oota-llvm.git / blobdiff