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

Make SROA pass more aggressive #44494

Closed
wants to merge 2 commits into from
Closed

Make SROA pass more aggressive #44494

wants to merge 2 commits into from

Conversation

Keno
Copy link
Member

@Keno Keno commented Mar 7, 2022

  • Avoid inserting unnecessary PhiNodes that confuse SROA (needs domtree)
  • Allow DCE to delete unused newly inserted nodes

@ianatol I think this one probably needs to go through PkgEval. It's pretty easy to end up in situations here where the use counts are off, which causes it to delete used statements. Could you take this one over, do PkgEval, add some tests, etc?

Keno added a commit that referenced this pull request Mar 7, 2022
With #44494, this cuts about 22M allocations (out of 59M) from the
compiler benchmark in #44492. Without #44494, it still reduces
the number of allocations, but not as much. This was originally
optimized in 100666b, but the
behavior of our compiler has changed to allow inling the Tuple{UseRef, Int}
into the outer struct, forcing a reallocation on every iteration.
@oscardssmith oscardssmith added the compiler:latency Compiler latency label Mar 7, 2022
ianatol pushed a commit to ianatol/julia that referenced this pull request Mar 15, 2022
With JuliaLang#44494, this cuts about 22M allocations (out of 59M) from the
compiler benchmark in JuliaLang#44492. Without JuliaLang#44494, it still reduces
the number of allocations, but not as much. This was originally
optimized in 100666b, but the
behavior of our compiler has changed to allow inling the Tuple{UseRef, Int}
into the outer struct, forcing a reallocation on every iteration.
Keno added a commit that referenced this pull request Mar 15, 2022
With #44494, this cuts about 22M allocations (out of 59M) from the
compiler benchmark in #44492. Without #44494, it still reduces
the number of allocations, but not as much. This was originally
optimized in 100666b, but the
behavior of our compiler has changed to allow inling the Tuple{UseRef, Int}
into the outer struct, forcing a reallocation on every iteration.
@Keno
Copy link
Member Author

Keno commented Mar 21, 2022

Merged as #44557

@Keno Keno closed this Mar 21, 2022
@vchuravy vchuravy deleted the kf/moresroa branch March 21, 2022 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:latency Compiler latency
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants