Potential Compiler Optimization Issue with &Vec<Vec<T>> vs &[Vec<T>]?

[zhongyi51]

rustc version: 1.78

See Godbolt .

In my understanding, the function that accepts &Vec<Vec> should have the same optimization as the function that accepts &[Vec], because &Vec<Vec> can be turned into &[Vec] by simply calling as_slice() or as_mut_slice().
However, I found that &Vec<Vec> may hinder further vectorization in the nested loop, as shown in the above link.

I am wondering whether this is a compiler bug or an intended action?

[clubby789]

An &Vec<Vec<T>> requires 3 pointer reads to access a T: dereferencing the reference, reading the outer Vecs pointer to get the inner vec, and reading the inner Vecs pointer to access the element
&[Vec<T>] only requires 2 reads - reading the vec from the slice, and reading the element from within that vec
Calling as_slice on &Vec<...> requires 2 reads (reading the pointer and length fields from behind the reference) so it is not a free conversion
https://godbolt.org/z/rYaY4W5sv

In general, you should always accept &[T] rather than &Vec<T> for both performance and ergonomics. There's a Clippy lint explaining the reasoning

[zhongyi51]

@clubby789
Thank you for your response! Indeed, I am curious about how &Vec<Vec> hinders vectorization in the nested loop, rather than the cost of reading &Vec<Vec>.

Here is an example: Godbolt. Even if I manually call as_slice() and as_mut_slice() before the nested loop, the lack of vectorization persists.

I just hope this under-optimization is intentional.

[scottmcm]

The OP moved this to IRLO, so cc https://internals.rust-lang.org/t/potential-compiler-optimization-issue-with-vec-const-t-vs-const-t/20865?u=scottmcm.

I am wondering whether this is a compiler bug or an intended action?

How about neither? It's an imperfection in optimizations, but imperfect optimization in non-canonical code isn't really something I'd call a "bug", even if it's not "intended" either.