[llvm-commits] [llvm] r66242 - /llvm/trunk/docs/GarbageCollection.html
Gordon Henriksen
gordonhenriksen at mac.com
Thu Mar 5 18:42:47 PST 2009
Author: gordon
Date: Thu Mar 5 20:42:47 2009
New Revision: 66242
URL: http://llvm.org/viewvc/llvm-project?rev=66242&view=rev
Log:
Committing unsaved changes that should've been with r66237.
Modified:
llvm/trunk/docs/GarbageCollection.html
Modified: llvm/trunk/docs/GarbageCollection.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GarbageCollection.html?rev=66242&r1=66241&r2=66242&view=diff
==============================================================================
--- llvm/trunk/docs/GarbageCollection.html (original)
+++ llvm/trunk/docs/GarbageCollection.html Thu Mar 5 20:42:47 2009
@@ -525,15 +525,14 @@
;; 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>
More information about the llvm-commits
mailing list