Vectors of pointers #287
Vectors of pointers #287
Conversation
calebzulawski
force-pushed
the
feature/pointer-vectors
branch
from
b32360d to
70d1008
Compare
calebzulawski
requested review from
programmerjake,
thomcc and
workingjubilee
|
New intrinsics merged, so this is ready to go. |
|
Huzzah. |
|
Apologies, going to try to get to this this week. |
|
Okay thanks! |
| @@ -71,3 +73,37 @@ macro_rules! impl_mask { | |||
| } | |||
|
|
|||
| impl_mask! { i8, i16, i32, i64, isize } | |||
|
|
|||
| impl<T, const LANES: usize> SimdPartialEq for Simd<*const T, LANES> | |||
There was a problem hiding this comment.
This seems okay. Are there any caveats, e.g. if the pointers get evaluated at const time, that we should document?
There was a problem hiding this comment.
I'm not sure it has any caveats beyond what's already true for const fn or whatever. Did you have anything specific in mind?
There was a problem hiding this comment.
I am thinking of the pointer indeterminacy problem during CTFE. Things that would share addresses during runtime may not during compile-time function execution, and vice versa.
There was a problem hiding this comment.
Honestly, not sure what the implications would be other than since the SIMD intrinsics aren't const (yet) so we know any pointers for now will be runtime only. If you do something bad with CTFE before putting it in a vector, that's probably out of scope for now.
There was a problem hiding this comment.
I think it's fair to assume all vector operations should mirror scalar operations in that regard, whatever the implications are.
There was a problem hiding this comment.
Fair enough. I think it's mostly something we should keep in mind while exploring the API surface.
| #[inline] | ||
| fn simd_clamp(self, min: Self, max: Self) -> Self { | ||
| assert!( | ||
| min.simd_le(max).all(), | ||
| "each lane in `min` must be less than or equal to the corresponding lane in `max`", | ||
| ); | ||
| self.simd_max(min).simd_min(max) | ||
| } |
There was a problem hiding this comment.
The notion of clamping pointers seems somewhat dubious...?
There was a problem hiding this comment.
It is odd, but pointers already implement Ord 🤷♂️
Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>
calebzulawski
force-pushed
the
feature/pointer-vectors
branch
from
0b8da1d to
469c620
Compare
| /// equivalent to `T as U` semantics, specifically for pointers | ||
| pub(crate) fn simd_cast_ptr<T, U>(ptr: T) -> U; | ||
|
|
||
| /// expose a pointer as an address | ||
| pub(crate) fn simd_expose_addr<T, U>(ptr: T) -> U; | ||
|
|
||
| /// convert an exposed address back to a pointer | ||
| pub(crate) fn simd_from_exposed_addr<T, U>(addr: T) -> U; |
There was a problem hiding this comment.
It look like currently no tests actually call any of these intrinsics, or am I missing something?
That would explain why portable-simd tests still pass in Miri where these intrinsics are not implemented.
There was a problem hiding this comment.
Ah, looking at the tests, I did omit some of the very simple ones like this. They shouldn't be hard to add.
Simd::cast, since all casts are no longer valid (e.g. castingf32to a pointer)