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

diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst
index 8428bc7de05fdae45ac7b811f7ba8c50de9fe4a0..b5a3b1f527b9d1d624b1dc0262660c7e7b418840 100644 (file)
--- a/docs/GarbageCollection.rst
+++ b/docs/GarbageCollection.rst
@@ -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 
 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 
 
 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
 -----------------------------
 
 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 
 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 
 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.  
 
 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 
   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
 
 
 Custom GC Strategies

diff --git a/docs/Statepoints.rst b/docs/Statepoints.rst
index 9d19d03414d7eae2687951c364ce82b08ed6090b..6f7dfe787822e4d5e036b25e9b27046c2f09aa09 100644 (file)
--- a/docs/Statepoints.rst
+++ b/docs/Statepoints.rst
@@ -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
 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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 'llvm.experimental.gc.result' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


@@ -242,8 +242,8 @@ Syntax:
 Overview:
 """""""""
 
 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.
 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:
 """""""""
 
 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
 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:
 """"""""""
 
 
 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
 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
 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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 'llvm.experimental.gc.relocate' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


@@ -284,16 +284,16 @@ Syntax:
 Overview:
 """""""""
 
 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:
 """""""""
 
 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
 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.
 
 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:
 """"""""""
 
 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
 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.
 
 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
 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
 
 
 Stack Map Format