[llvm-commits] [llvm] r50205 - in /llvm/trunk/docs: GarbageCollection.html LangRef.html

[Chris Lattner]

Author: lattner
Date: Thu Apr 24 00:59:56 2008
New Revision: 50205

URL: http://llvm.org/viewvc/llvm-project?rev=50205&view=rev
Log:
Doc updates/edits, contributed by Terence Parr!

Modified:
    llvm/trunk/docs/GarbageCollection.html
    llvm/trunk/docs/LangRef.html

Modified: llvm/trunk/docs/GarbageCollection.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GarbageCollection.html?rev=50205&r1=50204&r2=50205&view=diff

==============================================================================
--- llvm/trunk/docs/GarbageCollection.html (original)
+++ llvm/trunk/docs/GarbageCollection.html Thu Apr 24 00:59:56 2008
@@ -151,7 +151,7 @@
 <div class="doc_text">
 
 <p>LLVM's intermediate representation provides <a href="#intrinsics">garbage
-collection intrinsics</a> which offer support for a broad class of
+collection intrinsics</a> that offer support for a broad class of
 collector models. For instance, the intrinsics permit:</p>
 
 <ul>
@@ -280,8 +280,8 @@
 
 <div class="doc_text">
 
-<p>The SemiSpace runtime implements with the <a href="runtime">suggested
-runtime interface</a> and is compatible the ShadowStack backend.</p>
+<p>The SemiSpace runtime implements the <a href="runtime">suggested
+runtime interface</a> and is compatible with the ShadowStack backend.</p>
 
 <p>SemiSpace is a very simple copying collector. When it starts up, it
 allocates two blocks of memory for the heap. It uses a simple bump-pointer
@@ -321,7 +321,7 @@
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
-  <a name="core">Core support</a>
+  <a name="core">Core support</a><a name="intrinsics"></a>
 </div>
 <!-- *********************************************************************** -->
 
@@ -351,12 +351,12 @@
 <div class="doc_text">
 
 <p>The <tt>gc</tt> function attribute is used to specify the desired collector
-algorithm to the compiler. It is equivalent to specify the collector name
+algorithm to the compiler. It is equivalent to specifying the collector name
 programmatically using the <tt>setCollector</tt> method of
 <tt>Function</tt>.</p>
 
 <p>Specifying the collector on a per-function basis allows LLVM to link together
-programs which use different garbage collection algorithms.</p>
+programs that use different garbage collection algorithms.</p>
 
 </div>
 
@@ -372,7 +372,7 @@
 <div class="doc_text">
 
 <p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM of a pointer
-variable on the stack. The first argument <b>must</b> be an alloca instruction
+variable on the stack. The first argument <b>must</b> be a value referring to an alloca instruction
 or a bitcast of an alloca. The second contains a pointer to metadata that
 should be associated with the pointer, and <b>must</b> be a constant or global
 value address. If your target collector uses tags, use a null pointer for
@@ -399,7 +399,7 @@
    ;; Tell LLVM that the stack space is a stack root.
    ;; Java has type-tags on objects, so we pass null as metadata.
    %tmp = bitcast %Object** %X to i8**
-   call void %llvm.gcroot(%i8** %X, i8* null)
+   call void %llvm.gcroot(i8** %X, i8* null)
    ...
 
    ;; "CodeBlock" is the block corresponding to the start
@@ -439,16 +439,16 @@
 for completeness. In this snippet, <tt>%object</tt> is the object pointer, and 
 <tt>%derived</tt> is the derived pointer:</p>
 
-<blockquote><pre
->    ;; An array type.
+<blockquote><pre>
+    ;; An array type.
     %class.Array = type { %class.Object, i32, [0 x %class.Object*] }
-...
+    ...
 
     ;; Load the object pointer from a gcroot.
     %object = load %class.Array** %object_addr
 
     ;; Compute the derived pointer.
-    %derived = getelementptr %obj, i32 0, i32 2, i32 %n</pre></blockquote>
+    %derived = getelementptr %object, i32 0, i32 2, i32 %n</pre></blockquote>
 
 </div>
 
@@ -594,7 +594,7 @@
 generator that iterates through all of the GC roots on the stack, calling the
 specified function pointer with each record. For each GC root, the address of
 the pointer and the meta-data (from the <a
-href="#roots"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
+href="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
 </p>
 </div>
 
@@ -1329,7 +1329,7 @@
 <a href="#explicit"><tt>llvm_gc_collect</tt></a> functions. To do this, it will
 probably have to <a href="#traceroots">trace through the roots
 from the stack</a> and understand the <a href="#gcdescriptors">GC descriptors
-for heap objects</a>. Luckily, there are some <a href="#gcimpls">example
+for heap objects</a>. Luckily, there are some <a href="#usage">example
 implementations</a> available.
 </p>
 </div>
@@ -1366,7 +1366,7 @@
 <p>The LLVM garbage collectors are capable of supporting all of these styles of
 language, including ones that mix various implementations. To do this, it
 allows the source-language to associate meta-data with the <a
-href="#roots">stack roots</a>, and the heap tracing routines can propagate the
+href="#gcroot">stack roots</a>, and the heap tracing routines can propagate the
 information. In addition, LLVM allows the front-end to extract GC information
 in any form from a specific object pointer (this supports situations #1 and #3).
 </p>

Modified: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=50205&r1=50204&r2=50205&view=diff

==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html Thu Apr 24 00:59:56 2008
@@ -3020,8 +3020,8 @@
 '<tt>getelementptr</tt>' instruction is used to index down through the type
 levels of a structure or to a specific index in an array.  When indexing into a
 structure, only <tt>i32</tt> integer constants are allowed.  When indexing 
-into an array or pointer, only integers of 32 or 64 bits are allowed, and will 
-be sign extended to 64-bit values.</p>
+into an array or pointer, only integers of 32 or 64 bits are allowed; 32-bit 
+values will be sign extended to 64-bits if required.</p>
 
 <p>For example, let's consider a C code fragment and how it gets
 compiled to LLVM:</p>
@@ -3096,7 +3096,7 @@
 
 <p>Note that it is undefined to access an array out of bounds: array and 
 pointer indexes must always be within the defined bounds of the array type.
-The one exception for this rules is zero length arrays.  These arrays are
+The one exception for this rule is zero length arrays.  These arrays are
 defined to be accessible as variable length arrays, which requires access
 beyond the zero'th element.</p>
 
@@ -4207,7 +4207,7 @@
 
 <h5>Semantics:</h5>
 
-<p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
+<p>At runtime, a call to this intrinsic stores a null pointer into the "ptrloc"
 location.  At compile-time, the code generator generates information to allow
 the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>'
 intrinsic may only be used in a function which <a href="#gc">specifies a GC