address review comments

Author: mark-i-m

src/part-3-intro.md

@@ -1,9 +1,8 @@
 # Part 3: Source Code Representations
 
-This part of the guide looks at the various ways the compiler transforms and
-represents source code. This part describes the process of taking raw source
-code from the user and transforming it into various forms that the compiler can
-work with easily. These are called intermediate representations.
+This part describes the process of taking raw source code from the user and
+transforming it into various forms that the compiler can work with easily.
+These are called intermediate representations.
 
 This process starts with compiler understanding what the user has asked for:
 parsing the command line arguments given and determining what it is to compile.

src/part-5-intro.md

@@ -4,17 +4,17 @@ All of the preceding chapters of this guide have one thing in common: we never
 generated any executable machine code at all! With this chapter, all of that
 changes.
 
-It's often useful to think of compilers as being composed of a _frontend_ and a
-_backend_  (though in rustc, there's not a sharp line between frontend and
-backend). The _frontend_ is responsible for taking raw source code, checking it
-for correctness, and getting it into a format from which we can generate code.
-For rustc, we typically consider MIR to be this format (though arguably, one
-could consider LLVM IR to be this format). The _backend_ refers to the parts
-of the compiler that produce actual executable code (e.g. an ELF or EXE binary)
-that can run on a processor. All of the previous chapters deal with rustc's
-"frontend".
-
-rustc's "backend" does the following:
+So far, we've shown how the compiler can take raw source code in text format
+and transform it into MIR. We have also shown how the compiler does various
+analyses on the code to detect things like type or lifetime errors. Now, we
+will finally take the MIR and produce some executable machine code.
+
+> NOTE: This part of a compiler is often called the _backend_ the term is a bit
+> overloaded because in the compiler source, it usually refers to the "codegen
+> backend" (i.e. LLVM or Cranelift). Usually, when you see the word "backend"
+> in this part, we are refering to the "codegen backend".
+
+So what do we need to do?
 
 0. First, we need to collect the set of things to generate code for. In
    particular, we need to find out which concrete types to substitute for
@@ -24,15 +24,15 @@ rustc's "backend" does the following:
    collecting all the concrete types is called _monomorphization collection_.
 1. Next, we need to actually lower the MIR to a codegen IR
    (usually LLVM IR) for each concrete type we collected.
-2. Finally, we need to invoke the codegen backend (e.g. LLVM or Cranelift),
-   which runs a bunch of optimization passes, generates executable code, and
-   links together an executable binary.
+2. Finally, we need to invoke LLVM or Cranelift, which runs a bunch of
+   optimization passes, generates executable code, and links together an
+   executable binary.
 
 [codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html
 
 The code for codegen is actually a bit complex due to a few factors:
 
-- Support for multiple backends (LLVM and Cranelift). We try to share as much
+- Support for multiple codegen backends (LLVM and Cranelift). We try to share as much
   backend code between them as possible, so a lot of it is generic over the
   codegen implementation. This means that there are often a lot of layers of
   abstraction.