The compiler looses vector capacity information

[MSxDOS]

In this example:

pub fn test() -> Vec<u32> {
    let mut vec = Vec::with_capacity(3);
    let mut i = 0;
    while i < 3 {
        vec.push(32);
        i += 1;
    }
    vec
}

the compiler produces sub-optimal assembly.
https://rust.godbolt.org/z/1T3Knodn8

[nikic]

Don't know what role the MIR opts play here, but on the LLVM side this looks like a phase ordering issue. The final IR has:

  %10 = bitcast i64* %4 to <2 x i64>*
  store <2 x i64> <i64 3, i64 2>, <2 x i64>* %10, align 8
  %_6.idx.val.i.2 = load i64, i64* %4, align 8
  %_3.i.2 = icmp eq i64 %_6.idx.val.i.2, 2

The load can be load store forwarded to 3 and everything else folds from there. A sequence of -gvn -simplifycfg -sroa does it.

[nikic]

Took a while to root cause this, but should be fixed by llvm/llvm-project@3fedaf2. The issue was that GVN did not fully fold the function because available loads were materialized suboptimally, leading to unnecessary poisoning of MDA cache entries.

https://reviews.llvm.org/D98114 would also fix fix this case, though it's arguably more of a workaround.

[nikic]

I'm not completely sure what I'm supposed to be looking for here, but I think this has not been fixed by the LLVM 13 upgrade. It looks like the IR substantially changed in 1.53 and the goal now is presumably to eliminate the branch that contains the do_reserve_and_handle call.

[MSxDOS]

It wasn't fixed by LLVM 13, tested locally as the compiler on godbolt is outdated.

It fails to see that self.len == self.buf.capacity() inside push can't be true in the first place.
Adding

if vec.len() == vec.capacity() {
    unsafe { std::hint::unreachable_unchecked() }
}

in the beginning of the loop removes the reserve branch entirely.

[nikic]

Principally, a combination of loop load PRE and SCCP should be able to handle this. However, loop load PRE will currently fail for two reasons: First, the clobbering instruction (do_reserve_and_handle) is an invoke terminator, which would need edge splitting support in loop load PRE. Second, we don't have a guarantee that the call won't free the vec. The second issue is the more problematic one.

[MSxDOS]

The example now produces good assembly if the loop gets unrolled (possibly improved by #91352), no change otherwise.