Skip to content

Make x test --stage 2 compiler/rustc_XXX faster to run #96000

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

Merged
merged 1 commit into from
Apr 18, 2022

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Apr 13, 2022

Previously, bootstrap unconditionally rebuilt the stage 2 compiler,
even if it had previously built stage 1. This changes it to reuse stage 1 if possible.
In particular, it no longer runs the following step:

Building stage1 compiler artifacts (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu))

Previously, bootstrap unconditionally rebuilt the stage 2 compiler,
even if it had previously built stage 1. This changes it to reuse stage 1 if possible.
@rust-highfive
Copy link
Contributor

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 13, 2022
@jyn514
Copy link
Member Author

jyn514 commented Apr 13, 2022

Oh, I just realized - we should probably audit all the CI jobs to make sure they're building at most 2 compilers. It's very easy to call compiler() instead of compiler_for() by accident, and I don't think there's any reason it's necessary for dist artifacts? Do we even need compiler() at all?

@Mark-Simulacrum
Copy link
Member

I'm not sure I have in-cache enough the details to be certain, but I will say that any cross-compiling CI I think today goes up to stage 2 for the build triple and then cross-compiles from there (maybe I am wrong, I recall some work in that area a few years back, but it's been a while).

It seems like a good idea overall though.

I am not sure whether compiler/compiler_for is a meaningful + worthwhile distinction; I think the best way to find out is probably to try to unify and see what goes wrong. I suspect the intent behind the addition was largely the typical "it seems like this one place wants something slightly different" that perhaps was more of a patchwork fix than done with long-term correctness, so it's unlikely to be super principled I expect in terms of where it's used and such.

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup=iffy

Going to approve this change, though I wouldn't be too surprised if it bounces off CI in some obscure way :) I think it's not hurtful and may be helpful.

@bors
Copy link
Collaborator

bors commented Apr 16, 2022

📌 Commit 070bd64 has been approved by Mark-Simulacrum

@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 Apr 16, 2022
@bors
Copy link
Collaborator

bors commented Apr 18, 2022

⌛ Testing commit 070bd64 with merge 74582ac...

@bors
Copy link
Collaborator

bors commented Apr 18, 2022

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 74582ac to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 18, 2022
@bors bors merged commit 74582ac into rust-lang:master Apr 18, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 18, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (74582ac): comparison url.

Summary:

  • Primary benchmarks: 😿 relevant regression found
  • Secondary benchmarks: 🎉 relevant improvement found
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 1 0 0 1 1
mean2 1.5% N/A N/A -0.7% 1.5%
max 1.5% N/A N/A -0.7% 1.5%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

@rustbot rustbot added the perf-regression Performance regression. label Apr 18, 2022
@jyn514 jyn514 deleted the faster-doctests branch April 18, 2022 14:37
@jyn514
Copy link
Member Author

jyn514 commented Apr 18, 2022

I am not sure whether compiler/compiler_for is a meaningful + worthwhile distinction; I think the best way to find out is probably to try to unify and see what goes wrong. I suspect the intent behind the addition was largely the typical "it seems like this one place wants something slightly different" that perhaps was more of a patchwork fix than done with long-term correctness, so it's unlikely to be super principled I expect in terms of where it's used and such.

I tried changing this and it went ... not well. Removing compiler altogether gives 71 build errors, and changing it to alias compiler_for(stage, host, host) fails a bunch of the tests, including some that look like real issues:

---- builder::tests::dist::dist_with_targets_and_hosts stdout ----
thread 'builder::tests::dist::dist_with_targets_and_hosts' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
 [
     Rustc {
         compiler: Compiler {
<            stage: 1,
>            stage: 2,
             host: A,
>        },
>    },
>    Rustc {
>        compiler: Compiler {
>            stage: 2,
>            host: B,
         },
     },
 ]

', src/bootstrap/builder/tests.rs:314:9

Looking at the call sites, they usually look like this:

            fn make_run(run: RunConfig<'_>) {
                run.builder.ensure($name {
                    compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build),
                    target: run.target,
                    extra_features: Vec::new(),
                });
            }

so I think the "proper" fix is to pass run.target into compiler_for in most of these cases; at very least, we can't assume it's always host.

Don't have time for that soon, but I'll open an issue and hopefully someone grabs it.

@pnkfelix
Copy link
Member

Visiting for weekly performance triage. It seems like syn-1.0.89 opt full suddenly became much noisier around 2022-04-17, and I do not know why:

image

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Apr 21, 2022
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. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants