Skip to content

Commit 79a248d

Browse files
committed
Remove simd abi requirements from definition and ensure that the return type is noted as being part of signature compatibility
1 parent 36f80c3 commit 79a248d

File tree

1 file changed

+2
-47
lines changed

1 file changed

+2
-47
lines changed

src/abi.md

Lines changed: 2 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -155,61 +155,16 @@ r[abi.compatibility.signature]
155155
Two function signatures are compatible if:
156156
* The [abi tags][abi tag] of both signatures are *abi compatible*,
157157
* They have the same number of parameters, excluding C-varargs,
158+
* The return types of both signatures are *abi comaptible*,
158159
* Each parameter of both signatures, in order, are *abi compatible*, and
159160
* Either both signatures have C-varargs, or neither signature does.
160161

161162
> [!NOTE]
162163
> A signature is compatible with itself.
163164
164-
r[abi.compatibility.simd-abi]
165-
Certain types have *simd abi requirements*, which can impose additional constraints on calls with a parameter or return value of that type. A type has *simd abi requirements* if:
166-
* It is a type declared with the standard-library repr-attribute `simd`, or
167-
* It is a aggregate type[^aggregate], which has a type with *simd abi requirements* as a field.
168-
169-
> [!NOTE]
170-
> Types with *simd abi requirements* may be passed using special registers that aren't always available to code.
171-
172-
> [!NOTE]
173-
> Notably References and pointers to types with *simd abi requirements* do not have *simd abi requirements*.
174-
> Only direct parameters and return values are affected by *simd abi requirements*.
175-
176-
> [!NOTE]
177-
> The `repr(simd)` attribute cannot be used by Rust code, only by the standard library. The name used here is for *exposition only*.
178-
179-
r[abi.compatibility.simd-target-feature]
180-
A type with *simd abi requirements* may have one or more [*salient target features*][target_feature] . In the case of an aggregate type, the set of [*salient target features*][target_feature] is the union of the set of [*salient target features*][target_feature] of each field with *simd abi requirements*.
181-
182-
r[abi.compatibility.simd-target-feature-x86]
183-
> [!TARGET-SPECIFIC]
184-
> On x86 and x86-64, the [*salient target features*][target_feature] of the `simd` types are:
185-
> * [`__m128`], [`__m128i`], [`__m128f`], and [`__m128d`] (128-bit vector types): `sse`
186-
> * [`__m256`], [`__m256i`], [`__m256f`], and [`__m256d`] (256-bit vector types): `avx`
187-
> * [`__m512`], [`__m512i`], [`__m512f`], and [`__m512d`] (512-bit vector types): `avx512f` and `avx512vl`
188165

189166
r[abi.compatibility.call]
190-
A call to a function `f` via a function item or function pointer with a given signature `S` is valid if and only if the signature of the definition `f` is *compatible* with the signature `S`, and:
191-
* The ABI tag of the signature is `extern "Rust"`, or
192-
* If any parameter type, the return type, or the type of any argument passed via C-varargs has *simd abi requirements*, each [*salient target features*][target_feature] of that type is either set at both the definition site of the function, and at the call site, or is set at neither site.
193-
194-
The behavior of a call that is not valid is undefined.
195-
196-
> [!NOTE]
197-
> The ABI tag `extern "Rust"` is the default when the `extern` keyword is not used (either to declare the function within an [`extern` block], or as a [function qualifier][extern functions]). Thus it is safe to call most functions that use simd types.
198-
199-
[^aggregate]: The aggregate types, for the purposes of this clause, are [`struct`] types, [`enum`] types, [`union`] types, and [array] types.
200-
201-
[`__m128`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m128.html
202-
[`__m128i`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m128i.html
203-
[`__m128f`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m128f.html
204-
[`__m128d`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m128d.html
205-
[`__m256`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m256.html
206-
[`__m256i`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m256i.html
207-
[`__m256f`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m256f.html
208-
[`__m256d`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m256d.html
209-
[`__m512`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m512.html
210-
[`__m512i`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m512i.html
211-
[`__m512f`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m512f.html
212-
[`__m512d`]: https://doc.rust-lang.org/stable/core/arch/x86_64/struct.__m512d.html
167+
A call to a function `f` via a function item or function pointer with a given signature `S` is valid if and only if the signature of the definition `f` is *compatible* with the signature `S`. The behavior of a call that is not valid is undefined.
213168

214169
[layout.repr.rust.option.elision]: https://github.com/RalfJung/unsafe-code-guidelines/blob/option-like/reference/src/layout/enums.md#discriminant-elision-on-option-like-enums
215170

0 commit comments

Comments
 (0)