Refactor FnDecl and FnSig non-type fields into a new wrapper type
#### Why this Refactor?
This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.
It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413
It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.
#### Relationship to `splat` Experiment
I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.
Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit
#### Minor Changes
Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
There seemed to be non-deterministic failures on MSVC that looked like
corruption of the FFR in CI. Until this can be investigated, to avoid any
spurious failures, these tests are disabled.
`dumpbin.exe` produces `44a1c000`/`44e1c000`/`44a1c400`/`44e1c400` for
`[su]mull[tb]` instead of the instruction name - so skip `assert_instr`
for these intrinsics on MSVC targets.
The implementation for this has the same behaviour as a `pfalse` but
doesn't currently emit one until an intrinsic is added to emit a
`zeroinitializer` for this.
SVE intrinsics have both type and const generics and so the
`assert_instr` macro needs to be able to generate test cases with the
type generics instantiated with the types provided in the attribute.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
Co-authored-by: Luca Vizzarro <Luca.Vizzarro@arm.com>
Co-authored-by: Adam Gemmell <adam.gemmell@arm.com>
Co-authored-by: Jacob Bramley <jacob.bramley@arm.com>
`Into::into` can't be used here because the implementations can't have
the required target feature, so `SveInto` needs to be introduced and
written by the generator
Add the SVE types (without any of the generated intrinsics) and empty
modules where the generated intrinsics will be. Enables the
`adt_const_params` crate feature that the generated intrinsics will use.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
Co-authored-by: Luca Vizzarro <Luca.Vizzarro@arm.com>
Co-authored-by: Adam Gemmell <adam.gemmell@arm.com>
Co-authored-by: Jacob Bramley <jacob.bramley@arm.com>
Matching the current behaviour for arguments, `auto_llvm_sign_conversion`
should only be required for `as_unsigned` conversions, not `into`
conversions.
`simd_reinterpret` was expected to be used when it was added as
`transmute_unchecked` requires `Sized`, but scalable vectors are now
`Sized` so `transmute_unchecked` can be used and `simd_reinterpret` was
not added in rust-lang/rust#143924.
The `SvUndef` expression is no longer necessary as a
`core::intrinsics::scalable::sve_undef` intrinsic has been introduced
to produce an undefined SVE vector, used by `svundef*` intrinsics. Other
intrinsics that used `SvUndef` now use the `svundef*` intrinsics.
Instead of generating load/store tests based on the input filename -
which no longer works given the expected input file structure of
`stdarch-gen-arm` - add a simple global context option that SVE specs can
set.
Use `black_box` on SIMD intrinsic inputs to prevent the compiler from
constant folding SIMD operations, ensuring the corresponding SIMD
instructions are actually emitted and covered by tests.
simd_fmin/fmax: make semantics and name consistent with scalar intrinsics
This is the SIMD version of https://github.com/rust-lang/rust/pull/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 (https://github.com/rust-lang/stdarch/issues/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 https://github.com/rust-lang/rust/issues/153395.
bors