Add `[T]::as_simd(_mut)` by scottmcm · Pull Request #91479 · rust-lang/rust · Gi...
source link: https://github.com/rust-lang/rust/pull/91479
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
This looks fine, modulo the question it raises and the nits.
Outdated
@@ -3434,6 +3436,87 @@ impl<T> [T] {
}
}
/// Split a slice into a prefix, a middle of aligned simd types, and a suffix.
Outdated
/// This is a safe wrapper around [`slice::align_to`], so has the same weak
/// preconditions as that method. Notably, you must not assume any particular
/// split between the three parts: it's legal for the middle slice to be
/// empty even if the input slice is longer than `3 * LANES`.
Since this wrapper is safe, this should clarify that this is an invalid assumption for unsafe code, as the function can no longer be relied upon to maintain invariants in the same way. Safe code trying to "rely" on it would be "merely" logically incorrect.
Oh, I wrote "preconditions" here when I meant "postconditions" 
Outdated
unsafe { self.align_to() }
}
/// Split a slice into a prefix, a middle of aligned simd types, and a suffix.
// SAFETY: The simd types have the same layout as arrays, just with
// potentially-higher alignment, so the de-facto transmutes are sound.
unsafe { self.align_to() }
Sound, yes, but it would likely exhibit unexpected behavior if LANES is an odd number (like 3), as that would potentially result in bytes no longer being read (because the stride of the type will be as if LANES is 4). This is not supported yet, but we have not yet ruled this possibility out. This function therefore introduces an unanswered question. Should we:
- allow people to transmute data into padding
- add additional bounds on this if we relax those on
LANES - rule out types like
Simd<f32, 3>entirely?
Well I guess my assert_eq on the sizes (line 3487) is more useful than I'd thought, as if 3-simd is padded out to 4-simd it'd make the function just panic instead of skipping things.
The other possibility would be to have it just return everything in the prefix for that case, since align_to is allowed to do that anyway (for MIRI), and it'd just be slower than desired if someone uses the non-power-of-two sizes.
I didn't consider that, but it is indeed also an option!
This is definitely a bridge we can cross when we actually come to it, I just wanted to note the bridge is indeed up ahead.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK