-
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
tighten sanity checks around Scalar and ScalarPair #96220
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
// FIXME: Can we check anything here? | ||
} | ||
} | ||
} |
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.
I removed all this since I think it is redundant with the scalar size check in to_bits
that alloc.write_scalar
does.
This comment has been minimized.
This comment has been minimized.
a9666f7
to
60c3d1a
Compare
// HACK to support buggy enums whose variants have Aggregate ABI | ||
// (see https://github.com/rust-lang/rust/issues/96185). | ||
// codegen doesn't do this, not sure why. | ||
(Immediate::ScalarPair(a_val, b_val), Abi::Aggregate { .. }) => { |
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.
This is the odd one -- a ScalarPair at Aggregate
ABI just doesn't seem right.
I added sanity checking in operand_downcast
, and my theory was confirmed: when downcasting std::option::Option<*mut std::ffi::c_void>
to variant 1, the ABI changes from ScalarPair
to Aggegreate
.
downcast to 1 turned ScalarPair layout into non-scalar layout: TyAndLayout {
ty: std::option::Option<*mut std::ffi::c_void>,
layout: Layout {
fields: Arbitrary {
offsets: [
Size {
raw: 0,
},
],
memory_index: [
0,
],
},
variants: Multiple {
tag: Initialized {
value: Int(
I64,
false,
),
valid_range: 0..=1,
},
tag_encoding: Direct,
tag_field: 0,
variants: [
Layout {
fields: Arbitrary {
offsets: [],
memory_index: [],
},
variants: Single {
index: 0,
},
abi: Aggregate {
sized: true,
},
largest_niche: None,
align: AbiAndPrefAlign {
abi: Align {
pow2: 0,
},
pref: Align {
pow2: 3,
},
},
size: Size {
raw: 8,
},
},
Layout {
fields: Arbitrary {
offsets: [
Size {
raw: 8,
},
],
memory_index: [
0,
],
},
variants: Single {
index: 1,
},
abi: Aggregate {
sized: true,
},
largest_niche: None,
align: AbiAndPrefAlign {
abi: Align {
pow2: 3,
},
pref: Align {
pow2: 3,
},
},
size: Size {
raw: 16,
},
},
],
},
abi: ScalarPair(
Initialized {
value: Int(
I64,
false,
),
valid_range: 0..=1,
},
Initialized {
value: Pointer,
valid_range: 0..=18446744073709551615,
},
),
largest_niche: Some(
Niche {
offset: Size {
raw: 0,
},
value: Int(
I64,
false,
),
valid_range: 0..=1,
},
),
align: AbiAndPrefAlign {
abi: Align {
pow2: 3,
},
pref: Align {
pow2: 3,
},
},
size: Size {
raw: 16,
},
},
} to TyAndLayout {
ty: std::option::Option<*mut std::ffi::c_void>,
layout: Layout {
fields: Arbitrary {
offsets: [
Size {
raw: 8,
},
],
memory_index: [
0,
],
},
variants: Single {
index: 1,
},
abi: Aggregate {
sized: true,
},
largest_niche: None,
align: AbiAndPrefAlign {
abi: Align {
pow2: 3,
},
pref: Align {
pow2: 3,
},
},
size: Size {
raw: 16,
},
},
}
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.
Reported as #96221.
60c3d1a
to
e7d1ace
Compare
This comment has been minimized.
This comment has been minimized.
Ah, I guess this is enough to anger const-eval on the runtime version of this example.^^ I guess this is blocked on fixing that enum layout then. |
d448749
to
64826e5
Compare
This comment has been minimized.
This comment has been minimized.
Const prop strikes again 🙈 |
The curious part is that const prop managed to dodge the assertions we had in place before. I guess that goes to show some extra assertions are really needed. ;) |
☔ The latest upstream changes (presumably #96734) made this pull request unmergeable. Please resolve the merge conflicts. |
64826e5
to
fc4846f
Compare
This comment has been minimized.
This comment has been minimized.
fc4846f
to
aef8a93
Compare
I rebased and commented out the things that are broken by #96185. @oli-obk I think this is ready for review. Also let's ensure this does not cost too much perf. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit aef8a93 with merge e20aa27db438b844d57419af48c40860d88dbcda... |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 14f6daf with merge bae4e5b81419bd94533a9428d118973194da792b... |
☀️ Try build successful - checks-actions |
Queued bae4e5b81419bd94533a9428d118973194da792b with parent f296b9a, future comparison URL. |
Finished benchmarking commit (bae4e5b81419bd94533a9428d118973194da792b): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
Hm, well, that did not help... Maybe the |
mir interpret is always hitting LLVM inlining thresholds, I don't think it's worth looking into further in this PR @bors r+ |
📌 Commit 14f6daf has been approved by |
⌛ Testing commit 14f6daf with merge 3e2c8514996fffe0081afd8cd6dcf2fcf362d4ff... |
💔 Test failed - checks-actions |
@bors retry timeout, logs empty/stuck |
☀️ Test successful - checks-actions |
Finished benchmarking commit (6dd6840): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
While investigating #96185 I noticed codegen has tighter sanity checks here than Miri does, so I added some more assertions. Strangely, some of them fail, so I also needed to add a HACK... that is probably worth looking into.
This does not fix that issue, but it changes the ICE messages, making it quite clear that we have a scalar whose size is not the same as that of the surrounding layout.
r? @oli-obk