_MM_SHUFFLE has incorrect return type

[Paul-E]

_MM_SHUFFLE was added recently in #479 . Currently _MM_SHUFFLE returns a u32, but the functions it's output is used with take an i32, eg _mm_shuffle_epi32.

Although normally this isn't an issue as you could just transmute the results, the input to _mm_shuffle_epi32 requires the shuffle argument to be constant.

[gnzlbg]

cc @bitshifter

[bitshifter]

Oops. Will look into it.

[alexcrichton]

Hm it also looks like this isn't unsafe and it's also const, could it follow the existing intrisnics and be both unsafe and non-const?

[gnzlbg]

@alexcrichton this is a helper macro in C. I think that making it const (or a macro in Rust) is not only fine, but necessary, since its result needs to be passed to other intrinsics taking immediate mode arguments, which only accept constant expressions (so if we don't make this const, or a macro, this becomes unusable).

Also, this is not an intrinsic per se, in the sense that it does not require target features (it is a helper macro in C), so I don't know why it should be unsafe. We map other helper macros to just const variables, the difference here is that this helper macro takes some arguments, but that's about it.

[alexcrichton]

Hm ok if that's the case can it be marked as unstable for now? I'd prefer to not stabilize this behavior immediately personally

[gnzlbg]

I'd prefer to not stabilize this behavior immediately personally

Sure.

---

FWIW, I think we screwed up. _MM_SHUFFLE is sometimes the recommended way of using the SSE and AVX shuffle intrinsics, but some of the Rust intrinsics take an u32 (e.g. _mm_shuffle_ps, which is a bug, this should be i32) , and all others take an i32 (_mm256_shuffle_ps, _mm_shuffle_pi{16,32}, ...).

Ideally, we should do a breaking change and fix the argument type of _mm_shuffle_ps. The alternative is to make _MM_SHUFFLE! a macro, so that the argument type can be infered from the expansion...

If we don't fix the argument type of _mm_shuffle_ps, changing the return type of _MM_SHUFFLE would just mean that one still would need transmute for using it with _mm_shuffle_ps (that's better than needing a transmute with all other intrinsics though).

[gnzlbg]

FYI, the bug of _mm_shuffle_ps taking an u32 instead of i32 is not a Rust bug, but a bug in the intel intrinsics guide, as in, all other shuffle intrinsics take int, but that one takes unsigned int for some reason. In C that wouldn't really matter because implicit conversions, but in Rust that doesn't work...

Making _MM_SHUFFLE a macro appears to be the best way forward to me.

[alexcrichton]

For now I'd leave this as unstable and maybe publish a crate on crates.io with the fixed intrisnics and/or a macro? I think we'll want to avoid for now exporting more macros from the standard library (stability is a hard thing there)

[bitshifter]

This did start out as a macro as it is in C but I couldn't work out how to declare it in coresimd and rexport it to stdsimd.

So I'm not sure what the solution should be here.

[alexcrichton]

I think let's originally start out with destabilizing the function and go from there? @bitshifter would you be up for sending that PR?

[bitshifter]

Yep sure.

[Paul-E]

I think we'll want to avoid for now exporting more macros from the standard library (stability is a hard thing there)

I don't understand why we want to limit the number of macros in the standard library. Is the issue that the same macro's interface might not be stable from one rust release to the another?

[alexcrichton]

@Paul-E oh it's mostly related to stability where macros have had to be insta-stable in the past and we can't have an unstable macro exported from libstd. Times may have changed though!