@bors try @rust-timer queue

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

⌛ Trying commit cd8e4503bfe75258bad597fa5a1366505808dc55 with merge cc23adbddf8f354aad5b3f3e9b2aedccfd38a89b...

💔 Test failed - checks-actions

@bors try

⌛ Trying commit 07dfa390d71e89e2dc29bb920bd140ab08132543 with merge 610f0992faa3ebd54080a805f5bd068a720bce01...

💔 Test failed - checks-actions

@bors try

⌛ Trying commit 34f8765ec33b05e7a2637ad96381dba63457e32c with merge 2d4ed6f605ac632165706d1d4af30d9aa2b840e6...

💔 Test failed - checks-actions

@bors try

⌛ Trying commit de2b6aac7c4a8a8c9a335fcbec66cd58eae98092 with merge b87df8d2c7c5d9ac448c585de10927ab2ee1b864...

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

Queued b87df8d2c7c5d9ac448c585de10927ab2ee1b864 with parent 250384e, future comparison URL.

Finished benchmarking commit (b87df8d2c7c5d9ac448c585de10927ab2ee1b864): comparison url.

Summary: This benchmark run shows 134 relevant improvements 🎉 but 58 relevant regressions 😿 to instruction counts.

• Average relevant regression: 0.6%
• Average relevant improvement: -1.1%
• Largest improvement in instruction counts: -3.3% on full builds of ctfe-stress-4 check
• Largest regression in instruction counts: 2.1% on incr-full builds of piston-image opt

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

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 led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Merged in the upstream release branch, the musl issue has already been fixed by llvm/llvm-project@2a2286e in the meantime.

@bors r=nagisa

📌 Commit 75636bb has been approved by nagisa

i128 is not FFI safe due to this differing ABI. You can use #[win64_128bit_abi_hack] in the intrinsics! macro to make i128 passed as vector of two i64 like for clang.

Just to clarify, is the above (from this comment) a reference to issue #54341 ? Or are you referring to a different problem, @bjorn3 ?

My understanding is that the two are broadly unrelated. The ABI used by compiler builtins tends to be pretty bespoke regardless of other issues. It was not all that uncommon a little while ago to see builtins that don't really follow any documented calling convention. That's the reason we have e.g. unadjusted calling convention in Rust.

The #54341 is entirely about the alignment mismatch.

⌛ Testing commit 75636bb with merge 9f2b322c3782ddda66efcfa36900d27f4507707e...

💥 Test timed out

@bors retry LLVM rebuild timeout

It looks like bors failed to kill the build here and it actually succeeded afterwards, and now bors is just stuck...

⌛ Testing commit 75636bb with merge 30b3f35...

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing 30b3f35 to master...

Nice ;).

Finished benchmarking commit (30b3f35): comparison url.

Summary: This benchmark run shows 153 relevant improvements 🎉 but 51 relevant regressions 😿 to instruction counts.

• Average relevant regression: 0.7%
• Average relevant improvement: -1.3%
• Largest improvement in instruction counts: -3.8% on full builds of projection-caching check
• Largest regression in instruction counts: 3.0% on incr-patched: add static arr item builds of coercions debug

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

LLVM 14.0.0 final planned for Mar 15.
Rust 1.60.0 planned for Apr 7.

If there isn't an urgent reason to upgrade to LLVM 14 then maybe it is worth waiting for the release? IMO three weeks between when LLVM 14 final is expected to ship is not enough window. There's a good chance that the LLVM 14 release won't be fully rolled out or people will otherwise have trouble upgrading to LLVM 14.

When Rust upgrades to an as-yet-unreleased LLVM version, this breaks some (many?) people's CI/CD code coverage measurement, as often the LLVM tools version has to match Rust's LLVM version exactly in order for the coverage data to be accurate. It is pretty difficult to acquire a pre-release version of LLVM tools on certain platforms. Not sure if this aspect was overlooked or if it is expected breakage.

@briansmith I took a look at your CI config, and it looks like switching https://github.com/rustls/rustls/blob/5bda754ac18f37eb39132f89fb5522494b6202eb/.github/workflows/build.yml#L185 to llvm-toolchain-bionic-14 should work fine? This is available for pre-releases as well.

We always update LLVM for nightly well in advance of the release to make sure that any issues we discover can actually make it into the release. Our timing is chosen such that a stable LLVM release is available by the time the update makes it into a stable Rust release.

In this particular instance, we may want to revert the upgrade from the beta branch once promotion happens, because it landed very close to promotion this time, and we may want to give it more time to bake in nightly.

By the way, I believe -C instrument-coverage was recently stabilized, so you should be able to use a stable toolchain (with a stable LLVM release) for coverage in the future.

Upgrading LLVM is always likely to produce performance changes. Luckily the perf improvements seem to outweigh the perf regressions considerably both in number and magnitude.

@rustbot label: +perf-regression-triaged