add `core::arch::{x86, x86_64}::x87_f80` by folkertdev · Pull Request #163992 · rust-lang/rust

folkertdev · 2026-10-08T14:12:16Z

Add x87_f80 in the same way as f16b and ppcf128.

It's unclear what to do with this type on softfloat targets. Clang and GCC reject the type when the x87 registers are not available. We should do the same, probably just with a cfg?

I don't think we have a good cfg for this though? x87 is still set on softfloat targets, while soft-float doesn't get set (that does not give a warning even, it probably should?). We also don't set cfg_abi.

future work

the ABI of Complex<x87_f80> has not yet been implemented
x87_f80 does not yet implement VaArgSafe

folkertdev · 2026-10-08T19:07:19Z

r? beetrees
cc @tgross35 @RalfJung

rustbot · 2026-10-08T19:07:28Z

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @sayantn

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

This PR changes rustc_public

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

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

folkertdev · 2026-10-08T19:09:23Z

@bors try jobs=test-various,test-i686-*

add `core::arch::{x86, x86_64}::x87_f80` try-job: test-various try-job: test-i686-*

rust-bors · 2026-10-08T21:43:58Z

☀️ Try build successful (CI)
Build commit: 4923e95 (4923e95bc1c5973505d6b35dcddbc97d11ae69e5)
Base parent: 65efa19 (65efa194201c67ba29b7384255a534d61c2aa3cb)

RalfJung · 2026-10-09T08:28:39Z

This changes the signature of size because the size of x87_f80 depends on the target (12 bytes on 32-bit targets, 16 bytes on 64-bit targets).

"f80" is 128 bits large on 64-bit targets...?!?? How does that make any sense?

It also breaks an invariant that scalars are the size of their fields: the x87_f80 scalar is 80 bits, but the field is the aforementioned 12 or 16 bytes. Let's hope we don't subtly rely on that somewhere.

I'd be surprised if we didn't. That's been pretty much part of the definition of being a scalar -- if a type has padding, it is not a scalar type. The interpreter was built around that assumption.
Cc @scottmcm who recently generalized what a scalar can be, but even with that I don't think it can have padding.

It does not sound to me like this type can be a scalar, then.

RalfJung · 2026-10-09T08:32:01Z

+                // For `x87_f80` the primitive is 80 bits, but the field (after rounding up to
+                // the alignment) is 12 bytes (on 32-bit systems) or 16 bytes (64-bit).
+                // So we can't assert equality of size and layout.size.
+                assert_eq!(
+                    size.align_to(s.default_align(self).abi),
+                    mplace.layout.size,
+                    "abi::Scalar is larger than its layout"
+                );


The entire logic for dealing with scalars throughout the interpreter assumes that they have no padding. Changing this assertion is not enough, it just means the rest of the interpreter is now more or less silently wrong. Pretty much all codepaths that deal with scalars need to be audited. Same for every other MIR consumer.

I would strongly prefer if we didn't break the fundamental concept of a "scalar".

View changes since the review

To give just one example, here's one place we make that assumption:

rust/compiler/rustc_const_eval/src/interpret/place.rs

Lines 792 to 794 in 6aaabbb

Immediate::Scalar(scalar) => {

alloc.write_scalar(alloc_range(Size::ZERO, scalar.size()), scalar)?;

}

You can't even see it. But if you look at the ScalarPair path you can see that we have to ensure that padding gets reset to uninit, and in the Scalar path we don't have to worry about that.

Also, the basic APIs for reading/writing stuff in an Allocation are read_scalar/write_scalar. This again uses the term "scalar" to refer to something that has no padding. Same for the type Scalar. And so on.

RalfJung · 2026-10-09T08:40:37Z

It would probably be possible, with a lot of effort, to fix all the places where we assume scalars have no padding. But I think that's a bad idea. It makes life harder for every MIR consumer. (Most likely it'll mean many MIR consumers will stay buggy as nobody will expect something as outlandish as this weird type.) This new type is the weird one here, we should not shape everything around a legacy type that hardly anyone needs and that has no justification to exist in the first place other than "it has always been here".

beetrees · 2026-10-09T08:53:07Z

I think it might make sense to introduce something like BackendRepr::PaddedScalar (name bikesheddable)? This would be useful for more than just x87_f80: e.g. currently we can (don't have my laptop to check if we currently do) represent #[repr(align(16))] struct A(u8, u8); as a BackendRepr::ScalarPair, whereas #[repr(align(16))] struct A(u8); currently has to be represented as BackendRepr::Memory as it has padding.

tgross35 · 2026-10-09T08:56:55Z

For Rust's purposes could we just pretend it's a MaybeUninit<u128> on x86-64 rather than treating it as a padded scalar?

Without it, reads are reported as UB because the tracking of what bytes are initialized is incorect

rustbot · 2026-11-08T14:37:44Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

beetrees · 2026-11-09T21:04:13Z

r=me once r? @RalfJung gives a LGTM on the const eval/Miri stuff.

rustbot · 2026-11-09T21:04:19Z

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

RalfJung · 2026-11-09T21:42:45Z

@bors r=beetrees,RalfJung

rust-bors · 2026-11-09T21:42:48Z

📌 Commit 7274b42 has been approved by beetrees,RalfJung

It is now in the queue for this repository.

…ees,RalfJung add `core::arch::{x86, x86_64}::x87_f80` tracking issue: rust-lang#163982 cc rust-lang#161787 Add `x87_f80` in the same way as `f16b` and `ppcf128`. --- It's unclear what to do with this type on softfloat targets. Clang and GCC reject the type when the x87 registers are not available. We should do the same, probably just with a `cfg`? I don't think we have a good `cfg` for this though? `x87` is still set on softfloat targets, while `soft-float` doesn't get set (that does not give a warning even, it probably should?). We also don't set `cfg_abi`. ### future work - the ABI of `Complex<x87_f80>` has not yet been implemented - `x87_f80` does not yet implement `VaArgSafe`

rust-timer · 2026-11-11T13:17:40Z

Note

This PR was benchmarked as part of triage of its containing rollup: triage URL.

Finished benchmarking commit (ff26eab): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.2%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-0.3%, 0.2%]	7

Max RSS (memory usage)

Results (primary 2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Artifact size: 406.28 MiB -> 406.35 MiB (0.02%)

folkertdev added the F-c_longdouble `#![feature(c_longdouble)]` label Oct 8, 2026

This comment has been minimized.

Sign in to view

folkertdev force-pushed the x87_f80-simple branch from b4fafc4 to 16b2882 Compare October 8, 2026 15:25

This comment has been minimized.

Sign in to view

folkertdev force-pushed the x87_f80-simple branch from 16b2882 to 617db2d Compare October 8, 2026 16:37

folkertdev commented Oct 8, 2026

View reviewed changes

Comment thread compiler/rustc_ty_utils/src/layout/invariant.rs Resolved

Comment thread library/stdarch/crates/core_arch/src/x86/mod.rs Resolved

folkertdev force-pushed the x87_f80-simple branch from 617db2d to d582ca8 Compare October 8, 2026 19:07

rustbot assigned beetrees Oct 8, 2026

folkertdev marked this pull request as ready for review October 8, 2026 19:07

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 8, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Oct 8, 2026

Auto merge of #163992 - folkertdev:x87_f80-simple, r=<try>

4923e95

add `core::arch::{x86, x86_64}::x87_f80` try-job: test-various try-job: test-i686-*

tgross35 reviewed Oct 8, 2026

View reviewed changes

Comment thread library/stdarch/crates/core_arch/src/x86/mod.rs Resolved

Comment thread library/stdarch/crates/core_arch/src/x86/mod.rs Resolved

folkertdev force-pushed the x87_f80-simple branch from d582ca8 to a9a37a4 Compare October 8, 2026 21:29

RalfJung reviewed Oct 9, 2026

View reviewed changes

folkertdev force-pushed the x87_f80-simple branch 2 times, most recently from 16dc967 to 27fa2c7 Compare November 5, 2026 18:37

RalfJung reviewed Nov 5, 2026

View reviewed changes

Comment thread compiler/rustc_const_eval/src/interpret/validity.rs Resolved

folkertdev force-pushed the x87_f80-simple branch from 27fa2c7 to d64f2fb Compare November 5, 2026 21:23

This comment has been minimized.

Sign in to view

folkertdev added 6 commits November 8, 2026 15:31

add core::arch::{x86, x86_64}::x87_f80

a79fce1

rename Reg::align and Uniform::align to scratch_align

9da70e9

use type_padding_filler for x87_f80_raw in arrays and structs

3592132

add assert that we never cast to x87_f80

cc199fa

adjust comments on backend type functions

802a33e

support x87_f80 in const eval's try_visit_primitive

7274b42

Without it, reads are reported as UB because the tracking of what bytes are initialized is incorect

folkertdev force-pushed the x87_f80-simple branch from d64f2fb to 7274b42 Compare November 8, 2026 14:37

rustbot assigned RalfJung and unassigned beetrees Nov 9, 2026

rust-bors Bot 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 Nov 9, 2026

jhpratt mentioned this pull request Nov 10, 2026

Rollup of 11 pull requests #165735

Closed

This was referenced Nov 10, 2026

Rollup of 14 pull requests #165742

Closed

Rollup of 16 pull requests #165747

Closed

Rollup of 16 pull requests #165752

Closed

Rollup of 23 pull requests #165756

Closed

Rollup of 24 pull requests #165759

Closed

Rollup of 24 pull requests #165760

Merged

	Immediate::Scalar(scalar) => {
	alloc.write_scalar(alloc_range(Size::ZERO, scalar.size()), scalar)?;
	}

Conversation

folkertdev commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

future work

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

folkertdev commented Oct 8, 2026

Uh oh!

rustbot commented Oct 8, 2026

Uh oh!

folkertdev commented Oct 8, 2026

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

rust-bors Bot commented Oct 8, 2026

Uh oh!

RalfJung commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung Oct 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beetrees commented Oct 9, 2026

Uh oh!

tgross35 commented Oct 9, 2026

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Nov 8, 2026

Uh oh!

beetrees commented Nov 9, 2026

Uh oh!

rustbot commented Nov 9, 2026

Uh oh!

RalfJung commented Nov 9, 2026

Uh oh!

rust-bors Bot commented Nov 9, 2026

Uh oh!

rust-timer commented Nov 11, 2026

Overall result: ❌✅ regressions and improvements - please read:

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

folkertdev commented Oct 8, 2026 •

edited

Loading

RalfJung commented Oct 9, 2026 •

edited

Loading

RalfJung Oct 9, 2026 •

edited by rustbot

Loading

RalfJung commented Oct 9, 2026 •

edited

Loading