Update documentation to reflect:

* Changes in PHI node structure
* Intentions for load instruction to work with structures

llvm-svn: 22
This commit is contained in:
Chris Lattner 2001-06-11 15:03:43 +00:00
parent 5f46e8c9da
commit 7399a10ad5
2 changed files with 9 additions and 10 deletions

View file

@ -1,7 +1,7 @@
* Must update PHI node to have a pair between predecessor and value.
* pred/succ iterators on basic blocks don't handle switch statements correctly
* Enhance BB to make predecessor handling easier (to update PHI nodes)
* Provide a pass that eliminates critical edges from the CFG
* Provide a print hook to print out xvcg format files for vis
* Provide a print pass to print out xvcg format files for vis
* I need to provide an option to the bytecode loader to ignore memory
dependance edges. Instead, the VM would just treat memory operations
(load, store, getfield, putfield, call) as pinned instructions.
@ -13,8 +13,8 @@
structure size to 256 members. This can be fixed later by either:
1. adding varient that takes ushort
2. Splitting structures into nested structures each of half size
<float> %f = loadfield *{int, {float}} Str, ubyte 1, ubyte 0
storefield float %f, *{int, {float}} Str, ubyte 1, ubyte 0
<float> %f = load *{int, {float}} Str, 1, 0
store float %f, *{int, {float}} Str, 1, 0
* I'm noticing me writing a lot of code that looks like this (dtor material here):
ConstPool.dropAllReferences();
ConstPool.delete_all();
@ -42,8 +42,6 @@
* pointer int *
* "packed format", like this: [4 x sbyte]: Packed SIMD datatype
* Maybe 'tailcall' also?
* It might be nice to support enumerations of some sort... especially for use
as a compiler IR
* Include a method level bytecode block that defines a mapping between values
and registers that defines a minimally register allocated code. This can
make me finally address how to encode extensions in assembly.

View file

@ -1045,6 +1045,7 @@ Memory is allocated, a pointer is returned. '<tt>alloca</tt>'d memory is automa
<pre>
&lt;result&gt; = load &lt;ty&gt;* &lt;pointer&gt; <i>; yields {ty}:result</i>
&lt;result&gt; = load &lt;ty&gt;* &lt;arrayptr&gt;, uint &lt;idx&gt; <i>; yields {ty}:result</i>
&lt;result&gt; = load &lt;ty&gt;* &lt;structptr&gt;{, &lt;idx&gt;}* <i>; yields field type</i>
</pre>
<h5>Overview:</h5>
@ -1052,9 +1053,9 @@ The '<tt>load</tt>' instruction is used to read from memory.<p>
<h5>Arguments:</h5>
There are two forms of the '<tt>load</tt>' instruction: one for reading from a general pointer, and one for reading from a pointer to an array.<p>
There are three forms of the '<tt>load</tt>' instruction: one for reading from a general pointer, one for reading from a pointer to an array, and one for reading from a pointer to a structure.<p>
In the first form, '<tt>&lt;ty&gt;</tt>' may be any pointer type. If it is a pointer to an array, the first (zeroth) element is read from). In the second form, '<tt>&lt;ty&gt;</tt>' must be a pointer to an array. No bounds checking is performed on array reads.<p>
In the first form, '<tt>&lt;ty&gt;</tt>' may be any pointer type. If it is a pointer to an array, the first (zeroth) element is read from). In the second form, '<tt>&lt;ty&gt;</tt>' must be a pointer to an array. No bounds checking is performed on array reads. In the third form, the pointer must point to a (possibly nested) structure. There shall be one ubyte argument for each level of dereferencing involved.<p>
<h5>Semantics:</h5>
@ -1070,7 +1071,7 @@ In the first form, '<tt>&lt;ty&gt;</tt>' may be any pointer type. If it is a po
<a href="#i_store">store</a> [4 x ubyte]* %array,
uint 4, ubyte 124
%val = load [4 x ubyte]* %array, uint 4 <i>; yields {ubyte}:val = ubyte 124</i>
%val = load {{int, float}}* %stptr, 0, 1 <i>; yields {float}:val</i>
</pre>
@ -1370,7 +1371,7 @@ more...
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
<!-- hhmts start -->
Last modified: Thu May 31 17:36:39 CDT 2001
Last modified: Mon Jun 11 09:30:45 CDT 2001
<!-- hhmts end -->
</font>
</body></html>