Skip to content

Conversation

@valadaptive
Copy link
Contributor

These were requested in #simd > Quickly deinterleaving the underlying Simd arrays?, and seem useful.

They are a bit unusual in Neon, which has specific instructions for converting the low and high halves (and combining the two).

Due to some rearrangement and cleanup of the code generation, the reinterpret ops have been moved around a bit. They haven't been changed at all.

Copy link
Collaborator

@Ralith Ralith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea how to expose this to native-width code?

@valadaptive
Copy link
Contributor Author

Probably through adding SimdWiden and SimdNarrow traits similar to the existing SimdCvtTruncate and SimdCvtFloat traits.

@Ralith
Copy link
Collaborator

Ralith commented Nov 16, 2025

What would the return types be, though? We only have associated types of one width.

@valadaptive
Copy link
Contributor Author

valadaptive commented Nov 16, 2025

Hm, I see the issue. Maybe the Zulip thread's "split when widening / combine when narrowing" approach is better for this?

@Ralith
Copy link
Collaborator

Ralith commented Nov 16, 2025

I think that's probably the best we can do in current Rust, yeah. No reason not to leave that for follow-up work, of course.

@valadaptive
Copy link
Contributor Author

If the split/combine approach is what we're going with, it might be good to separate the conversions from the existing widen/narrow ops' convention. Like, let's say we want to implement the "generic" widen operation on f32x4. We call widen_f32x4, which widens to f64x4. Unless we're using AVX2, its implementation will split the f32x4 into two separate f64x2 vectors and widen them separately before combining them. Then, we call split on the resulting f64x4 that we just combined and return that. Sure, the compiler may elide the split/combine/split, but I wouldn't count on it.

@LaurenzV, would it be a good idea to just update the "widen/narrow" signatures to return and consume two vectors respectively? The Simd trait's operations cap out at a specific bit width of 512, not a specific scalar count. This means the current widen/narrow operations will never be implementable for all bit widths, since the highest-bit-width version would need to return a type wider than anything that exists.

@LaurenzV
Copy link
Collaborator

Seems reasonable, but maybe something for office hours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants