Update LLVM submodule

[nikic]

Update LLVM submodule with recent cherry-picks. In particular:

• Backport MergeFunctions scheduling fix llvm-project#123
• [cherry-pick] Fix MIPS FPU comparisons llvm-project#124

[rust-highfive]

r? @cuviper

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[nikic]

@bors try @rust-timer queue

Merge functions changes may have compile-time impact.

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 017f6b7 with merge 0f5562d0b97f9a6a7ce71c15bc596ea6be63626b...

[bors]

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

[rust-timer]

Queued 0f5562d0b97f9a6a7ce71c15bc596ea6be63626b with parent abba5ed, future comparison URL.

[rust-timer]

Finished benchmarking commit (0f5562d0b97f9a6a7ce71c15bc596ea6be63626b): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 1.0% on incr-full builds of deeply-nested-closures)

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

[cuviper]

The MergeFunctions change was for #91490 -- do you have a testcase to prove its worth?
(Then we can better justify the regression...)

[nikic]

The regression here is expected in that we perform function merging later -- this means that we merge more functions, but also that we process more duplicate functions until that point. Function merging is currently intended as a code size optimization rather than a compile-time optimization, though it may be worthwhile to investigate adding an additional MergeFunctions run early in the pipeline.

@cuviper The LLVM side test case is basically just the IR from the report in #91490. I can add that as a codegen test here as well.

[cuviper]

@bors r+

[bors]

📌 Commit e860f8e has been approved by cuviper

[bors]

⌛ Testing commit e860f8e with merge 06a6674...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 06a6674 to master...

[rust-timer]

Finished benchmarking commit (06a6674): comparison url.

Summary: This benchmark run did not return any relevant changes.

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

@rustbot label: -perf-regression