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

View File

@ -2,8 +2,8 @@
If you would like to get the MIR:
- for a function - you can use the `optimized_mir(def_id)` query;
- for a promoted - you can use the `promoted_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` query.
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
@ -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)`
goes through several suites of passes, each grouped by a
query. Each suite consists of passes which perform analysis, transformation or optimization.
Each query represent a useful intermediate point
query. Each suite consists of passes which perform linting, analysis, transformation or
optimization. Each query represent a useful intermediate point
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;
@ -62,7 +62,7 @@ fields:
pub struct CleanupNonCodegenStatements;
```
for which we then implement the `MirPass` trait:
for which we implement the `MirPass` trait:
```rust
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
done so.
<!-- FIXME - What is force? Do we still have it in rustc? -->
Concretely, this means that if you have a query `foo(D)`
that wants to access the result of `mir_const(D)` or
`mir_promoted(D)`, you need to have the successor pass "force"
`foo(D)` using `ty::queries::foo::force(...)`. This will force a query
that wants to access the result of `mir_promoted(D)`, you need to have `foo(D)`
calling the `mir_const(D)` query first. This will force it
to execute even though you don't directly require its result.
> This mechanism is a bit dodgy. There is a discussion of more elegant