Mark const SIMD intrinsics as indirectly stable

[sayantn]

recently most SIMD intrinsics were made available in const contexts in #147521. This PR makes the indirectly stable to use in const contexts.

cc @RalfJung @rust-lang/lang @rust-lang/wg-const-eval

This exposes most SIMD intrinsics to be used in stable const functions, except for the following

• simd_f{min,max} and simd_reduce_{min,max}: See @RalfJung's comment
• simd_reduce_{add,mul}_unordered: These are not even const yet, due to concerns about possible unsoundness due to non-determinism in float operations
• simd_expose_provenance: Rust doesn't allow ptr->int casts in const code yet
• simd_relaxed_fma: Same nondet concerns, also the scalar version fmuladd is not even indirectly stable yet
• simd_f{sin,cos,exp,exp2,log10,log2,log}: Not const yet

These all have const tests in tests/ui/simd (added in #147521), and some of these are currently also being tested in x86 stdarch (we have already converted some intrinsics to be available in const, and the stdarch testsuite automatically tests the const code).

I want to emphasize that I am not aiming to stabilize any of the const stdarch intrinsics in near future. The reason being that it is difficult to fix perf regressions in generic SIMD code (normally stdarch uses LLVM intrinsics, but we are aiming to convert as many as possible to generic SIMD. Unfortunately that sometimes leads to perf regressions, which might force us to go back to LLVM intrinsics). There is const_eval_select, but it is still a pain to use (considering that we have to ensure that the 2 alternatives behave identically to be sound). A recent such problem surfaced in #150560, and fixed in rust-lang/stdarch#1985.

[rustbot]

⚠️ #[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

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 platform-builtins intrinsics. Make sure the
LLVM backend as well as portable-simd gets adapted for the changes.

cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake

[rustbot]

r? @joboet

rustbot has assigned @joboet.
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

[RalfJung]

So you plan to soon const-stabilize functions using these intrinsics?

[sayantn]

I won't say soon (it would require t-libs-api approval), but yes the plan is eventually to stabilize them

[RalfJung]

Usually we do the t-lang FCP for const intrinsics as part of that stabilization, not preemptively.

[RalfJung]

For some of these I am not sure they are ready for stabilization.

Also, please give an overview of the test coverage we have for these being invoked from const-eval.

View changes since this review

[joboet]

r? @RalfJung
I'm really not sure who normally handles these PRs, feel free to reassign as necessary.

[RalfJung]

@rustbot author
based on the comments above

I would propose to remove all controversial cases, then we can proceed to FCP.

[rustbot]

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

[sayantn]

Apologize for the delay. @RalfJung do the above-mentioned caveats also apply to simd_fmax and simd_fmin?

[RalfJung]

Yeah, they do.

[sayantn]

@rustbot ready

I have removed the attributes from simd_reduce_{min,max}, simd_f{max,min} and simd_relaxed_fma.

[RalfJung]

I have nominated this for t-lang discussion. It'd be good to update the PR description to give the required context to team members visiting this during triage: which new capabilities are exposed to const code here, and what does the test coverage look like?

[joshtriplett]

Summary: this makes it possible for functions that indirectly call these SIMD intrinsics to be called from stable const-eval code.

The lang decision when things are marked as rustc_intrinsic_const_stable_indirect is to review what new language capabilities are exposed to const evaluation. In this case, as far as I can tell, these intrinsics don't give any new language capabilities, they're just other ways of doing basic operations (e.g. math and memory) that are optimized by SIMD at runtime. So, I think this adds no new const capabilities in practice.

@rfcbot merge lang

[rust-rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

To reiterate what @RalfJung said, it'd still be good to see this:

It'd be good to update the PR description to give the required context to team members visiting this during triage: which new capabilities are exposed to const code here, and what does the test coverage look like?

[RalfJung]

Ah sorry, I guess I should have waited for someone (specifically, @sayantn :) to do that before nominating. I was hoping it would be taken care of quickly enough to happen before t-lang gets around to look at the PR.

[sayantn]

@RalfJung sorry for the delay. I have updated the description, could you check if it is ok?

[rustbot]

This PR was rebased onto a different main 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.

[RalfJung]

Instead of listing which intrinsics are not affected, could you list the ones that are? Remember, the reader has likely ~never looked at these intrinsics before.

I want to emphasize that I am not aiming to stabilize any of the const stdarch intrinsics in near future.

That makes me wonder why we should go through the trouble of approving these attributes.^^

There is const_eval_select, but it is still a pain to use (considering that we have to ensure that the 2 alternatives behave identically to be sound)

Given that the stdarch tests check that the right instructions get emitted even with the "generic" version, how could they possibly not behave identically?

(Also, calling this "generic" is confusing since Rust generics are something very different. I'd call it "portable" or "target-independent".)

[traviscross]

Instead of listing which intrinsics are not affected, could you list the ones that are?

I might tweak this ask to "in addition to" rather than "instead of". It is valuable seeing what's not here, but it'd be good to say explicitly what is.

I want to emphasize that I am not aiming to stabilize any of the const stdarch intrinsics in near future.

That makes me wonder why we should go through the trouble of approving these attributes.^^

If you could speak more to this in particular, that would be helpful. I.e., I'd like to know more about the motivation and what specifically we're unblocking by accepting this. What do we want to do that will be possible after we approve this? An example would help.