Refactor layout to store offsets of fields, not offsets after fields #36904
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
| // FIXME(eddyb) use small vector optimization for the common case. | ||
| pub offset_after_field: Vec<Size> | ||
| /// Offsets for the first byte of each field. | ||
| pub offsets: Vec<Size>, |
There was a problem hiding this comment.
Does eddyb's fixme still apply?
// FIXME(eddyb) use small vector optimization for the common case.
|
@mark-buer The small vector optimization isn't about that struct, it's about avoiding a heap allocation in the compiler itself in some cases. I don't think it's worth it, unless someone adds something to the compiler that can be used in all cases where small vector optimization might be beneficial. |
|
Also, I should clarify: this isn't quite finalized yet. |
| // FIXME(eddyb) use small vector optimization for the common case. | ||
| pub offset_after_field: Vec<Size> | ||
| /// Offsets for the first byte of each field. | ||
| pub offsets: Vec<Size>, |
| /// Offsets for the first byte of each field. | ||
| pub offsets: Vec<Size>, | ||
|
|
||
| min_size: Size, |
There was a problem hiding this comment.
No reason to keep this private and require the accessor.
| self.offset_after_field[index-1] | ||
| } | ||
| assert!(index < self.offsets.len()); | ||
| self.offsets[index] | ||
| } |
There was a problem hiding this comment.
Only reason for this method was the oddity of offset_after_field, direct access to offsets would be better.
| if fields > 1 { | ||
| variant.offset_after_field[fields - 2].bytes() | ||
| variant.offsets[fields - 1].bytes() | ||
| } else { | ||
| 0 | ||
| } |
There was a problem hiding this comment.
This whole thing can be variant.offsets.last().map_or(0, |o| o.bytes()) - and local_prefix_bytes doesn't even need to exist as a separate function.
|
I mixed up the SVO FIXME comments. My bad. Is the small vector optimization anywhere outside layout? It seems to me that the way to fix this is to write something that implements a subset of Vec's API if we want it. |
ahicks92
force-pushed
the
field_offsets_refactor
branch
from
471352c to
9482bce
Compare
|
The first set of review comments should be incorporated. I squashed the history as well, so it's one commit. Think all that's maybe left is formatting. |
|
@bors r+ |
|
📌 Commit 9482bce has been approved by |
Refactor layout to store offsets of fields, not offsets after fields This is the next PR moving us towards being able to reorder struct fields. The old code implicitly stored the offset of the first field. This is inadequate because the first field may no longer be offset 0 in future. This PR refactors `layout` to use a `offsets` vector instead of a `offset_after_field` vector.
This is the next PR moving us towards being able to reorder struct fields.
The old code implicitly stored the offset of the first field. This is inadequate because the first field may no longer be offset 0 in future. This PR refactors
layoutto use aoffsetsvector instead of aoffset_after_fieldvector.