summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDylan MacKenzie <ecstaticmorse@gmail.com>2020-03-02 09:40:58 -0800
committerDylan MacKenzie <ecstaticmorse@gmail.com>2020-03-26 16:20:00 -0700
commitfe0e7c3cba6c8742f4e29920f4e7a52f88284a42 (patch)
treea5c6487808ef238fb52a62d70ec5c6f6e09c2c85
parentMove `BottomValue` into `framework/mod.rs` (diff)
downloadrust-fe0e7c3cba6c8742f4e29920f4e7a52f88284a42.tar.gz
rust-fe0e7c3cba6c8742f4e29920f4e7a52f88284a42.tar.bz2
rust-fe0e7c3cba6c8742f4e29920f4e7a52f88284a42.tar.xz
Update `framework` module docs
-rw-r--r--src/librustc_mir/dataflow/framework/mod.rs32
1 files changed, 15 insertions, 17 deletions
diff --git a/src/librustc_mir/dataflow/framework/mod.rs b/src/librustc_mir/dataflow/framework/mod.rs
index 345fb66..8556be7 100644
--- a/src/librustc_mir/dataflow/framework/mod.rs
+++ b/src/librustc_mir/dataflow/framework/mod.rs
@@ -1,26 +1,25 @@
1//! A framework that can express both [gen-kill] and generic dataflow problems. 1//! A framework that can express both [gen-kill] and generic dataflow problems.
2//! 2//!
3//! There is another interface for dataflow in the compiler in `librustc_mir/dataflow/mod.rs`. The 3//! To actually use this framework, you must implement either the `Analysis` or the
4//! interface in this module will eventually [replace that one][design-meeting]. 4//! `GenKillAnalysis` trait. If your transfer function can be expressed with only gen/kill
5//! operations, prefer `GenKillAnalysis` since it will run faster while iterating to fixpoint. The
6//! `impls` module contains several examples of gen/kill dataflow analyses.
5//! 7//!
6//! To actually use this framework, you must implement either the `Analysis` or the `GenKillAnalysis` 8//! Create an `Engine` for your analysis using the `into_engine` method on the `Analysis` trait,
7//! trait. If your transfer function can be expressed with only gen/kill operations, prefer 9//! then call `iterate_to_fixpoint`. From there, you can use a `ResultsCursor` to inspect the
8//! `GenKillAnalysis` since it will run faster while iterating to fixpoint. Create an `Engine` using 10//! fixpoint solution to your dataflow problem, or implement the `ResultsVisitor` interface and use
9//! the appropriate constructor and call `iterate_to_fixpoint`. You can use a `ResultsCursor` to 11//! `visit_results`. The following example uses the `ResultsCursor` approach.
10//! inspect the fixpoint solution to your dataflow problem.
11//! 12//!
12//! ```ignore(cross-crate-imports) 13//! ```ignore(cross-crate-imports)
13//! fn do_my_analysis(tcx: TyCtxt<'tcx>, body: &mir::Body<'tcx>, did: DefId) { 14//! use rustc_mir::dataflow::Analysis; // Makes `into_engine` available.
14//! let analysis = MyAnalysis::new();
15//!
16//! // If `MyAnalysis` implements `GenKillAnalysis`.
17//! let results = Engine::new_gen_kill(tcx, body, did, analysis).iterate_to_fixpoint();
18//! 15//!
19//! // If `MyAnalysis` implements `Analysis`. 16//! fn do_my_analysis(tcx: TyCtxt<'tcx>, body: &mir::Body<'tcx>, did: DefId) {
20//! // let results = Engine::new_generic(tcx, body, did, analysis).iterate_to_fixpoint(); 17//! let analysis = MyAnalysis::new()
21//! 18//! .into_engine(tcx, body, did)
22//! let mut cursor = ResultsCursor::new(body, results); 19//! .iterate_to_fixpoint()
20//! .into_results_cursor(body);
23//! 21//!
22//! // Print the dataflow state *after* each statement in the start block.
24//! for (_, statement_index) in body.block_data[START_BLOCK].statements.iter_enumerated() { 23//! for (_, statement_index) in body.block_data[START_BLOCK].statements.iter_enumerated() {
25//! cursor.seek_after(Location { block: START_BLOCK, statement_index }); 24//! cursor.seek_after(Location { block: START_BLOCK, statement_index });
26//! let state = cursor.get(); 25//! let state = cursor.get();
@@ -30,7 +29,6 @@
30//! ``` 29//! ```
31//! 30//!
32//! [gen-kill]: https://en.wikipedia.org/wiki/Data-flow_analysis#Bit_vector_problems 31//! [gen-kill]: https://en.wikipedia.org/wiki/Data-flow_analysis#Bit_vector_problems
33//! [design-meeting]https://github.com/rust-lang/compiler-team/issues/202
34 32
35use std::io; 33use std::io;
36 34