Be consistent with backticks.

A lot of names are used sometimes with backticks, sometimes without.
It's not 100% clear but I think "without" is better, for the following:

- rustc_codegen_*
- cuda_builder
- rustc
- cuda_std
- rust-gpu (which will become "Rust GPU" in a subsequent commit)

In contrast, `lib.rs` is a file name and should use backticks.

Author: nnethercote

guide/src/cuda/gpu_computing.md

@@ -40,7 +40,7 @@ Most of the reasons for using rust on the CPU apply to using Rust for the GPU, t
 I will not repeat them here. 
 
 A couple of particular rust features make writing CUDA code much easier: RAII and Results.
-In `cust` everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which 
+In cust everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which 
 frees users from having to think about that, which yields safer, more reliable code.
 
 Results are particularly helpful, almost every single call in every CUDA library returns a status code in the form of a CUDA result.

guide/src/faq.md

@@ -252,7 +252,7 @@ one GPU may be lacking a feature.
 - CUDA is usually 10-30% faster than OpenCL overall, this is likely due to subpar OpenCL drivers by NVIDIA,
 but it is unlikely this performance gap will change in the near future.
 - CUDA has a much richer set of libraries and tools than OpenCL, such as cuFFT, cuBLAS, cuRand, cuDNN, OptiX, NSight Compute, cuFile, etc.
-- You can seamlessly use existing CUDA C/C++ code with `cust` or `rustc_codegen_nvvm`-generated PTX by
+- You can seamlessly use existing CUDA C/C++ code with `cust` or rustc_codegen_nvvm-generated PTX by
 using the CUDA linker APIs which are exposed in `cust`. Allowing for incremental switching to Rust.
 - There is a generally larger set of code samples in CUDA C/C++ over OpenCL.
 - Documentation is __far__ better, there are (mostly) complete API docs for every single CUDA library and function out there.

guide/src/guide/compute_capabilities.md

@@ -142,9 +142,9 @@ Note: While the 'a' variant enables all these features during compilation (allow
 
 For more details on suffixes, see [NVIDIA's blog post on family-specific architecture features](https://developer.nvidia.com/blog/nvidia-blackwell-and-nvidia-cuda-12-9-introduce-family-specific-architecture-features/).
 
-### Manual Compilation (Without `cuda_builder`)
+### Manual Compilation (Without cuda_builder)
 
-If you're invoking `rustc` directly instead of using `cuda_builder`, you only need to specify the architecture through LLVM args:
+If you're invoking rustc directly instead of using cuda_builder, you only need to specify the architecture through LLVM args:
 
 ```bash
 rustc --target nvptx64-nvidia-cuda \
@@ -210,7 +210,7 @@ These patterns work when using base architectures (no suffix), which enable all
 
 If you encounter errors about missing functions or features:
 
-1. Check the compute capability you're targeting in `cuda_builder`
+1. Check the compute capability you're targeting in cuda_builder
 2. Verify your GPU supports the features you're using
 3. Use `nvidia-smi` to check your GPU's compute capability
 4. Add appropriate `#[cfg]` guards or increase the target architecture

guide/src/guide/getting_started.md

@@ -1,6 +1,6 @@
 # Getting Started
 
-This section covers how to get started writing GPU crates with `cuda_std` and `cuda_builder`.
+This section covers how to get started writing GPU crates with cuda_std and cuda_builder.
 
 ## Required Libraries
 
@@ -53,12 +53,12 @@ edition = "2021"
 +cuda_std = "XX"
 ```
 
-Where `XX` is the latest version of `cuda_std`.
+Where `XX` is the latest version of cuda_std.
 
 We changed our crate's crate types to `cdylib` and `rlib`. We specified `cdylib` because the nvptx targets do not support binary crate types.
 `rlib` is so that we will be able to use the crate as a dependency, such as if we would like to use it on the CPU.
 
-## lib.rs
+## `lib.rs`
 
 Before we can write any GPU kernels, we must add a few directives to our `lib.rs` which are required by the codegen:
 
@@ -86,7 +86,7 @@ If you would like to use `alloc` or things like printing from GPU kernels (which
 extern crate alloc;
 ```
 
-Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, `rustc_codegen_nvvm` guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).
+Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, rustc_codegen_nvvm guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).
 
 ```rs
 #![allow(improper_ctypes_definitions)]
@@ -161,7 +161,7 @@ It also applies `#[no_mangle]` so the name of the kernel is the same as it is de
 
 ## Building the GPU crate
 
