Obvious bounds checks don't get optimized unless I add a if+panic

[elichai]

I'm writing code to rank a matrix and the compiler doesn't see it can remove bounds checks even though it's obvious.
But if I add a check on the index the compiler can then remove the bounds checks.
The minimal code to reproduce it:

pub fn compute_rank(mat_float: [[f64; 64]; 64]) -> usize {
    const EPS: f64 = 1e-9;
    let row_selected = [false; 64];
    for i in 0..64 {
        for j in 0..64 {
            if !row_selected[j] && mat_float[j][i] > EPS {
                break;
            }
        }
    }
    0
}

godbolt: https://godbolt.org/z/xjhMq3TrY

But when adding an if+panic the bounds checks get removed: (even though the assume is obvious)

pub fn compute_rank(mat_float: [[f64; 64]; 64]) -> usize {
    const EPS: f64 = 1e-9;
    let row_selected = [false; 64];
    for i in 0..64 {
        if i >= 64 {panic!("This should never happen")}
        for j in 0..64 {
            if !row_selected[j] && mat_float[j][i] > EPS {
                break;
            }
        }
    }
    0
}

https://godbolt.org/z/Ecvd4e9nM

(The full code is obviously longer and contain more bounds checks that all get eliminated by this check)

(Originally I used unreachable_unchecked() for this but somehow even an if+panic solves this)

[leonardo-m]

Despite Rust is a system language, its handling of loops is still rather broken. Here LLVM removes all bound tests:

pub fn compute_rank(mat_float: [[f64; 64]; 64]) -> usize {
    const EPS: f64 = 1e-9;
    let row_selected = [false; 64];
    let mut i = 0;
    while i < 64 {
        for j in 0 .. 64 {
            if !row_selected[j] && mat_float[j][i] > EPS {
                break;
            }
        }
        i += 1;
    }
    0
}

Other loop problems (that lead to significant inefficiencies for computational kernels) are when you use ..= instead of .., and when you use a step_by especially when the step value isn't a compile-time constant. So often using a while loop like this is the way to go in reasonably efficient Rust code. And this is sad. C language is better regarding for loops.

[the8472]

Using range.for_each instead for _ in range also optimizes better, especially for inclusive ranges.

For inclusive ranges that's because the external iteration version has to keep track of the exhaustion state while the exclusive range can use the end element to indicate exhaustion.

For exclusive ranges it is strange that for_each works better here because there's no dedicated fold impl for exclusive ranges and the default implementation isn't all that different than the for loop desugaring (although less verbose than the latter) so they should optimize the same.

[MSxDOS]

I also encountered cases where adding an assertion removed both the unnecessary bounds check and the assertion itself, which is kinda weird.

This whole function should be optimized to just return zero anyways, and it is, up to rust 1.54 and only if the i < 64 assertion is present.

[workingjubilee]

Are we sure this is not a duplicate of #30112, #39220, #41789, #51709, #55147, #58388, #71066, #71935, #72462, #80075, #81253, #81432, or #84314? It's fine if it isn't, even, I am just trying to figure out which ones of these are unique.

[KamilaBorowska]

This issue appears to be fixed in Rust 1.72.0.

[workingjubilee]

Thank you! Closing this.