Skip to content

Remove ensure_done execution path#153472

Open
Zoxc wants to merge 1 commit intorust-lang:mainfrom
Zoxc:rem-ensure_done
Open

Remove ensure_done execution path#153472
Zoxc wants to merge 1 commit intorust-lang:mainfrom
Zoxc:rem-ensure_done

Conversation

@Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Mar 6, 2026

This removes the ensure_done execution path as it doesn't have a performance impact. ensure_done calls are left as markers still.

@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2026
@rust-log-analyzer

This comment has been minimized.

@Zoxc Zoxc force-pushed the rem-ensure_done branch from 9df2e95 to 7807faa Compare March 6, 2026 07:28
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 6, 2026

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Mar 6, 2026
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 6, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 6, 2026

☀️ Try build successful (CI)
Build commit: 0182a57 (0182a57e43b09ec52ae26ba9ba23c0af7f526148, parent: 69370dc4a8862b8401615a2a7b950704ba66c495)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0182a57): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.3% [0.2%, 0.4%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 0.3%, secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.7% [0.4%, 3.1%] 4
Regressions ❌
(secondary)
1.8% [0.5%, 2.8%] 4
Improvements ✅
(primary)
-1.5% [-2.7%, -0.8%] 3
Improvements ✅
(secondary)
-1.2% [-1.2%, -1.2%] 1
All ❌✅ (primary) 0.3% [-2.7%, 3.1%] 7

Cycles

Results (secondary 6.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
6.3% [5.9%, 6.7%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 482.035s -> 481.186s (-0.18%)
Artifact size: 397.04 MiB -> 397.03 MiB (-0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 6, 2026
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 6, 2026

Should we remove ensure_done? It doesn't do much since we do cache promotion anyway. We could also leave it as marker in case we remove cache promotion. cc @nnethercote @Zalathar

@Zalathar
Copy link
Member

Zalathar commented Mar 6, 2026

I’m surprised that this doesn’t have a big perf impact, though as you say, that’s probably because we end up promoting the values from disk later on anyway.

The way that we currently do promotion seems like it has room for improvement, so it might be prudent to leave ensure_done intact for now, at least as a marker.

@nnethercote
Copy link
Contributor

I'm always sympathetic to the idea of removing unnecessary stuff :) Is there a meaningful difference between tcx.ensure_done().foo() and let _ = tcx.foo()?

The comment on ensure_done says this:

    /// Wrapper that calls queries in a special "ensure done" mode, for callers
    /// that don't need the return value and just want to guarantee that the
    /// query won't be executed in the future, by executing it now if necessary.
    ///
    /// This is useful for queries that read from a [`Steal`] value, to ensure
    /// that they are executed before the query that will steal the value.
    ///
    /// Unlike [`Self::ensure_ok`], a query with all-green inputs will only be
    /// skipped if its return value is stored in the disk-cache. This is still
    /// more efficient than a regular query, because in that situation the
    /// return value doesn't necessarily need to be decoded.
    /// 
    /// (As with all query calls, execution is also skipped if the query result
    /// is already cached in memory.)

That sounds like partly an efficiency concern and partly a behavioural concern (the "guarantee" part). But I don't know if that comment is accurate. E.g. for the Steal part, I don't see much correlation between returning Steal and using ensure_done.

@Zoxc, do you know who introduced ensure_done? We should ask them.

@Zalathar
Copy link
Member

Zalathar commented Mar 6, 2026

The split between ensure_ok and ensure_done was introduced by #108820, though they had different names at the time. Previously, code would just use ensure_ok when it actually wanted ensure_done, leading to bugs when the provider was unexpectedly invoked later.

I introduced the current names and docs in #136279.

@nnethercote
Copy link
Contributor

Ok, looks like @cjgillot and @oli-obk were involved (no surprises!), let's see if they have opinions.

@Zalathar
Copy link
Member

Zalathar commented Mar 7, 2026

E.g. for the Steal part, I don't see much correlation between returning Steal and using ensure_done.

In several (most?) cases, the query used with ensure_done does not return Steal itself, but does rely on some other query's return value not having been stolen yet.

Anything that inspects THIR or MIR has a reasonable chance of falling into this category, for example.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 7, 2026

Yea I'd expect we'll need it for turning promoteds into their own items. But we can reintroduce this when needed

Just need to make sure we don't need it soon for https://github.com/rust-lang/rust/pull/153489/changes#diff-ad0c15bbde97a607d4758ec7eaf88248be5d6b8ae084dfc84127f81e3f7a9bb4R636

@rust-bors

This comment has been minimized.

@Zoxc Zoxc force-pushed the rem-ensure_done branch from 7807faa to 2abb0ba Compare March 23, 2026 19:50
@Zoxc Zoxc changed the title Disable ensure_done Remove ensure_done execution path Mar 23, 2026
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 23, 2026

I've removed the ensure_done execution path, but kept the calls as markers. Hopefully this should fix #152662 as the current ensure_done execution path has race conditions.

@Zoxc Zoxc marked this pull request as ready for review March 23, 2026 19:55
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 23, 2026
@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 23, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 23, 2026

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler, query-system
  • compiler, query-system expanded to 69 candidates
  • Random selection from 13 candidates

@oli-obk
Copy link
Contributor

oli-obk commented Mar 23, 2026

Curious. This removes 100% of cache hits of thir_abstract_const in various incremental patched tests I looked at. I don't know how to interpret that result, but it's not a perf issue anyway

@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 23, 2026

check_if_ensure_can_skip_execution adds cache hits for tcx.ensure_done().thir_abstract_const when it marks the node green, that no longer occurs.

#[derive(Debug)]
pub enum QueryMode {
/// This is a normal query call to `tcx.$query(..)` or `tcx.at(span).$query(..)`.
/// This is a query call to `tcx.$query(..)`, `tcx.at(span).$query(..)`or `tcx.ensure_done().$query(..)`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// This is a query call to `tcx.$query(..)`, `tcx.at(span).$query(..)`or `tcx.ensure_done().$query(..)`.
/// This is a query call to `tcx.$query(..)`, `tcx.at(span).$query(..)` or `tcx.ensure_done().$query(..)`.

Copy link
Contributor

@nnethercote nnethercote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment on TyCtxt::ensure_done definitely needs updating.

More generally, making ensure_done a no-op but leaving all the calls is icky. Lots of potential for confusion!

View changes since this review

@Zoxc Zoxc force-pushed the rem-ensure_done branch from 2abb0ba to 01c73a4 Compare March 24, 2026 01:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants