> 'We should do what C does.
Agreed, I am going to change this on the x64 branch to always use 32-bits for
the variant ID. There is an existing issue #792 that is relevant. I just
added the following comment:
In general, I think tags should be laid out as follows (this is fairly close to
what the current code does):
- No data: just like an enum.
- Only one variant: just like that variant's data
- Multiple variants with data:
struct Tag {
unsigned variant_id;
union { variant_1, variant_2, variant_3 } data;
}
where variant_N stands in for the translation of the data types.
The tricky case of course is with generic types. For something like
tag option<T> { none; some(val: T); }
where is the data located? That depends on the type of T and its corresponding
alignment restrictions. I am not clear on how the current dynamic
shape-walking code (GEP-tuple-like, Shape.h, and friends) handles this kind of
dynamic alignment. I could see an argument for using a pessimistic alignment
(i.e., maximally align the data in tags always), but that seems to waste a lot
of space, since the maximal reasonable alignment is probably 16 bytes (vector
data), and you only NEED 4 bytes (for the variant ID).
For reference, the current behavior is:
- No data: unsigned long variant_id
- Only one variant: use a char[X] array where X is the size of the variant
- Multiple variants: struct Tag { unsigned long variant_id; char[X] data; }
where X is the size of the largest variant
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
