Tracking Issue for `f16` and `f128` float types #116909

traviscross · 2023-10-18T22:19:47Z

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

Implement the RFC (see the list of tasks here]
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

None so far.

Implementation history

The text was updated successfully, but these errors were encountered:

tgross35 · 2023-12-09T06:47:38Z

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

#114607 (comment)

tgross35 · 2024-02-28T18:06:09Z

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

Add basic support stubs to IR and backend interfaces: Add stubs in IR and ABI for f16 and f128 #121728
Add AST support and intrinsics: f16 and f128 step 2: intrinsics #121841 (comment)
Connect the frontend, add the feature gate: f16 and f128 step 3: compiler support & feature gate #121926
Add the most basic traits that rustc more or less expects for primitives Add basic trait impls for f16 and f128 #123085
Finish support in rustdoc Add f16 and f128 to rustdoc's PrimitiveType #123581
Add library support. Some parts are blocked on const eval, compiler builtins updates, and LLVM lowering bugs.
Add needed functions to compiler-builtins. Unfortunately this one will block almost everything else on the list.
Figure out parsing and printing
- Migrate the tester to accept more types Rewrite test-float-parse in Rust #127510
- Add f16, which should be straightforward Add f16 formatting and parsing #127013
- Figure out f128 which will not be straightforward. Our current implementations are pretty u64-dependent so they can't fit a f128 mantissa. We could make them generic but probably want to instead use an implementation that is slower but better for size.
Update const eval
- Basic arithmetic Add f16 and f128 const eval for binary and unary operationations #126429
- Casting Enable const casting for f16 and f128 #127032
- Miri shims
Figure out mangling ~~Add encoding for f16 and f128 #122106~~ Add v0 symbol mangling for f16 and f128 #123816
~~Ensure known demanglers get updated or at least have issues for adding the new types~~ unneeded with the forward-compatible demangling
Add SIMD operations that can make use of these types Add SIMD operations that use f16 and f128 #125440
- Implement AVX512_FP16 stdarch#1605
Enable assembly registers where it makes sense Enable f16 and f128 in assembly on platforms that support it #125398
Make sure the GCC and Clif backends handle these types gracefully
- Support f16 and f128 rustc_codegen_gcc#461 (merged upstream, waiting on sync)
- Support f16 and f128 rustc_codegen_cranelift#1461
- Migrate float intrinsics to have a fallback (changes from Wishlist: allow adding intrinsics in a way that doesn't break every backend #93145)
Make sure all relevant unimplementeds and FIXMEs are removed from tools that need library support
Make use of new diagnostic attributes, e.g. f16_nan
Figure out ABI & platform-specific problems (thanks @beetrees for just about all of these)
- f16 ABI bugs in compiler-rt f16 generates code that uses the incorrect ABI for compiler-rt #123885
- 32-bit ABI bugs from LLVM [clang] missing support for _Float128 (C23) llvm/llvm-project#80195 (comment)
- f16 miscompilations from LLVM (affects T2 and T3 targets) LLVM miscompiles consecutive half operations by using too much precision on several backends llvm/llvm-project#97975 LLVM miscompiles passing/returning half on several backends by using lossy conversions llvm/llvm-project#97981
- Tier 1 MinGW incompatibilities from GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
- Tier2 PowerPC BE precision issues f128 symbols on powerpc64 give inaccurate results #125109
- Tier2 Power9 possible ABI issues f128 from_bits / to_bits sometimes gets reversed on ppc #125102
- Tier2 PowerPC LE f128 as f16 casting bug LLVM f128 -> f16 conversion selection failure on powerpc64le llvm/llvm-project#92866
- Tier 2 PowerPC sometimes uses the wrong symbol names PowerPC fp128 -> half uses __trunctfhf2 but should be __trunckfhf2 llvm/llvm-project#98126
- Tier 2 Loongarch failure to select loongarch64 half (f16) failure to select with f and d llvm/llvm-project#93894 (fixed upstream)
- Tier 2 arm64ec does not support these types Can't pass or return half or fp128 on arm64ec llvm/llvm-project#94434
- Tier 2 s390x-unknown-linux-gnu doesn't support f16: SystemZ Backend: Add support for operations such as FP16_TO_FP and FP_TO_FP16 llvm/llvm-project#50374
- Tier 2 wasm32 correctness bug On wasm32, half operation results aren't correctly rounded between each operation llvm/llvm-project#96437
- Tier 2 nvptx64-nvidia-cuda doesn't support f128: fp128 causes compilation failures when compiling for nvptx64-nvidia-cuda llvm/llvm-project#95471
- Tier 3 mips LLVM crashes with f128 Compiler crash when targeting mips64 when returning fp128 after calling a function returning { i8, i128 } llvm/llvm-project#96432
- Tier 3 sparc-unknown-linux-gnu doesn't support passing f128 directly (error message SPARCv8 does not handle f128 in calls; pass indirectly): Passing long double args on 32-bit SPARC violates ABI llvm/llvm-project#41838
- Tier 3 powerpc64-ibm-aix doesn't currently support f128 arguments: fp128 arguments cause a compiler error on powerpc64-ibm-aix llvm/llvm-project#101545
Other misc miscompilations or bugs
- LLVM does fma.f16 incorrectly llvm.fma.f16 intrinsic is expanded incorrectly on targets without native half FMA support llvm/llvm-project#98389
- powi.f16 constant folding returns incorrect values Misoptimization: EarlyCSEPass uses replaces powi.f16 with float result llvm/llvm-project#98665
Eventually, stabilization

This is based on the suggested pattern at #120645 (comment). I have a more complete reference PR with most of these done at #114607

I am trying to consistently use unimplemented!("f16_f128") and // FIXME(f16_f128) to make needed changes easily greppable.

Nice to have changes:

@rustbot claim

Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`s This was originally a PR against the Clippy repo, rust-lang#12950 r? ``@flip1995`` Tracking issue: rust-lang/rust#116909 Fixes: rust-lang/rust#126636

Add more constants, functions, and tests for `f16` and `f128` This adds everything that was in some way blocked on const eval, since rust-lang/rust#126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change. `f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64. Tracking issue: rust-lang/rust#116909

…rister Add Natvis visualiser and debuginfo tests for `f16` To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` . `f16`/`f128` MSVC debug info issue: rust-lang#121837 Tracking issue: rust-lang#116909

beetrees · 2024-07-08T03:02:41Z

It seems the LLVM f16 excess precision and ABI-handling bugs aren't limited to WASM:

LLVM miscompiles consecutive half operations by using too much precision on several backends llvm/llvm-project#97975
LLVM miscompiles passing/returning half on several backends by using lossy conversions llvm/llvm-project#97981

The list of affected LLVM backends is included in each issue: both affect tier 2 and tier 3 Rust targets.

…rister Add Natvis visualiser and debuginfo tests for `f16` To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` . `f16`/`f128` MSVC debug info issue: rust-lang#121837 Tracking issue: rust-lang#116909

Refactor float `Primitive`s to a separate `Float` type Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`. As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`. Tracking issue: rust-lang#116909 `@rustbot` label F-f16_and_f128

uweigand · 2024-07-10T19:28:41Z

The test suite currently fails on s390x in the following doctests:

    library/core/src/num/f16.rs - f16::f16::is_sign_negative (line 377)
    library/core/src/num/f16.rs - f16::f16::is_sign_positive (line 354)
    library/core/src/num/f16.rs - f16::f16::to_be_bytes (line 695)
    library/core/src/num/f16.rs - f16::f16::to_le_bytes (line 716)
    library/core/src/num/f16.rs - f16::f16::to_ne_bytes (line 743)

due to

rustc-LLVM ERROR: Cannot select: 0x3ffcc0737a0: i32 = fp_to_fp16 0x3ffcc072fc0

(which is llvm/llvm-project#50374)

After #127235 most doctests are already restricted to x64_64 (or aarch64), but these few listed above remain active on all Linux platforms. Could those also be restricted for now (until the s390x LLVM back-end is fixed) so that the test suite passes again? Thanks!

tgross35 · 2024-07-10T20:04:20Z

Thanks for reporting @uweigand, yes those could be restricted too. Feel free to open a PR similar to #127235 if you're up for it, otherwise I'll try to put one up in the next couple days.

uweigand · 2024-07-10T21:25:31Z

Thanks for reporting @uweigand, yes those could be restricted too. Feel free to open a PR similar to #127235 if you're up for it, otherwise I'll try to put one up in the next couple days.

I've now opened #127588, thanks!

beetrees · 2024-07-10T21:30:01Z

LLVM lowers f16 FMA incorrectly on targets without native f16 FMA support (so this will affect most targets including all tier 1 targets): llvm/llvm-project#98389

scottmcm · 2024-07-14T23:15:18Z

It appears that today f128 doesn't trigger the incomplete_features lint: https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=9d8a3698d5d506fc960bde270e9a1a54

It might be a good idea to do that for now, to avoid people making threads like https://users.rust-lang.org/t/display-for-f128/114405?u=scottmcm

…indows-abi, r=<try> 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

…-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

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 · 2024-08-02T09:17:04Z

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

traviscross added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Oct 18, 2023