Skip to content

Potential missed optimization with mutable noalias #85570

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
veber-alex opened this issue May 21, 2021 · 3 comments
Open

Potential missed optimization with mutable noalias #85570

veber-alex opened this issue May 21, 2021 · 3 comments
Labels
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.

Comments

@veber-alex
Copy link
Contributor

https://godbolt.org/z/9TY68vcjq

In the above code the methods on the struct that owns the array are not SIMD optimized but the methods on struct which has a reference are SIMD optimized.
On stable or with -Zmutable-noalias=off all methods are not SIMD optimized.

Is this a missed optimization or is there a real difference between owning the array and having a reference?

@veber-alex
Copy link
Contributor Author

@rustbot label +I-slow

@rustbot rustbot added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Jun 5, 2021
@nikic
Copy link
Contributor

nikic commented Jun 5, 2021

I expect the problem here is that self.data[self.ptr] += 1; could overwrite self.ptr. It would be necessary to reason about the range of the induction variable in AA to exclude the possibility.

@veber-alex
Copy link
Contributor Author

Looks like the upgrade to LLVM 16 in Rust 1.70 fixed the first case and it's now SIMD optimized.
However the second method still has a bound check that doesn't exist in version of the code where data is borrowed.

@workingjubilee workingjubilee added the C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such label Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

No branches or pull requests

4 participants