Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking Issue for f16 and f128 float types #116909

Open
42 of 84 tasks
traviscross opened this issue Oct 18, 2023 · 32 comments
Open
42 of 84 tasks

Tracking Issue for f16 and f128 float types #116909

traviscross opened this issue Oct 18, 2023 · 32 comments
Assignees
@tgross35
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Oct 18, 2023 •
edited by tgross35
Loading

This is a tracking issue for the RFC 3453 (rust-lang/rfcs#3453).

The feature gate for the issue is #![feature(f16_and_f128)].

From the RFC:

This RFC proposes adding new IEEE-compliant floating point types f16 and f128 into the core language and standard library. We will provide a soft float implementation for all targets, and use hardware support where possible.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved questions

  • Do any new target features need to be marked as "forbidden" since they affect ABI? The logic here looks like that may be the case.

Implementation history

Note that unimplemented!("f16_f128") and // FIXME(f16_f128) is being used where relevant, to make the todo list easily greppable.

Nice to have changes:
@traviscross traviscross added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Oct 18, 2023
@traviscross

This comment has been minimized.

Sign in to view
@rustbot rustbot added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Oct 18, 2023
@traviscross

This comment has been minimized.

Sign in to view
@rustbot rustbot added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Oct 19, 2023
@traviscross traviscross mentioned this issue Oct 19, 2023
Merged
@tgross35

This comment was marked as outdated.

Sign in to view
@trevyn trevyn mentioned this issue Oct 22, 2023
Open
2 tasks
@gorentbarak

This comment has been minimized.

Sign in to view
@gorentbarak

This comment has been minimized.

Sign in to view
@gorentbarak

This comment has been minimized.

Sign in to view
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Oct 27, 2023
@gorentbarak

This comment has been minimized.

Sign in to view
@rustbot

This comment has been minimized.

Sign in to view
@gorentbarak

This comment has been minimized.

Sign in to view
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 27, 2023
@lqd

This comment has been minimized.

Sign in to view
@lqd lqd removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Oct 27, 2023
@LegNeato LegNeato mentioned this issue Nov 2, 2023
Open
@traviscross traviscross added the F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` label Nov 4, 2023
@LegNeato LegNeato mentioned this issue Nov 27, 2023
Closed
@tgross35 tgross35 mentioned this issue Dec 3, 2023
Closed
@nicoburns nicoburns mentioned this issue Dec 8, 2023
Merged
@tgross35
Copy link
Contributor

tgross35 commented Dec 9, 2023

A blocking issue should be added: ensure C compatibility with ABI-cafe or similar

#114607 (comment)

@yasammez yasammez mentioned this issue Jan 17, 2024
Open
@tgross35
Copy link
Contributor

tgross35 commented Feb 28, 2024 •
edited
Loading

Implementation steps (could somebody link this in the top post?):

(massive todo list moved to the top post)

@rustbot claim

@tgross35 tgross35 mentioned this issue Feb 28, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 30, 2024
@matthiaskrgr
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve…
6e18d8a 
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
tgross35 added a commit to tgross35/rust that referenced this issue Jul 31, 2024
@tgross35
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve…
84cc3ab 
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 31, 2024
@matthiaskrgr
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve…
177d187 
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 31, 2024
@matthiaskrgr
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve…
5c63363 
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 31, 2024
@rust-timer
Unrolled build for rust-lang#128388
8e6ce9f 
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
@beetrees beetrees mentioned this issue Aug 2, 2024
Open
@beetrees
Copy link
Contributor

beetrees commented Aug 2, 2024

Tier 3 powerpc64-ibm-aix doesn't currently support f128 arguments: llvm/llvm-project#101545

@jalil-salame jalil-salame mentioned this issue Aug 11, 2024
Draft
@beetrees beetrees mentioned this issue Aug 16, 2024
Merged
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
@tgross35
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r…
9c044b5 
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
@tgross35
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r…
d70f8b9 
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
@tgross35
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r…
8f916ca 
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
jieyouxu added a commit to jieyouxu/rust that referenced this issue Aug 18, 2024
@jieyouxu
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r…
42b54a9 
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 18, 2024
@rust-timer
Unrolled build for rust-lang#129173
aa0b880 
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
@beetrees beetrees mentioned this issue Aug 24, 2024
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
@bors
Auto merge of rust-lang#129536 - beetrees:f16-f128-inline-asm-aarch64…
e6fadc6 
…, r=<try>

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
@bors
Auto merge of rust-lang#129536 - beetrees:f16-f128-inline-asm-aarch64…
2e5b402 
…, r=<try>

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
tgross35 added a commit to tgross35/rust that referenced this issue Aug 27, 2024
@tgross35
Rollup merge of rust-lang#129536 - beetrees:f16-f128-inline-asm-aarch…
8ea70e9 
…64, r=Amanieu

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
@rust-timer
Unrolled build for rust-lang#129536
38593bf 
Rollup merge of rust-lang#129536 - beetrees:f16-f128-inline-asm-aarch64, r=Amanieu

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
@beetrees
Copy link
Contributor

llvm/llvm-project#104915: f16 abs and neg quieten signalling NaNs on targets where f16 is not natively supported.

@beetrees beetrees mentioned this issue Oct 15, 2024
Merged
@beetrees beetrees mentioned this issue Nov 3, 2024
Merged
@86maid

This comment has been minimized.

Sign in to view
@taiki-e taiki-e mentioned this issue Nov 21, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 25, 2024
@matthiaskrgr
Rollup merge of rust-lang#131664 - taiki-e:s390x-asm-vreg-inout, r=Am…
3f86edd 
…anieu

Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: rust-lang#133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in rust-lang#130869.

cc rust-lang#130869 about vector facility support in s390x
cc rust-lang#125398 & rust-lang#116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 25, 2024
@rust-timer
Unrolled build for rust-lang#131664
ba23619 
Rollup merge of rust-lang#131664 - taiki-e:s390x-asm-vreg-inout, r=Amanieu

Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: rust-lang#133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in rust-lang#130869.

cc rust-lang#130869 about vector facility support in s390x
cc rust-lang#125398 & rust-lang#116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
@Neutron3529

This comment has been minimized.

Sign in to view
@traviscross

This comment has been minimized.

Sign in to view
@traviscross traviscross mentioned this issue Nov 26, 2024
Closed
bjorn3 pushed a commit to rust-lang/rustc_codegen_cranelift that referenced this issue Nov 28, 2024
@matthiaskrgr
Rollup merge of #131664 - taiki-e:s390x-asm-vreg-inout, r=Amanieu
e73d321 
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: rust-lang/rust#133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in rust-lang/rust#130869.

cc rust-lang/rust#130869 about vector facility support in s390x
cc rust-lang/rust#125398 & rust-lang/rust#116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tgross35 tgross35

Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests