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

Merge collect_mod_item_types query into check_well_formed #121500

Merged
merged 4 commits into from
Mar 8, 2024

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Feb 23, 2024

follow-up to #121154

this removes more potential parallel-compiler bottlenecks and moves diagnostics for the same items next to each other, instead of grouping diagnostics by analysis kind

@rustbot rustbot added 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Feb 23, 2024
@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 23, 2024

@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 Feb 23, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 23, 2024
Merge `collect_mod_item_types` query into `check_well_formed`

follow-up to rust-lang#121154

r? `@ghost`
@bors
Copy link
Contributor

bors commented Feb 23, 2024

⌛ Trying commit 62bc4bd with merge f7e3a77...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Feb 23, 2024

☀️ Try build successful - checks-actions
Build commit: f7e3a77 (f7e3a773b2abb47ee303fe6f3caf3fe054442d77)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (f7e3a77): 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 a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

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

Cycles

Results

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)
2.3% [2.0%, 2.5%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.9% [-5.1%, -0.8%] 4
All ❌✅ (primary) 1.0% [1.0%, 1.0%] 1

Binary size

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

Bootstrap: 650.894s -> 650.065s (-0.13%)
Artifact size: 310.95 MiB -> 310.88 MiB (-0.02%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 23, 2024
@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 7, 2024

@bors try @rust-timer queue

r? compiler

@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 7, 2024
@bors
Copy link
Contributor

bors commented Mar 7, 2024

⌛ Trying commit fa823ff with merge 1f106e7...

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 7, 2024
Merge `collect_mod_item_types` query into `check_well_formed`

follow-up to rust-lang#121154

this removes more potential parallel-compiler bottlenecks and moves diagnostics for the same items next to each other, instead of grouping diagnostics by analysis kind
&& let Some(def_id) = frame.query.def_id
{
let n = tcx.generics_of(def_id).params.len();
vec![ty::Variance::Bivariant; n].leak()
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you explain what happens here?
When will this impl be called? Is this logic for error recovery?

(Also tcx.arena.allocate could probably be used instead of leak.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When will this impl be called? Is this logic for error recovery?

This is not part of recovery, but of cycle_delay_bug. In order to hide cycle errors in favor of more useful errors, we can make the query cycle turn into a span_delayed_bug. But then we need a value to return from the query, which is where all the impls in this module are invoked. They produce a dummy value for the query.

(Also tcx.arena.allocate could probably be used instead of leak.)

Then I would have to transmute the result 😆

I guess if someone is running rustc in a loop from within the same process, and keep hitting this cycle error, they would slowly lose memory

Copy link
Contributor Author

Choose a reason for hiding this comment

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

edit: leak is already being used elsewhere in this file, so this is more of a general point that we could figure out, but it seems low priority, so I think just avoiding the unsafe code is best

Copy link
Contributor

@petrochenkov petrochenkov Mar 7, 2024

Choose a reason for hiding this comment

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

This is not part of recovery

I mean ErrorGuaranteed is passed to this function, so some error already happened (or at least was stashed)?
So this dummy value is never created on a good path.

Edit: the bit about span_delayed_bug is also not clear, if we have an ErrorGuaranteed then the delayed bug will never be reported.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

span_delayed_bug creates an ErrorGuaranteed without emitting an error. It will ICE the compiler if you forgot to emit an error later

});
let _ = items.par_foreign_items(|item| {
Ok(CollectItemTypesVisitor { tcx }.visit_foreign_item(hir.foreign_item(item)))
});
Copy link
Contributor

Choose a reason for hiding this comment

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

In general, I'd expect having something like par_visit_item_likes_in_module instead of doing things like this here or in wf checking.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That can't be done nicely, because visit_item_likes_in_module uses a visitor. I guess we could add something that creates the visitor 4 times just like I did here, but considering after this PR we again have only a single use site of such a par_visit_item_likes_in_module method, keeping it inline at the one use site seems best to me?

Copy link
Contributor

@petrochenkov petrochenkov Mar 7, 2024

Choose a reason for hiding this comment

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

considering after this PR we again have only a single use site of such a par_visit_item_likes_in_module method

If overhead of parallel queries was low enough, then I'd expect pretty much every visit_item_likes_in_modules and visit_all_item_likes_in_crates to benefit from being turned into its par_ version.
(Although maybe we'll need a special Par version of visitor for this.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll add it to the list of things I am investigating around the parallel compiler

@petrochenkov petrochenkov 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 Mar 7, 2024
@rust-log-analyzer

This comment has been minimized.

@petrochenkov
Copy link
Contributor

No requests, besides the general questions I was also waiting for perf results from #121500 (comment), that perf run is still in the queue.

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 7, 2024

whoops, force pushes for clippy ui tests cancelled rust-timer, but not the try build, so reusing that build

@rust-timer build 1f106e7

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1f106e7): 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 a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.7%, -0.2%] 3
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.2%] 9
All ❌✅ (primary) -0.5% [-0.7%, -0.2%] 3

Max RSS (memory usage)

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

Cycles

Results

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)
2.6% [2.4%, 2.7%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 648.501s -> 647.819s (-0.11%)
Artifact size: 172.69 MiB -> 172.65 MiB (-0.02%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 8, 2024
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Mar 8, 2024

📌 Commit ae50e36 has been approved by petrochenkov

It is now in the queue for this repository.

@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 8, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 8, 2024
Merge `collect_mod_item_types` query into `check_well_formed`

follow-up to rust-lang#121154

this removes more potential parallel-compiler bottlenecks and moves diagnostics for the same items next to each other, instead of grouping diagnostics by analysis kind
@bors
Copy link
Contributor

bors commented Mar 8, 2024

⌛ Testing commit ae50e36 with merge 5bff44f...

@bors
Copy link
Contributor

bors commented Mar 8, 2024

💔 Test failed - checks-actions

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

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
  SDKROOT: /Applications/Xcode_14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk
  AR: ar
##[endgroup]
curl: (28) Operation too slow. Less than 100 bytes/sec transferred the last 5 seconds
Error: Failure while executing; `/usr/bin/env /usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie /dev/null --globoff --user-agent Homebrew/4.2.9\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.4\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --remote-time --output /Users/runner/Library/Caches/Homebrew/api/formula.jws.json --location --disable --cookie /dev/null --globoff --show-error --user-agent Homebrew/4.2.9\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.4\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --compressed --speed-limit 100 --speed-time 5 https://formulae.brew.sh/api/formula.jws.json` exited with 28. Here's the output:

##[error]Process completed with exit code 1.
Post job cleanup.
[command]/usr/local/bin/git version

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 8, 2024

@bors retry curl: (28) Operation too slow. Less than 100 bytes/sec transferred the last 5 seconds

@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 8, 2024
@bors
Copy link
Contributor

bors commented Mar 8, 2024

⌛ Testing commit ae50e36 with merge 74acabe...

@bors
Copy link
Contributor

bors commented Mar 8, 2024

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 74acabe to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 8, 2024
@bors bors merged commit 74acabe into rust-lang:master Mar 8, 2024
12 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Mar 8, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 8, 2024
Run a single huge par_body_owners instead of many small ones after each other.

This improves parallel rustc parallelism by avoiding the bottleneck after each individual `par_body_owners` (because it needs to wait for queries to finish, so if there is one long running one, a lot of cores will be idle while waiting for the single query).

based on rust-lang#121500
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (74acabe): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.8%, -0.2%] 4
Improvements ✅
(secondary)
-0.5% [-0.6%, -0.5%] 2
All ❌✅ (primary) -0.6% [-0.8%, -0.2%] 4

Max RSS (memory usage)

Results

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)
- - 0
Improvements ✅
(secondary)
-5.6% [-5.8%, -5.4%] 2
All ❌✅ (primary) - - 0

Cycles

Results

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.7% [1.4%, 2.0%] 3
Regressions ❌
(secondary)
2.0% [1.7%, 2.4%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-3.3%, -2.1%] 5
All ❌✅ (primary) 1.7% [1.4%, 2.0%] 3

Binary size

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

Bootstrap: 649.016s -> 648.792s (-0.03%)
Artifact size: 172.57 MiB -> 172.56 MiB (-0.01%)

@oli-obk oli-obk deleted the track_errors12 branch March 8, 2024 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants