[Docs] Minor Fixups in Advanced Builds Documentation

[aidengrossman]

Summary

This patch makes some minor fixups in the PGO section of the advanced
builds documentation in preparation for some future changes. Some minor
formatting and wording changes are included to hopefully make the
documentation more clear.

[sylvestre.ledru]

thanks for caring for the doc!

[aidengrossman]

Thank you for the quick review!

llvm/docs/AdvancedBuilds.rst

 
 At a high level, the way PGO works is that you build an instrumented compiler,
 then you run the instrumented compiler against sample source files. While the
 instrumented compiler runs it will output a bunch of files containing
 performance counters (.profraw files). After generating all the profraw files
 you use llvm-profdata to merge the files into a single profdata file that you
 can feed into the LLVM_PROFDATA_FILE option.
 
-Our PGO.cmake cache script automates that whole process. You can use it by
-running:
+Our PGO.cmake cache automates that whole process. You can use it by running:
 
 .. code-block:: console
 
   $ cmake -G Ninja -C <path to source>/clang/cmake/caches/PGO.cmake <path to source>
   $ ninja stage2-instrumented-generate-profdata
 
 If you let that run for a few hours or so, it will place a profdata file in your
 build directory. This takes a really long time because it builds clang twice,
 and you *must* have compiler-rt in your build tree.
 
 This process uses any source files under the perf-training directory as training
 data as long as the source files are marked up with LIT-style RUN lines.
 
-After it finishes you can use “find . -name clang.profdata” to find it, but it
+After it finishes you can use :code:`find . -name clang.profdata` to find it, but it
 should be at a path something like:
 
 .. code-block:: console
 
   <build dir>/tools/clang/stage2-instrumented-bins/utils/perf-training/clang.profdata
 
 You can feed that file into the LLVM_PROFDATA_FILE option when you build your
 optimized compiler.
 
-The PGO came cache has a slightly different stage naming scheme than other
-multi-stage builds. It generates three stages; stage1, stage2-instrumented, and
+The PGO cache has a slightly different stage naming scheme than other
+multi-stage builds. It generates three stages: stage1, stage2-instrumented, and
 stage2. Both of the stage2 builds are built using the stage1 compiler.
 
-The PGO came cache generates the following additional targets:
+The PGO cache generates the following additional targets:
 
 **stage2-instrumented**
-  Builds a stage1 x86 compiler, runtime, and required tools (llvm-config,
+  Builds a stage1 compiler, runtime, and required tools (llvm-config,
   llvm-profdata) then uses that compiler to build an instrumented stage2 compiler.
 
 **stage2-instrumented-generate-profdata**
-  Depends on "stage2-instrumented" and will use the instrumented compiler to
+  Depends on stage2-instrumented and will use the instrumented compiler to
   generate profdata based on the training files in clang/utils/perf-training
 
 **stage2**
-  Depends of "stage2-instrumented-generate-profdata" and will use the stage1
+  Depends on stage2-instrumented-generate-profdata and will use the stage1
   compiler with the stage2 profdata to build a PGO-optimized compiler.
 
 **stage2-check-llvm**
   Depends on stage2 and runs check-llvm using the stage2 compiler.
 
 **stage2-check-clang**
   Depends on stage2 and runs check-clang using the stage2 compiler.
 
 **stage2-check-all**
   Depends on stage2 and runs check-all using the stage2 compiler.
 
 **stage2-test-suite**
-  Depends on stage2 and runs the test-suite using the stage3 compiler (requires
+  Depends on stage2 and runs the test-suite using the stage2 compiler (requires
   in-tree test-suite).
 
 3-Stage Non-Determinism
 =======================
 
 In the ancient lore of compilers non-determinism is like the multi-headed hydra.
 Whenever its head pops up, terror and chaos ensue.