Update to LLVM 16.0.5

[nikic]

Rebase to LLVM 16.0.5, plus one cherry-pick.

Fixes #111823.
Fixes #112061.
Fixes #112170.

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

⚠️ Warning ⚠️

• These commits modify submodules.

[cuviper]

@bors r+ rollup=never

[bors]

📌 Commit 5ff8767 has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit 5ff8767 with merge cb797b2f3cfbe11360fc0734222c1d052b696de5...

[bors]

💥 Test timed out

[nikic]

@bors retry

[bors]

⌛ Testing commit 5ff8767 with merge 3572d74...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 3572d74 to master...

[rust-timer]

Finished benchmarking commit (3572d74): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

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
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.2%, 0.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.2%	[-5.2%, -5.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.9%	[-0.9%, -0.9%]	1
Improvements ✅ (secondary)	-4.6%	[-4.6%, -4.6%]	1
All ❌✅ (primary)	-0.9%	[-0.9%, -0.9%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 646.658s -> 646.759s (0.02%)

[nikic]

Beta nominating for miscompilation fixes.

[pnkfelix]

• effects are all to secondary benchmarks
• effects are small enough that they would not block an LLVM upgrade
• marking as triaged.

@rustbot label: +perf-regression-triaged

[apiraino]

Beta backport approved as per compiler team on Zulip

@rustbot label +beta-accepted

[nagisa]

This ended up fixing a fair number of issues, but none of them have a rust-side test of any sort.

Given that at least two of the three issues had a fairly minimal Rust reproducer, would it make sense to add those reproducers to our test suite, or are we confident that testing on the LLVM side is sufficient here?

[nikic]

I don't think we should have Rust-side tests for LLVM bugs. Especially fuzzer generated test cases are quite unlikely to keep testing the relevant code paths over time.

Testing LLVM behavior on the Rust side is useful if we're testing end-to-end optimization behavior, which is affected both by the IR rust generates and phase ordering in LLVM -- this is usually only relevant for tests guarding against optimization regressions, and certain end-to-end miscompilations (e.g. infinite loop removal).