-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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.
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
Tracking Issue for f16
and f128
float types
#116909
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
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.
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.
This comment has been minimized.
This comment has been minimized.
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 |
…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
…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
…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
…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
The test suite currently fails on s390x in the following doctests:
due to
(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! |
LLVM lowers |
It appears that today 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
…-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
…-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
…-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
Tier 3 |
…=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
…=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
…=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
…=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
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
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
None so far.
Implementation history
f16
andf128
#121728f16
andf128
step 2: intrinsics #121841 (comment)f16
andf128
step 3: compiler support & feature gate #121926rustc
more or less expects for primitives Add basic trait impls forf16
andf128
#123085f16
andf128
to rustdoc'sPrimitiveType
#123581Some parts are blocked on const eval, compiler builtins updates, and LLVM lowering bugs.hooray, this part is done!f16
andf128
step 4: basic library support #122470Debug
impl and some basic functions tof16
andf128
#123783f16
andf128
#126608f16
andf128
math functions #127027f16
/f128
float conversions compiler-builtins#593f128
compiler-builtins#606f128
float to integer conversion functions compiler-builtins#613__divtf3
compiler-builtins#622__powitf2
symbol forf128
integer exponentiation compiler-builtins#614test-float-parse
in Rust #127510f16
, which should be straightforward Addf16
formatting and parsing #127013f128
which will not be straightforward. Our current implementations are prettyu64
-dependent so they can't fit af128
mantissa. We could make them generic but probably want to instead use an implementation that is slower but better for size.f16
andf128
const eval for binary and unary operationations #126429f16
andf128
#127032Add encoding forAdd v0 symbol mangling forf16
andf128
#122106f16
andf128
#123816Ensure known demanglers get updated or at least have issues for adding the new typesunneeded with the forward-compatible demanglingf16
andf128
in assembly on platforms that support it #125398f16
andf128
inline ASM support forx86
andx86-64
#126417f16
inline ASM support for RISC-V #126530f16
inline ASM support for 32-bit ARM #126555f16
andf128
rustc_codegen_gcc#461 (merged upstream, waiting on sync)f16
andf128
rustc_codegen_cranelift#1461unimplemented
s andFIXME
s are removed from tools that need library supportf16
andf128
unimplemented!
/FIXME
s #126636f16
andf128
pattern matching stubs with real implementations #123088f16
/f128
FIXMEs that needed(NEG_)INFINITY
#127496f16_nan
f16
generates code that uses the incorrect ABI for compiler-rt #123885half
operations by using too much precision on several backends llvm/llvm-project#97975 LLVM miscompiles passing/returninghalf
on several backends by using lossy conversions llvm/llvm-project#97981f128
symbols on powerpc64 give inaccurate results #125109f128
from_bits
/to_bits
sometimes gets reversed on ppc #125102f128 as f16
casting bug LLVM f128 -> f16 conversion selection failure on powerpc64le llvm/llvm-project#92866fp128
->half
uses__trunctfhf2
but should be__trunckfhf2
llvm/llvm-project#98126+f
and+d
llvm/llvm-project#93894 (fixed upstream)half
orfp128
onarm64ec
llvm/llvm-project#94434wasm32
,half
operation results aren't correctly rounded between each operation llvm/llvm-project#96437fp128
causes compilation failures when compiling fornvptx64-nvidia-cuda
llvm/llvm-project#95471f128
Compiler crash when targetingmips64
when returningfp128
after calling a function returning{ i8, i128 }
llvm/llvm-project#96432powerpc64-ibm-aix
doesn't currently supportf128
arguments:fp128
arguments cause a compiler error onpowerpc64-ibm-aix
llvm/llvm-project#101545fma.f16
incorrectlyllvm.fma.f16
intrinsic is expanded incorrectly on targets without nativehalf
FMA support llvm/llvm-project#98389powi.f16
constant folding returns incorrect values Misoptimization:EarlyCSEPass
uses replacespowi.f16
withfloat
result 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
#127001f128
f16
andf128
support (add toFloatTy
) rust-analyzer#17451f16
andf128
under a nightly flag Lokathor/bytemuck#250The text was updated successfully, but these errors were encountered: