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).

[oli-obk]

I think it's mostly a parser problem that we don't allow print_const::<Const::<T>::N>(), i believe the type system can handle that already

[RalfJung]

I am using print_const::<{Const::<T>::N}>() though, shouldn't that help the parser...?

When using non-assoc const, having or not having the curly braces does not seem to make any difference.

[oli-obk]

I am using print_const::<{Const::<T>::N}>() though, shouldn't that help the parser...?

that works, but is interpreted as an arbitrary expression instead of "naming an assoc const"

[oli-obk]

When using non-assoc const, having or not having the curly braces does not seem to make any difference.

hmm ok, I think I:m misremembering

[RalfJung]

Yeah this works on stable:

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

const N: usize = 5;

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