mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

refine mir passes doc

This commit is contained in:
Jaic1 2024-06-30 11:04:30 +08:00 committed by Oli Scherer
parent bd44a1714a
commit 03dfd90ce5
1 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/mir/passes.md
View File

@ -2,8 +2,8 @@
If you would like to get the MIR: If you would like to get the MIR:
- for a function - you can use the `optimized_mir(def_id)` query; - for a function - you can use the `optimized_mir` query (typically used by codegen) or the `mir_for_ctfe` query (typically used by compile time function evaluation, i.e., *CTFE*);
- for a promoted - you can use the `promoted_mir(def_id)` query. - for a promoted - you can use the `promoted_mir` query.
These will give you back the final, optimized MIR. For foreign def-ids, we simply read the MIR These will give you back the final, optimized MIR. For foreign def-ids, we simply read the MIR
from the other crate's metadata. But for local def-ids, the query will from the other crate's metadata. But for local def-ids, the query will
@ -13,8 +13,8 @@ This section describes how those queries and passes work and how you can extend
To produce the optimized MIR for a given def-id `D`, `optimized_mir(D)` To produce the optimized MIR for a given def-id `D`, `optimized_mir(D)`
goes through several suites of passes, each grouped by a goes through several suites of passes, each grouped by a
query. Each suite consists of passes which perform analysis, transformation or optimization. query. Each suite consists of passes which perform linting, analysis, transformation or
Each query represent a useful intermediate point optimization. Each query represent a useful intermediate point
where we can access the MIR dialect for type checking or other purposes: where we can access the MIR dialect for type checking or other purposes:
- `mir_built(D)` – it gives the initial MIR just after it's built; - `mir_built(D)` – it gives the initial MIR just after it's built;
@ -62,7 +62,7 @@ fields:
pub struct CleanupNonCodegenStatements; pub struct CleanupNonCodegenStatements;
``` ```
for which we then implement the `MirPass` trait: for which we implement the `MirPass` trait:
```rust ```rust
impl<'tcx> MirPass<'tcx> for CleanupNonCodegenStatements { impl<'tcx> MirPass<'tcx> for CleanupNonCodegenStatements {
@ -95,11 +95,9 @@ ensure that, before the MIR at a particular phase in the processing
pipeline is stolen, anyone who may want to read from it has already pipeline is stolen, anyone who may want to read from it has already
done so. done so.
<!-- FIXME - What is force? Do we still have it in rustc? -->
Concretely, this means that if you have a query `foo(D)` Concretely, this means that if you have a query `foo(D)`
that wants to access the result of `mir_const(D)` or that wants to access the result of `mir_promoted(D)`, you need to have `foo(D)`
`mir_promoted(D)`, you need to have the successor pass "force" calling the `mir_const(D)` query first. This will force it
`foo(D)` using `ty::queries::foo::force(...)`. This will force a query
to execute even though you don't directly require its result. to execute even though you don't directly require its result.
> This mechanism is a bit dodgy. There is a discussion of more elegant > This mechanism is a bit dodgy. There is a discussion of more elegant