Skip to content
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

Bounds check optimizations are not applied if the accessed slice len is smaller than the upfront checked slice len #69101

Closed
Matthias247 opened this issue Feb 12, 2020 · 2 comments · Fixed by #73362
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. 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

@Matthias247
Copy link
Contributor

When using a loop and checking exact bounds upfront, vectorized instructions are used:

pub fn xorl(a: &[u8], b: &[u8], c: &mut [u8]) {
    let (a_bound, b_bound, c_bound) = (&a[..1024], &b[..1024], &mut c[..1024]);
    for i in 0..1024 {
        c[i] = a[i] ^ b[i];
    }
}

Godbolt

However when the upfront checks actually tests for a bigger slice size, the same optimizations are not applied:

pub fn xorl(a: &[u8], b: &[u8], c: &mut [u8]) {
    let (a_bound, b_bound, c_bound) = (&a[..2048], &b[..2048], &mut c[..2048]);
    for i in 0..1024 {
        c[i] = a[i] ^ b[i];
    }
}

Godbolt

Since slices of size 2048 are always also at least of size 1024, I would expect the generated code to be equivalent.

Meta

rustc --version --verbose:

Happens on nightly as well as 1.40 - as seen in Godbolt

@Matthias247 Matthias247 added the C-bug Category: This is a bug. label Feb 12, 2020
@jonas-schievink jonas-schievink added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. 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. labels Feb 12, 2020
@nikic
Copy link
Contributor

nikic commented Feb 12, 2020

From a quick look, seems like something indvars should be able to handle based on scev. IV dependent condition is known based on loop entry guard.

@the8472
Copy link
Member

the8472 commented Jun 6, 2020

This seems to be fixed with current nightlies.

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 17, 2020
Test that bounds checks are elided when slice len is checked up-front

Closes rust-lang#69101
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 17, 2020
Test that bounds checks are elided when slice len is checked up-front

Closes rust-lang#69101
@bors bors closed this as completed in 7d3238f Jun 19, 2020
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-bug Category: This is a bug. 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

Successfully merging a pull request may close this issue.

4 participants