From bffc86684e2d2742e6fb0757d8149189628d3760 Mon Sep 17 00:00:00 2001
From: Gordon Henriksen <gordonhenriksen@mac.com>
Date: Fri, 6 Mar 2009 02:42:47 +0000
Subject: Committing unsaved changes that should've been with r66237.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66242 91177308-0d34-0410-b5e6-96231b3b80d8
---
 docs/GarbageCollection.html | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

(limited to 'docs/GarbageCollection.html')

diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index 1508bcf223..ccf9162600 100644
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -525,15 +525,14 @@ for completeness. In this snippet, <tt>%object</tt> is the object pointer, and
     ;; Compute the derived pointer.
     %derived = getelementptr %object, i32 0, i32 2, i32 %n</pre></blockquote>
 
+<p>LLVM does not enforce this relationship between the object and derived
+pointer (although a <a href="#plugin">plugin</a> might). However, it would be
+an unusual collector that violated it.</p>
+
 <p>The use of these intrinsics is naturally optional if the target GC does
-require the corresponding barrier. If so, the GC plugin will replace the
-intrinsic calls with the corresponding <tt>load</tt> or <tt>store</tt>
-instruction if they are used.</p>
-
-<p>LLVM does not enforce any particular relationship between the object and
-derived pointer (although a <a href="#plugin">plugin</a> might). However, it
-would be unusual that the derived pointer not be a <tt>getelementptr</tt> of the
-object pointer.</p>
+require the corresponding barrier. Such a GC plugin will replace the intrinsic
+calls with the corresponding <tt>load</tt> or <tt>store</tt> instruction if they
+are used.</p>
 
 </div>
 
-- 
cgit v1.2.3