RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-30 06:40:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[GC Docs] Update LangRef to link to Statepoint docs

Browse Source 
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
This commit is contained in:
Philip Reames 2015-02-25 23:45:20 +00:00
parent 7cf1817c95
commit 32bece890d
2 changed files with 22 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/GarbageCollection.rst
View File

@ -386,6 +386,8 @@ greater performance impact since pointer reads are more frequent than writes.
.. _plugin: .. _plugin:
.. _builtin-gc-strategies:
Built In GC Strategies Built In GC Strategies
====================== ======================

30
docs/LangRef.rst
View File

@ -1014,19 +1014,22 @@ Currently, only the following parameter attributes are defined:
.. _gc: .. _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: string:
.. code-block:: llvm .. code-block:: llvm
define void @f() gc "name" { ... } define void @f() gc "name" { ... }
The compiler declares the supported values of *name*. Specifying a The supported values of *name* includes those :ref:`built in to LLVM
collector will cause the compiler to alter its output in order to <builtin-gc-strategies>` and any provided by loaded plugins. Specifying a GC
support the named garbage collection algorithm. 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: .. _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. require :ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers.
Front-ends for type-safe garbage collected languages should generate Front-ends for type-safe garbage collected languages should generate
these intrinsics to make use of the LLVM garbage collectors. For more these intrinsics to make use of the LLVM garbage collectors. For more
details, see `Accurate Garbage Collection with details, see `Garbage Collection with LLVM <GarbageCollection.html>`_.
LLVM <GarbageCollection.html>`_.
The garbage collection intrinsics only operate on objects in the generic Experimental Statepoint Intrinsics
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: .. _int_gcroot: