Autovectorization fails if a field follows an array

[EsotericPyramid]

The following code fails to be autovectorized on opt-level=3 despite it being safe to do so:

struct ArrayIter{arr: [i32; 10000],start: usize}

pub fn main() {
    let mut array_iter = ArrayIter{arr: [10; 10000],start: 0};
    let arr_ref = &mut array_iter.arr;
    let start_ref = &mut array_iter.start;
    while *start_ref < 10000 {
        let index = *start_ref;
        *start_ref += 1;
        arr_ref[index] = 100 * arr_ref[index]
    }
    assert_eq!(array_iter.arr,[1000; 10000]);
}

Looking at LLVM pass remarks, it states that

remark: test.rs:7:11: loop not vectorized: value that could not be identified as reduction is used outside the loop
remark: test.rs:7:11: loop not vectorized: could not determine number of loop iterations

neither of which make sense as start_ref should be a reduction and the number of loop iterations can be determined.
As such, I'm guessing that LLVM for some reason thinks that the writes or reads done with array can somehow interact with start_ref in some way when that is clearly impossible.
Additionally, if you manually specify the order of ArrayIter's fields using Repr(C), it does get autovectorized if start comes before arr as seen here. Furthermore, it will also be autovectorized if you add some padding as seen here

[EsotericPyramid]

Additionally, doesn't even require a struct, just putting these fields in a tuple causes this as seen here.
Ordering of tuple still affects whether it is autovectorized, albeit without repr(C).

Furthermore, other values will also break it if stored there as seen here.
This also changes the LLVM pass remarks which now state that

remark: test.rs:11:9: loop not vectorized: unsafe dependent memory operations in loop. Use #pragma loop distribute(enable) to allow loop distribution to attempt to isolate the offending operations into a separate loop
Unknown data dependence. Memory location is the same as accessed at test.rs:4:26