Taints relaxed loads to enforce load/store ordering

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

diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst
index d9ae6c1b50573d65dd902042baca0883e0fbbf12..56b4b9f8f957d8bc4dc0f46946b9223e429d6eee 100644 (file)
--- a/docs/GarbageCollection.rst
+++ b/docs/GarbageCollection.rst
@@ -386,8 +386,10 @@ greater performance impact since pointer reads are more frequent than writes.
 
 .. _plugin:
 
-Built In Collectors
-====================
+.. _builtin-gc-strategies:
+
+Built In GC Strategies
+======================
 
 LLVM includes built in support for several varieties of garbage collectors.  
 
@@ -492,6 +494,7 @@ a ``gcroot`` strategy.
 As there names imply, the binary format produced is intended to model that 
 used by the Erlang and OCaml compilers respectively.  
 
+.. _statepoint_example_gc:
 
 The Statepoint Example GC
 -------------------------
@@ -501,8 +504,42 @@ The Statepoint Example GC
   F.setGC("statepoint-example");
 
 This GC provides an example of how one might use the infrastructure provided 
-by ``gc.statepoint``.  
+by ``gc.statepoint``. This example GC is compatible with the 
+:ref:`PlaceSafepoints` and :ref:`RewriteStatepointsForGC` utility passes 
+which simplify ``gc.statepoint`` sequence insertion. If you need to build a 
+custom GC strategy around the ``gc.statepoints`` mechanisms, it is recommended
+that you use this one as a starting point.
+
+This GC strategy does not support read or write barriers.  As a result, these 
+intrinsics are lowered to normal loads and stores.
+
+The stack map format generated by this GC strategy can be found in the 
+:ref:`stackmap-section` using a format documented :ref:`here 
+<statepoint-stackmap-format>`. This format is intended to be the standard 
+format supported by LLVM going forward.
+
+The CoreCLR GC
+-------------------------
+
+.. code-block:: c++
+
+  F.setGC("coreclr");
+
+This GC leverages the ``gc.statepoint`` mechanism to support the 
+`CoreCLR <https://github.com/dotnet/coreclr>`__ runtime.
+
+Support for this GC strategy is a work in progress. This strategy will 
+differ from 
+:ref:`statepoint-example GC<statepoint_example_gc>` strategy in 
+certain aspects like:
+
+* Base-pointers of interior pointers are not explicitly 
+  tracked and reported.
+
+* A different format is used for encoding stack maps.
 
+* Safe-point polls are only needed before loop-back edges
+  and before tail-calls (not needed at function-entry).
 
 Custom GC Strategies
 ====================