forked from OSchip/llvm-project
Fix some typos in the llvm docs
This commit is contained in:
parent
84f99ef2b1
commit
c28473fe4a
|
@ -431,7 +431,7 @@ However, this would be a bad test: if the value for ``foo`` changes, the test
|
|||
would still pass because the "``CHECK: Value: 1``" line would match the value
|
||||
from ``baz``. To fix this, you could add ``CHECK-NEXT`` matchers for every
|
||||
``FieldN:`` line, but that would be verbose, and need to be updated when
|
||||
``Field4`` is added. A more succint way to write the test using the
|
||||
``Field4`` is added. A more succinct way to write the test using the
|
||||
"``CHECK-SAME:``" matcher would be as follows:
|
||||
|
||||
.. code-block:: text
|
||||
|
|
|
@ -45,14 +45,14 @@ For example, consider the following:
|
|||
}
|
||||
|
||||
This code contains a statement that has a loop carried dependence on
|
||||
itself creating a cycle in the DDG. The figure bellow illustrates
|
||||
itself creating a cycle in the DDG. The figure below illustrates
|
||||
how the cycle of dependency is carried through multiple def-use relations
|
||||
and a memory access dependency.
|
||||
|
||||
.. image:: cycle.png
|
||||
|
||||
The DDG corresponding to this example would have a pi-block that contains
|
||||
all the nodes participating in the cycle, as shown bellow:
|
||||
all the nodes participating in the cycle, as shown below:
|
||||
|
||||
.. image:: cycle_pi.png
|
||||
|
||||
|
@ -71,7 +71,7 @@ High-Level Design
|
|||
The DDG and the PDG are both directed graphs and they extend the
|
||||
``DirectedGraph`` class. Each implementation extends its corresponding
|
||||
node and edge types resulting in the inheritance relationship depicted
|
||||
in the UML diagram bellow:
|
||||
in the UML diagram below:
|
||||
|
||||
.. image:: uml_nodes_and_edges.png
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ suffices.
|
|||
|
||||
You will also need the `CMake <http://www.cmake.org/>`_ build system since it
|
||||
generates the project files you will use to build with. CMake is bundled with
|
||||
Visual Studio 2019 so seperate installation is not required.
|
||||
Visual Studio 2019 so separate installation is not required.
|
||||
|
||||
If you would like to run the LLVM tests you will need `Python
|
||||
<http://www.python.org/>`_. Version 3.6 and newer are known to work. You can
|
||||
|
|
|
@ -687,12 +687,12 @@ All subsequent operations are provided by the
|
|||
|
||||
* ``virtual MutableArrayRef<char> getWorkingMemory(ProtectionFlags Seg)``
|
||||
|
||||
Should be overriden to return the address in working memory of the segment
|
||||
Should be overridden to return the address in working memory of the segment
|
||||
with the given protection flags.
|
||||
|
||||
* ``virtual JITTargetAddress getTargetMemory(ProtectionFlags Seg)``
|
||||
|
||||
Should be overriden to return the address in the executor's address space of
|
||||
Should be overridden to return the address in the executor's address space of
|
||||
the segment with the given protection flags.
|
||||
|
||||
* ``virtual void finalizeAsync(FinalizeContinuation OnFinalize)``
|
||||
|
@ -704,7 +704,7 @@ All subsequent operations are provided by the
|
|||
|
||||
* ``virtual Error deallocate()``
|
||||
|
||||
Should be overriden to deallocate memory in the target address space.
|
||||
Should be overridden to deallocate memory in the target address space.
|
||||
|
||||
JITLink provides a simple in-process implementation of this interface:
|
||||
``InProcessMemoryManager``. It allocates pages once and re-uses them as both
|
||||
|
|
|
@ -924,7 +924,7 @@ calls, or transforming sets of stores into ``memset``\ s.
|
|||
``-mergefunc``: Merge Functions
|
||||
-------------------------------
|
||||
|
||||
This pass looks for equivalent functions that are mergable and folds them.
|
||||
This pass looks for equivalent functions that are mergeable and folds them.
|
||||
|
||||
Total-ordering is introduced among the functions set: we define comparison
|
||||
that answers for every two functions which of them is greater. It allows to
|
||||
|
|
|
@ -846,7 +846,7 @@ their parent classes. So the ``let`` acts to override inherited field
|
|||
values. A ``let`` cannot override the value of a template argument.
|
||||
|
||||
Top-level ``let`` statements are often useful when a few fields need to be
|
||||
overriden in several records. Here are two examples. Note that ``let``
|
||||
overridden in several records. Here are two examples. Note that ``let``
|
||||
statements can be nested.
|
||||
|
||||
.. code-block:: text
|
||||
|
|
|
@ -201,7 +201,7 @@ Additional Topics
|
|||
to LLVM.
|
||||
|
||||
:doc:`HowToBuildWindowsItaniumPrograms`
|
||||
Notes on assembling a Windows Itanium enviroment.
|
||||
Notes on assembling a Windows Itanium environment.
|
||||
|
||||
:doc:`HowToCrossCompileBuiltinsOnArm`
|
||||
Notes on cross-building and testing the compiler-rt builtins for Arm.
|
||||
|
|
Loading…
Reference in New Issue