-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add f16
and f128
#114607
Add f16
and f128
#114607
Conversation
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.
// num.parse().ok() | ||
// } | ||
|
||
// FIXME: bootstrap `f16` parsing via `f32` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// FIXME: bootstrap `f16` parsing via `f32` | |
// FIXME: bootstrap `f128` parsing via `f64` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also please don't remove this until both cg_clif and cg_gcc support the new types. Otherwise they can't bootstrap rustc anymore.
library/core/src/fmt/float.rs
Outdated
#[cfg(not(bootstrap))] | ||
floating! { f16 } | ||
#[cfg(not(bootstrap))] | ||
floating! { f128 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These methods are not #[inline]
so they will completely break building the standard library with cg_gcc and cg_clif until these backends support f16 and f128.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the correct way to fix this? I have also just been using unimplemented!()
in clif and gcc to make things compiile, I guess those should just throw errors instead?
(down the line of course, I'm still on the very first stage of getting this to work)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[inline]
functions are only codegened when actually used. So making them #[inline]
at least temporarily would be an option.
I guess those should just throw errors instead?
That would replace an ICE with an error when compiling libcore. Both prevent successful compilation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cg_clif and cg_gcc don't yet have CI tests yet right? Could turn them on while I'm working on this if so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try cherry-picking #112701 and then remove https://github.com/rust-lang/rust/pull/112701/files#diff-8479eab02701e686aedb15b567dc8fc31220c6e4efb9565ccc9d662b7fee2214R3057-R3063 Once that is done if you set codegen-backends
in config.toml to include llvm and cranelift (llvm first to avoid building rustc itself with cranelift), you can test it with ./x.py test compiler/rustc_codegen_cranelift
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these mini_core
errors usually show up in CI? I don't think I'm getting them on local https://github.com/rust-lang/rust/actions/runs/5806522313/job/15739585197?pr=114607#step:24:3221
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because #112701 hasn't landed yet it is possible for PR's in this repo to break cg_clif's testsuite. I fixed that issue just today in bjorn3/rustc_codegen_cranelift@3deb6c6. Opened #114666 to sync it back to this repo.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@rustbot label -A-testsuite -T-bootstrap -T-infra |
…r-errors Add stubs in IR and ABI for `f16` and `f128` This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary. These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`. The next steps will probably be AST support with parsing and the feature gate. r? `@compiler-errors` cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)
…, r=compiler-errors `f16` and `f128` step 2: intrinsics Continuation of rust-lang#121728, another portion of rust-lang#114607. This PR adds `f16` and `f128` intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per `@rcvalle's` in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1. Once these types are usable in code, I will add the codegen tests from rust-lang#114607 (codegen is passing on that branch) This does add more `unimplemented!`s to Clippy, but I still don't think we can do better until library support is added. r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +T-compiler +F-f16_and_f128
Rollup merge of rust-lang#121841 - tgross35:f16-f128-step2-intrinsics, r=compiler-errors `f16` and `f128` step 2: intrinsics Continuation of rust-lang#121728, another portion of rust-lang#114607. This PR adds `f16` and `f128` intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per `@rcvalle's` in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1. Once these types are usable in code, I will add the codegen tests from rust-lang#114607 (codegen is passing on that branch) This does add more `unimplemented!`s to Clippy, but I still don't think we can do better until library support is added. r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +T-compiler +F-f16_and_f128
Work is in progress elsewhere, not much sense in keeping this open |
…r-errors Add stubs in IR and ABI for `f16` and `f128` This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary. These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`. The next steps will probably be AST support with parsing and the feature gate. r? `@compiler-errors` cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? ``@compiler-errors`` cc ``@Nilstrieb`` ``@rustbot`` label +F-f16_and_f128
…te, r=compiler-errors `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? ```@compiler-errors``` cc ```@Nilstrieb``` ```@rustbot``` label +F-f16_and_f128
…r-errors Add stubs in IR and ABI for `f16` and `f128` This is the very first step toward the changes in rust-lang/rust#114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary. These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`. The next steps will probably be AST support with parsing and the feature gate. r? `@compiler-errors` cc `@Nilstrieb` suggested breaking the PR up in rust-lang/rust#120645 (comment)
…ler-errors `f16` and `f128` step 2: intrinsics Continuation of rust-lang/rust#121728, another portion of rust-lang/rust#114607. This PR adds `f16` and `f128` intrinsics, and hooks them up to both HIR and LLVM. This is all still unexposed to the frontend, which will probably be the next step. Also update itanium mangling per `@rcvalle's` in https://github.com/rust-lang/rust/pull/121728/files#r1506570300, and fix a typo from step 1. Once these types are usable in code, I will add the codegen tests from #114607 (codegen is passing on that branch) This does add more `unimplemented!`s to Clippy, but I still don't think we can do better until library support is added. r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +T-compiler +F-f16_and_f128
…, r=compiler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…, r=compiler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang#121841, another portion of rust-lang#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…ler-errors,petrochenkov `f16` and `f128` step 3: compiler support & feature gate Continuation of rust-lang/rust#121841, another portion of rust-lang/rust#114607 This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed). If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes. Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step. Tracking issue: rust-lang/rust#116909 r? `@compiler-errors` cc `@Nilstrieb` `@rustbot` label +F-f16_and_f128
…r=Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? `@Amanieu` since you were pretty involved in the RFC cc `@compiler-errors` `@rustbot` label +T-libs-api +S-blocked +F-f16_and_f128
…r=Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? ``@Amanieu`` since you were pretty involved in the RFC cc ``@compiler-errors`` ``@rustbot`` label +T-libs-api +S-blocked +F-f16_and_f128
…r=Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? ```@Amanieu``` since you were pretty involved in the RFC cc ```@compiler-errors``` ```@rustbot``` label +T-libs-api +S-blocked +F-f16_and_f128
…Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? `@Amanieu` since you were pretty involved in the RFC cc `@compiler-errors` `@rustbot` label +T-libs-api +S-blocked +F-f16_and_f128
…Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? `@Amanieu` since you were pretty involved in the RFC cc `@compiler-errors` `@rustbot` label +T-libs-api +S-blocked +F-f16_and_f128
Rollup merge of rust-lang#122470 - tgross35:f16-f128-step4-libs-min, r=Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? ```@Amanieu``` since you were pretty involved in the RFC cc ```@compiler-errors``` ```@rustbot``` label +T-libs-api +S-blocked +F-f16_and_f128
Remove `f16` and `f128` ICE paths from smir Just chasing down some possible ICE paths. `@compiler-errors` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial? r? `@celinval` since you reviewed rust-lang#114607 (review)
Remove `f16` and `f128` ICE paths from smir Just chasing down some possible ICE paths. ``@compiler-errors`` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial? r? ``@celinval`` since you reviewed rust-lang#114607 (review)
Remove `f16` and `f128` ICE paths from smir Just chasing down some possible ICE paths. ```@compiler-errors``` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial? r? ```@celinval``` since you reviewed rust-lang#114607 (review)
Rollup merge of rust-lang#126983 - tgross35:f16-f128-smir, r=celinval Remove `f16` and `f128` ICE paths from smir Just chasing down some possible ICE paths. ```@compiler-errors``` mentioned in rust-lang#121728 (comment) that it is okay not to support these in smir, but this change seems pretty trivial? r? ```@celinval``` since you reviewed rust-lang#114607 (review)
Preliminary implementation of rust-lang/rfcs#3453 (still a work in progress)
This introduces four new features:
f16
: lang feature, basic support for 16-bit floating point numbersf128
: same as above for 128-bitf16_math
: libs feature, gates math that relies on intrinsicsf128_math
: libs feature, same as aboveThe math features are gated separately because it seems like LLVM has some bugs with the intrinsics. F16 should work but f128 is completely unusable llvm/llvm-project#44744.
I have found this calculator helpful if anyone is validating the data: http://weitz.de/ieee/
Tracking issue: #116909
Edit: I have started merging this in portions, see #116909 (comment)
r? ghost
@rustbot label +T-lang +T-libs-api