<li><a href="#t_classifications">Type Classifications</a></li>
<li><a href="#t_primitive">Primitive Types</a>
<ol>
+ <li><a href="#t_integer">Integer Type</a></li>
<li><a href="#t_floating">Floating Point Types</a></li>
<li><a href="#t_void">Void Type</a></li>
<li><a href="#t_label">Label Type</a></li>
</li>
<li><a href="#t_derived">Derived Types</a>
<ol>
- <li><a href="#t_integer">Integer Type</a></li>
<li><a href="#t_array">Array Type</a></li>
<li><a href="#t_function">Function Type</a></li>
<li><a href="#t_pointer">Pointer Type</a></li>
<p>The <a href="#t_firstclass">first class</a> types are perhaps the most
important. Values of these types are the only ones which can be produced by
- instructions, passed as arguments, or used as operands to instructions.</p>
+ instructions.</p>
</div>
</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 type that simply specifies an arbitrary
+ bit width for the integer type desired. Any bit width from 1 bit to
+ 2<sup>23</sup>-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></td>
+ <td class="left">a single-bit integer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i32</tt></td>
+ <td class="left">a 32-bit integer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i1942652</tt></td>
+ <td class="left">a really big integer of over 1 million bits.</td>
+ </tr>
+</table>
+
+<p>Note that the code generator does not yet support large integer types to be
+ used as function return types. The specific limit on how large a return type
+ the code generator can currently handle is target-dependent; currently it's
+ often 64 bits for 32-bit targets and 128 bits for 64-bit targets.</p>
+
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_floating">Floating Point Types</a> </div>
<div class="doc_text">
<h5>Overview:</h5>
-<p>The metadata type represents embedded metadata. The only derived type that
- may contain metadata is <tt>metadata*</tt> or a function type that returns or
- takes metadata typed parameters, but not pointer to metadata types.</p>
+<p>The metadata type represents embedded metadata. No derived types may be
+ created from metadata except for <a href="#t_function">function</a>
+ arguments.
<h5>Syntax:</h5>
<pre>
<p>The real power in LLVM comes from the derived types in the system. This is
what allows a programmer to represent arrays, functions, pointers, and other
- useful types. Note that these derived types may be recursive: For example,
- it is possible to have a two dimensional array.</p>
-
-</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></td>
- <td class="left">a single-bit integer.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i32</tt></td>
- <td class="left">a 32-bit integer.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i1942652</tt></td>
- <td class="left">a really big integer of over 1 million bits.</td>
- </tr>
-</table>
-
-<p>Note that the code generator does not yet support large integer types to be
- used as function return types. The specific limit on how large a return type
- the code generator can currently handle is target-dependent; currently it's
- often 64 bits for 32-bit targets and 128 bits for 64-bit targets.</p>
+ useful types. Each of these types contain one or more element types which
+ may be a primitive type, or another derived type. For example, it is
+ possible to have a two dimensional array, using an array as the element type
+ of another array.</p>
</div>
<h5>Syntax:</h5>
<pre>
- <returntype list> (<parameter list>)
+ <returntype> (<parameter list>)
</pre>
<p>...where '<tt><parameter list></tt>' is a comma-separated list of type
which indicates that the function takes a variable number of arguments.
Variable argument functions can access their arguments with
the <a href="#int_varargs">variable argument handling intrinsic</a>
- functions. '<tt><returntype list></tt>' is a comma-separated list of
- <a href="#t_firstclass">first class</a> type specifiers.</p>
+ functions. '<tt><returntype></tt>' is a any type except
+ <a href="#t_label">label</a>.</p>
<h5>Examples:</h5>
<table class="layout">
</td>
</tr><tr class="layout">
<td class="left"><tt>{i32, i32} (i32)</tt></td>
- <td class="left">A function taking an <tt>i32</tt>, returning two
- <tt>i32</tt> values as an aggregate of type <tt>{ i32, i32 }</tt>
+ <td class="left">A function taking an <tt>i32</tt>, returning a
+ <a href="#t_struct">structure</a> containing two <tt>i32</tt> values
</td>
</tr>
</table>
<dl>
<dt><b>Boolean constants</b></dt>
<dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid
- constants of the <tt><a href="#t_primitive">i1</a></tt> type.</dd>
+ constants of the <tt><a href="#t_integer">i1</a></tt> type.</dd>
<dt><b>Integer constants</b></dt>
<dd>Standard integers (such as '4') are constants of
Undefined values may be of any type (other than label or void) and be used
anywhere a constant is permitted.</p>
-<p>Undefined values are useful, because it indicates to the compiler that the
+<p>Undefined values are useful because they indicate to the compiler that the
program is well defined no matter what value is used. This gives the
compiler more freedom to optimize. Here are some examples of (potentially
surprising) transformations that are valid (in pseudo IR):</p>
<p>These logical operations have bits that are not always affected by the input.
For example, if "%X" has a zero bit, then the output of the 'and' operation will
always be a zero, no matter what the corresponding bit from the undef is. As
-such, it is unsafe to optimizer or assume that the result of the and is undef.
-However, it is safe to assume that all bits of the undef are 0, and optimize the
-and to 0. Likewise, it is safe to assume that all the bits of the undef operand
-to the or could be set, allowing the or to be folded to -1.</p>
+such, it is unsafe to optimize or assume that the result of the and is undef.
+However, it is safe to assume that all bits of the undef could be 0, and
+optimize the and to 0. Likewise, it is safe to assume that all the bits of
+the undef operand to the or could be set, allowing the or to be folded to
+-1.</p>
<div class="doc_code">
<pre>
"variable" doesn't actually <em>have a live range</em>. Instead, the value is
logically read from arbitrary registers that happen to be around when needed,
so the value is not neccesarily consistent over time. In fact, %A and %C need
-to have the same semantics of the core LLVM "replace all uses with" concept
+to have the same semantics or the core LLVM "replace all uses with" concept
would not hold.</p>
<div class="doc_code">
not (currently) defined on SNaN's. However, in the second example, we can make
a more aggressive assumption: because the undef is allowed to be an arbitrary
value, we are allowed to assume that it could be zero. Since a divide by zero
-is has <em>undefined behavior</em>, we are allowed to assume that the operation
+has <em>undefined behavior</em>, we are allowed to assume that the operation
does not execute at all. This allows us to delete the divide and all code after
it: since the undefined operation "can't happen", the optimizer can assume that
it occurs in dead code.
<h5>Semantics:</h5>
<p>The '<tt>icmp</tt>' compares <tt>op1</tt> and <tt>op2</tt> according to the
condition code given as <tt>cond</tt>. The comparison performed always yields
- either an <a href="#t_primitive"><tt>i1</tt></a> or vector of <tt>i1</tt>
+ either an <a href="#t_integer"><tt>i1</tt></a> or vector of <tt>i1</tt>
result, as follows:</p>
<ol>
values based on comparison of its operands.</p>
<p>If the operands are floating point scalars, then the result type is a boolean
-(<a href="#t_primitive"><tt>i1</tt></a>).</p>
+(<a href="#t_integer"><tt>i1</tt></a>).</p>
<p>If the operands are floating point vectors, then the result type is a vector
of boolean with the same number of elements as the operands being
<p>The '<tt>fcmp</tt>' instruction compares <tt>op1</tt> and <tt>op2</tt>
according to the condition code given as <tt>cond</tt>. If the operands are
vectors, then the vectors are compared element by element. Each comparison
- performed always yields an <a href="#t_primitive">i1</a> result, as
+ performed always yields an <a href="#t_integer">i1</a> result, as
follows:</p>
<ol>
%ZZ = call zeroext i32 @bar() <i>; Return value is %zero extended</i>
</pre>
+<p>llvm treats calls to some functions with names and arguments that match the
+standard C99 library as being the C99 library functions, and may perform
+optimizations or generate code for them under that assumption. This is
+something we'd like to change in the future to provide better support for
+freestanding environments and non-C-based langauges.</p>
+
</div>
<!-- _______________________________________________________________________ -->
projects / oota-llvm.git / blobdiff