vec![None; 1024] randomly gets vectorized or not

[frankdavid]

I want to initialize a large Vec<Option<i32>> with None.

pub fn vec_none() -> Vec<Option<i32>> {
    vec![None; 1024]
}

Compiling with Rust 1.66 -C opt-level=3 -C target-cpu=skylake generates mov instructions.

However, after initializing with Some(...) the code gets vectorized as expected:

pub fn vec_some() -> Vec<Option<i32>> {
    vec![Some(42); 1024]
}

The generated assembly contains vmovups instructions.

Now, the weird thing is that if I have both functions in the same file, both get vectorized.

See this demonstration. As long asvec_some() is commented out, vec_none() is not vectorized. As soon as you remove the comment, both functions are vectorized.

[scottmcm]

Easiest fix for Option<i32> specifically would be to update https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/alloc/vec/is_zero/trait.IsZero.html, I think.

We don't guarantee a layout for it, but internally for optimizations I think we'd be safe doing this.

(We can put some tests like const _OPTION_I32_IS_VALID_FROM_ZEROS: Option<i32> = unsafe { crate::mem::zeroed() }; in non-public stuff to help double-check it.)

[frankdavid]

When Option<T> is None, couldn't the T part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if None sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what T is? Or if the discriminator is represented with a non-zero value, couldn't the whole data structure be filled up with that value (or just left unitialized depending on which is faster)?

[joboet]

When Option<T> is None, couldn't the T part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if None sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what T is?

Unfortunately not, because there can be other niches than 0. For instance, None::<File> has the value 0xffff_ffff on Unix platforms.

[frankdavid]

Can we at least assume that two None::<T>-s will always have the same bytes in memory for any fixed T? If so, couldn't we vectorize filling up the Vec with those bytes?

[clubby789]

I think similar to #101685. iirc the main issue is that LLVM's InstCombine removes the store undef instructions before reaching the passes that could use this information to optimize - at this point, it generally becomes a series of stores with gaps between which LLVM no longer knows can be written to freely.

[scottmcm]

Can we at least assume that two None::<T>-s will always have the same bytes in memory for any fixed T?

No, because something like None::<u32> is half undef, where "the same" isn't a meaningful question.

couldn't we always zero out the entire memory no matter what T is?

That's exactly what I mention IsZero for -- you can use that to check that it's a value where it would be legal to zero out the whole thing, and if that function returns true then vec! uses a zeroing allocator instead of the Vec needing initialize the memory.