Repository navigation
add core::arch::{x86, x86_64}::x87_f80
#163992
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -327,6 +327,7 @@ pub struct TargetDataLayout { | |
| pub f16_align: Align, | ||
| pub f32_align: Align, | ||
| pub f64_align: Align, | ||
| pub x87_f80_align: Align, | ||
| pub f128_align: Align, | ||
| pub aggregate_align: Align, | ||
|
|
||
|
|
@@ -367,6 +368,7 @@ impl Default for TargetDataLayout { | |
| f16_align: align(16), | ||
| f32_align: align(32), | ||
| f64_align: align(64), | ||
| x87_f80_align: align(128), | ||
| f128_align: align(128), | ||
| aggregate_align: align(8), | ||
| vector_align: vec![ | ||
|
|
@@ -510,6 +512,7 @@ impl TargetDataLayout { | |
| ["f16", a @ ..] => dl.f16_align = parse_align_seq(a, "f16")?, | ||
| ["f32", a @ ..] => dl.f32_align = parse_align_seq(a, "f32")?, | ||
| ["f64", a @ ..] => dl.f64_align = parse_align_seq(a, "f64")?, | ||
| ["f80", a @ ..] => dl.x87_f80_align = parse_align_seq(a, "f80")?, | ||
| ["f128", a @ ..] => dl.f128_align = parse_align_seq(a, "f128")?, | ||
| [p, s, a @ ..] if p.starts_with("p") => { | ||
| let mut p = p.strip_prefix('p').unwrap(); | ||
|
|
@@ -1427,10 +1430,22 @@ pub enum Float { | |
| F16B, | ||
| F32, | ||
| F64, | ||
| /// `x87_f80`. This is not a builtin type in Rust (it is exposed as a lang item), | ||
| /// but it is a builtin type in LLVM so needs to be explicitly represented | ||
| /// in the backend. | ||
| /// | ||
| /// Here we define the 80-bit scalar value that corresponds to the `x87_f80_raw` lang item. | ||
| /// In `core::arch::{x86, x86_64}` this type is wrapped by the `x87_f80` lang item that adds | ||
| /// the proper alignment and bumps the size to either 12 or 16 bytes depending on the target. | ||
| /// | ||
| /// Only used on x86 and x86_64 targets. | ||
| X87F80, | ||
| F128, | ||
| /// `ppcf128`. This is not a builtin type in Rust (it is exposed as a lang item), | ||
| /// but it is a builtin type in LLVM so needs to be explicitly represented | ||
| /// in the backend. | ||
| /// | ||
| /// Only used on powerpc and powerpc64 targets. | ||
| PpcF128, | ||
| } | ||
|
|
||
|
|
@@ -1443,6 +1458,7 @@ impl Float { | |
| F16B => Size::from_bits(16), | ||
| F32 => Size::from_bits(32), | ||
| F64 => Size::from_bits(64), | ||
| X87F80 => Size::from_bits(80), | ||
| F128 => Size::from_bits(128), | ||
| PpcF128 => Size::from_bits(128), | ||
| } | ||
|
|
@@ -1456,6 +1472,9 @@ impl Float { | |
| F16 | F16B => dl.f16_align, | ||
| F32 => dl.f32_align, | ||
| F64 => dl.f64_align, | ||
| // Use an alignment of 1 for x87_f80_raw, | ||
| // so that its size really is 80 bits in memory. | ||
| X87F80 => Align::ONE, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Might be worth a short comment here explaining why this isn't |
||
| F128 => dl.f128_align, | ||
| PpcF128 => dl.f128_align, | ||
| }) | ||
|
|
@@ -1469,6 +1488,7 @@ impl Float { | |
| F16B => "f16b", | ||
| F32 => "f32", | ||
| F64 => "f64", | ||
| X87F80 => "x87_f80", | ||
| F128 => "f128", | ||
| PpcF128 => "ppcf128", | ||
| } | ||
|
|
@@ -1496,9 +1516,9 @@ impl Numeric { | |
| match self { | ||
| Numeric::Int(_, _) => RegKind::Integer, | ||
| Numeric::Float(Float::PpcF128) => RegKind::PpcF128, | ||
| Numeric::Float(Float::F16 | Float::F16B | Float::F32 | Float::F64 | Float::F128) => { | ||
| RegKind::Float | ||
| } | ||
| Numeric::Float( | ||
| Float::F16 | Float::F16B | Float::F32 | Float::F64 | Float::X87F80 | Float::F128, | ||
| ) => RegKind::Float, | ||
| } | ||
| } | ||
| } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,7 +1,7 @@ | ||
| use std::fmt::Write; | ||
|
|
||
| use rustc_abi::Primitive::{Float, Int, Pointer}; | ||
| use rustc_abi::{Align, BackendRepr, FieldsShape, Scalar, Size, Variants}; | ||
| use rustc_abi::{Align, BackendRepr, FieldsShape, Scalar, Size, TyAbiInterface, Variants}; | ||
| use rustc_codegen_ssa::traits::*; | ||
| use rustc_middle::ty::layout::{LayoutOf, TyAndLayout}; | ||
| use rustc_middle::ty::print::{with_no_trimmed_paths, with_no_visible_paths}; | ||
|
|
@@ -75,6 +75,11 @@ fn uncached_llvm_type<'a, 'tcx>( | |
| BackendRepr::Memory { .. } | BackendRepr::ScalarPair { .. } => {} | ||
| } | ||
|
|
||
| // Map `core::arch::{x86, x86_64}::x87_f80` to LLVM's `x86_fp80`. | ||
| if Ty::is_x87_f80_lang_item(layout, cx) { | ||
| return cx.type_x87_f80(); | ||
| } | ||
|
Comment on lines
+78
to
+81
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, this is really all it takes in the LLVM backend to make this type work. it gets the LLVM store size of 10 bytes (touched by load/store) and target-dependent alloc size of 12 or 16.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the LLVM type just behaves correctly though? It has a store size of 10 but an allocation size of 12/16, and LLVM uses the right value in the right context as far as I can tell. Hence, we don't need to manually convert to the array?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. phrased differently: what sort of code do you think fails with the current implementation, because we should test its behavior either way. |
||
|
|
||
| let name = match layout.ty.kind() { | ||
| // FIXME(eddyb) producing readable type names for trait objects can result | ||
| // in problematically distinct types due to HRTB and subtyping (see #47638). | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
Given that
(80 / 8) % dl.x87_f80_align != 0, could you add a comment here explaining why this is correct (I think it is as the align is only used to affect the overall alignment of the cast alloca, but we should document that fact somewhere to avoid confusion).View changes since the review