Update documentation for gc intrinsics change.  Contributed by
Tobias Nurmiranta


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15095 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index 744279b..8747e93 100644
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -234,8 +234,8 @@
 <div class="doc_text">
 
 <div class="doc_code"><tt>
-  sbyte *%llvm.gcread(sbyte **)<br>
-  void %llvm.gcwrite(sbyte*, sbyte**)
+  sbyte *%llvm.gcread(sbyte *, sbyte **)<br>
+  void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)
 </tt></div>
 
 <p>Several of the more interesting garbage collectors (e.g., generational
@@ -250,7 +250,9 @@
 <p>To support garbage collectors that use read or write barriers, LLVM provides
 the <tt>llvm.gcread</tt> and <tt>llvm.gcwrite</tt> intrinsics.  The first
 intrinsic has exactly the same semantics as a non-volatile LLVM load and the
-second has the same semantics as a non-volatile LLVM store.  At code generation
+second has the same semantics as a non-volatile LLVM store, with the
+additions that they also take a pointer to the start of the memory
+object as an argument.  At code generation
 time, these intrinsics are replaced with calls into the garbage collector
 (<tt><a href="#llvm_gc_readwrite">llvm_gc_read</a></tt> and <tt><a
 href="#llvm_gc_readwrite">llvm_gc_write</a></tt> respectively), which are then
@@ -341,8 +343,8 @@
 
 <div class="doc_text">
   <div class="doc_code"><tt>
-    void *llvm_gc_read(void **)<br>
-    void llvm_gc_write(void*, void**)
+    void *llvm_gc_read(void*, void **)<br>
+    void llvm_gc_write(void*, void *, void**)
  </tt></div>
 
 <p>
@@ -353,8 +355,7 @@
 
 <p>
 If an actual read or write barrier is needed, it should be straight-forward to
-implement it.  Note that we may add a pointer to the start of the memory object
-as a parameter in the future, if needed.
+implement it.
 </p>
 
 </div>