Skip to content

Sync from rust 2026/04/05#870

Open
antoyo wants to merge 10 commits intomasterfrom
sync_from_rust_2026_04_05
Open

Sync from rust 2026/04/05#870
antoyo wants to merge 10 commits intomasterfrom
sync_from_rust_2026_04_05

Conversation

@antoyo
Copy link
Copy Markdown
Contributor

@antoyo antoyo commented Apr 8, 2026

No description provided.

N1ark and others added 10 commits March 16, 2026 21:49
Add `bounds::FloatPrimitive`

Exhaustive float pattern match

Fix GCC

use span bugs
…ski,antoyo

simd_fmin/fmax: make semantics and name consistent with scalar intrinsics

This is the SIMD version of rust-lang/rust#153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.

In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.

In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (rust-lang/stdarch#2056).

Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?

Also see rust-lang/rust#153395.
… in cleanup"

This reverts commit acbfd79acf662be04745dc0675558e75e0d30d87.
Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.

This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.

A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.
Generate debuginfo for scalable vectors, following the structure that
Clang generates for scalable vectors.
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.

6 participants