simd_shuffle, simd_insert, simd_extract should use const generics

[RalfJung]

simd_shuffle requires its last parameter, the array defining the shuffling, to be a constant:

rust/compiler/rustc_codegen_llvm/src/intrinsic.rs

Line 888 in 487e273

emit_error!("shuffle index #{} is not a constant", arg_idx);

Currently (after #85110), this is enforced by an ad-hoc hack in compiler/rustc_mir/src/transform/lower_intrinsics.rs.

But I think it'd be better to instead change the type of simd_shuffle to make the shuffle array a const generic parameter. I am not doing this yet since const generic arrays require enabling an incomplete_feature which is not great, but once const generic arrays are sufficiently stable we could use them as a more principled way to ensure that simd_shuffle is called in the right way.

Update (2024-02-17): A const-generic version of simd_shuffle now exists, but using it in stdarch would require generic_const_exprs and that's too experimental for such uses.

Cc @rust-lang/project-const-generics

[workingjubilee]

Would this enable using simd_shuffle as a single function without a suffix instead of calling e.g. simd_shuffle4?

[RalfJung]

I had not thought about this... maybe? Do const generic support "dependent types" like this one?

fn simd_shuffle<const N: usize, const IDX: [u32; N]>(...)

[oli-obk]

I think the full const generics feature does support that, but there's still the open question on how we know whether the type is StructuralEq. For this specific case it is easy, because the array length does not influence that question, but we still need to figure out the details here

[nikomatsakis]

cc @Amanieu -- is this is a case that should use the new attribute you added or have been adding?

[Amanieu]

Not really. simd_shuffle is a private intrinsic, so we don't need to worry too much about API user-friendlyness.

[oli-obk]

In that case... how about we change the const generic argument to be a slice?

Right now this

#![feature(const_generics)]
#![allow(incomplete_features)]

fn foo<const X: &'static [usize]>() {
    
}

fn main() {
    foo::<{&[1, 2, 3, 4]}>();
}

ICEs with

error: internal compiler error: compiler/rustc_mir/src/const_eval/mod.rs:160:14: cannot destructure constant Const { ty: &[usize], val: Value(ByRef { alloc: Allocation { bytes: [0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [(Size { raw: 0 }, ((), alloc2))] }), init_mask: InitMask { blocks: [65535], len: Size { raw: 16 } }, size: Size { raw: 16 }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }) }

thread 'rustc' panicked at 'Box<Any>', /rustc/21e92b97309e15b16bc6b8dd4509d5e3ad4c430d/library/std/src/panic.rs:59:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.54.0-nightly (21e92b973 2021-05-12) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [destructure_const] destructure constant
#1 [type_op_ascribe_user_type] evaluating `type_op_ascribe_user_type` `Canonical { max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }], value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: UserFacing }, value: AscribeUserType { mir_ty: fn() {foo::<{&[1, 2, 3, 4]}>}, def_id: DefId(0:3 ~ playground[b426]::foo), user_substs: UserSubsts { substs: [Const { ty: &'static [usize], val: Unevaluated(Unevaluated { def: WithOptConstParam { did: DefId(0:6 ~ playground[b426]::main::{constant#0}), const_param_did: Some(DefId(0:4 ~ playground[b426]::foo::X)) }, substs: [], promoted: None }) }], user_self_ty: None } } } }`
end of query stack

but it seems totally straight forward to fix

[RalfJung]

FWIW, there also currently seems to be no way to use any generic parameters in a const generic expression, even when indirecting via associated consts. Until that is resolved, using const generics for simd_shuffle (or simd_insert/simd_extract, which possibly should get the same treatment -- Cc #77477) is pretty much out of the question.

#![feature(const_generics, const_evaluatable_checked)]

pub fn print_const<const N: usize>() {
    println!("{}", N);
}

struct Const<T>(T);
impl<T> Const<T> {
    const N: usize = 5;
}

pub fn print_thing<T>() {
    print_const::<{Const::<T>::N}>()
}

This needs extra where bounds, which would be a breaking change to add to the stdarch API surface (I assume).

[RalfJung]

A const-generic version of simd_shuffle now exists. However, using it requires generic_const_exprs. From talking with @lcnr, this feature is still pretty unstable, so unfortunately stdarch cannot currently use simd_shuffle_generic.

It also needs adt_const_params since the array is passed as a slice. That's more mature though some thorny open questions make it unfit for stabilization (but I don't think those are a blocker for use in stdarch).

[RalfJung]

My understanding is that the main complexity with generic_const_exprs is "what happens if const-eval fails". So would it make sense to try and carve out a min_generic_const_exprs of guaranteed-not-to-fail expressions? That would contain e.g. constructing an array and as casts, which would cover at least a large fraction of what simd_shuffle needs.

[lcnr]

There are also quite a few issues wrt to generic consts in where-clauses and some other less fundamental implementation challenges. While it hasn't been updated recently as there hasn't been any focussed work on gce, here's a list of the known issues https://github.com/rust-lang/project-const-generics/issues?q=is%3Aissue+is%3Aopen+label%3AA-generic-exprs+label%3AC-design-docs+