Upgrade to LLVM 16 #107224
Upgrade to LLVM 16 #107224
Conversation
rustbot
added
the
S-waiting-on-review
|
How neat is it that upgrades are as simple as this now! |
|
@bors try @rust-timer queue
It's quiet. Too quiet... |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 776fb8e470bab3324cc0d9e34ab6a905f774f19e with merge e6dbb34783cfa1de81bc2fffcbb8bbe0a5a4f9fa... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
|
Ha, I did say it was too quiet! This is kind of weird though, because I tested dist-x86_64-linux locally, though I was using the DEPLOY_ALT=1 configuration. Either this only happens with DEPLOY=1, or something managed to break in the one day in between. |
|
The backtrace for the crash looks like this: I haven't been able to reproduce this outside of rustc yet. Edit: With symbols: |
|
Note that it did complete one build, but breaks in further PGO. On my machine, it crashed while "Building stage1 library artifacts" in this command: Lines 194 to 198 in d7948c8 I don't see a detailed crash in the CI log, but it seems to have gotten just past that and failed in the next collector. |
|
For me and in CI the crash is during the third profile collection, using the build that has been PGO optimized and has BOLT instrumentation. Probably a thing to try would be to drop the BOLT part and see whether that works. If not, then this is probably a PGO miscompile. Doesn't sound fun to debug, might be easiest to bisect. |
I am really, really sorry for raising that 🏴 😿 |
|
Hrm, I can reproduce a crash even on llvm/llvm-project@3c0c24e, which I had previously successfully tested in #105956. |
|
Dropping |
|
BOLT isn't always super stable, so it might very well be caused by it. We use BOLT |
|
I tried a local build with 15.0.7 in |
|
Using 16.0.0-rc2 as the host compiler fails with: Presumably due to https://reviews.llvm.org/D135402. |
|
Related: #105967 |
|
@TimNN Yeah, that's the same problem. @chbaker0 Unfortunately, the patch from #108017 doesn't seem to actually fix the issue for this case. Possibly this is due to the issue mentioned by @bjorn3 in #105967 (comment)? I dumped the rustc invocation, and it looks like this:
Notably, we're building both a dylib and rlib, and the |
|
Does a |
|
@the8472 Could be. My first suspicion would be an ABI mismatch. dist-x86_64-linux builds with clang, while most other builders use gcc. And createTargetMachine() was switched to use |
Thanks for the cc! Let's continue that thread of discussion in rust-lang/stdarch#1396 (nothing amiss with LLVM 16 itself, just backend changes as expected) |
Rust recently updated to LLVM 16 (rust-lang/rust#107224) and the change is likely to be provided in next nightly builds.
Rust recently updated to LLVM 16 (rust-lang/rust#107224) and the change is likely to be provided in next nightly builds.
…ce, r=eholk move Option::as_slice to intrinsic `@scottmcm` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc `@nikic` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
|
This is the ABI incompatibility I suspect: https://clang.godbolt.org/z/qbW5a58qv dist-x86_64-linux uses libstdc++ 7.5, which has different std::optional ABI from future versions. So if other builders use a newer GCC version, they end up being incompatible with the built libLLVM.so. Not sure what to do about this. The right way to fix this would probably be to also distribute llvm-wrapper, so that we only link against a C API. But this is probably not a short term solution (I believe llvm-wrapper is currently statically linked in.) Possibly we could get away with updating the builder to GCC 8, assuming other builders using these artifacts are also on GCC 8 or newer. |
|
That ABI difference is also visible with direct GCC: https://godbolt.org/z/KvPx7En9f, and
I think that's the way to go. AFAICS all the test builders are on at least |
|
Visiting for rustc-perf triage
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
…ce, r=eholk move Option::as_slice to intrinsic ``@scottmcm`` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ``@nikic`` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…ce, r=eholk move Option::as_slice to intrinsic ```@scottmcm``` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ```@nikic``` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…ce, r=eholk move Option::as_slice to intrinsic ````@scottmcm```` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ````@nikic```` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
Upgrade to LLVM 16, again Relative to the previous attempt in rust-lang#107224: * Update to GCC 8.5 on dist-x86_64-linux, to avoid std::optional ABI-incompatibility between libstdc++ 7 and 8. * Cherry-pick llvm/llvm-project@96df79a. * Cherry-pick llvm/llvm-project@6fc670e. r? `@cuviper`
Use llvm 16.0.0 instead of 16.0.0-rc4 for build-clang.sh Ref: rust-lang#107224 This PR doesn't make any update on LLVM submodule used by Rust repo, but would be super keen to update it, if necessary (https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html). LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1. - https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html
Upgrade to LLVM 16, again Relative to the previous attempt in rust-lang/rust#107224: * Update to GCC 8.5 on dist-x86_64-linux, to avoid std::optional ABI-incompatibility between libstdc++ 7 and 8. * Cherry-pick llvm/llvm-project@96df79a. * Cherry-pick llvm/llvm-project@6fc670e. r? `@cuviper`
Use llvm 16.0.0 instead of 16.0.0-rc4 for build-clang.sh Ref: rust-lang/rust#107224 This PR doesn't make any update on LLVM submodule used by Rust repo, but would be super keen to update it, if necessary (https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html). LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1. - https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html
Update host compiler to LLVM 16 Update the host compiler for dist-x86_64-linux to LLVM 16. In particular, this pulls in llvm/llvm-project@1de305d, which is needed to update Rust's own LLVM (rust-lang/rust#107224).
Update host compiler to LLVM 16 Update the host compiler for dist-x86_64-linux to LLVM 16. In particular, this pulls in llvm/llvm-project@1de305d, which is needed to update Rust's own LLVM (rust-lang/rust#107224).
This updates Rust to LLVM 16. It also updates our host compiler for dist-x86_64-linux to LLVM 16. The reason for that is that Bolt from LLVM 15 is not capable of compiling LLVM 16 (llvm/llvm-project#61114).
LLVM 16.0.0 has been released on March 18, while Rust 1.70 will become stable on June 1.
Tested images:
dist-x86_64-linux,dist-riscv64-linux(alt),dist-x86_64-illumos,dist-various-1,dist-various-2,dist-powerpc-linux,wasm32,armhf-gnuTested images until the usual IPv6 failures:
test-various