[GC Docs] Update LangRef to link to Statepoint docs
authorPhilip Reames <listmail@philipreames.com>
Wed, 25 Feb 2015 23:45:20 +0000 (23:45 +0000)
committerPhilip Reames <listmail@philipreames.com>
Wed, 25 Feb 2015 23:45:20 +0000 (23:45 +0000)
Add a brief section linking to the experimental statepoint intrinsics analogous to the one we have linking to patchpoint.

While I'm here, cleanup some wording about what the gc "name" attribute actually means.  It's not the name of a *collector* it's the name of the *strategy* which may be compatible with multiple collectors.

llvm-svn: 230576

llvm/docs/GarbageCollection.rst
llvm/docs/LangRef.rst

index 5d1588a..a1557fc 100644 (file)
@@ -386,6 +386,8 @@ greater performance impact since pointer reads are more frequent than writes.
 
 .. _plugin:
 
+.. _builtin-gc-strategies:
+
 Built In GC Strategies
 ======================
 
index 6b72e74..6706552 100644 (file)
@@ -1014,19 +1014,22 @@ Currently, only the following parameter attributes are defined:
 
 .. _gc:
 
-Garbage Collector Names
------------------------
+Garbage Collector Strategy Names
+--------------------------------
 
-Each function may specify a garbage collector name, which is simply a
+Each function may specify a garbage collector strategy name, which is simply a
 string:
 
 .. code-block:: llvm
 
     define void @f() gc "name" { ... }
 
-The compiler declares the supported values of *name*. Specifying a
-collector will cause the compiler to alter its output in order to
-support the named garbage collection algorithm.
+The supported values of *name* includes those :ref:`built in to LLVM 
+<builtin-gc-strategies>` and any provided by loaded plugins.  Specifying a GC
+strategy will cause the compiler to alter its output in order to support the 
+named garbage collection algorithm.  Note that LLVM itself does not contain a 
+garbage collector, this functionality is restricted to generating machine code
+which can interoperate with a collector provided externally.  
 
 .. _prefixdata:
 
@@ -7113,11 +7116,18 @@ stack <int_gcroot>`, as well as garbage collector implementations that
 require :ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers.
 Front-ends for type-safe garbage collected languages should generate
 these intrinsics to make use of the LLVM garbage collectors. For more
-details, see `Accurate Garbage Collection with
-LLVM <GarbageCollection.html>`_.
+details, see `Garbage Collection with LLVM <GarbageCollection.html>`_.
+
+Experimental Statepoint Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The garbage collection intrinsics only operate on objects in the generic
-address space (address space zero).
+LLVM provides an second experimental set of intrinsics for describing garbage
+collection safepoints in compiled code.  These intrinsics are an alternative 
+to the ``llvm.gcroot`` intrinsics, but are compatible with the ones for 
+:ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers.  The 
+differences in approach are covered in the `Garbage Collection with LLVM 
+<GarbageCollection.html>`_ documentation.  The intrinsics themselves are 
+described in :doc:`Statepoints`.
 
 .. _int_gcroot: