Tracking Issue for f16 and f128 float types
#116909
Assignees
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
added
the
C-tracking-issue
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
T-lang
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
B-RFC-approved
This comment was marked as outdated.
This comment was marked as outdated.
2 tasks
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
I-prioritize
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
T-compiler
This comment has been minimized.
This comment has been minimized.
lqd
removed
the
I-prioritize
Closed
|
A blocking issue should be added: ensure C compatibility with ABI-cafe or similar |
|
Implementation steps (massive todo list moved to the top post) @rustbot claim |
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 31, 2024
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
|
Tier 3 |
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 17, 2024
…=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
…=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
…=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
…=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
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 27, 2024
…, 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
…, 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
…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
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
|
llvm/llvm-project#104915: |
This comment has been minimized.
This comment has been minimized.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Nov 25, 2024
…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
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
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
bjorn3
pushed a commit
to rust-lang/rustc_codegen_cranelift
that referenced
this issue
Nov 28, 2024
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
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:
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
Implementation history
f16andf128#121728f16andf128step 2: intrinsics #121841 (comment)f16andf128step 3: compiler support & feature gate #121926rustcmore or less expects for primitives Add basic trait impls forf16andf128#123085f16andf128to rustdoc'sPrimitiveType#123581Some parts are blocked on const eval, compiler builtins updates, and LLVM lowering bugs.hooray, this part is done!f16andf128step 4: basic library support #122470Debugimpl and some basic functions tof16andf128#123783f16andf128#126608f16andf128math functions #127027f16/f128float conversions compiler-builtins#593f128compiler-builtins#606f128float to integer conversion functions compiler-builtins#613__divtf3compiler-builtins#622__powitf2symbol forf128integer exponentiation compiler-builtins#614test-float-parsein Rust #127510f16, which should be straightforward Addf16formatting and parsing #127013f128which will not be straightforward. Our current implementations are prettyu64-dependent so they can't fit af128mantissa. We could make them generic but probably want to instead use an implementation that is slower but better for size.f16andf128const eval for binary and unary operationations #126429f16andf128#127032Add encoding forAdd v0 symbol mangling forf16andf128#122106f16andf128#123816Ensure known demanglers get updated or at least have issues for adding the new typesunneeded with the forward-compatible demanglingf16andf128in assembly on platforms that support it #125398f16andf128inline ASM support foraarch64#129536f16andf128inline ASM support forx86andx86-64#126417f16inline ASM support for RISC-V #126530f16inline ASM support for 32-bit ARM #126555f16andf128rustc_codegen_gcc#461 (merged upstream, waiting on sync)f16andf128rustc_codegen_cranelift#1461unimplementeds andFIXMEs are removed from tools that need library supportf16andf128unimplemented!/FIXMEs #126636f16andf128pattern matching stubs with real implementations #123088f16/f128FIXMEs that needed(NEG_)INFINITY#127496f16_nanf16generates code that uses the incorrect ABI for compiler-rt #123885halfoperations by using too much precision on several backends llvm/llvm-project#97975 LLVM miscompiles passing/returninghalfon several backends by using lossy conversions llvm/llvm-project#97981@llvm.fabs.f16generates call to__extendhfsf2llvm/llvm-project#104915 (comment)f128symbols on powerpc64 give inaccurate results #125109f128from_bits/to_bitssometimes gets reversed on ppc #125102f128 as f16casting bug LLVM f128 -> f16 conversion selection failure on powerpc64le llvm/llvm-project#92866fp128->halfuses__trunctfhf2but should be__trunckfhf2llvm/llvm-project#98126+fand+dllvm/llvm-project#93894 (fixed upstream)halforfp128onarm64ecllvm/llvm-project#94434wasm32,halfoperation results aren't correctly rounded between each operation llvm/llvm-project#96437fp128causes compilation failures when compiling fornvptx64-nvidia-cudallvm/llvm-project#95471f128Compiler crash when targetingmips64when returningfp128after calling a function returning{ i8, i128 }llvm/llvm-project#96432powerpc64-ibm-aixdoesn't currently supportf128arguments:fp128arguments cause a compiler error onpowerpc64-ibm-aixllvm/llvm-project#101545-Ctarget-feature#116344 (and in particular Figure out which target features affect float ABI #131799) for all targets; those issues are mostly focusing on f32 and f64 so there might be more target features we have to worry about for f16/f128fma.f16incorrectlyllvm.fma.f16intrinsic is expanded incorrectly on targets without nativehalfFMA support llvm/llvm-project#98389powi.f16constant folding returns incorrect values Misoptimization:EarlyCSEPassuses replacespowi.f16withfloatresult llvm/llvm-project#98665Note that
unimplemented!("f16_f128")and// FIXME(f16_f128)is being used where relevant, to make the todo list easily greppable.Nice to have changes:
f16: Add Natvis visualiser and debuginfo tests forf16#127001f128f16andf128support (add toFloatTy) rust-analyzer#17451f16andf128under a nightly flag Lokathor/bytemuck#250The text was updated successfully, but these errors were encountered: