Skip to content
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

Represent diagnostic side effects as dep nodes #122156

Merged
merged 4 commits into from
Mar 19, 2025

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Mar 7, 2024

This changes diagnostic to be tracked as a special dep node (SideEffect) instead of having a list of side effects associated with each dep node. SideEffect is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new SideEffect with an unique dep node index.

Some implications of this:

  • Diagnostic may now be emitted more than once as they can be emitted once when the SideEffect gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.

  • Anon tasks which emits diagnostics will no longer incorrectly be merged with other anon tasks.

  • Reusing a CGU will now emit diagnostics from the task generating it.

@rustbot
Copy link
Collaborator

rustbot commented Mar 7, 2024

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

@rustbot rustbot added 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. labels Mar 7, 2024
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 8, 2024

Performance impact:

BenchmarkBeforeAfter
TimeTime%
🟣 clap:check:unchanged0.3793s0.3780s -0.34%
🟣 hyper:check:unchanged0.1193s0.1180s💚 -1.04%
🟣 regex:check:unchanged0.2780s0.2768s -0.42%
🟣 syn:check:unchanged0.5607s0.5593s -0.25%
🟣 syntex_syntax:check:unchanged1.3421s1.3397s -0.18%
Total2.6793s2.6718s -0.28%
Summary1.0000s0.9955s -0.45%
BenchmarkBeforeAfter
TimeTime%
🟣 clap:check:initial1.8871s1.8846s -0.13%
🟣 hyper:check:initial0.3099s0.3094s -0.16%
🟣 regex:check:initial1.1095s1.1079s -0.15%
🟣 syn:check:initial1.8133s1.8098s -0.19%
🟣 syntex_syntax:check:initial6.6921s6.6865s -0.08%
Total11.8119s11.7981s -0.12%
Summary1.0000s0.9986s -0.14%

@bors
Copy link
Contributor

bors commented Mar 13, 2024

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

@cjgillot cjgillot self-assigned this Mar 14, 2024
@fmease fmease removed their assignment Mar 14, 2024
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 15, 2024

cc @michaelwoerister

@michaelwoerister
Copy link
Member

Thanks for the ping, @Zoxc! I'll try to take a closer look some time this week.

@michaelwoerister
Copy link
Member

The changes1 look good to me. I like how this remove state from the context 🙂

One question: does this increase the number of dep-nodes we create? I can't quite tell if this will unconditionally emit a SideEffect dep-node, even if no diagnostic was emitted.

Footnotes

  1. I've only looked at the last commit, since the rest seems to come from https://github.com/rust-lang/rust/pull/122070)

@michaelwoerister
Copy link
Member

does this increase the number of dep-nodes we create? I can't quite tell if this will unconditionally emit a SideEffect dep-node, even if no diagnostic was emitted.

Looks like it will be one dep-node per emitted diagnostic, so that's fine.

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

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

Thanks @Zoxc! I like a lot how this design simplifies this whole side-effect tracking business.

Could you run perf on the rebased PR?

Could we do without having to thread the SerializedDepNodeIndex everywhere?
An quick idea I have would be some SideEffectIndex: a sequential index returned by store_side_effects, and put into the side-effect DepNode's fingerprint part. We'd still have the information we need, encoded sequentially in the on-disk cache instead of a hash-map.

@Dylan-DPC Dylan-DPC added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2024
@Zoxc Zoxc force-pushed the side-effect-dep-node branch from f0413f6 to c6011a7 Compare March 11, 2025 20:44
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 11, 2025

This can get a perf run now.

@Kobzol
Copy link
Contributor

Kobzol commented Mar 11, 2025

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 11, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 11, 2025
Represent diagnostic side effects as dep nodes

This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index.

Some implications of this:

- Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.

- Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks.

- Reusing a CGU will now emit diagnostics from the task generating it.

Based on rust-lang#122070.
@bors
Copy link
Contributor

bors commented Mar 11, 2025

⌛ Trying commit c6011a7 with merge b616195...

@bors
Copy link
Contributor

bors commented Mar 12, 2025

☀️ Try build successful - checks-actions
Build commit: b616195 (b61619566995f8b3b176227de681f28b7add8834)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (b616195): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking 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
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-1.3%, -0.3%] 114
Improvements ✅
(secondary)
-0.9% [-1.5%, -0.2%] 29
All ❌✅ (primary) -0.7% [-1.3%, -0.3%] 114

Max RSS (memory usage)

Results (primary 0.8%, secondary -4.2%)

This 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.

mean range count
Regressions ❌
(primary)
3.6% [2.7%, 4.9%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-3.3% [-4.0%, -2.6%] 2
Improvements ✅
(secondary)
-4.2% [-6.2%, -2.2%] 2
All ❌✅ (primary) 0.8% [-4.0%, 4.9%] 5

Cycles

Results (primary -1.3%)

This 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.

mean range count
Regressions ❌
(primary)
1.2% [0.5%, 1.9%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.9% [-3.9%, -2.4%] 3
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.3% [-3.9%, 1.9%] 5

Binary size

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

Bootstrap: 780.09s -> 779.623s (-0.06%)
Artifact size: 365.26 MiB -> 365.23 MiB (-0.01%)

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

Zoxc commented Mar 13, 2025

An quick idea I have would be some SideEffectIndex: a sequential index returned by store_side_effects, and put into the side-effect DepNode's fingerprint part. We'd still have the information we need, encoded sequentially in the on-disk cache instead of a hash-map.

I think something like that could work, less sure if it's an improvement though.

@Zoxc Zoxc force-pushed the side-effect-dep-node branch from c6011a7 to 9a847b1 Compare March 14, 2025 17:55
@Zoxc Zoxc marked this pull request as ready for review March 14, 2025 17:56
@Zoxc
Copy link
Contributor Author

Zoxc commented Mar 14, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 14, 2025
@oli-obk oli-obk assigned oli-obk and unassigned cjgillot Mar 18, 2025
if let Some(ref data) = self.data {
D::read_deps(|task_deps| match task_deps {
TaskDepsRef::EvalAlways | TaskDepsRef::Ignore => return,
TaskDepsRef::Forbid | TaskDepsRef::Allow(..) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't Forbid be unreachable here? If we are decoding a query will we ever emit diagnostics?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The forbid case will just panic in read_index, so it's just a sanity check.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess 😃

@oli-obk
Copy link
Contributor

oli-obk commented Mar 18, 2025

@bors r+

@bors
Copy link
Contributor

bors commented Mar 18, 2025

📌 Commit b43a297 has been approved by oli-obk

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Mar 18, 2025

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2025
@bors
Copy link
Contributor

bors commented Mar 19, 2025

⌛ Testing commit b43a297 with merge 1aeb99d...

@bors
Copy link
Contributor

bors commented Mar 19, 2025

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 1aeb99d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 19, 2025
@bors bors merged commit 1aeb99d into rust-lang:master Mar 19, 2025
7 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 19, 2025
Copy link

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing a7fc463 (parent) -> 1aeb99d (this PR)

Test differences

No test diffs found

@Zoxc Zoxc deleted the side-effect-dep-node branch March 19, 2025 19:03
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1aeb99d): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-1.4%, -0.2%] 117
Improvements ✅
(secondary)
-0.9% [-1.6%, -0.0%] 37
All ❌✅ (primary) -0.7% [-1.4%, -0.2%] 117

Max RSS (memory usage)

Results (primary 1.0%)

This 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.

mean range count
Regressions ❌
(primary)
1.0% [1.0%, 1.0%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.0% [1.0%, 1.0%] 1

Cycles

Results (primary -1.6%, secondary -2.9%)

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.6% [-2.3%, -0.9%] 22
Improvements ✅
(secondary)
-2.9% [-4.5%, -1.6%] 10
All ❌✅ (primary) -1.6% [-2.3%, -0.9%] 22

Binary size

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

Bootstrap: 773.717s -> 774.586s (0.11%)
Artifact size: 365.52 MiB -> 365.51 MiB (-0.00%)

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) merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

None yet

10 participants