Continue refactoring inline asm code. If there is an earlyclobber output

[oota-llvm.git] / docs / GarbageCollection.html

diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index 744279bdf31364cee000602df22ac1d1bf663f12..0accd0c78a09796cb876e7eea47086c36e42a8b7 100644 (file)
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -65,8 +65,9 @@ conservative and accurate.</p>
 <p>Conservative garbage collection often does not require any special support
 from either the language or the compiler: it can handle non-type-safe
 programming languages (such as C/C++) and does not require any special
-information from the compiler.  The [LINK] Boehm collector is an example of a
-state-of-the-art conservative collector.</p>
+information from the compiler.  The
+<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm collector</a> is
+an example of a state-of-the-art conservative collector.</p>
 
 <p>Accurate garbage collection requires the ability to identify all pointers in
 the program at run-time (which requires that the source-language be type-safe in
@@ -234,8 +235,8 @@ zeroed-out block of memory of the appropriate size.</p>
 <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 +251,9 @@ tolerable.</p>
 <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 +344,8 @@ implementations</a> available.
 
 <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 +356,7 @@ pointer, then return.
 
 <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>
@@ -386,7 +388,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="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
+href="#roots"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
 </p>
 </div>
 
@@ -524,7 +526,7 @@ conference on LISP and functional programming.</p>
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+  <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$
 </address>