Open ericlagergren opened 1 month ago
@rustbot label +A-codegen +C-optimization +T-compiler +I-slow -needs-triage
From a quick glance at the IR it looks like the bounds checks exist for both in MIR but get removed before the IR, so maybe mir opts gets one but not the other? Cc @rust-lang/wg-mir-opt if somebody wants to take a closer look.
The bounds checks of has_bce
are eliminated in LLVM InstCombine
: https://godbolt.org/z/38EaT1n73. IIUC, mir-opt currently does not perform similar optimizations (e.g. CorrelatedValuePropagationPass). Or rather, some range analysis optimizations.
@rustbot label +A-LLVM
May I point that the code shown is summing upto index 0 but not index 0, which I think is the reason why there's a bound check.
May I point that the code shown is summing upto index 0 but not index 0, which I think is the reason why there's a bound check.
Why would that cause a bounds check?
It should be trivial for the compiler to prove that 0 < i < s.len()
and elide the bounds checks.
I'm saying that a break after the index update is causing a bound check
// This code is equivalent to the first snippet
// And also causes a bound check instruction to be present in the assembly
loop {
sum += v[i];
i -= 1;
if i == 0 {
break;
}
}
where as, a break before the index update is not causing a bound check
loop {
sum += v[i];
if i == 0 {
break;
}
i -= 1;
}
On Rust 1.79.0.
https://godbolt.org/z/xxjKd5anW
The compiler should be able to elide the bounds check for
v[i]
sincei
is always in [0, v.len()-1].