many edits, patch by Kelly Wilson!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44157 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 18 insertions, 18 deletions

diff --git a/docs/tutorial/LangImpl8.html b/docs/tutorial/LangImpl8.html
index d84dfdca6b..855b8f3692 100644
--- a/docs/tutorial/LangImpl8.html
+++ b/docs/tutorial/LangImpl8.html
@@ -98,7 +98,7 @@ Programmer's Manual</a> that describes how to construct them.</li>
 <li><b>standard runtime</b> - Our current language allows the user to access
 arbitrary external functions, and we use it for things like "printd" and
 "putchard".  As you extend the language to add higher-level constructs, often
-these constructs make the most amount of sense to be lowered into calls into a
+these constructs make the most sense if they are lowered to calls into a
 language-supplied runtime.  For example, if you add hash tables to the language,
 it would probably make sense to add the routines to a runtime, instead of 
 inlining them all the way.</li>
@@ -106,14 +106,14 @@ inlining them all the way.</li>
 <li><b>memory management</b> - Currently we can only access the stack in
 Kaleidoscope.  It would also be useful to be able to allocate heap memory,
 either with calls to the standard libc malloc/free interface or with a garbage
-collector.  If you choose to use garbage collection, note that LLVM fully
+collector.  If you would like to use garbage collection, note that LLVM fully
 supports <a href="../GarbageCollection.html">Accurate Garbage Collection</a>
 including algorithms that move objects and need to scan/update the stack.</li>
 
 <li><b>debugger support</b> - LLVM supports generation of <a 
 href="../SourceLevelDebugging.html">DWARF Debug info</a> which is understood by
 common debuggers like GDB.  Adding support for debug info is fairly 
-straight-forward.  The best way to understand it is to compile some C/C++ code
+straightforward.  The best way to understand it is to compile some C/C++ code
 with "<tt>llvm-gcc -g -O0</tt>" and taking a look at what it produces.</li>
 
 <li><b>exception handling support</b> - LLVM supports generation of <a 
@@ -139,22 +139,22 @@ expression interpreter into native code with LLVM?</li>
 
 <p>
 Have fun - try doing something crazy and unusual.  Building a language like
-everyone else always has is much less fun than trying something a little crazy
-and off the wall and seeing how it turns out.  If you get stuck or want to talk
+everyone else always has, is much less fun than trying something a little crazy
+or off the wall and seeing how it turns out.  If you get stuck or want to talk
 about it, feel free to email the <a 
 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev mailing 
 list</a>: it has lots of people who are interested in languages and are often
 willing to help out.
 </p>
 
-<p>Before we end, I want to talk about some "tips and tricks" for generating
+<p>Before we end this tutorial, I want to talk about some "tips and tricks" for generating
 LLVM IR.  These are some of the more subtle things that may not be obvious, but
 are very useful if you want to take advantage of LLVM's capabilities.</p>
 
 </div>
 
 <!-- *********************************************************************** -->
-<div class="doc_section"><a name="llvmirproperties">Properties of LLVM 
+<div class="doc_section"><a name="llvmirproperties">Properties of the LLVM 
 IR</a></div>
 <!-- *********************************************************************** -->
 
@@ -184,7 +184,7 @@ compiling that on targets that LLVM doesn't support natively.  You can trivially
 tell that the Kaleidoscope compiler generates target-independent code because it
 never queries for any target-specific information when generating code.</p>
 
-<p>The fact that LLVM provides a compact target-independent representation for
+<p>The fact that LLVM provides a compact, target-independent, representation for
 code gets a lot of people excited.  Unfortunately, these people are usually
 thinking about C or a language from the C family when they are asking questions
 about language portability.  I say "unfortunately", because there is really no
@@ -208,7 +208,7 @@ the input text:</p>
 </div>
 
 <p>While it is possible to engineer more and more complex solutions to problems
-like this, it cannot be solved in full generality in a way better than shipping
+like this, it cannot be solved in full generality in a way that is better than shipping
 the actual source code.</p>
 
 <p>That said, there are interesting subsets of C that can be made portable.  If
@@ -263,7 +263,7 @@ few observations:</p>
 writing, there is no way to distinguish in the LLVM IR whether an SSA-value came
 from a C "int" or a C "long" on an ILP32 machine (other than debug info).  Both
 get compiled down to an 'i32' value and the information about what it came from
-is lost.  The more general issue here is that the LLVM type system uses
+is lost.  The more general issue here, is that the LLVM type system uses
 "structural equivalence" instead of "name equivalence".  Another place this
 surprises people is if you have two types in a high-level language that have the
 same structure (e.g. two different structs that have a single int field): these
@@ -275,10 +275,10 @@ continue to enhance and improve it in many different ways.  In addition to
 adding new features (LLVM did not always support exceptions or debug info), we
 also extend the IR to capture important information for optimization (e.g.
 whether an argument is sign or zero extended, information about pointers
-aliasing, etc.  Many of the enhancements are user-driven: people want LLVM to
-do some specific feature, so they go ahead and extend it to do so.</p>
+aliasing, etc).  Many of the enhancements are user-driven: people want LLVM to
+include some specific feature, so they go ahead and extend it.</p>
 
-<p>Third, it <em>is possible and easy</em> to add language-specific
+<p>Third, it is <em>possible and easy</em> to add language-specific
 optimizations, and you have a number of choices in how to do it.  As one trivial
 example, it is easy to add language-specific optimization passes that
 "know" things about code compiled for a language.  In the case of the C family,
@@ -291,7 +291,7 @@ function does.</p>
 other language-specific information into the LLVM IR.  If you have a specific
 need and run into a wall, please bring the topic up on the llvmdev list.  At the
 very worst, you can always treat LLVM as if it were a "dumb code generator" and
-implement the high-level optimizations you desire in your front-end on the
+implement the high-level optimizations you desire in your front-end, on the
 language-specific AST.
 </p>
 
@@ -316,8 +316,8 @@ offsetof/sizeof</a></div>
 
 <div class="doc_text">
 
-<p>One interesting thing that comes up if you are trying to keep the code 
-generated by your compiler "target independent" is that you often need to know
+<p>One interesting thing that comes up, if you are trying to keep the code 
+generated by your compiler "target independent", is that you often need to know
 the size of some LLVM type or the offset of some field in an llvm structure.
 For example, you might need to pass the size of a type into a function that
 allocates memory.</p>
@@ -342,10 +342,10 @@ they are garbage collected or to allow easy implementation of closures.  There
 are often better ways to implement these features than explicit stack frames,
 but <a 
 href="http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt">LLVM
-does support them if you want</a>.  It requires your front-end to convert the
+does support them,</a> if you want.  It requires your front-end to convert the
 code into <a 
 href="http://en.wikipedia.org/wiki/Continuation-passing_style">Continuation
-Passing Style</a> and use of tail calls (which LLVM also supports).</p>
+Passing Style</a> and the use of tail calls (which LLVM also supports).</p>
 
 </div>