Skip to content

Conversation

@valadaptive
Copy link
Contributor

Split off from #115 to make review of that PR easier.

Copy link
Member

@DJMcNab DJMcNab left a comment

Choose a reason for hiding this comment

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

At last, the associated types actually show their value!

Thanks for doing a changelog entry (and in #115).

The fallback level can be restored with the `force_support_fallback` cargo feature. We don't expect this to be necessary outside
of tests.
- Code generation for `select` and `unzip` operations on x86 has been improved. ([#115][] by [@valadaptive][])
- Breaking change: The native-width associated types (`f32s`, `u8s`, etc.) for the `Avx2` struct have been widened from 128-bit
Copy link
Member

Choose a reason for hiding this comment

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

In my mind, marking this as a breaking change is a decision on a knife-edge.
I probably wouldn't have myself, but I can understand why you have, and I'm perfectly happy for it to be marked as such.

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.

Nice!

@valadaptive valadaptive added this pull request to the merge queue Nov 14, 2025
Merged via the queue into linebender:main with commit 3688f88 Nov 14, 2025
18 checks passed
@valadaptive valadaptive deleted the widen-avx2 branch November 14, 2025 22:05
github-merge-queue bot pushed a commit that referenced this pull request Nov 19, 2025
Stacked on #123 since it touches the same code.

Adding 64-bit *integer* types is tricky because SSE4.2 and AVX2 are
missing some important 64-bit operations, and I don't feel comfortable
implementing those until #124 is addressed. However, we already have
`mask64x[N]` and `f64x[N]` types.

The `f32s` associated type has a `Bytes = <Self::u32s as Bytes>::Bytes`
constraint, which misled me into thinking that a float type *needs* an
associated int type, but that constraint is only there to assert that
the two share the same `Bytes` type.
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