Transitioning to superset enum variant causes unnecessary copy

[erin-desu]

When I have an enum whose variants are superset of the previous ones, transitioning to the superset variant unnecessarily copies the entire variant instead of just changing discriminant and copying the new data over.

https://rust.godbolt.org/z/Mjeq3d4MW

Example

use std::mem::{ManuallyDrop, take};

type Param = ManuallyDrop<String>;

#[derive(Default)]
enum State {
    #[default]
    None,
    A([Param; 16]),
    B([Param; 16], Param),
    C([Param; 16], Param, Param),
}

impl State {
    #[unsafe(no_mangle)]
    fn transition(&mut self, param: Param) {
        let taken = take(self);
        *self = match taken {
            Self::None | Self::C { .. } => Self::None,
            Self::A(a) => Self::B(a, param),
            Self::B(a, b) => Self::C(a, b, param),
        };
    }
}

[bjorn3]

The [Param; 16] is at offset 8 for variants A and B, while it is at offset 0 for variant C. Offset 0 is also used as the location of the discriminant. Basically if 64bit integer at offset 0 has the value 9223372036854775808 it is None, if 9223372036854775809 it is A, if 9223372036854775810 it is B and if anything else it is C. The only way rustc could make the [Param; 16] have a consistent location would be either use a different field for the niche or to stop using niche filling entirely for this enum.

https://rust.godbolt.org/z/c1G6j9o4r

[the8472]

Enum layout currently is somewhat myopic, it computes one for each variant separately. A more holistic approach could try to look for patterns where one variant is a prefix of another, but making that efficient for enums with lots of variants would increase complexity further.

[the8472]

The [Param; 16] is at offset 8 for variants A and B,

I suspect this is a poor interaction of

• niche-bias (we try to get the niche to the start or the end of the struct)
• the myopic variant layout calculation mentioned above
• that we only track the largest_niche and since everything in those variants is the same it might choose poorly

[hanna-kruppe]

Besides the complexity, an optimization that tries to put similar fields at similar offsets across variants would also (sometimes) conflict with the goal of minimizing size. And compatible layout doesn’t necessarily mean LLVM will optimize match-and-reassemble into the in-place update OP would like to see. So it may never be a very predictable/reliable optimization.