-Now that you have some kernels defined in a crate, you can build them easily using `cuda_builder`.
+Now that you have some kernels defined in a crate, you can build them easily using cuda_builder.
 which builds GPU crates while passing everything needed by rustc.
 
 To use it you can simply add it as a build dependency in your CPU crate (the crate running the GPU kernels):
@@ -173,7 +173,7 @@ To use it you can simply add it as a build dependency in your CPU crate (the cra
 
 Where `XX` is the current version of cuda_builder.
 
-Then, you can simply invoke it in the build.rs of your CPU crate:
+Then, you can simply invoke it in the `build.rs` of your CPU crate:
 
 ```rs
 use cuda_builder::CudaBuilder;

guide/src/nvvm/backends.md

@@ -21,18 +21,18 @@ five publicly known codegens that exist:
 - rustc_codegen_spirv
 - rustc_codegen_nvvm, obviously the best codegen ;)
 
-`rustc_codegen_cranelift` targets the cranelift backend, which is a codegen backend written in rust that is faster than LLVM but does not have many optimizations
-compared to LLVM. `rustc_codegen_llvm` is obvious, it is the backend almost everybody uses which targets LLVM. `rustc_codegen_gcc` targets GCC (GNU Compiler Collection)
-which is able to target more exotic targets than LLVM, especially for embedded. `rustc_codegen_spirv` targets the SPIR-V (Standard Portable Intermediate Representation 5)
+rustc_codegen_cranelift targets the cranelift backend, which is a codegen backend written in rust that is faster than LLVM but does not have many optimizations
+compared to LLVM. rustc_codegen_llvm is obvious, it is the backend almost everybody uses which targets LLVM. rustc_codegen_gcc targets GCC (GNU Compiler Collection)
+which is able to target more exotic targets than LLVM, especially for embedded. rustc_codegen_spirv targets the SPIR-V (Standard Portable Intermediate Representation 5)
 format, which is a format mostly used for compiling shader languages such as GLSL or WGSL to a standard representation that Vulkan/OpenGL can use, the reasons
 why SPIR-V is not an alternative to CUDA/rustc_codegen_nvvm have been covered in the [FAQ](../../faq.md).
 
-Finally, we come to the star of the show, `rustc_codegen_nvvm`. This backend targets NVVM IR for compiling rust to GPU kernels that can be run by CUDA. 
+Finally, we come to the star of the show, rustc_codegen_nvvm. This backend targets NVVM IR for compiling rust to GPU kernels that can be run by CUDA. 
 What NVVM IR/libNVVM are has been covered in the [CUDA section](../../cuda/pipeline.md).
 
 # rustc_codegen_ssa
 
-`rustc_codegen_ssa` is the central crate behind every single codegen and does much of the hard work.
+rustc_codegen_ssa is the central crate behind every single codegen and does much of the hard work.
 It abstracts away the MIR lowering logic so that custom codegens only have to implement some
 traits and the SSA codegen does everything else. For example:
 - A trait for getting a type like an integer type.

guide/src/nvvm/ptxgen.md

@@ -69,7 +69,7 @@ libdevice is also lazy loaded so we do not import useless intrinsics.
 # libintrinsics
 
 This is the last special module we load, it is simple, it is just a dumping ground for random wrapper functions 
-we need to define that `cuda_std` or the codegen needs. You can find the LLVM IR definition for it in the codegen directory
+we need to define that cuda_std or the codegen needs. You can find the LLVM IR definition for it in the codegen directory
 called `libintrinsics.ll`. All of its functions should be declared with the `__nvvm_` prefix.
 
 # Compilation

guide/src/nvvm/types.md

@@ -3,8 +3,8 @@
 Types! who doesn't love types, especially those that cause libNVVM to randomly segfault or loop forever!
 Anyways, types are an integral part of the codegen and everything revolves around them and you will see them everywhere.
 
-`rustc_codegen_ssa` does not actually tell you what your type representation should be, it allows you to decide. For
-example, `rust-gpu` represents it as a `SpirvType` enum, while both `rustc_codegen_llvm` and our codegen represent it as 
+rustc_codegen_ssa does not actually tell you what your type representation should be, it allows you to decide. For
+example, rust-gpu represents it as a `SpirvType` enum, while both rustc_codegen_llvm and our codegen represent it as 
 opaque LLVM types:
 
 ```rs