Updates for grammar/punctuation.

Incorporate feed back from Rich to clean up some issues.

Documentation/llilc-arch.md

@@ -22,13 +22,13 @@ areas still need to be fully fleshed out.
 
 The following are the main components of the system.  In the case of CoreCLR and LLVM, these components 
 are provided by other projects/repositories and provide their own documentation.  Others, like the MSIL 
-reader, are provided by this documented by LLILC.
+reader, are provided by LLILC.
 
 ####CoreCLR
 
-The CoreCLR is the open source dynamic execution environment for MSIL (C#) it provides a dynamic type system, 
+The CoreCLR is the open source dynamic execution environment for MSIL (C#). It provides a dynamic type system, 
 a code manager that organizes compilation, and an execution engine (EE).  Additionally the runtime provides the 
-helpers, type tests, memory barriers, required by the code generator for compilation.  The LLILC JIT takes a 
+helpers, type tests, and memory barriers required by the code generator for compilation.  The LLILC JIT takes a 
 dependency on a particular version of the common JIT interface provided by the CoreCLR and requires the specific 
 version of the runtime that supports that interface.
 
@@ -65,8 +65,8 @@ to compile across a spectrum of compile times, attracted us to LLVM.  For our JI
 infrastructure allows us to use all the different targets supported by the MC infrastructure as a JIT.  This was our 
 quickest path to running code.  We're aware of the ORC JIT infrastructure but as the CoreCLR only notifies the JIT 
 to compile a method one method at a time, we currently would not get any benefit from the particular features of ORC. 
-(we already compile one method per module today and we don't have to do any of the inter module fixups as that is 
-performed by the runtime)
+(We already compile one method per module today and we don't have to do any of the inter module fixups as that is 
+performed by the runtime.)
 
 There is a further discussion of how we're modeling the managed code semantics within LLVM in a following 
 [section](##Managed Semantics in LLVM). 
@@ -97,7 +97,7 @@ by zero. Different languages on the CLR can implement different subsets of the C
 EH can be found [here](https://msdn.microsoft.com/en-us/library/ms173162.aspx). For more specific information refer to 
 the ECMA spec [here](http://www.ecma-international.org/publications/standards/Ecma-335.htm). 
 In LLILC we will explicitly expand the CLR required checks in to explicit flow, while for the additional clauses, use 
-the funclet design that is emerging in LLVM to to support MSVC-compatible EH.  A full description of our EH approach can be 
+the funclet design that is emerging in LLVM to support MSVC-compatible EH.  A full description of our EH approach can be 
 found in our documentation [here](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-jit-eh.md).
 
 #### Ahead of Time (AOT) Compilation Driver
@@ -124,7 +124,7 @@ ground here yet.
 As laid out above the JIT runs with CoreCLR, where the runtime requests compilation from the code generator as it is needed 
 during execution.  This dynamic execution relies on the dynamic type system contained in CoreCLR as well as several utilities 
 provided by the runtime.  All of these facilities that the JIT relies on are exposed to it via the CoreCLR common JIT 
-interface.  This is the a simpler environment for the compiler to work in.  It just needs to service requests and all generic, 
+interface.  This is a simpler environment for the compiler to work in.  It just needs to service requests and all generic, 
 inter-op, and interface dispatch complexity is resolved by the runtime and provided by query across the JIT interface. This 
 code generator is being brought up first due to its relative simplicity in getting test cases working and providing a test bed 
 to implement the managed semantics in LLVM.  All of the features required in the JIT will be reused by the AOT framework with 
@@ -156,7 +156,7 @@ These extra checks are implicit in the code and produce catchable exceptions.  T
 thrown for any arithmetic overflow in the program.    
 - Division by zero.  A DivisionByZeroException is thrown for any division of an integral or decimal by zero.
 
-These each of these checks, if naively inserted into the code, could cause a great deal over overhead.  For each case above 
+Each of these checks, if naively inserted into the code, could cause a great deal of overhead.  For each case above 
 there are optimizations that will either compute that the required invariant is either implied by a prior check or other code, 
 or can synthesize a check that will precondition a number of accesses/operations.  This language specific optimizations will 
 need to be added to LLVM either through extending current passes or the introduction of new passes.   
@@ -171,6 +171,6 @@ to gain more benefit from the mid-level optimizer.
 The GC used by the CLR differentiates between reported base pointers and interior pointers (see 
 [Garbage Collection](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-gc.md#interior-pointers) doc for 
 more details).  In simple terms an interior pointer results from an arithmetic operation on a base pointer if the resulting 
-pointer is still contained within the object being referenced. (exterior pointers are not supported) While all pointers can 
+pointer is still contained within the object being referenced. (Exterior pointers are not supported.) While all pointers can 
 be reported as interior this will increase the overhead of the GC since more checks are required to establish the object 
 from an interior pointer.