Be consistent with backticks.

A lot of names are used sometimes with backticks, sometimes without.
This commit removes backticks where necessary for these:

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

And adds backticks where necessary for these:

- rustc_codegen_*
- cuda_builder
- cuda_std
- lib.rs

Author: nnethercote

guide/src/SUMMARY.md

@@ -12,9 +12,9 @@
 - [The CUDA Toolkit](cuda/README.md)
   - [GPU Computing](cuda/gpu_computing.md)
   - [The CUDA Pipeline](cuda/pipeline.md)
-- [rustc_codegen_nvvm](nvvm/README.md)
+- [`rustc_codegen_nvvm`](nvvm/README.md)
   - [Custom Rustc Backends](nvvm/backends.md)
-  - [rustc_codegen_nvvm](nvvm/nvvm.md)
+  - [`rustc_codegen_nvvm`](nvvm/nvvm.md)
   - [Types](nvvm/types.md)
   - [PTX Generation](nvvm/ptxgen.md)
   - [Debugging](nvvm/debugging.md)

guide/src/cuda/gpu_computing.md

@@ -23,7 +23,7 @@ AMD GPUs with OpenCL, since OpenCL is generally slower, clunkier, and lacks libr
 
 # Why Rust?
 
-Rust is a great choice for GPU programming, however, it has needed a kickstart, which is what rustc_codegen_nvvm tries to 
+Rust is a great choice for GPU programming, however, it has needed a kickstart, which is what `rustc_codegen_nvvm` tries to 
 accomplish; The initial hurdle of getting Rust to compile to something CUDA can run is over, now comes the design and 
 polish part. 
 

guide/src/faq.md

@@ -153,13 +153,13 @@ things to gain in terms of safety using Rust.
 The reasoning for this is the same reasoning as to why you would use CUDA over opengl/vulkan compute shaders:
 - CUDA usually outperforms shaders if kernels are written well and launch configurations are optimal.
 - CUDA has many useful features such as shared memory, unified memory, graphs, fine grained thread control, streams, the PTX ISA, etc.
-- rust-gpu does not perform many optimizations, and with rustc_codegen_ssa's less than ideal codegen, the optimizations by LLVM and libNVVM are needed.
+- rust-gpu does not perform many optimizations, and with `rustc_codegen_ssa`'s less than ideal codegen, the optimizations by LLVM and libNVVM are needed.
 - SPIR-V is arguably still not suitable for serious GPU kernel codegen, it is underspecced, complex, and does not mention many things which are needed.
 While libNVVM (which uses a well documented subset of LLVM IR) and the PTX ISA are very thoroughly documented/specified.
 - rust-gpu is primarily focused on graphical shaders, compute shaders are secondary, which the rust ecosystem needs, but it also 
 needs a project 100% focused on computing, and computing only.
 - SPIR-V cannot access many useful CUDA libraries such as OptiX, cuDNN, cuBLAS, etc.
-- SPIR-V debug info is still very young and rust-gpu cannot generate it. While rustc_codegen_nvvm does, which can be used
+- SPIR-V debug info is still very young and rust-gpu cannot generate it. While `rustc_codegen_nvvm` does, which can be used
 for profiling kernels in something like nsight compute.
 
 Moreover, CUDA is the primary tool used in big computing industries such as VFX and scientific computing. Therefore 

guide/src/guide/getting_started.md

@@ -60,7 +60,7 @@ 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:
 
