Update LLVM submodule to latest release/23.x branch - #161466
Conversation
rustbot
added
the
A-LLVM
rustbot
added
the
S-waiting-on-review
|
r? @cuviper rustbot has assigned @cuviper. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Oops, that sounds like a bootstrap bug, possibly caused by some of my recent refactorings. I'll take a look. |
|
#161475 should hopefully fix this, but I'll have to do some experiments with it first. |
|
@bors try @rust-timer queue This update is expected to have perf impact. |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
This comment has been minimized.
This comment has been minimized.
Update LLVM submodule to latest `release/23.x` branch
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (0587bd1): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.6%, secondary 4.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -4.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 468.499s -> 469.706s (0.26%) |
rustbot
removed
the
S-waiting-on-perf
|
I'd rather land them separately, both in case we'd need to revert that other PR, and also to test that the LLVM check will work in a PR that only updates LLVM (after the fix was already landed). |
…=jieyouxu Fix checking of LLVM prebuilt status This regressed in rust-lang#160916. I'll start from the end. There was a pre-existing bug (fixed by the second commit of this PR), where if we do `x check library`, we have `builder.kind == Kind::Check`, but we are actually building things (like the compiler) during that bootstrap invocation. But bootstrap was only checking the builder kind before, and in that case it would skip building LLVM, *unless* it was already built locally previously. On PR CI, and perhaps always (because build steps executed during check likely only occur during `x check library`, which requires *building* the compiler anyway), the LLVM was built locally anyway, so this bug was hidden away. This also removes an unnecessary LLVM build when running Clippy on the rustc_private tools. However, after rust-lang#160916, this was no longer case, because it stopped treating locally built LLVM as being prebuilt (which, in and of itself, is kinda a bug). Because when we check the compiler, we want to avoid building (and checking out!) LLVM. Before rust-lang#160916, bootstrap considered a *previously locally built* LLVM to be available as a prebuilt `llvm-config`, and in that case configured `LLVM_CONFIG` for `rustc_llvm`. Because all PR CI bootstrap invocations that do `check` actually built LLVM prior doing a build, this worked, somehow, but broke after my PR. Should unblock rust-lang#161466. r? jieyouxu
Rollup merge of #161475 - Kobzol:bootstrap-llvm-check-fix, r=jieyouxu Fix checking of LLVM prebuilt status This regressed in #160916. I'll start from the end. There was a pre-existing bug (fixed by the second commit of this PR), where if we do `x check library`, we have `builder.kind == Kind::Check`, but we are actually building things (like the compiler) during that bootstrap invocation. But bootstrap was only checking the builder kind before, and in that case it would skip building LLVM, *unless* it was already built locally previously. On PR CI, and perhaps always (because build steps executed during check likely only occur during `x check library`, which requires *building* the compiler anyway), the LLVM was built locally anyway, so this bug was hidden away. This also removes an unnecessary LLVM build when running Clippy on the rustc_private tools. However, after #160916, this was no longer case, because it stopped treating locally built LLVM as being prebuilt (which, in and of itself, is kinda a bug). Because when we check the compiler, we want to avoid building (and checking out!) LLVM. Before #160916, bootstrap considered a *previously locally built* LLVM to be available as a prebuilt `llvm-config`, and in that case configured `LLVM_CONFIG` for `rustc_llvm`. Because all PR CI bootstrap invocations that do `check` actually built LLVM prior doing a build, this worked, somehow, but broke after my PR. Should unblock #161466. r? jieyouxu
This pulls in rust-lang/llvm-project#199 which updates the revision of LLVM 23 to the latest copy of the release branch, just past the rc3 release.
f841587 to
ca79f4f
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
7 participants
This pulls in rust-lang/llvm-project#199 which updates the revision of LLVM 23 to the latest copy of the release branch, just past the rc3 release.