Optimize enum layout

[mahkoh]

fn main() {
    enum X { A, B(u8, uint) }
    enum Y { A, B(uint, u8) }
    assert_eq!(std::mem::size_of::<X>(), 16);
    assert_eq!(std::mem::size_of::<Y>(), 24);
}

[frewsxcv]

Interestingly:

fn main() {
    enum X { A, B(u64, u32) }
    enum Y { A, B(u32, u64) }
    assert_eq!(std::mem::size_of::<X>(), 24);
    assert_eq!(std::mem::size_of::<Y>(), 16);
}

I don't know much about llvm, but I would maybe guess some sort of optimization is going on

[Diggsey]

@frewsxcv Those sizes are what one would expect without any kind of optimisation:
X => 1 byte discriminator + 7 bytes padding for field alignment + 8 bytes for u64 + 4 bytes for u32 + 4 bytes padding for struct alignment = 24 bytes total
Y => 1 byte discriminator + 3 bytes padding for field alignment + 4 bytes for u32 + 8 bytes for u64 = 16 bytes total

[frewsxcv]

@Diggsey Awesome, thanks for the clarification 👍 . I'm not experienced in this lower level way of thinking

[frewsxcv]

@Diggsey also, for X, 1 + 7 + 8 + 4 != 24

[frewsxcv]

Nevermind, missed that last + 4

[Diggsey]

NP, you had me worried for a second there...

[huonw]

@mahkoh to be clear, are you suggesting that the compiler should reorder fields to try to make enums as small as possible?

[mahkoh]

Isn't that the point behind leaving the layout undefined?

[huonw]

I'll take that as a yes. Thanks for clarifying.

[mahkoh]

This particular enum can be optimized without reordering fields. Reordering is just one method to find an unused byte.

[kmcallister]

Reordering is just one method to find an unused byte.

Some of which we should only do with #[repr(packed)].