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.

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 stubs in IR and ABI for f16 and f128 #121728

Merged
merged 5 commits into from
Mar 1, 2024

Conversation

tgross35
Copy link
Contributor

@tgross35 tgross35 commented Feb 28, 2024

This is the very first step toward the changes in #114607 and the f16 and f128 RFC. 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 #120645 (comment)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Feb 28, 2024
@rustbot
Copy link
Collaborator

rustbot commented Feb 28, 2024

This PR changes Stable MIR

cc @oli-obk, @celinval, @spastorino, @ouz-a

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

Some changes occurred in exhaustiveness checking

cc @Nadrieril

@tgross35 tgross35 force-pushed the f16-f128-step1-ty-updates branch 2 times, most recently from c126076 to 44c1336 Compare February 28, 2024 09:25
@@ -778,8 +778,10 @@ pub fn mir_to_const<'tcx>(lcx: &LateContext<'tcx>, result: mir::Const<'tcx>) ->
let range = alloc_range(offset + size * idx, size);
let val = alloc.read_scalar(&lcx.tcx, range, /* read_provenance */ false).ok()?;
res.push(match flt {
FloatTy::F16 => unimplemented!("f16_f128"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit wary about adding this, especially to tools. There's definitely a risk of forgetting some of them, causing ICEs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change this, what would be better?

My original change did more https://github.com/rust-lang/rust/pull/114607/files#diff-83cfffe9dbc2758ecf7b34a433525befc32ebff4525aef0de105fa5e7b659c21R808-R815, but since the surface area of this PR is intentionally much smaller, the primitives aren't available for use.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the benefit of small PRs and this comment isn't meant to block the PR. Just a concern, that we shouldn't forget about those unimplemented! macros.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the panics could be added as a step to the tracking issue

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fairness to @tgross35, this is impossible to hit right now. I think this approach is the best for the moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a todo list that mentions these at #116909 (comment)

@@ -0,0 +1,37 @@
// Make sure we don't ICE while incrementally adding f16 and f128 support
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think parser is quite right, the parser doesn't care :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this test does literally nothing lol

Copy link
Contributor Author

@tgross35 tgross35 Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There didn't seem to be a good folder :) I can move it if there is a better place

I know it does nothing but I just wanted a test that can be updated as the steps move along. So as to not accidentally go from "f128 does nothing" to "typing f128 anywhere in your code causes an ICE" :)

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some tiny nits, then I think this is fine

compiler/rustc_smir/src/rustc_internal/internal.rs Outdated Show resolved Hide resolved
Comment on lines +473 to +476
FloatTy::F16 => unimplemented!("f16_f128"),
FloatTy::F32 => 'f',
FloatTy::F64 => 'd',
FloatTy::F128 => unimplemented!("f16_f128"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rcvalle: are there encodings for these types?

Copy link
Contributor Author

@tgross35 tgross35 Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some more discussion for these at #114607 (comment) and rust-lang/rustc-demangle#64 for this too

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replied on the other issue, but will reply it here as well for easier reference. My recommendation is:

  • For f128, if it's compatible with __float128 regardless of the underlying representation (i.e., changes between IEEE 754R 128-bit floating point type or IBM extended double depending on the target), we should always encode it as 'g' as it will be how it will also be encoded by Clang. (FWIW, it seems Clang uses IEEE 754R 128-bit floating point type instead of IBM extended double for __float128 by default for ppc64le since May 2023 and __ibm128 also doesn't seem to have a distinct encoding specified in the Itanium C++ ABI mangling.)
  • For f16, if it's compatible with IEEE 754R 128-bit floating point type (__fp16 and _Float16 in Clang), we should always encode it as 'Dh'; if it's compatible with bfloat16 (which is unlikely?), we should always encode it as 'DF16b'.
  • The 'Dd, 'De', and 'Df' encodings are for when the Rust compiler and Clang support decimal floating point types.

tl;dr.: We should always encode f128 as 'g', and f16 as 'Dh'.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note that this independent/dissociated to Rust mangling/demangling and a different encoding can be used for it.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I will update these in the upcoming PR to add intrinsics.

Total miss that they didn't make __float128 mangle as q to be consistent with f and d :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! :)

@@ -778,8 +778,10 @@ pub fn mir_to_const<'tcx>(lcx: &LateContext<'tcx>, result: mir::Const<'tcx>) ->
let range = alloc_range(offset + size * idx, size);
let val = alloc.read_scalar(&lcx.tcx, range, /* read_provenance */ false).ok()?;
res.push(match flt {
FloatTy::F16 => unimplemented!("f16_f128"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fairness to @tgross35, this is impossible to hit right now. I think this approach is the best for the moment.

@@ -0,0 +1,37 @@
// Make sure we don't ICE while incrementally adding f16 and f128 support
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this test does literally nothing lol

@tgross35
Copy link
Contributor Author

@rustbot label +F-f16_and_f128

@rustbot rustbot added the F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` label Feb 28, 2024
@compiler-errors
Copy link
Member

@bors r+ rollup=never

@tgross35
Copy link
Contributor Author

@fmease fmease closed this Feb 28, 2024
@fmease fmease reopened this Feb 28, 2024
@fmease
Copy link
Member

fmease commented Feb 28, 2024

@bors r=compiler-errors rollup=never

@bors
Copy link
Contributor

bors commented Feb 28, 2024

📌 Commit 406790e has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 28, 2024
@compiler-errors
Copy link
Member

compiler-errors commented Feb 29, 2024

@bors r+

I believe the PR was already in the queue last time I checked this morning (until it was r-'d). This PR was not given a priority, and rollup=never PRs are merged in order of the date the PR was opened, which is why the current one is merging.

@bors
Copy link
Contributor

bors commented Feb 29, 2024

📌 Commit 406790e has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 29, 2024
@tgross35
Copy link
Contributor Author

tgross35 commented Feb 29, 2024

@bors r+

I believe the PR was already in the queue last time I checked this morning. This PR was not given a priority, and rollup=never PRs are merged in order of the date the PR was opened, which is why the current one is merging.

🤦‍♂️ I thought it was approval date not opening date, thanks

All the same something is weird. Every time #121242 got to the top of the queue in the past 24 hours Bors would give up and stop merging things, this one was right behind it. And it merged a stale commit of mine #119748 (comment)

@tgross35
Copy link
Contributor Author

tgross35 commented Mar 1, 2024

Same PR at the top, again Bors stopped running autos. Weird (mentioned to infra on zulip)

image

@bors
Copy link
Contributor

bors commented Mar 1, 2024

⌛ Testing commit 406790e with merge 6cbf092...

@bors
Copy link
Contributor

bors commented Mar 1, 2024

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 6cbf092 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 1, 2024
@bors bors merged commit 6cbf092 into rust-lang:master Mar 1, 2024
23 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Mar 1, 2024
@tgross35 tgross35 deleted the f16-f128-step1-ty-updates branch March 1, 2024 06:12
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (6cbf092): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.5% [3.5%, 3.5%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.0% [-5.1%, -1.5%] 3
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
4.3% [2.1%, 6.3%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-2.8%, -2.6%] 2
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 650.561s -> 653.924s (0.52%)
Artifact size: 311.48 MiB -> 311.55 MiB (0.02%)

Nadrieril added a commit to Nadrieril/rust that referenced this pull request Mar 2, 2024
…, 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
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 3, 2024
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
GuillaumeGomez pushed a commit to GuillaumeGomez/rust that referenced this pull request Mar 5, 2024
…r=compiler-errors

Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in rust-lang#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#120645 (comment)
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request Mar 7, 2024
…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
flip1995 pushed a commit to flip1995/rust that referenced this pull request Mar 7, 2024
…r=compiler-errors

Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in rust-lang#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#120645 (comment)
celinval pushed a commit to model-checking/kani that referenced this pull request Mar 12, 2024
Relevant upstream changes:

rust-lang/rust#120675: An intrinsic `Symbol` is
now wrapped in a `IntrinsicDef` struct, so the relevant part of the code
needed to be updated.
rust-lang/rust#121464: The second argument of
the `create_wrapper_file` function changed from a vector to a string.
rust-lang/rust#121662: `NullOp::DebugAssertions`
was renamed to `NullOp::UbCheck` and it now has data (currently unused
by Kani)
rust-lang/rust#121728: Introduces `F16` and
`F128`, so needed to add stubs for them
rust-lang/rust#121969: `parse_sess` was renamed
to `psess`, so updated the relevant code.
rust-lang/rust#122059: The
`is_val_statically_known` intrinsic is now used in some `core::fmt`
code, so had to handle it in (codegen'ed to false).
rust-lang/rust#122233: This added a new
`retag_box_to_raw` intrinsic. This is an operation that is primarily
relevant for stacked borrows. For Kani, we just return the pointer.

Resolves #3057
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2024
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)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 26, 2024
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)
jhpratt added a commit to jhpratt/rust that referenced this pull request Jun 27, 2024
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)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jun 27, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants