@@ -194,6 +194,33 @@ Along the way, we also construct the THIR, which is an even more desugared HIR.
194
194
THIR is used for pattern and exhaustiveness checking. It is also more
195
195
convenient to convert into MIR than HIR is.
196
196
197
+ We do [ many optimizations on the MIR] [ mir-opt ] because it is still
198
+ generic and that improves the code we generate later, improving compilation
199
+ speed too.
200
+ MIR is a higher level (and generic) representation, so it is easier to do
201
+ some optimizations at MIR level than at LLVM-IR level. For example LLVM
202
+ doesn't seem to be able to optimize the pattern the [ ` simplify_try ` ] mir
203
+ opt looks for.
204
+
205
+ Rust code is _ monomorphized_ , which means making copies of all the generic
206
+ code with the type parameters replaced by concrete types. To do
207
+ this, we need to collect a list of what concrete types to generate code for.
208
+ This is called _ monomorphization collection_ and it happens at the MIR level.
209
+
210
+ ### Code generation
211
+
212
+ We then begin what is vaguely called _ code generation_ or _ codegen_ .
213
+ The [ code generation stage] [ codegen ] is when higher level
214
+ representations of source are turned into an executable binary. ` rustc `
215
+ uses LLVM for code generation. The first step is to convert the MIR
216
+ to LLVM Intermediate Representation (LLVM IR). This is where the MIR
217
+ is actually monomorphized, according to the list we created in the
218
+ previous step.
219
+ The LLVM IR is passed to LLVM, which does a lot more optimizations on it.
220
+ It then emits machine code. It is basically assembly code with additional
221
+ low-level types and annotations added (e.g. an ELF object or WASM).
222
+ The different libraries/binaries are then linked together to produce the final
223
+ binary.
197
224
198
225
[ String interning ] : https://en.wikipedia.org/wiki/String_interning
199
226
[ `rustc_lexer` ] : https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
0 commit comments