<li><a href="#i_switch">'<tt>switch</tt>' Instruction</a>
<li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a>
</ol>
- <li><a href="#unaryops">Unary Operations</a>
- <ol>
- <li><a href="#i_not" >'<tt>not</tt>' Instruction</a>
- </ol>
<li><a href="#binaryops">Binary Operations</a>
<ol>
<li><a href="#i_add" >'<tt>add</tt>' Instruction</a>
</ol>
<li><a href="#otherops">Other Operations</a>
<ol>
+ <li><a href="#i_phi" >'<tt>phi</tt>' Instruction</a>
<li><a href="#i_cast">'<tt>cast .. to</tt>' Instruction</a>
<li><a href="#i_call" >'<tt>call</tt>' Instruction</a>
- <li><a href="#i_icall">'<tt>icall</tt>' Instruction</a>
- <li><a href="#i_phi" >'<tt>phi</tt>' Instruction</a>
</ol>
</ol>
+<!--
<li><a href="#related">Related Work</a>
+-->
</ol>
<!-- *********************************************************************** -->
<blockquote>
- This document describes the LLVM assembly language. LLVM is an SSA based
- representation that is a useful midlevel IR, providing type safety, low level
- operations, flexibility, and the capability of representing 'all' high level
- languages cleanly.
+ This document is a reference manual for the LLVM assembly language. LLVM is
+ an SSA based representation that provides type safety, low level operations,
+ flexibility, and the capability of representing 'all' high level languages
+ cleanly. It is the common code representation used throughout all phases of
+ the LLVM compilation strategy.
</blockquote>
readable representation and notation.<p>
The LLVM representation aims to be a light weight and low level while being
-expressive, type safe, and extensible at the same time. It aims to be a
-"universal IR" of sorts, by being at a low enough level that high level ideas
-may be cleanly mapped to it (similar to how microprocessors are "universal
-IR's", allowing many source languages to be mapped to them). By providing type
-safety, LLVM can be used as the target of optimizations: for example, through
-pointer analysis, it can be proven that a C automatic variable is never accessed
-outside of the current function... allowing it to be promoted to a simple SSA
-value instead of a memory location.<p>
+expressive, typed, and extensible at the same time. It aims to be a "universal
+IR" of sorts, by being at a low enough level that high level ideas may be
+cleanly mapped to it (similar to how microprocessors are "universal IR's",
+allowing many source languages to be mapped to them). By providing type
+information, LLVM can be used as the target of optimizations: for example,
+through pointer analysis, it can be proven that a C automatic variable is never
+accessed outside of the current function... allowing it to be promoted to a
+
simple SSA value instead of a memory location.<p>
<!-- _______________________________________________________________________ -->
</ul><a name="wellformed"><h4><hr size=0>Well Formedness</h4><ul>
%x = <a href="#i_add">add</a> int 1, %x
</pre>
-...because only a <tt><a href="#i_phi">phi</a></tt> node may refer to itself.
-The LLVM api provides a verification pass (created by the
-<tt>createVerifierPass</tt> function) that may be used to verify that an LLVM
-module is well formed. This pass is automatically run by the parser after
+...because the definition of %x does not dominate all of its uses. The LLVM
+infrastructure provides a verification pass that may be used to verify that an
+LLVM module is well formed. This pass is automatically run by the parser after
parsing input assembly, and by 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>
-Describe the typesetting conventions here.
+<!-- Describe the typesetting conventions here. -->
<!-- *********************************************************************** -->
And the hard way:
<pre>
- <a href="#i_add">add</a> uint %X, %X <i>; yields {int}:%0</i>
- <a href="#i_add">add</a> uint %0, %0 <i>; yields {int}:%1</i>
+ <a href="#i_add">add</a> uint %X, %X <i>; yields {uint}:%0</i>
+ <a href="#i_add">add</a> uint %0, %0 <i>; yields {uint}:%1</i>
%result = <a href="#i_add">add</a> uint %1, %1
</pre>
<!-- *********************************************************************** -->
The LLVM type system is one of the most important features of the intermediate
-representation. Being strongly typed enables a number of optimizations to be
-performed on the IR directly, without having to do extra analyses on the side
-before the transformation. A strong type system makes it easier to read the
-generated code and enables novel analyses and transformations that are not
-
feasible to perform on normal three address code representations.<p>
+representation. Being typed enables a number of optimizations to be performed
+on the IR directly, without having to do extra analyses on the side before the
+transformation. A strong type system makes it easier to read the generated code
+and enables novel analyses and transformations that are not feasible to perform
+on normal three address code representations.<p>
-The written form for the type system was heavily influenced by the syntactic
-problems with types in the C language<sup><a
-href="#rw_stroustrup">1</a></sup>.<p>
+<!-- The written form for the type system was heavily influenced by the
+
syntactic problems with types in the C language<sup><a
+href="#rw_stroustrup">1</a></sup>.<p> -->
<h5>Overview:</h5>
The structure type is used to represent a collection of data members together in
-memory. Although the runtime is allowed to lay out the data members any way
-that it would like, they are guaranteed to be "close" to each other.<p>
+memory. The packing of the field types is defined to match the ABI of the
+underlying processor. The elements of a structure may be any type that has a
+size.<p>
Structures are accessed using '<tt><a href="#i_load">load</a></tt> and '<tt><a
href="#i_store">store</a></tt>' by getting a pointer to a field with the '<tt><a
<tr><td><tt>{ int, int, int }</tt></td><td>: a triple of three <tt>int</tt>
values</td></tr>
-<tr><td><tt>{ float, int (int *) * }</tt></td><td>: A pair, where the first
+<tr><td><tt>{ float, int (int) * }</tt></td><td>: A pair, where the first
element is a <tt>float</tt> and the second element is a <a
href="#t_pointer">pointer</a> to a <a href="t_function">function</a> that takes
an <tt>int</tt>, returning an <tt>int</tt>.</td></tr>
and global variables are global values. Global values are represented by a
pointer to a memory location (in this case, a pointer to an array of char, and a
pointer to a function), and can be either "internal" or externally accessible
-(which corresponds to the static keyword in C, when used at
function scope).<p>
+(which corresponds to the static keyword in C, when used at
global scope).<p>
For example, since the "<tt>.LC0</tt>" variable is defined to be internal, if
another module defined a "<tt>.LC0</tt>" variable and was linked with this one,
one of the two would be renamed, preventing a collision. Since "<tt>main</tt>"
-and "<tt>puts</tt>" are external (lacking "<tt>internal</tt>" declarations),
-they are accessible outside of the current module. It is illegal for a function
-declaration to be "<tt>internal</tt>".<p>
+and "<tt>puts</tt>" are external (i.e., lacking "<tt>internal</tt>"
+declarations), they are accessible outside of the current module. It is illegal
+
for a function declaration to be "<tt>internal</tt>".<p>
<!-- ======================================================================= -->
</b></font></td></tr></table><ul>
Global variables define regions of memory allocated at compilation time instead
-of runtime. Global variables, may optionally be initialized. A variable may be
-defined as a global "constant", which indicates that the contents of the
+of run-time. Global variables may optionally be initialized. A variable may
+be defined as a global "constant", which indicates that the contents of the
variable will never be modified (opening options for optimization). Constants
must always have an initial value.<p>
-As SSA values, global variables define pointer values that are in scope in
-(i.e. they dominate) all basic blocks in the program. Global variables always
-define a pointer to their "content" type because they describe a region of
-memory, and all memory objects in LLVM are accessed through pointers.<p>
+As SSA values, global variables define pointer values that are in scope
+(i.e. they dominate) for all basic blocks in the program. Global variables
+always define a pointer to their "content" type because they describe a region
+
of memory, and all memory objects in LLVM are accessed through pointers.<p>
<!-- *********************************************************************** -->
The LLVM instruction set consists of several different classifications of
-instructions: <a href="#terminators">terminator instructions</a>, a <a
-href="#unaryops">unary instruction</a>, <a href="#binaryops">binary
-instructions</a>, <a href="#memoryops">memory instructions</a>, and <a
-href="#otherops">other instructions</a>.<p>
+instructions: <a href="#terminators">terminator instructions</a>, <a
+href="#binaryops">binary instructions</a>, <a href="#memoryops">memory
+instructions</a>, and <a href="#otherops">other instructions</a>.<p>
<!-- ======================================================================= -->
</b></font></td></tr></table><ul>
As mentioned <a href="#functionstructure">previously</a>, every basic block in a
-program ends with a "Terminator" instruction, which indicates where control flow
-should go now that this basic block has been completely executed. These
-terminator instructions typically yield a '<tt>void</tt>' value: they produce
-control flow, not values (the one exception being the '<a
-
href="#i_invoke"><tt>invoke</tt></a>' instruction).<p>
+program ends with a "Terminator" instruction, which indicates which block should
+be executed after the current block is finished. These terminator instructions
+typically yield a '<tt>void</tt>' value: they produce control flow, not values
+(the one exception being the '<a href="#i_invoke"><tt>invoke</tt></a>'
+instruction).<p>
There are four different terminator instructions: the '<a
href="#i_ret"><tt>ret</tt></a>' instruction, the '<a
to label <normal label> except label <exception label>
</pre>
-<h5>Overview:</h5> The '<tt>invoke</tt>' instruction is used to cause control
-flow to transfer to a specified function, with the possibility of control flow
-transfer to either the '<tt>normal label</tt>' label or the '<tt>exception
-label</tt>'. The '<tt><a href="#i_call">call</a></tt>' instruction is closely
-related, but guarantees that control flow either never returns from the called
-function, or that it returns to the instruction succeeding the '<tt><a
-href="#i_call">call</a></tt>' instruction.<p>
+<h5>Overview:</h5>
+
+The '<tt>invoke</tt>' instruction is used to cause control flow to transfer to a
+specified function, with the possibility of control flow transfer to either the
+'<tt>normal label</tt>' label or the '<tt>exception label</tt>'. The '<tt><a
+href="#i_call">call</a></tt>' instruction is closely related, but guarantees
+that control flow either never returns from the called function, or that it
+returns to the instruction following the '<tt><a href="#i_call">call</a></tt>'
+instruction.<p>
<h5>Arguments:</h5>
function to be invoked.
<li>'<tt>function args</tt>': argument list whose types match the function
-signature argument types.
+signature argument types. If the function signature indicates the function
+accepts a variable number of arguments, the extra arguments can be specified.
<li>'<tt>normal label</tt>': the label reached when the called function executes
a '<tt><a href="#i_ret">ret</a></tt>' instruction.
Additionally, this is important for implementation of '<tt>catch</tt>' clauses
in high-level languages that support them.<p>
-For a more comprehensive explanation of this instruction look in the llvm/docs/2001-05-18-ExceptionHandling.txt document.<p>
+<!-- For a more comprehensive explanation of how this instruction is used, look in the llvm/docs/2001-05-18-ExceptionHandling.txt document.<p> -->
<h5>Example:</h5>
<pre>
-<!-- ======================================================================= -->
-</ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
-<tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
-<a name="unaryops">Unary Operations
-</b></font></td></tr></table><ul>
-
-Unary operators are used to do a simple operation to a single value.<p>
-
-There is only one unary operator: the '<a href="#i_not"><tt>not</tt></a>' instruction.<p>
-
-
-<!-- _______________________________________________________________________ -->
-</ul><a name="i_not"><h4><hr size=0>'<tt>not</tt>' Instruction</h4><ul>
-
-<h5>Syntax:</h5>
-<pre>
- <result> = not <ty> <var> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-The '<tt>not</tt>' instruction returns the bitwise complement of its operand.<p>
-
-<h5>Arguments:</h5>
-The single argument to '<tt>not</tt>' must be of of <a href="#t_integral">integral</a> type.<p>
-
-
-<h5>Semantics:</h5> The '<tt>not</tt>' instruction returns the bitwise
-complement (AKA ones complement) of an <a href="#t_integral">integral</a>
-type.<p>
-
-<pre>
- <result> = xor bool true, <var> <i>; yields {bool}:result</i>
-</pre>
-
-<h5>Example:</h5>
-<pre>
- %x = not int 1 <i>; {int}:x is now equal to -2</i>
- %x = not bool true <i>; {bool}:x is now equal to false</i>
-</pre>
-
-
-
<!-- ======================================================================= -->
</ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
<a name="binaryops">Binary Operations
The two arguments to the '<tt>add</tt>' instruction must be either <a href="#t_integral">integral</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The value produced is the integral or floating point sum of the two operands.<p>
<h5>Example:</h5>
<pre>
values. Both arguments must have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The value produced is the integral or floating point difference of the two
+operands.<p>
<h5>Example:</h5>
<pre>
The two arguments to the '<tt>mul</tt>' instruction must be either <a href="#t_integral">integral</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The value produced is the integral or floating point product of the two
+operands.<p>
There is no signed vs unsigned multiplication. The appropriate action is taken
based on the type of the operand. <p>
values. Both arguments must have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The value produced is the integral or floating point quotient of the two
+operands.<p>
<h5>Example:</h5>
<pre>
The two arguments to the '<tt>rem</tt>' instruction must be either <a href="#t_integral">integral</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
<h5>Semantics:</h5>
-TODO: remainder or modulus?<p>
-...<p>
+
+This returns the <i>remainder</i> of a division (where the result has the same
+sign as the divisor), not the <i>modulus</i> (where the result has the same sign
+as the dividend) of a value. For more information about the difference, see: <a
+href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The Math
+Forum</a>.<p>
<h5>Example:</h5>
<pre>
<result> = setge <ty> <var1>, <var2> <i>; yields {bool}:result</i>
</pre>
-<h5>Overview:</h5>
-
The '<tt>set<i>cc</i></tt>' family of instructions returns a boolean value based on a comparison of their two operands.<p>
+<h5>Overview:</h5> The '<tt>set<i>cc</i></tt>' family of instructions returns a
+boolean value based on a comparison of their two operands.<p>
<h5>Arguments:</h5> The two arguments to the '<tt>set<i>cc</i></tt>'
instructions must be of <a href="#t_firstclass">first class</a> or <a
href="#t_pointer">pointer</a> type (it is not possible to compare
'<tt>label</tt>'s, '<tt>array</tt>'s, '<tt>structure</tt>' or '<tt>void</tt>'
-values). Both arguments must have identical types.<p>
+values
, etc...). Both arguments must have identical types.<p>
-The '<tt>setlt</tt>', '<tt>setgt</tt>', '<tt>setle</tt>', and '<tt>setge</tt>' instructions do not operate on '<tt>bool</tt>' typed arguments.<p>
+The '<tt>setlt</tt>', '<tt>setgt</tt>', '<tt>setle</tt>', and '<tt>setge</tt>'
+instructions do not operate on '<tt>bool</tt>' typed arguments.<p>
<h5>Semantics:</h5>
-The '<tt>seteq</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if both operands are equal.<br>
-The '<tt>setne</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if both operands are unequal.<br>
-The '<tt>setlt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if the first operand is less than the second operand.<br>
-The '<tt>setgt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if the first operand is greater than the second operand.<br>
-The '<tt>setle</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if the first operand is less than or equal to the second operand.<br>
-The '<tt>setge</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if the first operand is greater than or equal to the second operand.<p>
+
+The '<tt>seteq</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+both operands are equal.<br>
+
+The '<tt>setne</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+both operands are unequal.<br>
+
+The '<tt>setlt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+the first operand is less than the second operand.<br>
+
+The '<tt>setgt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+the first operand is greater than the second operand.<br>
+
+The '<tt>setle</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+the first operand is less than or equal to the second operand.<br>
+
+The '<tt>setge</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+the first operand is greater than or equal to the second operand.<p>
<h5>Example:</h5>
<pre>
The '<tt>and</tt>' instruction returns the bitwise logical and of its two operands.<p>
<h5>Arguments:</h5>
-The two arguments to the '<tt>and</tt>' instruction must be either <a href="#t_integral">integral</a> or <a href="#t_bool"><tt>bool</tt></a> values. Both arguments must have identical types.<p>
+
+The two arguments to the '<tt>and</tt>' instruction must be either <a
+href="#t_integral">integral</a> or <tt>bool</tt> values. Both arguments must
+have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The truth table used for the '<tt>and</tt>' instruction is:<p>
+
+<center><table border=1 cellspacing=0 cellpadding=4>
+<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
+<tr><td>0</td> <td>0</td> <td>0</td></tr>
+<tr><td>0</td> <td>1</td> <td>0</td></tr>
+<tr><td>1</td> <td>0</td> <td>0</td></tr>
+<tr><td>1</td> <td>1</td> <td>1</td></tr>
+</table></center><p>
<h5>Example:</h5>
<h5>Arguments:</h5>
The two arguments to the '<tt>or</tt>' instruction must be either <a
-href="#t_integral">integral</a> or <a href="#t_bool"><tt>bool</tt></a> values.
-
Both arguments must have identical types.<p>
+href="#t_integral">integral</a> or <tt>bool</tt> values. Both arguments must
+have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The truth table used for the '<tt>or</tt>' instruction is:<p>
+
+<center><table border=1 cellspacing=0 cellpadding=4>
+<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
+<tr><td>0</td> <td>0</td> <td>0</td></tr>
+<tr><td>0</td> <td>1</td> <td>1</td></tr>
+<tr><td>1</td> <td>0</td> <td>1</td></tr>
+<tr><td>1</td> <td>1</td> <td>1</td></tr>
+</table></center><p>
<h5>Example:</h5>
<h5>Arguments:</h5>
The two arguments to the '<tt>xor</tt>' instruction must be either <a
-href="#t_integral">integral</a> or <a href="#t_bool"><tt>bool</tt></a> values.
-
Both arguments must have identical types.<p>
+href="#t_integral">integral</a> or <tt>bool</tt> values. Both arguments must
+have identical types.<p>
<h5>Semantics:</h5>
-...<p>
+
+The truth table used for the '<tt>xor</tt>' instruction is:<p>
+
+<center><table border=1 cellspacing=0 cellpadding=4>
+<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
+<tr><td>0</td> <td>0</td> <td>0</td></tr>
+<tr><td>0</td> <td>1</td> <td>1</td></tr>
+<tr><td>1</td> <td>0</td> <td>1</td></tr>
+<tr><td>1</td> <td>1</td> <td>0</td></tr>
+</table></center><p>
<h5>Example:</h5>
'<tt>ubyte</tt>' type.<p>
<h5>Semantics:</h5>
-... 0 bits are shifted into the emptied bit positions...<p>
+
+The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.<p>
<h5>Example:</h5>
The first argument to the '<tt>shr</tt>' instruction must be an <a href="#t_integral">integral</a> type. The second argument must be an '<tt>ubyte</tt>' type.<p>
<h5>Semantics:</h5>
-... if the first argument is a <a href="#t_signed">signed</a> type, the most significant bit is duplicated in the newly free'd bit positions. If the first argument is unsigned, zeros shall fill the empty positions...<p>
+
+If the first argument is a <a href="#t_signed">signed</a> type, the most
+significant bit is duplicated in the newly free'd bit positions. If the first
+argument is unsigned, zero bits shall fill the empty positions.<p>
<h5>Example:</h5>
<pre>
<a name="memoryops">Memory Access Operations
</b></font></td></tr></table><ul>
-Accessing memory in SSA form is, well, sticky at best. This section describes how to read
and write memory in LLVM.<p>
+Accessing memory in SSA form is, well, sticky at best. This section describes how to read
, write, allocate and free memory in LLVM.<p>
<!-- _______________________________________________________________________ -->
<h5>Arguments:</h5>
-'<tt>value</tt>' shall be a pointer value that points to a value that was allocated with the '<tt><a href="#i_malloc">malloc</a></tt>' instruction.<p>
+'<tt>value</tt>' shall be a pointer value that points to a value that was
+allocated with the '<tt><a href="#i_malloc">malloc</a></tt>' instruction.<p>
<h5>Semantics:</h5>
-Memory is available for use after this point. The contents of the '<tt>value</tt>' pointer are undefined after this instruction.<p>
+Access to the memory pointed to by the pointer is not longer defined after this instruction executes.<p>
<h5>Example:</h5>
<pre>
<h5>Overview:</h5>
The '<tt>getelementptr</tt>' instruction is used to get the address of a
-subelement of an aggregate data structure. In addition to being present as an
-explicit instruction, the '<tt>getelementptr</tt>' functionality is present in
-both the '<tt><a href="#i_load">load</a></tt>' and '<tt><a
-href="#i_store">store</a></tt>' instructions to allow more compact specification
-of common expressions.<p>
+subelement of an aggregate data structure.<p>
<h5>Arguments:</h5>
'<tt>getelementptr</tt>' instruction is used to index down through the type
levels of a structure.<p>
-TODO.
+For example, lets consider a C code fragment and how it gets compiled to
+LLVM:<p>
+
+<pre>
+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>
+
+The LLVM code generated by the GCC frontend is:
+
+<pre>
+%RT = type { sbyte, [10 x [20 x int]], sbyte }
+%ST = type { int, double, %RT }
+
+int* "foo"(%ST* %s) {
+ %reg = getelementptr %ST* %s, uint 1, ubyte 2, ubyte 1, uint 5, uint 13
+ ret int* %reg
+}
+</pre>
<h5>Semantics:</h5>
+The index types specified for the '<tt>getelementptr</tt>' instruction depend on
+the pointer type that is being index into. <a href="t_pointer">Pointer</a> and
+<a href="t_array">array</a> types require '<tt>uint</tt>' values, and <a
+href="t_struct">structure</a> types require '<tt>ubyte</tt>'
+<b>constants</b>.<p>
+
+In the example above, the first index is indexing into the '<tt>%ST*</tt>' type,
+which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ int, double, %RT }</tt>'
+type, a structure. The second index indexes into the third element of the
+structure, yielding a '<tt>%RT</tt>' = '<tt>{ sbyte, [10 x [20 x int]], sbyte
+}</tt>' type, another structure. The third index indexes into the second
+element of the structure, yielding a '<tt>[10 x [20 x int]]</tt>' type, an
+array. The two dimensions of the array are subscripted into, yielding an
+'<tt>int</tt>' type. The '<tt>getelementptr</tt>' instruction return a pointer
+to this element, thus yielding a '<tt>int*</tt>' type.<p>
+
+Note that it is perfectly legal to index partially through a structure,
+returning a pointer to an inner element. Because of this, the LLVM code for the
+given testcase is equivalent to:<p>
+
+<pre>
+int* "foo"(%ST* %s) {
+ %t1 = getelementptr %ST* %s , uint 1 <i>; yields %ST*:%t1</i>
+ %t2 = getelementptr %ST* %t1, uint 0, ubyte 2 <i>; yields %RT*:%t2</i>
+ %t3 = getelementptr %RT* %t2, uint 0, ubyte 1 <i>; yields [10 x [20 x int]]*:%t3</i>
+ %t4 = getelementptr [10 x [20 x int]]* %t3, uint 0, uint 5 <i>; yields [20 x int]*:%t4</i>
+ %t5 = getelementptr [20 x int]* %t4, uint 0, uint 13 <i>; yields int*:%t5</i>
+ ret int* %t5
+}
+</pre>
+
+
<h5>Example:</h5>
<pre>
- %aptr = getelementptr {int, [12 x ubyte]}* %sptr, 1 <i>; yields {[12 x ubyte]*}:aptr</i>
- %ub = load [12x ubyte]* %aptr, 4 <i>;yields {ubyte}:ub</i>
+ <i>; yields {[12 x ubyte]*}:aptr</i>
+ %aptr = getelementptr {int, [12 x ubyte]}* %sptr, uint 0, ubyte 1
</pre>
<!-- _______________________________________________________________________ -->
-</ul><a name="i_cast"><h4><hr size=0>'<tt>cast .. to</tt>' Instruction</h4><ul>
-
-<h1>TODO</h1>
-
-<a name="logical_integrals">
- Talk about what is considered true or false for integrals.
-
-
+</ul><a name="i_phi"><h4><hr size=0>'<tt>phi</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
+ <result> = phi <ty> [ <val0>, <label0>], ...
</pre>
<h5>Overview:</h5>
+The '<tt>phi</tt>' instruction is used to implement the φ node in the SSA
+graph representing the function.<p>
<h5>Arguments:</h5>
+The type of the incoming values are 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.<p>
+
+There must be no non-phi instructions between the start of a basic block and the
+PHI instructions: i.e. PHI instructions must be first in a basic block.<p>
<h5>Semantics:</h5>
+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>
<h5>Example:</h5>
+
<pre>
+Loop: ; Infinite loop that counts from 0 on up...
+ %indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
+ %nextindvar = add uint %indvar, 1
+ br label %Loop
</pre>
-
<!-- _______________________________________________________________________ -->
-</ul><a name="i_ca
ll"><h4><hr size=0>'<tt>call</tt>' Instruction</h4><ul>
+</ul><a name="i_ca
st"><h4><hr size=0>'<tt>cast .. to</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
-
+ <result> = cast <ty> <value> to <ty2> <i>; yields ty2</i>
</pre>
<h5>Overview:</h5>
+The '<tt>cast</tt>' instruction is used as the primitive means to convert
+integers to floating point, change data type sizes, and break type safety (by
+casting pointers).<p>
<h5>Arguments:</h5>
+The '<tt>cast</tt>' instruction takes a value to cast, which must be a first
+class value, and a type to cast it to, which must also be a first class type.<p>
<h5>Semantics:</h5>
+This instruction follows the C rules for explicit casts when determining how the
+data being cast must change to fit in its new container.<p>
-<h5>Example:</h5>
-<pre>
- %retval = call int %test(int %argc)
-</pre>
-
-
-<!-- _______________________________________________________________________ --></ul><a name="i_icall"><h3><hr size=0>'<tt>icall</tt>' Instruction</h3><ul>
-
-Indirect calls are desperately needed to implement virtual function tables (C++, java) and function pointers (C, C++, ...).<p>
+When casting to bool, any value that would be considered true in the context of
+a C '<tt>if</tt>' condition is converted to the boolean '<tt>true</tt>' values,
+all else are '<tt>false</tt>'.<p>
-A new instruction <tt>icall</tt> or similar should be introduced to represent an indirect call.<p>
+When extending an integral value from a type of one signness to another (for
+example '<tt>sbyte</tt>' to '<tt>ulong</tt>'), the value is sign-extended if the
+<b>source</b> value is signed, and zero-extended if the source value is
+unsigned.<p>
-Example:
+<h5>Example:</h5>
<pre>
- %retval = icall int %funcptr(int %arg1) <i>; yields {int}:%retval</i>
+ %X = cast int 257 to ubyte <i>; yields ubyte:1</i>
+ %Y = cast int 123 to bool <i>; yields bool:true</i>
</pre>
<!-- _______________________________________________________________________ -->
-</ul><a name="i_
phi"><h4><hr size=0>'<tt>phi</tt>' Instruction</h4><ul>
+</ul><a name="i_
call"><h4><hr size=0>'<tt>call</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
+ <result> = call <ty>* <fnptrval>(<param list>)
</pre>
<h5>Overview:</h5>
+The '<tt>call</tt>' instruction represents a simple function call.<p>
<h5>Arguments:</h5>
+This instruction requires several arguments:<p>
+<ol>
+
+<li>'<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>'<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>'<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.
+</ol>
<h5>Semantics:</h5>
+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>
-</pre>
+ %retval = call int %test(int %argc)
+ call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);
+</pre>
+<!--
-<!-- *********************************************************************** -->
+<!x- *********************************************************************** -x>
</ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
<tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
<a name="related">Related Work
</b></font></td></tr></table><ul>
-<!-- *********************************************************************** -->
+<!x- *********************************************************************** -x>
Codesigned virtual machines.<p>
<DD>This interview influenced the design and thought process behind LLVM in several ways, most notably the way that derived types are written in text format. See the question that starts with "you defined the C declarator syntax as an experiment that failed".<p>
</dl>
-<!-- _______________________________________________________________________ -->
+<!x- _______________________________________________________________________ -x>
</ul><a name="rw_vectorization"><h3><hr size=0>Vectorized Architectures</h3><ul>
<dl>
<dt><a href="http://www.nondot.org/~sabre/os/H1ChipFeatures/VISInstructionSetUsersManual.pdf">Sun VIS ISA</a>
<DD>Desciption here<p>
+<a name="rw_powerpc_simd">
+<dt>PowerPC Altivec
+<DD>Desciption here<p>
</dl>
more...
+-->
+
+
<!-- *********************************************************************** -->
</ul>
<!-- *********************************************************************** -->
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
<!-- hhmts start -->
-Last modified: Fri May 3 14:39:52 CDT 2002
+Last modified: Wed Aug 14 12:54:55 CDT 2002
<!-- hhmts end -->
</font>
</body></html>
projects / oota-llvm.git / blobdiff