-
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
Prevent constant rebuilds of rustc-main
(and thus everything else)
#114613
Conversation
This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp. |
3ff748f
to
3de398c
Compare
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.
Sorry this was missed in the initial PR.
I've tested this and stripping still works locally on both llvm and rustc_driver.
r=me with the nit fixed
We had the exact same issue with BOLT. I solved it with doing the BOLT modification on-the-fly in the |
3de398c
to
da00356
Compare
@bors r=lqd rollup |
Prevent constant rebuilds of `rustc-main` (and thus everything else) PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times. We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice. The explanation of the problem is in the code comments. r? `@lqd` cc `@ozkanonur`
Prevent constant rebuilds of `rustc-main` (and thus everything else) PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times. We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice. The explanation of the problem is in the code comments. r? ``@lqd`` cc ``@ozkanonur``
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#106425 (Make ExitStatus implement Default) - rust-lang#113480 (add aarch64-unknown-teeos target) - rust-lang#113586 (Mention style for new syntax in tracking issue template) - rust-lang#113593 (CFI: Fix error compiling core with LLVM CFI enabled) - rust-lang#114612 (update llvm-wrapper include to silence deprecation warning) - rust-lang#114613 (Prevent constant rebuilds of `rustc-main` (and thus everything else)) - rust-lang#114615 (interpret: remove incomplete protection against invalid where clauses) - rust-lang#114628 (Allowing re-implementation of mir_drops_elaborated query) - rust-lang#114629 (tests: Uncomment now valid GAT code behind FIXME) - rust-lang#114630 (Migrate GUI colors test to original CSS color format) - rust-lang#114631 (add provisional cache test for new solver) r? `@ghost` `@rustbot` modify labels: rollup
…acrum CI: use smaller machines in PR runs mingw-check job-linux-16c -> job-linux-4c ~job-linux-4c 20 min in auto job ~job-linux-16c 13 min in pr job with current pr regressed to almost 21 min, it's ok. mingw-check-tidy job-linux-16c -> job-linux-4c small enough, so reduce to minimal ~ job-linux-16c 3 min with current pr regressed to almost 5 min, it's ok. x86_64-gnu-tools job-linux-16c this is top job by time in PR, so don't touch it ~ job-linux-8c 1.30 hour in auto job ~ job-linux-16c 1 hour in pr job (affected by rust-lang#114613, actual time ~ 30 min) x86_64-gnu-llvm-15 job-linux-16c don't change too ~ job-linux-8c 1.30 hour in auto job ~ job-linux-16c 30 min in pr job Noticed while working on rust-lang#114621, so current time affected by always rebuilded docker images (but pr images always rebuilded before too, so nvm)
PR #114305 changed bootstrap to run
strip -g
onlibrustc_driver.so
andlibllvm.so
on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1rustc-main
(including stage 1 libraries and tests) when invoking bootstrap multiple times.We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running
./x build library/sysroot --stage 1
twice.The explanation of the problem is in the code comments.
r? @lqd
cc @ozkanonur