-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incr.comp.: Make sure dependencies are recorded when feeding queries during eval-always queries. #109935
incr.comp.: Make sure dependencies are recorded when feeding queries during eval-always queries. #109935
Conversation
…during eval-always queries.
TaskDepsRef::EvalAlways => { | ||
edges.push(DepNodeIndex::FOREVER_RED_NODE); | ||
} | ||
TaskDepsRef::Ignore => {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we insert this red dependency in both cases? Or should we ICE when feeding in ignore mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I've been wondering about that too. I think adding a dependency would be surprising. We are inside a with_ignore()
after all. But ICEing might be useful?
One factor that might influence a decision here is that we seem to wrap everything inside of TaskDepsRef::Ignore
by default:
rust/compiler/rustc_middle/src/ty/context/tls.rs
Lines 40 to 49 in a412564
pub fn new(gcx: &'tcx GlobalCtxt<'tcx>) -> Self { | |
let tcx = TyCtxt { gcx }; | |
ImplicitCtxt { | |
tcx, | |
query: None, | |
diagnostics: None, | |
query_depth: 0, | |
task_deps: TaskDepsRef::Ignore, | |
} | |
} |
If we changed that to TaskDepsRef::Forbid
there would be less chance of things being silently ignored and as a result less harm in treating TaskDepsRef::Ignore
as "yes, really turn off dependency tracking". We use DepGraph::with_ignore()
in a few places where we really don't want any dep-tracking to happen, e.g. when re-computing the value of a green node.
But I haven't tried what the fallout of switching to TaskDepsRef::Forbid
would be. It might need some cleanup.
Overall, I think DepGraph::with_ignore()
should really reliable turn off dep-tracking -- but we should use it in as few places as possible. This PR would be an example of replacing it with something more targeted.
@@ -8,34 +8,34 @@ use rustc_middle::hir::nested_filter; | |||
use rustc_middle::ty::TyCtxt; | |||
|
|||
pub fn check_crate(tcx: TyCtxt<'_>) { | |||
tcx.dep_graph.assert_ignored(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually running inside of an eval-always query, not in with_ignore()
. The two kinds both used TaskDepsRef::Ignore
before this PR. Now that there is a TaskDepsRef::EvalAlways
, the assertion fails.
Looking at the code again, I think we might actually want to just run it normally. I think the original with_ignore()
scope was just a performance optimization when this check was run for release builds too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the DepGraph::with_ignore()
scope in 5f52a96. It shouldn't make a difference for performance since the function doesn't do much in release builds.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 6117c06 with merge 2e6dc6945d8cfad0f6fd06ef2fc221f8930a8942... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (2e6dc6945d8cfad0f6fd06ef2fc221f8930a8942): comparison URL. Overall result: ❌✅ regressions and improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
According to the release schedule the next beta will be branched off on Friday. Maybe we can get this merged before then? Are there open questions you'd like me to address, @cjgillot? |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (661b33f): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
This PR makes sure we don't drop dependency edges when feeding queries during an eval-always query.
Background: During eval-always queries, no dependencies are recorded because the system knows to unconditionally re-evaluate them regardless of any actual dependencies. This works fine for these queries themselves but leads to a problem when feeding other queries: When queries are fed, we set up their dependency edges by copying the current set of dependencies of the feeding query. But because this set is empty for eval-always queries, we record no edges at all -- which has the effect that the fed query instances always look "green" to the system, although they should always be "red".
The fix is to explicitly add a dependency on the artificial "always red" dep-node when feeding during eval-always queries.
Fixes #108481
Maybe also fixes issue #88488.
cc @jyn514
r? @cjgillot or @oli-obk