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

Alias analysis sometimes too strict for SubArrays #54621

Closed
termi-official opened this issue May 29, 2024 · 1 comment · Fixed by #54624
Closed

Alias analysis sometimes too strict for SubArrays #54621

termi-official opened this issue May 29, 2024 · 1 comment · Fixed by #54624
Labels
arrays [a, r, r, a, y, s] performance Must go faster

Comments

@termi-official
Copy link

Hi everyone,

I hit some very weird corner case where I create views on vectors where the index set is a vector. This causes some troubles for alias analysis. A minimal example which should be efficient to perform due to the shared index set is to copy the values from one subvector to another one.

using BenchmarkTools

indices = [1,3]
a = rand(3)
av = @view a[indices]
b = rand(3)
bv = @view b[indices]
@btime copyto!($av, $bv) # 2 allocations

av = @view a[[1,3]]
bv = @view b[[1,3]]
@btime copyto!($av, $bv) # 0 allocations

I discovered this on Julia 1.10, but from going down the call graph I also assume that it is reproducible with older versions too, because it can be tracked down to mightalias returning true for the first case.

@dkarrasch dkarrasch added the arrays [a, r, r, a, y, s] label May 29, 2024
@oscardssmith oscardssmith added the performance Must go faster label May 31, 2024
fredrikekre pushed a commit that referenced this issue Jun 5, 2024
This avoids returning false positives where only the indices are shared.
As the indices are not mutated by array assignments (and are explicitly
warned against mutation in general), we can ignore the case where _only_
the indices are aliasing.

Fix #54621
@termi-official
Copy link
Author

Thanks for the quick fix!

KristofferC pushed a commit that referenced this issue Jun 7, 2024
This avoids returning false positives where only the indices are shared.
As the indices are not mutated by array assignments (and are explicitly
warned against mutation in general), we can ignore the case where _only_
the indices are aliasing.

Fix #54621

(cherry picked from commit 97bf148)
KristofferC pushed a commit that referenced this issue Jun 7, 2024
This avoids returning false positives where only the indices are shared.
As the indices are not mutated by array assignments (and are explicitly
warned against mutation in general), we can ignore the case where _only_
the indices are aliasing.

Fix #54621

(cherry picked from commit 97bf148)
KristofferC pushed a commit that referenced this issue Jul 24, 2024
This avoids returning false positives where only the indices are shared.
As the indices are not mutated by array assignments (and are explicitly
warned against mutation in general), we can ignore the case where _only_
the indices are aliasing.

Fix #54621

(cherry picked from commit 97bf148)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] performance Must go faster
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants