<li><a href="#t_opaque">Opaque Type</a></li>
</ol>
</li>
+ <li><a href="#t_uprefs">Type Up-references</a></li>
</ol>
</li>
<li><a href="#constants">Constants</a>
<dl>
- <dt><tt><b><a name="linkage_internal">internal</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_private">private</a></b></tt>: </dt>
- <dd>Global values with internal linkage are only directly accessible by
+ <dd>Global values with private linkage are only directly accessible by
objects in the current module. In particular, linking code into a module with
- an internal global value may cause the internal to be renamed as necessary to
- avoid collisions. Because the symbol is internal to the module, all
- references can be updated. This corresponds to the notion of the
+ an private global value may cause the private to be renamed as necessary to
+ avoid collisions. Because the symbol is private to the module, all
+ references can be updated. This doesn't show up in any symbol table in the
+ object file.
+ </dd>
+
+ <dt><tt><b><a name="linkage_internal">internal</a></b></tt>: </dt>
+
+ <dd> Similar to private, but the value shows as a local symbol (STB_LOCAL in
+ the case of ELF) in the object file. This corresponds to the notion of the
'<tt>static</tt>' keyword in C.
</dd>
<dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
or variable via a global pointer to a pointer that is set up by the DLL
exporting the symbol. On Microsoft Windows targets, the pointer name is
- formed by combining <code>_imp__</code> and the function or variable name.
+ formed by combining <code>__imp_</code> and the function or variable name.
</dd>
<dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt>
<dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
pointer to a pointer in a DLL, so that it can be referenced with the
<tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
- name is formed by combining <code>_imp__</code> and the function or variable
+ name is formed by combining <code>__imp_</code> and the function or variable
name.
</dd>
</div>
-
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="globalvars">Global Variables</a>
</tr>
</tbody>
</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>
<!-- _______________________________________________________________________ -->
length. This allows implementation of 'pascal style arrays' with the LLVM
type "{ i32, [0 x float]}", for example.</p>
+<p>Note that the code generator does not yet support large aggregate types
+to be used as function return types. The specific limit on how large an
+aggregate return type the code generator can currently handle is
+target-dependent, and also dependent on the aggregate element types.</p>
+
</div>
<!-- _______________________________________________________________________ -->
an <tt>i32</tt>.</td>
</tr>
</table>
+
+<p>Note that the code generator does not yet support large aggregate types
+to be used as function return types. The specific limit on how large an
+aggregate return type the code generator can currently handle is
+target-dependent, and also dependent on the aggregate element types.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<td class="left">Vector of 2 64-bit integer values.</td>
</tr>
</table>
+
+<p>Note that the code generator does not yet support large vector types
+to be used as function return types. The specific limit on how large a
+vector return type codegen can currently handle is target-dependent;
+currently it's often a few times longer than a hardware vector register.</p>
+
</div>
<!-- _______________________________________________________________________ -->
</table>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="t_uprefs">Type Up-references</a>
+</div>
+
+<div class="doc_text">
+<h5>Overview:</h5>
+<p>
+An "up reference" allows you to refer to a lexically enclosing type without
+requiring it to have a name. For instance, a structure declaration may contain a
+pointer to any of the types it is lexically a member of. Example of up
+references (with their equivalent as named type declarations) include:</p>
+
+<pre>
+ { \2 * } %x = type { %t* }
+ { \2 }* %y = type { %y }*
+ \1* %z = type %z*
+</pre>
+
+<p>
+An up reference is needed by the asmprinter for printing out cyclic types when
+there is no declared name for a type in the cycle. Because the asmprinter does
+not want to print out an infinite type string, it needs a syntax to handle
+recursive types that have no names (all names are optional in llvm IR).
+</p>
+
+<h5>Syntax:</h5>
+<pre>
+ \<level>
+</pre>
+
+<p>
+The level is the count of the lexical type that is being referred to.
+</p>
+
+<h5>Examples:</h5>
+
+<table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>\1*</tt></td>
+ <td class="left">Self-referential pointer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>{ { \3*, i8 }, i32 }</tt></td>
+ <td class="left">Recursive structure where the upref refers to the out-most
+ structure.</td>
+ </tr>
+</table>
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="constants">Constants</a> </div>
ret void <i>; Return from a void function</i>
ret { i32, i8 } { i32 4, i8 2 } <i>; Return an aggregate of values 4 and 2</i>
</pre>
+
+<p>Note that the code generator does not yet fully support large
+ return values. The specific sizes that are currently supported are
+ dependent on the target. For integers, on 32-bit targets the limit
+ is often 64 bits, and on 64-bit targets the limit is often 128 bits.
+ For aggregate types, the current limits are dependent on the element
+ types; for example targets are often limited to 2 total integer
+ elements and 2 total floating-point elements.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
%array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
%array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
</pre>
+
+<p>Note that the code generator does not yet respect the
+ alignment value.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<result> = icmp ule i16 -4, 5 <i>; yields: result=false</i>
<result> = icmp sge i16 4, 5 <i>; yields: result=false</i>
</pre>
+
+<p>Note that the code generator does not yet support vector types with
+ the <tt>icmp</tt> instruction.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<result> = fcmp olt float 4.0, 5.0 <i>; yields: result=true</i>
<result> = fcmp ueq double 1.0, 2.0 <i>; yields: result=false</i>
</pre>
+
+<p>Note that the code generator does not yet support vector types with
+ the <tt>fcmp</tt> instruction.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<pre>
%X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
</pre>
+
+<p>Note that the code generator does not yet support conditions
+ with vector type.</p>
+
</div>
<p>See the <a href="#int_varargs">variable argument processing</a> section.</p>
+<p>Note that the code generator does not yet fully support va_arg
+ on many targets. Also, it does not currently support va_arg with
+ aggregate types on any target.</p>
+
</div>
<!-- *********************************************************************** -->
projects / oota-llvm.git / blobdiff