about summary refs log tree commit diff
path: root/compiler
diff options
context:
space:
mode:
authorManish Goregaokar <manishsmail@gmail.com>2021-10-05 12:52:48 -0700
committerGitHub <noreply@github.com>2021-10-05 12:52:48 -0700
commitf71b3e2b46505fda8dea7187fa90b80472f7abfa (patch)
treefbf28a75f29d4f004795e4adf0a826fc81e01f30 /compiler
parent048b0fd98df7ed3351e4c133eda4f683cb872956 (diff)
parent9f9f7f695a793c5ef27d219dbd00c66810f34e92 (diff)
downloadrust-f71b3e2b46505fda8dea7187fa90b80472f7abfa.tar.gz
rust-f71b3e2b46505fda8dea7187fa90b80472f7abfa.zip
Rollup merge of #89532 - ecstatic-morse:maybe-live-locals-enum, r=oli-obk,tmiasko
Document behavior of  `MaybeLiveLocals` regarding enums and field-senstivity

This arose from a [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/MaybeLiveLocals.20and.20Discriminants) where a new contributor attempted to implement a dead-store elimination pass using this analysis. They ran into a nasty hack around `SetDiscriminant` the effect of which is to lets handle assignments of literals to enum-typed locals (e.g. `x = Some(4)`) correctly. This took me a while to figure out.

Document this oddity, so the next person will have an easier time, and add a test to enshrine the current behavior.

r? ``@tmiasko``
Diffstat (limited to 'compiler')
-rw-r--r--compiler/rustc_mir_dataflow/src/impls/liveness.rs31
1 files changed, 31 insertions, 0 deletions
diff --git a/compiler/rustc_mir_dataflow/src/impls/liveness.rs b/compiler/rustc_mir_dataflow/src/impls/liveness.rs
index 0039d3188d5..3e2548845e2 100644
--- a/compiler/rustc_mir_dataflow/src/impls/liveness.rs
+++ b/compiler/rustc_mir_dataflow/src/impls/liveness.rs
@@ -11,6 +11,37 @@ use crate::{AnalysisDomain, Backward, GenKill, GenKillAnalysis};
 /// exist. See [this `mir-dataflow` test][flow-test] for an example. You almost never want to use
 /// this analysis without also looking at the results of [`MaybeBorrowedLocals`].
 ///
+/// ## Field-(in)sensitivity
+///
+/// As the name suggests, this analysis is field insensitive. If a projection of a variable `x` is
+/// assigned to (e.g. `x.0 = 42`), it does not "define" `x` as far as liveness is concerned. In fact,
+/// such an assignment is currently marked as a "use" of `x` in an attempt to be maximally
+/// conservative.
+///
+/// ## Enums and `SetDiscriminant`
+///
+/// Assigning a literal value to an `enum` (e.g. `Option<i32>`), does not result in a simple
+/// assignment of the form `_1 = /*...*/` in the MIR. For example, the following assignment to `x`:
+///
+/// ```
+/// x = Some(4);
+/// ```
+///
+/// compiles to this MIR
+///
+/// ```
+/// ((_1 as Some).0: i32) = const 4_i32;
+/// discriminant(_1) = 1;
+/// ```
+///
+/// However, `MaybeLiveLocals` **does** mark `x` (`_1`) as "killed" after a statement like this.
+/// That's because it treats the `SetDiscriminant` operation as a definition of `x`, even though
+/// the writes that actually initialized the locals happened earlier.
+///
+/// This makes `MaybeLiveLocals` unsuitable for certain classes of optimization normally associated
+/// with a live variables analysis, notably dead-store elimination. It's a dirty hack, but it works
+/// okay for the generator state transform (currently the main consumuer of this analysis).
+///
 /// [`MaybeBorrowedLocals`]: super::MaybeBorrowedLocals
 /// [flow-test]: https://github.com/rust-lang/rust/blob/a08c47310c7d49cbdc5d7afb38408ba519967ecd/src/test/ui/mir-dataflow/liveness-ptr.rs
 /// [liveness]: https://en.wikipedia.org/wiki/Live_variable_analysis