mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-25 00:29:20 +00:00
Fix consistently wrong sphinx markup
I'd been using '' where I should have been using ``. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230407 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
b0991ba014
commit
b4ecacfe06
@ -59,8 +59,8 @@ When generating LLVM IR for your functions, you will need to:
|
||||
You will need to identify roots (i.e. references to heap objects your collector
|
||||
needs to know about) in your generated IR, so that LLVM can encode them into
|
||||
your final stack maps. Depending on the collector strategy chosen, this is
|
||||
accomplished by using either the ''@llvm.gcroot'' intrinsics or an
|
||||
''gc.statepoint'' relocation sequence.
|
||||
accomplished by using either the ``@llvm.gcroot`` intrinsics or an
|
||||
``gc.statepoint`` relocation sequence.
|
||||
|
||||
Don't forget to create a root for each intermediate value that is generated when
|
||||
evaluating an expression. In ``h(f(), g())``, the result of ``f()`` could
|
||||
@ -482,12 +482,12 @@ data structure, but there are only 20 lines of meaningful code.)
|
||||
The 'Erlang' and 'Ocaml' GCs
|
||||
-----------------------------
|
||||
|
||||
LLVM ships with two example collectors which leverage the ''gcroot''
|
||||
LLVM ships with two example collectors which leverage the ``gcroot``
|
||||
mechanisms. To our knowledge, these are not actually used by any language
|
||||
runtime, but they do provide a reasonable starting point for someone interested
|
||||
in writing an ''gcroot' compatible GC plugin. In particular, these are the
|
||||
in writing an ``gcroot`` compatible GC plugin. In particular, these are the
|
||||
only in tree examples of how to produce a custom binary stack map format using
|
||||
a ''gcroot'' strategy.
|
||||
a ``gcroot`` strategy.
|
||||
|
||||
As there names imply, the binary format produced is intended to model that
|
||||
used by the Erlang and OCaml compilers respectively.
|
||||
@ -501,7 +501,7 @@ 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``.
|
||||
|
||||
|
||||
Custom GC Strategies
|
||||
|
@ -226,7 +226,7 @@ illegal to mark a statepoint as being either 'readonly' or 'readnone'.
|
||||
Note that legal IR can not perform any memory operation on a 'gc
|
||||
pointer' argument of the statepoint in a location statically reachable
|
||||
from the statepoint. Instead, the explicitly relocated value (from a
|
||||
''gc.relocate'') must be used.
|
||||
``gc.relocate``) must be used.
|
||||
|
||||
'llvm.experimental.gc.result' Intrinsic
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -242,8 +242,8 @@ Syntax:
|
||||
Overview:
|
||||
"""""""""
|
||||
|
||||
'''gc.result''' extracts the result of the original call instruction
|
||||
which was replaced by the '''gc.statepoint'''. The '''gc.result'''
|
||||
``gc.result`` extracts the result of the original call instruction
|
||||
which was replaced by the ``gc.statepoint``. The ``gc.result``
|
||||
intrinsic is actually a family of three intrinsics due to an
|
||||
implementation limitation. Other than the type of the return value,
|
||||
the semantics are the same.
|
||||
@ -251,22 +251,22 @@ the semantics are the same.
|
||||
Operands:
|
||||
"""""""""
|
||||
|
||||
The first and only argument is the '''gc.statepoint''' which starts
|
||||
the safepoint sequence of which this '''gc.result'' is a part.
|
||||
The first and only argument is the ``gc.statepoint`` which starts
|
||||
the safepoint sequence of which this ``gc.result`` is a part.
|
||||
Despite the typing of this as a generic i32, *only* the value defined
|
||||
by a '''gc.statepoint''' is legal here.
|
||||
by a ``gc.statepoint`` is legal here.
|
||||
|
||||
Semantics:
|
||||
""""""""""
|
||||
|
||||
The ''gc.result'' represents the return value of the call target of
|
||||
the ''statepoint''. The type of the ''gc.result'' must exactly match
|
||||
The ``gc.result`` represents the return value of the call target of
|
||||
the ``statepoint``. The type of the ``gc.result`` must exactly match
|
||||
the type of the target. If the call target returns void, there will
|
||||
be no ''gc.result''.
|
||||
be no ``gc.result``.
|
||||
|
||||
A ''gc.result'' is modeled as a 'readnone' pure function. It has no
|
||||
A ``gc.result`` is modeled as a 'readnone' pure function. It has no
|
||||
side effects since it is just a projection of the return value of the
|
||||
previous call represented by the ''gc.statepoint''.
|
||||
previous call represented by the ``gc.statepoint``.
|
||||
|
||||
'llvm.experimental.gc.relocate' Intrinsic
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -284,16 +284,16 @@ Syntax:
|
||||
Overview:
|
||||
"""""""""
|
||||
|
||||
A ''gc.relocate'' returns the potentially relocated value of a pointer
|
||||
A ``gc.relocate`` returns the potentially relocated value of a pointer
|
||||
at the safepoint.
|
||||
|
||||
Operands:
|
||||
"""""""""
|
||||
|
||||
The first argument is the '''gc.statepoint''' which starts the
|
||||
safepoint sequence of which this '''gc.relocation'' is a part.
|
||||
The first argument is the ``gc.statepoint`` which starts the
|
||||
safepoint sequence of which this ``gc.relocation`` is a part.
|
||||
Despite the typing of this as a generic i32, *only* the value defined
|
||||
by a '''gc.statepoint''' is legal here.
|
||||
by a ``gc.statepoint`` is legal here.
|
||||
|
||||
The second argument is an index into the statepoints list of arguments
|
||||
which specifies the base pointer for the pointer being relocated.
|
||||
@ -309,18 +309,18 @@ within the 'gc parameter' section of the statepoint's argument list.
|
||||
Semantics:
|
||||
""""""""""
|
||||
|
||||
The return value of ''gc.relocate'' is the potentially relocated value
|
||||
The return value of ``gc.relocate`` is the potentially relocated value
|
||||
of the pointer specified by it's arguments. It is unspecified how the
|
||||
value of the returned pointer relates to the argument to the
|
||||
''gc.statepoint'' other than that a) it points to the same source
|
||||
``gc.statepoint`` other than that a) it points to the same source
|
||||
language object with the same offset, and b) the 'based-on'
|
||||
relationship of the newly relocated pointers is a projection of the
|
||||
unrelocated pointers. In particular, the integer value of the pointer
|
||||
returned is unspecified.
|
||||
|
||||
A ''gc.relocate'' is modeled as a 'readnone' pure function. It has no
|
||||
A ``gc.relocate`` is modeled as a ``readnone`` pure function. It has no
|
||||
side effects since it is just a way to extract information about work
|
||||
done during the actual call modeled by the ''gc.statepoint''.
|
||||
done during the actual call modeled by the ``gc.statepoint``.
|
||||
|
||||
|
||||
Stack Map Format
|
||||
|
Loading…
Reference in New Issue
Block a user