Optimization regression: array argument somehow produces null check?

[alex]

Minimal reproducer:

#[no_mangle]
pub fn f1(v: [&mut usize; 1]) {
    for x in v {
        *x += 1;
    }
}

Results in:

f1:
        test    rdi, rdi
        je      .LBB0_2
        inc     qword ptr [rdi]
.LBB0_2:
        ret

Rust's semantics don't allow v to ever be NULL! I don't know where the test rdi, rdi is coming from!

This regressed between 1.78 and 1.79.

[saethlin]

Rust's semantics don't allow v to ever be NULL! I don't know where the test rdi, rdi is coming from!

Well, if you look at the MIR for this you can see where the check is coming from: https://rust.godbolt.org/z/zYoT5dhW1. It's from the IntoIter::next call which returns an Option<&mut usize> so of course we need to check the discriminant.

But I think something is deeply wrong here. The LLVM IR for f1 says it takes an i64 argument and that's not right, it should be ptr noalias noundef align 8 dereferenceable(8). We've lost the niche information when lowering to LLVM IR, which is probably why the optimization pipeline fell over.

[saethlin]

Very good find, how did you come across this?

[alex]

I was investigating whether you can do vectorized reference count incrementing, so my starting point was https://rust.godbolt.org/z/P1zKbGf3b.

That itself was downstream of numpy/numpy#28651, and thinking about what perf could be for numpy's object dtype... In short, its @nelhage's fault!

[the8472]

Note that this is an owning array iterator which moves the references into the IntoIter struct first before iterating.
If you use v.iter_mut() you get a slice iterator instead which does optimize.

[scottmcm]

This is similar to #123183 -- it's about this particular ABI not getting parameter attributes that it could.

Getting range(i64 1, 0) on the parameter would also fix this (Demo: https://llvm.godbolt.org/z/5qn8Ed4qz), even if it doesn't turn into ptr nonnull.

---

EDIT: oh, #124533 (comment) looks like another similar case.