On: How much does Rust's bounds checking cost?

[oconnor663]

I think LLVM is smart enough to optimize regular `for i in 0..stuff.len()` loops into the same assembly as `for i in &stuff` loops in almost all cases. I imagine this sort of "we can tell that i is always less than len" optimization is a big contributor to the low cost of bounds checks. In some large portion of cases where they're not needed, the optimizer can already see that.

[ridiculous_fish → oconnor663]

IME loops with induction variables (integer indexes) often produces better codegen than with iterators. Compare the these two Rust functions for inverting bits: https://rust.godbolt.org/z/cE4vPdbdY

This got improved in Rust 1.65 just this month, but the point stands.

edit: ARM64 compilation is even sillier. https://rust.godbolt.org/z/PEsbeGxWP

[akshaykarthik → ridiculous_fish]

Interestingly enough, with `-C opt-level=3` both functions yield the same assembly.

I wonder if there's some pass that's missing or not done at the lower opt level.

[masklinn → akshaykarthik]

Might be a problem of the number of pass repetitions, where O2 does not rerun the vectorisation after whatever manages to unroll everything but O3 does.

[brundolf → oconnor663]

Yeah, I wondered about those too. Less straightforward than pure iterator usage but still plausible