Stop backends from needing to support nullary intrinsics

[oli-obk]

And then remove our infrastructure special casing them. Further improvements can now be done to them by avoiding the intermediate ConstValue step, but let's leave that to follow up work

r? @RalfJung

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit a44843e with merge a5e9784...

[fbstj]

nit: I see this is a code-move & fixup to work in here, but is it worth sorting these arms into the rest of the match? though I guess the other arms are also not sorted simply... it was mostly that needs_drop is between type_id & type_name that caught my eye hehe

[oli-obk]

yea, could do that, good point. didn't want to do it in the first commit to kinda make the diff line up

[bors]

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

[rust-timer]

Finished benchmarking commit (a5e9784): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	3.2%	[2.8%, 3.5%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.2%]	2
All ❌✅ (primary)	2.0%	[-0.3%, 3.5%]	3

Max RSS (memory usage)

Results (primary 3.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[2.0%, 5.5%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.7%	[2.0%, 5.5%]	2

Cycles

Results (primary 2.7%, secondary -6.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.7%, 2.8%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.5%	[-6.5%, -6.5%]	1
All ❌✅ (primary)	2.7%	[2.7%, 2.8%]	2

Binary size

Results (primary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.0%, 1.1%]	9
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.0%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-0.1%, 1.1%]	11

Bootstrap: 691.091s -> 687.91s (-0.46%)
Artifact size: 371.86 MiB -> 371.89 MiB (0.01%)

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[RalfJung]

In my view, the goal of this PR is to establish a new invariant -- nullary intrinsics must be invoked in const blocks only, codegen should never see them. So before this PR there wasn't any invariant to worry about.

I like the plan, it's a lightweight version of "nullary intrinsics are consts, really" without having to figure out how to shove that into a mir::Const::Unevaluated. I guess the alternative would be to say that the DefId in an UnevaluatedConst can be a nullary intrinsic, and then we can handle them in lower_intrinsics (translating intrinsic calls into const values)... but that sounds like it might require some "interesting" hackery.

[oli-obk]

We already have nullary intrinsics that can't be a constant:

• cold_path,
• breakpoint

Tho technically abort and unreachable also qualify, but these could easily be special cased on the return type. I guess we could make a list of intrinsics that are nullary but do not need to be constants and check against that.

[RalfJung]

Ah... well I guess then we don't actually have a new invariant here, and we'd have to rely on comments to ensure this will be consistent. I am quite confident this won't be enough, but OTOH if a nullary intrinsic creeps back in we can always fix that again later.

[RalfJung]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[oli-obk]

@rustbot ready

[RalfJung]

The core parts LGTM, but I have no idea how to review the stable MIR test changes.
Cc @celinval

[bors]

☔ The latest upstream changes (presumably #143091) made this pull request unmergeable. Please resolve the merge conflicts.

[celinval]

The core parts LGTM, but I have no idea how to review the stable MIR test changes. Cc @celinval

The test changes make sense to me. Thanks for checking!

[RalfJung]

Thanks! r=RalfJung,celinval after a rebase.