Clarify use of the word "codegen".

The existing text uses "codegen" frequently as a shorthand for "codegen
backend". I found this confusing and distracting. ("Codegens" is even
worse.) This commit replaces these uses with "codegen backend" (or
occasionally something else more appropriate).

The commit preserves the use of "codegen" for the act of code generation,
e.g. "during codegen we do XYZ", because that's more standard.

Author: nnethercote

guide/src/faq.md

@@ -14,8 +14,8 @@ This can be circumvented by building LLVM in a special way, but this is far beyo
 which yield considerable performance differences (especially on more complex kernels with more information in the IR).
 - For some reason (either rustc giving weird LLVM IR or the LLVM PTX backend being broken) the LLVM PTX backend often
 generates completely invalid PTX for trivial programs, so it is not an acceptable workflow for a production pipeline.
-- GPU and CPU codegen is fundamentally different, creating a codegen that is only for the GPU allows us to 
-seamlessly implement features which would have been impossible or very difficult to implement in the existing codegen, such as:
+- GPU and CPU codegen is fundamentally different, creating a codegen backend that is only for the GPU allows us to 
+seamlessly implement features which would have been impossible or very difficult to implement in the existing codegen backend, such as:
   - Shared memory, this requires some special generation of globals with custom addrspaces, its just not possible to do without backend explicit handling.
   - Custom linking logic to do dead code elimination so as to not end up with large PTX files full of dead functions/globals.
   - Stripping away everything we do not need, no complex ABI handling, no shared lib handling, control over how function calls are generated, etc.
@@ -33,7 +33,7 @@ Long answer, there are a couple of things that make this impossible:
 - NVVM IR is a __subset__ of LLVM IR, there are tons of things that NVVM will not accept. Such as a lot of function attrs not being allowed. 
 This is well documented and you can find the spec [here](https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html). Not to mention
 many bugs in libNVVM that I have found along the way, the most infuriating of which is nvvm not accepting integer types that arent `i1, i8, i16, i32, or i64`.
-This required special handling in the codegen to convert these "irregular" types into vector types.
+This required special handling in the codegen backend to convert these "irregular" types into vector types.
 
 ## What is the point of using Rust if a lot of things in kernels are unsafe?
 

guide/src/features.md

@@ -54,7 +54,7 @@ around to adding it yet.
 | cuSPARSE | ❌ |
 | AmgX | ❌ |
 | cuTENSOR | ❌ |
-| OptiX | 🟨 | CPU OptiX is mostly complete, GPU OptiX is still heavily in-progress because it needs support from the codegen | 
+| OptiX | 🟨 | CPU OptiX is mostly complete, GPU OptiX is still heavily in-progress because it needs support from the codegen backend | 
 
 # GPU-side Features
 

guide/src/guide/getting_started.md

@@ -10,7 +10,7 @@ Before you can use the project to write GPU crates, you will need a couple of pr
 
   This is only for building GPU crates, to execute built PTX you only need CUDA `9+`.
 
-- LLVM 7.x (7.0 to 7.4), The codegen searches multiple places for LLVM:
+- LLVM 7.x (7.0 to 7.4), The codegen backend searches multiple places for LLVM:
 
   - If `LLVM_CONFIG` is present, it will use that path as `llvm-config`.
   - Or, if `llvm-config` is present as a binary, it will use that, assuming that `llvm-config --version` returns `7.x.x`.