Skip to content

Counter in slice iter fails to eliminate bounds check #132557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
clubby789 opened this issue Nov 3, 2024 · 1 comment
Open

Counter in slice iter fails to eliminate bounds check #132557

clubby789 opened this issue Nov 3, 2024 · 1 comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@clubby789
Copy link
Contributor

The following code (somewhat extracted from #126425) includes an unreachable bounds check panic

pub fn getnonzero(buf: &[u8; 128]) -> &[u8] {
    let mut curr = 0;
    for n in buf.iter() {
        if *n == 0 { break; }
        curr += 1;
    }
    &buf[..curr]
}

https://godbolt.org/z/vzooGexnj

This bounds check can be eliminated: Alive2

This also occurs with reverse iteration (like in the original) and iterating 0..buf.len() instead of direct slice iteration. Lowering the slice length to the point where the loop is fully unrolled does eliminate this, but the exact number depends on the specific code.

@clubby789 clubby789 added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. labels Nov 3, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 3, 2024
@clubby789 clubby789 removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 3, 2024
@jieyouxu jieyouxu added C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Nov 3, 2024
@clubby789
Copy link
Contributor Author

Another similar example: Godbolt
With N < 75, the assert is optimized out

@saethlin saethlin added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants