layout: Always use the largest tag size that fits. #63902
layout: Always use the largest tag size that fits. #63902hvenev wants to merge 2 commits intorust-lang:masterfrom hvenev:layout-max-tag
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @zackmdavis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
r? @eddyb |
|
|
||
| // Use the initial field alignment | ||
| let mut ity = if def.repr.c() || def.repr.int.is_some() { | ||
| let ity = if def.repr.inhibit_enum_layout_opt() { |
There was a problem hiding this comment.
Not a good idea, the old condition here is not about optimizations, it's about whether the discriminant is being forced with #[repr].
|
|
||
| for fields in variants.iter() { | ||
| let (v_size, v_align) = self.variant_size(fields, &def.repr) | ||
| .ok_or(LayoutError::SizeOverflow(ty))?; |
There was a problem hiding this comment.
This looks like it could be expensive.
There was a problem hiding this comment.
It also doesn't take field sorting and the offset for the tag into account?
There was a problem hiding this comment.
It considers field sorting, but it does not compute it. If sorting happens, all padding can be at the start.
This also means it's relatively cheap.
| min_ity | ||
| } else { | ||
| Integer::for_align(dl, start_align).unwrap_or(min_ity) | ||
| Integer::approximate_size(gap).unwrap() |
There was a problem hiding this comment.
If you pick something large enough to increase the alignment, you'll easily waste space in types containing this one.
If you think this will never happen, that's still not obvious from the code, and you'd have to either compute both and assert they're the same, and we can land that, crater it, etc. or prove it formally somehow.
There was a problem hiding this comment.
Let gap0 be the original value of gap. We either have gap = gap0 < align.abi, or gap = gap0 + (min_ity.size() - gap0).align_to(align.abi) < gap0 + min_ity.size() - gap0 + align.abi = min_ity.size() + align.abi.
ity.size() <= gap. In both cases ity.size() <= gap < min_ity.size() + align.abi, therefore either ity = min_ity or ity.size() < align.abi.
| B(u32), | ||
| } | ||
| // CHECK: %Align64 = type { [0 x i32], i32, [15 x i32] } | ||
| // CHECK: %Align64 = type { [0 x i64], i64, [7 x i64] } |
There was a problem hiding this comment.
So you're actually moving the field? How do you know that won't cause the field sorting to produce worse results?
|
☔ The latest upstream changes (presumably #63998) made this pull request unmergeable. Please resolve the merge conflicts. |
rustbot
added
S-waiting-on-author
JohnCSimon
added
the
S-inactive
9 participants
After pull request #63899.
Try to fit the largest integer in the padding bytes before the fields.