Constified SIMD

[clarfonthey]

I figured I'd start a discussion here since I didn't see one already made, and because I actually would like to work on this.

I think that it would be useful to have const support for all the SIMD operations, since the story on const floats has been resolved, and const traits seem on the horizon. The main reason why I wanted to put this out there is because it's unclear what approach should be used for this.

Motivation for const SIMD operations is pretty self-explanatory: you want to make things use SIMD to speed them up at runtime, but you still want to be able to run some operations ahead of time if needed. Right now, this requires effectively writing separate code for const and runtime operations, which requires a lot of extra boilerplate and means you may have twice the code to check for correctness.

The biggest issue IMHO is that most SIMD intrinsics are not set up to work in const context, and I think it would be ideal if this were the case. The few const methods that do exist (mainly splat) rely on const_eval_select, which effectively offoads the same issue as before onto the standard library: writing twice the code and requiring twice the tests to verify it.

So, I wanted to list this here and start a discussion on what would be needed to get this working.

[programmerjake]

one issue this will run into is that some architectures have SIMD that has different rules for floating-point than scalars, e.g. 32-bit Arm will flush denormals to zero in SIMD but properly handle them in scalar FP.

what should const-eval do for that?

[clarfonthey]

I believe that falls under the acceptable const evaluation rules for floats: constants always compute using IEEE 754 rules, even though some hardware might not.

[clarfonthey]

Poking around intrinsics, is there any particular reason why simd_insert_dyn and simd_insert (and similarly for simd_extract_dyn and simd_extract) need to be separated out?

Can't these just operate differently depending on whether the index argument is actually a constant or not?

[bjorn3]

simd_insert and simd_extract should be changed to use a const generic for the index. Cranelift requires it's insertlane and extractlane instructions to take a constant. It is not enough for them to be a known value after optimizations. Already when building clif ir you need to pass a u8. Getting a const value at clif ir build time without const generics requires a fragile hack that basically walks over all statements in the MIR body to see if there is an assignment for the local and recurses when the assignment references another local: https://github.com/rust-lang/rustc_codegen_cranelift/blob/a0e0a4a7fa7872b3014e11a29d4b4bbe4acc3d71/src/constant.rs#L504-L623 It doesn't work when for example there are multiple assignments.

[clarfonthey]

That makes sense! I can see value into keeping them separate if it's updated to be a generic.

The main thing I was looking into was how easy it'd be to insert fallback implementations for the SIMD operations (which would be what miri & consteval use going forward) and it seemed relatively simple, although I wanted to ask about these intrinsics since they seemed weird.

I haven't actually looked into the code that miri uses for these intrinsics, but my guess is that it'd simplify things on that end too to just add fallback implementations, since then the code could exist in the standard library instead of just in miri.

[clarfonthey]

Second question: what exactly is the policy when it comes to making intrinsic changes like this? Since right now we're in the weird situation where intrinsics are in the rust-lang/rust Repo, but the things that use them are here, and while I know there's a subtree for the rust-lang/portable-simd repo, it's currently out of date.

Would be more than happy to help make this change, just don't know where to start. I know how to modify the code to make it work (I think), just don't actually know what the PR process would be.

[calebzulawski]

For changes that affect both repos, feel free to make the changes in rust-lang/rust and I'll sync any changes both ways.

[clarfonthey]

FWIW: I realised that this wouldn't be possible without generic_const_args due to the fact that some stdarch methods will take an i32 const arg instead of a u32 const arg, and need to cast it.

While the compiler itself can use unstable features and this probably isn't that bad, I figured that it's worth holding off until that's stable to make the change from a const arg to a const generic.

Will poke around with const fallbacks for these methods, though, when I can.