use funnel shift as fallback impl for rotating shifts

[RalfJung]

That lets us remove this gnarly implementation from Miri and const-eval.

However, rotate_left/rotate_right are stable as const fn, so to do this we have to rustc_allow_const_fn_unstable a bunch of const trait stuff. Is that a bad idea? Cc @oli-obk @fee1-dead

[rustbot]

⚠️ #[rustc_allow_const_fn_unstable] needs careful audit to avoid accidentally exposing unstable
implementation details on stable.

cc @rust-lang/wg-const-eval

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

⚠️ #[miri::intrinsic_fallback_is_spec] must only be used if the function actively checks for all UB cases,
and explores the possible non-determinism of the intrinsic.

cc @rust-lang/miri

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

[rustbot]

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[oli-obk]

this seems fine to me. Absolutely worst case we can always remove bounds from the intrinsic and have the compiler do all the work again, but with the setup we have now for libstd bootstrap I'm not worried about even major changes anymore

[RalfJung]

@antoyo @bjorn3 in case you'd like to drop the rotate_left/right intrinsic implementations from your backends, that's possible now as there is a library fallback implementation in terms of the funnel shift intrinsics (which in turn also have a fallback implementation).

However, at least cranelift seems to have native support for rotations so we probably want to keep the direct implementation in the backend? OTOH if we can remove it from all backends we can stop making this an intrinsic so that would also be nice. ;)

[oli-obk]

@bors try @rust-timer queue

[bjorn3]

However, at least cranelift seems to have native support for rotations so we probably want to keep the direct implementation in the backend?

Indeed.

OTOH if we can remove it from all backends we can stop making this an intrinsic so that would also be nice. ;)

I haven't implemented funnel shift support yet and Cranelift doesn't have native support for this.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[oli-obk]

@bors rollup-

The "perf regression" is noise (a change in macro expansion for one benchmark)

[RalfJung]

@jdonszelmann would you prefer me to reroll the reviewer here?

[jdonszelmann]

I'm so sorry Ralf, didn't get around to it. r? compiler

[RalfJung]

No worries. :)
We have this command now that's smart about picking a reviewer based on which files the PR touches:
@rustbot reroll

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

📌 Commit a00db66 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[Zalathar]

Scheduling: Fall back to rollup=never if a rollup-of-iffy fails.

@bors p=1

[bors]

⌛ Testing commit a00db66 with merge 89fe961...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 89fe961 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 69d4d5f (parent) -> 89fe961 (this PR)

Test differences

Show 6438 test diffs

6438 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 89fe96197d232f86d733566df31c6dcebd1750da --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. aarch64-gnu-debug: 3891.2s -> 4882.9s (+25.5%)
2. pr-check-1: 1533.3s -> 1899.5s (+23.9%)
3. x86_64-gnu-llvm-20: 2270.7s -> 2802.1s (+23.4%)
4. x86_64-gnu-llvm-21-2: 5013.3s -> 6036.4s (+20.4%)
5. dist-x86_64-apple: 6372.6s -> 7459.3s (+17.1%)
6. aarch64-apple: 7759.1s -> 8879.6s (+14.4%)
7. x86_64-gnu-tools: 3271.0s -> 3692.1s (+12.9%)
8. i686-gnu-nopt-1: 7314.8s -> 8155.7s (+11.5%)
9. x86_64-gnu-aux: 6501.9s -> 7216.2s (+11.0%)
10. x86_64-gnu-gcc: 3105.1s -> 3446.0s (+11.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (89fe961): comparison URL.

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

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	10
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	1.7%	[-0.4%, 3.8%]	2

Max RSS (memory usage)

Results (primary 0.3%, secondary 2.2%)

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

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.8%, 2.0%]	3
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-3.3%, 2.0%]	4

Cycles

Results (primary 1.2%, secondary 0.4%)

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

	mean	range	count
Regressions ❌ (primary)	4.4%	[4.4%, 4.4%]	1
Regressions ❌ (secondary)	3.4%	[3.4%, 3.4%]	1
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	1
All ❌✅ (primary)	1.2%	[-2.1%, 4.4%]	2

Binary size

Results (primary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.1%, 0.0%]	7

Bootstrap: 475.558s -> 476.458s (0.19%)
Artifact size: 388.70 MiB -> 388.72 MiB (0.00%)

[RalfJung]

Ah, that's not quite expected... if I understand the detailed results correctly, the eza regression is just the extra time spent generating the code for the fallback implementation?

But the odd thing is, we did a perf run before and nothing relevant showed up.