7 files changed, 11 insertions, 11 deletions

diff --git a/llvm/docs/CommandGuide/FileCheck.rst b/llvm/docs/CommandGuide/FileCheck.rst
index a4e3e06..c594076 100644
--- a/llvm/docs/CommandGuide/FileCheck.rst
+++ b/llvm/docs/CommandGuide/FileCheck.rst
@@ -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
diff --git a/llvm/docs/DependenceGraphs/index.rst b/llvm/docs/DependenceGraphs/index.rst
index e3e6447..8b7421d 100644
--- a/llvm/docs/DependenceGraphs/index.rst
+++ b/llvm/docs/DependenceGraphs/index.rst
@@ -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
 
diff --git a/llvm/docs/GettingStartedVS.rst b/llvm/docs/GettingStartedVS.rst
index a23cd01..b9e294f 100644
--- a/llvm/docs/GettingStartedVS.rst
+++ b/llvm/docs/GettingStartedVS.rst
@@ -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
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
index 616dcd5..55425ee 100644
--- a/llvm/docs/JITLink.rst
+++ b/llvm/docs/JITLink.rst
@@ -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
diff --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst
index 14131cb..92f0649 100644
--- a/llvm/docs/Passes.rst
+++ b/llvm/docs/Passes.rst
@@ -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
diff --git a/llvm/docs/TableGen/ProgRef.rst b/llvm/docs/TableGen/ProgRef.rst
index 9b9ae58..248af5b 100644
--- a/llvm/docs/TableGen/ProgRef.rst
+++ b/llvm/docs/TableGen/ProgRef.rst
@@ -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
diff --git a/llvm/docs/UserGuides.rst b/llvm/docs/UserGuides.rst
index 43f52c3..29d16c0 100644
--- a/llvm/docs/UserGuides.rst
+++ b/llvm/docs/UserGuides.rst
@@ -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.