Most AVX and AVX2 intrinsics should be const

[raphaelcohn]

Most AVX intrinsics should be const. In particular, those that create vectors (eg the set1) variants.

This is probably true of the other vector instruction sets (eg SSE2).

Undoubtably, this would be hard to do, but would give use feature parity, if not more, with C-land.

[Lokathor]

Your best bet for now is to make an array of correct size as a const, and then transmute the value.

[raphaelcohn]

@Lokathor Sure; in my case, I needed it in a loop, so manually unrolled. But it makes my code difficult to follow (Context: I'm computing a Not(__m256i) using a 256-bit XOR against a vector of all ones; the vector of all ones should be const).

However, is their a 'view' you have about whether this should be a feature or not?

[damageboy]

Hi, bumping this as well since I see other intrinsics as well, such as pdep/pext in bmi2 that should be safe to call from a const caller. Is there a reason not to do this?

[bjorn3]

Making them const would require providing a manual implementation of every single intrinsic made const in the compiler. This is a lot of work and likely to result in bugs. I think the currently unstable core::simd (portable-simd) has more chance to be made const as it only requires a small amount of base operations to implement and those don't need to be duplicated per vector width and architecture unlike core::arch.

[raphaelcohn]

@bjorn3 Yes, it requires a lot of work for the compiler. I don't see why it should result in a lot of bugs, if any, if proper test coverage and TDD is followed. What might be a small source of bugs is divergence from official documentation. That might even throw up a few zero days... might be an interesting project for one of the (well funded) security research teams.

I originally raised this issue when I was porting some C code that assumed intrinsics could be const.

Intrinsics are painful - painful to implement, painful to use and painful to reason about.

[Lokathor]

I can certainly agree that at least all the integer related intrinsics and data shuffle intrinsics should be available as const fn. There's a lot of ops, but you just add them one at a time until it's done. If someone (perhaps raphaelcohn, perhaps someone else) is willing to put in the work there's no other good reason to not have the integer intrinsics be made const fn over time. A few operations are maybe hard to write tests for because they're hard to even understand at all, but something like 90% or more of them are all very obvious. I say this having written hundreds of tests for safe_arch and wide to cover all this sort of code. It's a long and boring task, but not complex.

That said, the floating point intrinsics should continue to not be const fn because Rust isn't (yet?) in general able to support const fn float ops. Until our story there gets sorted out it would be too early to try and change how the intrinsics work.