simd_select_bitmask: the 'padding' bits in the mask are just ignored #140034
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to the platform-builtins intrinsics. Make sure the cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter |
| /// | ||
| /// The bitmask bit order matches `simd_bitmask`. | ||
| /// | ||
| /// # Safety | ||
| /// Padding bits must be all zero. | ||
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| pub unsafe fn simd_select_bitmask<M, T>(m: M, yes: T, no: T) -> T; |
There was a problem hiding this comment.
Can intrinsics be safe? I think it would be safe with the expected generic arguments but could still raise mono errors
There was a problem hiding this comment.
Yes, we have allowed marking intrinsics as safe for a couple of years now.
There was a problem hiding this comment.
Many SIMD intrinsics could be safe, but none are. I don't think this PR is the right place to change that.
Fixes #137942: we documented simd_select_bitmask to require the 'padding' bits in the mask (the mask can sometimes be longer than the vector; I am referring to these extra bits as 'padding' here) to be zero, mostly because nobody felt like doing the research for what should be done when they are non-zero. However, codegen is already perfectly happy just ignoring them, so in practice they can have any value. Some of the intrinsic wrappers in stdarch have trouble ensuring that they are zero. So let's just adjust the docs and Miri to permit non-zero 'padding' bits.
Cc @Amanieu @workingjubilee