Rust has no type-based aliasing restrictions at all. However, it does require references to be either unique or read-only, which means that it can automatically treat them as noalias (LLVM equivalent of __restrict). Unfortunately, this feature is disabled due to an LLVM bug:

https://github.com/rust-lang/rust/issues/54878

On the other hand, if you use the more idiomatic `&mut [u8]`, that passes the pointer and size by value, so it should avoid the issue.

Edit: Using an iterator also avoids the problem, unlike in C++, because Rust iterators store their bounds within the iterator itself rather than calling iterable.end() on each iteration.

Regardless of what exactly rustc does right now, in the future Rust's strict aliasing rules will basically ensure Rust does this optimization in every possible case, because Rust reasons at compile time to ensure no mutable references ever alias. Things have been held up for a while on this LLVM bug, though[0].

[0] https://github.com/rust-lang/rust/issues/54878

Last I heard there's a fair chance that this might be implemented at the MIR level instead, allowing it to be unblocked from the LLVM bug.

To answer both my own questions. Rust does not seem to have this same problem: https://godbolt.org/z/JpwcRN

But iterating over the loop with .iter_mut is different than iterating over 0..v.len(), which is interesting.

I'm guessing its bounds-checking, though replacing v[i] += 1 by `*v.get_unchecked_mut(i) += 1` generates yet another bit of code (it seems to somewhat unroll the loop but stops there).

Also you can use `-C target_cpu=native` and get AVX512 instructions on godbolt's.

rustc also doesn't vectorize it?

It does if you use iterators as totalperspectiv did in their alternate version https://godbolt.org/z/JpwcRN

Because Rust bounds-checks indexes, which likely breaks LLVM's vectorisation (you'd have to reimplement vectorisation & vectorised bounds-checking in MIR for it to work I guess e.g. bounds-check the entire chunk before applying the vectorised operation).