Make const_eval_select a real intrinsic

[fee1-dead]

This fixes issues where track_caller functions do not have nice panic
messages anymore when there is a call to the function, and uses the
MIR system to replace the call instead of dispatching via lang items.

Fixes #100696.

[rust-highfive]

r? @davidtwco

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

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[RalfJung]

Another possible implementation plan would be to exploit that we have separate MIR for CTFE and runtime, and implement the intrinsic via lowering to a regular function call some place in the MIR pipeline. That would make supporting track_caller trivial. It'd also share the code to do that between codegen and CTFE.

[fee1-dead]

Another possible implementation plan would be to exploit that we have separate MIR for CTFE and runtime

Yes, but AFAIK there is no separate query for runtime-only MIR, right? Implementing it that way would require adding such a query and rewiring runtime MIR usage to that.

[RalfJung]

The optimized_mir query is only used for runtime MIR, I think. But maybe that changed again. The hierarchy of MIR queries is historically an underdocumented mess, not sure if it improved over the last year.

But I am pretty sure that there is a fork in the road somewhere for MIR (where it becomes CTFE/runtime only), and we should be able to use that here.

[RalfJung]

Yeah looks like mir_drops_elaborated_and_const_checked is the last MIR that is shared, and then mir_for_ctfe clones that while optimized_mir steals it.

[RalfJung]

It is kind of a crude hack to have 'implementation' passes in optimized_mir, but it might be the best solution for this particular intrinsic.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

yea, I like this variant of doing it on the MIR

[oli-obk]

@bors r+

[bors]

📌 Commit 0d03c6273e96b843d88afb14fd68d4310a6e29c3 has been approved by oli-obk

It is now in the queue for this repository.

[fee1-dead]

@bors r- There was a test that changed to a no-op when I was debugging. I need to fix that

[bors]

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

[RalfJung]

@bors delegate+

bors r=oli-obk,RalfJung once CI is green

[bors]

✌️ @fee1-dead can now approve this pull request

[fee1-dead]

@bors r=oli-obk,RalfJung

[bors]

📌 Commit 65b685e has been approved by oli-obk,RalfJung

It is now in the queue for this repository.

[bors]

⌛ Testing commit 65b685e with merge 9358d09...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk,RalfJung
Pushing 9358d09 to master...

[rust-timer]

Finished benchmarking commit (9358d09): 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.

	mean1	range	count2
Regressions ❌ (primary)	0.8%	[0.3%, 1.4%]	12
Regressions ❌ (secondary)	2.4%	[0.2%, 4.1%]	9
Improvements ✅ (primary)	-1.2%	[-3.0%, -0.6%]	7
Improvements ✅ (secondary)	-1.4%	[-1.6%, -1.0%]	10
All ❌✅ (primary)	0.1%	[-3.0%, 1.4%]	19

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.

	mean1	range	count2
Regressions ❌ (primary)	9.8%	[9.8%, 9.8%]	1
Regressions ❌ (secondary)	2.3%	[1.4%, 2.9%]	3
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-3.6%	[-4.6%, -2.6%]	2
All ❌✅ (primary)	3.2%	[-3.3%, 9.8%]	2

Cycles

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[1.7%, 3.8%]	7
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	1

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[pnkfelix]

Visiting for weekly performance triage.

Many of the reported regressions are being classified as noise from recently arising bimodalities in certain benchmarks.

But, the regression to ripgrep does look like it might be legitimate, at least from skimming its graph and zooming in.

Not marking as triaged, not yet.

[oli-obk]

ripgrep only regressed in LLVM, a bit later it got improved (in llvm) by a targetted placement of #[inline]. So maybe this is just inlining noise and we can get the perf back by sprinkling #[inline] at the functions modified in this PR