@@ -88,7 +88,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_ctypes_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)]
@@ -173,7 +173,7 @@ To use it you can simply add it as a build dependency in your CPU crate (the cra
 +cuda_builder = "XX"
 ```
 
-Where `XX` is the current version of cuda_builder.
+Where `XX` is the current version of `cuda_builder`.
 
 Then, you can simply invoke it in the build.rs of your CPU crate:
 

guide/src/guide/kernel_abi.md

@@ -15,7 +15,7 @@ other ABI we override purely to avoid footguns.
 
 Functions marked as `#[kernel]` are enforced to be `extern "C"` by the kernel macro, and it is expected
 that __all__ GPU kernels be `extern "C"`, not that you should be declaring any kernels without the `#[kernel]` macro,
-because the codegen/cuda_std is allowed to rely on the behavior of `#[kernel]` for correctness.
+because the codegen/`cuda_std` is allowed to rely on the behavior of `#[kernel]` for correctness.
 
 ## Structs 
 

guide/src/nvvm/README.md

@@ -1,10 +1,10 @@
-# rustc_codegen_nvvm
+# `rustc_codegen_nvvm`
 
-This section will cover the more technical details of how rustc_codegen_nvvm works 
+This section will cover the more technical details of how `rustc_codegen_nvvm` works 
 as well as the issues that came with it.
 
 It will also explain some technical details about CUDA/PTX/etc, it is not necessarily 
-limited to rustc_codegen_nvvm.
+limited to `rustc_codegen_nvvm`.
 
 Basic knowledge of how rustc and LLVM work and what they do is assumed. You can find
 info about rustc in the [rustc dev guide](https://rustc-dev-guide.rust-lang.org/).

guide/src/nvvm/backends.md

@@ -1,6 +1,6 @@
 # Custom Rustc Backends
 
-Before we get into the details of rustc_codegen_nvvm, we obviously need to explain what a codegen is!
+Before we get into the details of `rustc_codegen_nvvm`, we obviously need to explain what a codegen is!
 
 Custom codegens are rustc's answer to "well what if I want rust to compile to X?". This is a problem
 that comes up in many situations, especially conversations of "well LLVM cannot target this, so we are screwed".
@@ -15,22 +15,22 @@ Nowadays, Rustc is almost fully decoupled from LLVM and it is instead generic ov
 Rustc instead uses a system of codegen backends that implement traits and then get loaded as dynamically linked libraries.
 This allows rust to compile to virtually anything with a surprisingly small amount of work. At the time of writing, there are
 five publicly known codegens that exist:
-- rustc_codegen_cranelift
-- rustc_codegen_llvm
-- rustc_codegen_gcc
-- rustc_codegen_spirv
-- rustc_codegen_nvvm, obviously the best codegen ;)
+- `rustc_codegen_cranelift`
+- `rustc_codegen_llvm`
+- `rustc_codegen_gcc`
+- `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)
 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).
+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. 
 What NVVM IR/libNVVM are has been covered in the [CUDA section](../../cuda/pipeline.md).
 
-# rustc_codegen_ssa
+# `rustc_codegen_ssa`
 
 `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

guide/src/nvvm/nvvm.md

@@ -1,4 +1,4 @@
-# rustc_codegen_nvvm
+# `rustc_codegen_nvvm`
 
 At the highest level, our codegen workflow goes like this:
 
@@ -14,7 +14,7 @@ Source code -> Typechecking -> MIR -> SSA Codegen -> LLVM IR (NVVM IR) -> PTX ->
 Before we do anything, rustc does its normal job, it typechecks, converts everything to MIR, etc. Then, 
 rustc loads our codegen shared lib and invokes it to codegen the MIR. It creates an instance of
 `NvvmCodegenBackend` and it invokes `codegen_crate`. You could do anything inside `codegen_crate` but 
-we just defer back to rustc_codegen_ssa and tell it to do the job for us:
+we just defer back to `rustc_codegen_ssa` and tell it to do the job for us:
 
 ```rs
 fn codegen_crate<'tcx>(

guide/src/nvvm/ptxgen.md

@@ -61,7 +61,7 @@ important one is libdevice, libdevice is essentially a bitcode module containing
 that nvidia provides for us. You can find it as a `.bc` file in the libdevice folder inside your NVVM install location.
 Every function inside of it is prefixed with `__nv_`, you can find docs for it [here](https://docs.nvidia.com/cuda/libdevice-users-guide/index.html).
 
-We declare these intrinsics inside of `ctx_intrinsics.rs` and link to them inside cuda_std. We also use them to codegen
+We declare these intrinsics inside of `ctx_intrinsics.rs` and link to them inside `cuda_std`. We also use them to codegen
 a lot of intrinsics inside `intrinsic.rs`, such as `sqrtf32`.
 
 libdevice is also lazy loaded so we do not import useless intrinsics.

guide/src/nvvm/types.md

@@ -4,7 +4,7 @@ Types! who doesn't love types, especially those that cause libNVVM to randomly s
 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 
+example, rust-gpu represents it as a `SpirvType` enum, while both `rustc_codegen_llvm` and our codegen represent it as 
 opaque LLVM types:
 
 ```rs
@@ -13,7 +13,7 @@ type Type = &'ll llvm::Type;
 
 `llvm::Type` is an opaque type that comes from llvm-c. `'ll` is one of the main lifetimes you will see
 throughout the whole codegen, it is used for anything that lasts as long as the current usage of LLVM. 
-LLVM gives you back pointers when you ask for a type or value, some time ago rustc_codegen_llvm fully switched to using
+LLVM gives you back pointers when you ask for a type or value, some time ago `rustc_codegen_llvm` fully switched to using
 references over pointers, and we follow in their footsteps. 
 
 One important fact about types is that they are opaque, you cannot take a type and ask "is this X struct?",