Add some html anchors, to allow attributes to be linked to directly.
[oota-llvm.git] / docs / GarbageCollection.html
index 1508bcf2231068fc44472d16f6f37a125cafdfb1..56085ca710bc998aa33bb1ed8cf61cd9a08d8c1b 100644 (file)
@@ -118,7 +118,7 @@ conservative garbage collectors (though these seem rare in practice).</p>
 they can suffer from degraded scalar optimization of the program. In particular,
 because the runtime must be able to identify and update all pointers active in
 the program, some optimizations are less effective. In practice, however, the
-locality and performance benefits of using aggressive garbage allocation
+locality and performance benefits of using aggressive garbage collection
 techniques dominates any low-level losses.</p>
 
 <p>This document describes the mechanisms and interfaces provided by LLVM to
@@ -334,11 +334,11 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) {
     
     // For roots [0, NumMeta), the metadata pointer is in the FrameMap.
     for (unsigned e = R->Map->NumMeta; i != e; ++i)
-      Visitor(&R->Roots[i], R->Map->Meta[i]);
+      Visitor(&amp;R->Roots[i], R->Map->Meta[i]);
     
     // For roots [NumMeta, NumRoots), the metadata pointer is null.
     for (unsigned e = R->Map->NumRoots; i != e; ++i)
-      Visitor(&R->Roots[i], NULL);
+      Visitor(&amp;R->Roots[i], NULL);
   }
 }</pre></div>
 
@@ -398,7 +398,7 @@ program.</p>
 </div>
 
 <div class="doc_code"><tt>
-  define <i>ty</i> @<i>name</i>(...) <u>gc "<i>name</i>"</u> { ...
+  define <i>ty</i> @<i>name</i>(...) <span style="text-decoration: underline">gc "<i>name</i>"</span> { ...
 </tt></div>
 
 <div class="doc_text">
@@ -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>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 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>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>
+<p>The use of these intrinsics is naturally optional if the target GC does
+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>
 
@@ -618,7 +617,7 @@ conforms to the binary interface defined by library, most essentially the
 using namespace llvm;
 
 namespace {
-  class VISIBILITY_HIDDEN MyGC : public GCStrategy {
+  class LLVM_LIBRARY_VISIBILITY MyGC : public GCStrategy {
   public:
     MyGC() {}
   };
@@ -1230,7 +1229,7 @@ generation in the JIT, nor using the object writers.</p>
 using namespace llvm;
 
 namespace {
-  class VISIBILITY_HIDDEN MyGCPrinter : public GCMetadataPrinter {
+  class LLVM_LIBRARY_VISIBILITY MyGCPrinter : public GCMetadataPrinter {
   public:
     virtual void beginAssembly(std::ostream &amp;OS, AsmPrinter &amp;AP,
                                const TargetAsmInfo &amp;TAI);