fix some various typos in the doc

llvm-svn: 274449

3 files changed, 5 insertions, 5 deletions

diff --git a/llvm/docs/tutorial/BuildingAJIT1.rst b/llvm/docs/tutorial/BuildingAJIT1.rst
index 0859100f8d8..f30b979579d 100644
--- a/llvm/docs/tutorial/BuildingAJIT1.rst
+++ b/llvm/docs/tutorial/BuildingAJIT1.rst
@@ -47,7 +47,7 @@ code for that chapter and replace it with optimization support in our JIT class
 in Chapter #2.
 
 Finally, a word on API generations: ORC is the 3rd generation of LLVM JIT API.
-It was preceeded by MCJIT, and before that by the (now deleted) legacy JIT.
+It was preceded by MCJIT, and before that by the (now deleted) legacy JIT.
 These tutorials don't assume any experience with these earlier APIs, but
 readers acquainted with them will see many familiar elements. Where appropriate
 we will make this connection with the earlier APIs explicit to help people who
@@ -140,7 +140,7 @@ to build our LLVM compiler instance; A DataLayout, DL, which will be used for
 symbol mangling (more on that later), and two ORC *layers*: an
 ObjectLinkingLayer and a IRCompileLayer. We'll be talking more about layers in
 the next chapter, but for now you can think of them as analogous to LLVM
-Passes: they wrap up useful JIT utilities behind an easy to compose interace.
+Passes: they wrap up useful JIT utilities behind an easy to compose interface.
 The first layer, ObjectLinkingLayer, is the foundation of our JIT: it takes
 in-memory object files produced by a compiler and links them on the fly to make
 them executable. This JIT-on-top-of-a-linker design was introduced in MCJIT,
diff --git a/llvm/docs/tutorial/BuildingAJIT2.rst b/llvm/docs/tutorial/BuildingAJIT2.rst
index 7f2b4a8b264..8fa92317f54 100644
--- a/llvm/docs/tutorial/BuildingAJIT2.rst
+++ b/llvm/docs/tutorial/BuildingAJIT2.rst
@@ -286,7 +286,7 @@ these choices will have different performance characteristics: Doing work
 eagerly means the JIT takes longer up-front, but proceeds smoothly once this is
 done. Deferring work allows the JIT to get up-and-running quickly, but will
 force the JIT to pause and wait whenever some code or data is needed that hasn't
-already been procesed.
+already been processed.
 
 Our current REPL is eager: Each function definition is optimized and compiled as
 soon as it's typed in. If we were to make the transform layer lazy (but not
diff --git a/llvm/docs/tutorial/LangImpl08.rst b/llvm/docs/tutorial/LangImpl08.rst
index b2eeb35ae3a..96eccaebd32 100644
--- a/llvm/docs/tutorial/LangImpl08.rst
+++ b/llvm/docs/tutorial/LangImpl08.rst
@@ -46,7 +46,7 @@ returns the target triple of the current machine.
 
 LLVM doesn't require us to to link in all the target
 functionality. For example, if we're just using the JIT, we don't need
-the assembly printers. Similarly, if we're only targetting certain
+the assembly printers. Similarly, if we're only targeting certain
 architectures, we can only link in the functionality for those
 architectures.
 
@@ -80,7 +80,7 @@ Target Machine
 ==============
 
 We will also need a ``TargetMachine``. This class provides a complete
-machine description of the machine we're targetting. If we want to
+machine description of the machine we're targeting. If we want to
 target a specific feature (such as SSE) or a specific CPU (such as
 Intel's Sandylake), we do so now.