A single framework for gen-kill and generic dataflow problems

[ecstatic-morse]

This is the prototype implementation discussed in rust-lang/compiler-team#202. You can read a high-level description of it in the proposal for that design meeting. This would eventually supersede the existing BitDenotation interface.

r? @ghost

cc @rust-lang/compiler (esp. @eddyb and @pnkfelix)

[bors]

☔ The latest upstream changes (presumably #65869) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

Ping from triage:
@ecstatic-morse Hi! is this PR still in progress?
thanks.

[JohnCSimon]

Pinging from triage:
@ecstatic-morse Can you please provide status on this PR?
thanks.

[ecstatic-morse]

This was discussed in the design meeting on Nov. 8 (rust-lang/compiler-team#202). The consensus was to move forward on a design similar to the prototype. I'll be actively working to finish this, hopefully with some input from the compiler team.

[ecstatic-morse]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 75775ba with merge 1e0b457...

[bors]

☀️ Try build successful - checks-azure
Build commit: 1e0b457 (1e0b457f588f21c0dfef20d076a5bc1371571aa1)

[rust-timer]

Queued 1e0b457 with parent 3f07f1c, future comparison URL.

[rust-timer]

Finished benchmarking try commit 1e0b457, comparison URL.

[ecstatic-morse]

Okay, this now converts a commonly used dataflow analysis, MaybeInitializedLocals to the new framework to get an idea of usability/perf changes. The Engine implementation is simpler than the original since the choice of whether to cache block transfer functions is now dynamic. As a result, we can skip caching block transfer functions for acyclic MIR in the future.

I've triggered a perf run and the results look okay except for a slight regression in wg-grammar. I will try lifting the check for a cached block transfer function out of the loop to see if that helps. Regardless, I think this is ready for an initial round of review.

r? @pnkfelix cc @rust-lang/compiler (feel free to reassign)

Here are the unresolved "details" questions from the design meeting that are pertinent to this PR along with my thoughts on each. We should resolve these questions before merging.

• How do we feel about the {before_,}*_effect naming convention? It takes a bit of getting used to, and doesn’t extend nicely to backwards dataflow.
  • OTOH, having a canonical statement_effect which most implementers want to use and a secondary, prefixed effect which is only rarely used is good.
• Should we be passing a mir::Statement to the statement effect methods? What about mir::Body to bits_per_block?
  • I'd like to have a HasBody<'mir, 'tcx> trait that is a requirement for AnalysisDomain instead of passing in a separate body around everywhere, but this will increase the amount of boilerplate required.
• Should the Analysis methods take &self or &mut self?
  • Some may depend on the results of an earlier dataflow analysis and want to hold a cursor.
  • However, transfer functions should be pure for a given MIR, so maybe forcing those analyses to use interior mutability is appropriate.

[ecstatic-morse]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit dceb654 with merge 43d649e...

[bors]

☀️ Try build successful - checks-azure
Build commit: 43d649e (43d649e19deb1597a734b28389fc636e8f1f2ad0)

[ecstatic-morse]

I migrated the analyses used during borrow checking/drop elaboration to the new framework and perf seems good. I'm gonna try a few small optimizations I mentioned during the design meeting over on that PR as well.

While doing the conversion, it became apparent that code would much be nicer if we continued the "builder" style all the way back to Analysis by extending it with an into_engine method. For example, code like this:

let flow_inits = MaybeInitializedPlaces::new(tcx, &body, &mdpe);
let mut flow_inits = dataflow::generic::Engine::new_gen_kill(tcx, &body, def_id, flow_inits)
    .iterate_to_fixpoint()
    .into_cursor(&body);

could instead be written like this:

let mut flow_inits = MaybeInitializedPlaces::new(tcx, &body, &mdpe)
    .into_engine(tcx, &body, def_id)
    .iterate_to_fixpoint()
    .into_cursor(&body);

Another idea was to add HasBody as a supertrait of AnalysisDomain. This would obviate the need to pass body everywhere. With the current API, it's possible (albeit unlikely) for a user to pass a different mir::Body into, for example, into_engine than was used to create the analysis, which would cause subtle bugs. I believe this would only work if the Analysis methods continue to take &self, however.

I think it will take a few revisions to find the optimal API, and this PR has been sitting in the queue for a while, so I think we should not block it on making a decision re: the aforementioned changes. For now I'm focused on resolving any outstanding concerns of @pnkfelix.

[ecstatic-morse]

@pnkfelix I addressed the motivation for the GenKill trait and added some documentation/renamed some methods in the last two commits.

[pnkfelix]

Thanks @ecstatic-morse !

[pnkfelix]

@bors r+

[bors]

📌 Commit 7b4dca2 has been approved by pnkfelix

[bors]

⌛ Testing commit 7b4dca2 with merge 2cf24ab...

[bors]

☀️ Test successful - checks-azure
Approved by: pnkfelix
Pushing 2cf24ab to master...