From 05d670971e5de3b199b0bbdcd36c4062b8c0065e Mon Sep 17 00:00:00 2001
From: Chris Lattner <sabre@nondot.org>
Date: Thu, 24 Apr 2008 05:59:56 +0000
Subject: Doc updates/edits, contributed by Terence Parr!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50205 91177308-0d34-0410-b5e6-96231b3b80d8
---
 docs/GarbageCollection.html | 30 +++++++++++++++---------------
 docs/LangRef.html           |  8 ++++----
 2 files changed, 19 insertions(+), 19 deletions(-)

(limited to 'docs')

diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index 0e97f02..6086a08 100644
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -151,7 +151,7 @@ support accurate garbage collection.</p>
 <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 @@ compatible runtime.</p>
 
 <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 @@ may use <tt>load</tt> and <tt>store</tt> instead of <tt>llvm.gcread</tt> and
 
 <!-- *********************************************************************** -->
 <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 @@ specified by the runtime.</p>
 <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 @@ programs which use different garbage collection algorithms.</p>
 <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 @@ Entry:
    ;; 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 @@ object). Accordingly, these intrinsics take both pointers as separate arguments
 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 @@ The <tt>llvm_cg_walk_gcroots</tt> function is a function provided by the code
 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 @@ href="#gcdescriptors">where pointers are located in heap objects</a>.</p>
 <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 @@ book-keeping is needed at all. This is common for Lisp-like languages.</li>
 <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>
diff --git a/docs/LangRef.html b/docs/LangRef.html
index 9679291..6591b27 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -3020,8 +3020,8 @@ provided depend on the type of the first pointer argument.  The
 '<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 @@ the LLVM code for the given testcase is equivalent to:</p>
 
 <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 @@ value address) contains the meta-data to be associated with the root.</p>
 
 <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
-- 
cgit v1.1