Enable MIR inlining

[cjgillot]

Continuation of #82280 by @wesleywiser.

#82280 has shown nice compile time wins could be obtained by enabling MIR inlining.
Most of the issues in #81567 are now fixed,
except the interaction with polymorphization which is worked around specifically.

I believe we can proceed with enabling MIR inlining in the near future
(preferably just after beta branching, in case we discover new issues).

Steps before merging:

• figure out the interaction with polymorphization;
• figure out how miri should deal with extern types;
• silence the extra arithmetic overflow warnings;
• remove the codegen fulfilment ICE;
• remove the type normalization ICEs while compiling nalgebra;
• tweak the inlining threshold.

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @jackh726

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

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 6a4e632dd082da698d23955f33781a45a00d2e64 with merge e158c01eec3c90aaf0463f93c68c9971a0c00924...

[bors]

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

[rust-timer]

Queued e158c01eec3c90aaf0463f93c68c9971a0c00924 with parent 0b42dea, future comparison URL.

[rust-timer]

Finished benchmarking commit (e158c01eec3c90aaf0463f93c68c9971a0c00924): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -2.1% on incr-patched: empty 3072 builds of issue-46449)
• Very large regression in instruction counts (up to 15.7% on full builds of deeply-nested-async)

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

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit f5a5f1c979c645cef188e0ca113d427e8dd400be with merge 82c0b57dc36973c6b38f4dcfa748798e4d019ecd...

[bors]

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

[rust-timer]

Queued 82c0b57dc36973c6b38f4dcfa748798e4d019ecd with parent 4a66a70, future comparison URL.

[rust-timer]

Finished benchmarking commit (82c0b57dc36973c6b38f4dcfa748798e4d019ecd): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -3.0% on incr-patched: empty 3072 builds of issue-46449)
• Very large regression in instruction counts (up to 17.0% on full builds of deeply-nested-async)

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

[therealprof]

stm32f4-0.14.0 | opt | full | 7.16% | 37.94x

Boooooo. 😅

I guess tons of trivial code, all inlineable, is a total nightmare for the MIR inliner.

[bjorn3]

This has improved runtime performance of cg_clif compiled programs by a lot (when compiled in release mode). For example rustc compiled using cg_clif now builds the standard library in 8 min instead of 22 min. Thanks everyone who worked on enabling this!

[RalfJung]

This change made the test fail in --stage 1 (the default for ./x.py test) on my system

/home/r/src/rust/rustc.3/build/x86_64-unknown-linux-gnu/test/codegen/mem-replace-direct-memcpy/mem-replace-direct-memcpy.ll:138:2: note: possible intended match here
 call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %_4, i8* align 1 %src, i64 1, i1 false)
 ^

It should be src, not dest, it seems. Or it should be %{{.*}} I guess since the name seems to be unstable. The 2nd argument is the src though so the "dest" you added here makes no sense to me.