Updates for grammar/punctuation.

Incorporate feed back from Rich to clean up some issues.

Documentation/llilc-arch.md

@@ -6,7 +6,7 @@ LLILC is a code generator based on LLVM for MSIL (C#).  The intent of the archit
 compilation of MSIL using industrial strength components from a C++ compiler.  LLVM gives us the 
 infrastructure to do this but additions are required to bring managed code semantics to LLVM. The 
 LLILC architecture is split broadly into three logical components.  First, high level MSIL transforms, 
-that expand out high level semantics in to more MSIL, second, high level type optimizations that removes 
+that expand out high level semantics into more MSIL, second, high level type optimizations that removes 
 unneeded types from the program, and third translation to LLVM BitCode and code generation.   
 
 Since we're in the early days of the project we've taken the third item first.  Today we're building 
@@ -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.
 
@@ -38,8 +38,8 @@ which can give a more complete overview of the CoreCLR.
 
 #### Garbage Collector
 
-The CLR relies on a precise, relocating garbage collector.  This garbage collector is used with in CoreCLR 
-for the JIT compilation model, and with in the native runtime for the AOT model.  The types for objects allocated 
+The CLR relies on a precise, relocating garbage collector.  This garbage collector is used within CoreCLR 
+for the JIT compilation model, and within the native runtime for the AOT model.  The types for objects allocated 
 on the heap are used to identify fields with GC references, and the JIT is required to report stack slots and registers that 
 contain GC references.  This information is used by the garbage collector for updating references when heap objects 
 are relocated.  A discussion of the garbage collector as used by LLILC is 
@@ -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). 
@@ -86,7 +86,7 @@ A number of optimizations can be done on the incoming programs type graph.  The
 generics sharing. In tree shaking, unused types and fields are removed from the program to reduce code size and improve 
 locality.  For generic sharing, where possible generic method instances are shared to reduce code size.
 
-Like the IL transforms this area is not defined.  Further design work is needed for this with in the AOT tool.
+Like the IL transforms this area is not defined.  Further design work is needed for this within the AOT tool.
 
 ####Exception Handling Model
 
@@ -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 
@@ -137,7 +137,7 @@ implements.  But ahead of time, the type system queries are backed by the simpli
 transitive closure of referenced types and invokes the compiler for all needed methods to translate to BitCode.  Finally all 
 BitCode is compiled together and then linked by the platform linker to the static runtime libs. 
 
-A more complete document specifying the ahead of time approach at a deeper level is forth coming and will be linked here when 
+A more complete document specifying the ahead of time approach at a deeper level is forthcoming and will be linked here when 
 it's available.
 
 ![AOT Architecture](./Images/AOTArch.png)
@@ -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.