optimizer: simple array SROA #43909

aviatesk · 2022-01-24T07:00:00Z

Implements a simple Julia-level array allocation elimination on top of #43888.

julia> code_typed((String,String)) do s, t
           a = Vector{Base.RefValue{String}}(undef, 2)
           a[1] = Ref(s)
           a[2] = Ref(t)
           return a[1][]
       end

diff --git a/master b/pr
index 9c8da14380..5b63d08190 100644
--- a/master
+++ b/pr
@@ -1,11 +1,4 @@
 1-element Vector{Any}:
  CodeInfo(
-1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Base.RefValue{String}}, svec(Any, Int64), 0, :(:ccall), Vector{Base.RefValue{String}}, 2, 2))::Vector{Base.RefValue{String}}
-│   %2 = %new(Base.RefValue{String}, s)::Base.RefValue{String}
-│        Base.arrayset(true, %1, %2, 1)::Vector{Base.RefValue{String}}
-│   %4 = %new(Base.RefValue{String}, t)::Base.RefValue{String}
-│        Base.arrayset(true, %1, %4, 2)::Vector{Base.RefValue{String}}
-│   %6 = Base.arrayref(true, %1, 1)::Base.RefValue{String}
-│   %7 = Base.getfield(%6, :x)::String
-└──      return %7
+1 ─     return s
 ) => String

Still this array SROA handle is very limited and able to handle only
trivial examples (though I confirmed this version already eliminates
few array allocations during sysimg build).
For those who interested, I added some discussions on array optimization
here.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (#43888), array SROA (#43909), `mutating_arrayfreeze` optimization (#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA in this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA in this commit, and then merge the depending PRs built on top of this commit like #43888, #43909 and #42465 This commit simply defines and runs EA inside Julia base compiler and enables the existing test suite with it. In this commit, we just run EA before inlining to generate IPO cache. The depending PRs, EA will be reran after inlining to be used for various local optimizations.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (#43888), array SROA (#43909), `mutating_arrayfreeze` optimization (#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA in this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA in this commit, and then merge the depending PRs built on top of this commit like #43888, #43909 and #42465 This commit simply defines and runs EA inside Julia base compiler and enables the existing test suite with it. In this commit, we just run EA before inlining to generate IPO cache. The depending PRs, EA will be invoked again after inlining to be used for various local optimizations.

@allocated

Enhances SROA of mutables using the novel Julia-level escape analysis (on top of #43800): 1. alias-aware SROA, mutable ϕ-node elimination 2. `isdefined` check elimination 3. load-forwarding for non-eliminable but analyzable mutables --- 1. alias-aware SROA, mutable ϕ-node elimination EA's alias analysis allows this new SROA to handle nested mutables allocations pretty well. Now we can eliminate the heap allocations completely from this insanely nested examples by the single analysis/optimization pass: ```julia julia> function refs(x) (Ref(Ref(Ref(Ref(Ref(Ref(Ref(Ref(Ref(Ref((x))))))))))))[][][][][][][][][][] end refs (generic function with 1 method) julia> refs("julia"); @allocated refs("julia") 0 ``` EA can also analyze escape of ϕ-node as well as its aliasing. Mutable ϕ-nodes would be eliminated even for a very tricky case as like: ```julia julia> code_typed((Bool,String,)) do cond, x # these allocation form multiple ϕ-nodes if cond ϕ2 = ϕ1 = Ref{Any}("foo") else ϕ2 = ϕ1 = Ref{Any}("bar") end ϕ2[] = x y = ϕ1[] # => x return y end 1-element Vector{Any}: CodeInfo( 1 ─ goto #3 if not cond 2 ─ goto #4 3 ─ nothing::Nothing 4 ┄ return x ) => Any ``` Combined with the alias analysis and ϕ-node handling above, allocations in the following "realistic" examples will be optimized: ```julia julia> # demonstrate the power of our field / alias analysis with realistic end to end examples # adapted from http://wiki.luajit.org/Allocation-Sinking-Optimization#implementation%5B abstract type AbstractPoint{T} end julia> struct Point{T} <: AbstractPoint{T} x::T y::T end julia> mutable struct MPoint{T} <: AbstractPoint{T} x::T y::T end julia> add(a::P, b::P) where P<:AbstractPoint = P(a.x + b.x, a.y + b.y); julia> function compute_point(T, n, ax, ay, bx, by) a = T(ax, ay) b = T(bx, by) for i in 0:(n-1) a = add(add(a, b), b) end a.x, a.y end; julia> function compute_point(n, a, b) for i in 0:(n-1) a = add(add(a, b), b) end a.x, a.y end; julia> function compute_point!(n, a, b) for i in 0:(n-1) a′ = add(add(a, b), b) a.x = a′.x a.y = a′.y end end; julia> compute_point(MPoint, 10, 1+.5, 2+.5, 2+.25, 4+.75); julia> compute_point(MPoint, 10, 1+.5im, 2+.5im, 2+.25im, 4+.75im); julia> @allocated compute_point(MPoint, 10000, 1+.5, 2+.5, 2+.25, 4+.75) 0 julia> @allocated compute_point(MPoint, 10000, 1+.5im, 2+.5im, 2+.25im, 4+.75im) 0 julia> compute_point(10, MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75)); julia> compute_point(10, MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im)); julia> @allocated compute_point(10000, MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75)) 0 julia> @allocated compute_point(10000, MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im)) 0 julia> af, bf = MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75); julia> ac, bc = MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im); julia> compute_point!(10, af, bf); julia> compute_point!(10, ac, bc); julia> @allocated compute_point!(10000, af, bf) 0 julia> @allocated compute_point!(10000, ac, bc) 0 ``` 2. `isdefined` check elimination This commit also implements a simple optimization to eliminate `isdefined` call by checking load-fowardability. This optimization may be especially useful to eliminate extra allocation involved with a capturing closure, e.g.: ```julia julia> callit(f, args...) = f(args...); julia> function isdefined_elim() local arr::Vector{Any} callit() do arr = Any[] end return arr end; julia> code_typed(isdefined_elim) 1-element Vector{Any}: CodeInfo( 1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Any}, svec(Any, Int64), 0, :(:ccall), Vector{Any}, 0, 0))::Vector{Any} └── goto #3 if not true 2 ─ goto #4 3 ─ $(Expr(:throw_undef_if_not, :arr, false))::Any 4 ┄ return %1 ) => Vector{Any} ``` 3. load-forwarding for non-eliminable but analyzable mutables EA also allows us to forward loads even when the mutable allocation can't be eliminated but still its fields are known precisely. The load forwarding might be useful since it may derive new type information that succeeding optimization passes can use (or just because it allows simpler code transformations down the load): ```julia julia> code_typed((Bool,String,)) do c, s r = Ref{Any}(s) if c return r[]::String # adce_pass! will further eliminate this type assert call also else return r end end 1-element Vector{Any}: CodeInfo( 1 ─ %1 = %new(Base.RefValue{Any}, s)::Base.RefValue{Any} └── goto #3 if not c 2 ─ return s 3 ─ return %1 ) => Union{Base.RefValue{Any}, String} ``` --- Please refer to the newly added test cases for more examples. Also, EA's alias analysis already succeeds to reason about arrays, and so this EA-based SROA will hopefully be generalized for array SROA as well.

Implements a simple Julia-level array allocation elimination on top of #43888. ```julia julia> code_typed((String,String)) do s, t a = Vector{Base.RefValue{String}}(undef, 2) a[1] = Ref(s) a[2] = Ref(t) return a[1][] end ``` ```diff diff --git a/master b/pr index 9c8da14380..5b63d08190 100644 --- a/master +++ b/pr @@ -1,11 +1,4 @@ 1-element Vector{Any}: CodeInfo( -1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Base.RefValue{String}}, svec(Any, Int64), 0, :(:ccall), Vector{Base.RefValue{String}}, 2, 2))::Vector{Base.RefValue{String}} -│ %2 = %new(Base.RefValue{String}, s)::Base.RefValue{String} -│ Base.arrayset(true, %1, %2, 1)::Vector{Base.RefValue{String}} -│ %4 = %new(Base.RefValue{String}, t)::Base.RefValue{String} -│ Base.arrayset(true, %1, %4, 2)::Vector{Base.RefValue{String}} -│ %6 = Base.arrayref(true, %1, 1)::Base.RefValue{String} -│ %7 = Base.getfield(%6, :x)::String -└── return %7 +1 ─ return s ) => String ``` Still this array SROA handle is very limited and able to handle only trivial examples (though I confirmed this version already eliminates few array allocations during sysimg build). For those who interested, I added some discussions on array optimization [here](https://aviatesk.github.io/EscapeAnalysis.jl/dev/#EA-Array-Analysis).

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (#43888), array SROA (#43909), `mutating_arrayfreeze` optimization (#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA in this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA in this commit, and then merge the depending PRs built on top of this commit like #43888, #43909 and #42465 This commit simply defines and runs EA inside Julia base compiler and enables the existing test suite with it. In this commit, we just run EA before inlining to generate IPO cache. The depending PRs, EA will be invoked again after inlining to be used for various local optimizations.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (JuliaLang#43888), array SROA (JuliaLang#43909), `mutating_arrayfreeze` optimization (JuliaLang#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA in this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA in this commit, and then merge the depending PRs built on top of this commit like JuliaLang#43888, JuliaLang#43909 and JuliaLang#42465 This commit simply defines and runs EA inside Julia base compiler and enables the existing test suite with it. In this commit, we just run EA before inlining to generate IPO cache. The depending PRs, EA will be invoked again after inlining to be used for various local optimizations.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (#43888), array SROA (#43909), `mutating_arrayfreeze` optimization (#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA in this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA in this commit, and then merge the depending PRs built on top of this commit like #43888, #43909 and #42465 This commit simply defines and runs EA inside Julia base compiler and enables the existing test suite with it. In this commit, we just run EA before inlining to generate IPO cache. The depending PRs, EA will be invoked again after inlining to be used for various local optimizations.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (#43888), array SROA (#43909), `mutating_arrayfreeze` optimization (#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA by this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA to Julia Base by this commit, and then merge the depending PRs built on top of this commit later. This commit simply defines EA inside Julia base compiler and enables the existing test suite with it. In this commit we don't run EA at all, and so this commit shouldn't affect Julia-level compilation latency. In the depending PRs, EA will run in two stages: - `IPO EA`: run EA on pre-inlining state to generate IPO-valid cache - `Local EA`: run EA on post-inlining state to generate local escape information used for various optimizations In order to integrate `IPO EA` with our compilation cache system, this commit also implements a new `CodeInstance.argescapes` field that keeps the IPO-valid cache generated by `IPO EA`.

This commit ports [EscapeAnalysis.jl](https://github.com/aviatesk/EscapeAnalysis.jl) into Julia base. You can find the documentation of this escape analysis at [this GitHub page](https://aviatesk.github.io/EscapeAnalysis.jl/dev/)[^1]. [^1]: The same documentation will be included into Julia's developer documentation by this commit. This escape analysis will hopefully be an enabling technology for various memory-related optimizations at Julia's high level compilation pipeline. Possible target optimization includes alias aware SROA (JuliaLang#43888), array SROA (JuliaLang#43909), `mutating_arrayfreeze` optimization (JuliaLang#42465), stack allocation of mutables, finalizer elision and so on[^2]. [^2]: It would be also interesting if LLVM-level optimizations can consume IPO information derived by this escape analysis to broaden optimization possibilities. The primary motivation for porting EA by this PR is to check its impact on latency as well as to get feedbacks from a broader range of developers. The plan is that we first introduce EA to Julia Base by this commit, and then merge the depending PRs built on top of this commit later. This commit simply defines EA inside Julia base compiler and enables the existing test suite with it. In this commit we don't run EA at all, and so this commit shouldn't affect Julia-level compilation latency. In the depending PRs, EA will run in two stages: - `IPO EA`: run EA on pre-inlining state to generate IPO-valid cache - `Local EA`: run EA on post-inlining state to generate local escape information used for various optimizations In order to integrate `IPO EA` with our compilation cache system, this commit also implements a new `CodeInstance.argescapes` field that keeps the IPO-valid cache generated by `IPO EA`.

ViralBShah · 2024-02-10T18:00:13Z

@aviatesk Should this be closed as old? Or will it be revived?

oscardssmith · 2024-02-10T18:08:04Z

I'm going to go ahead and close since pretty much all of it will require changing now that we have Memory. The good news is it should now be a lot simpler. #52382 is roughly the continuation of this.

aviatesk added the compiler:optimizer Optimization passes (mostly in base/compiler/ssair/) label Jan 24, 2022

aviatesk requested review from Keno, vchuravy and vtjnash January 24, 2022 07:00

aviatesk mentioned this pull request Jan 24, 2022

optimizer: alias-aware SROA #43888

Draft

aviatesk force-pushed the avi/EASROA branch from 619edba to ad727df Compare January 24, 2022 10:01

aviatesk force-pushed the avi/ArraySROA branch 2 times, most recently from 4b513d3 to d41a79d Compare January 24, 2022 11:39

vchuravy requested a review from pchintalapudi January 24, 2022 13:12

aviatesk force-pushed the avi/EASROA branch 4 times, most recently from 7e11637 to ce7dee2 Compare January 25, 2022 09:26

aviatesk force-pushed the avi/ArraySROA branch from d41a79d to 0e31edb Compare January 25, 2022 09:57

aviatesk mentioned this pull request Jan 25, 2022

optimizer: Julia-level escape analysis #43800

Merged

2 tasks

aviatesk force-pushed the avi/ArraySROA branch from 0e31edb to 9fa07fe Compare January 25, 2022 16:24

aviatesk force-pushed the avi/EASROA branch from 458073f to d74352a Compare January 26, 2022 13:25

aviatesk force-pushed the avi/ArraySROA branch from e2438ca to cf74102 Compare January 26, 2022 13:25

aviatesk force-pushed the avi/EASROA branch 2 times, most recently from 976127b to f3550fd Compare January 27, 2022 05:20

aviatesk force-pushed the avi/ArraySROA branch from cf74102 to 612a0e7 Compare January 27, 2022 05:22

aviatesk force-pushed the avi/EASROA branch 2 times, most recently from 2abfdf1 to ae183d8 Compare January 28, 2022 01:49

aviatesk force-pushed the avi/ArraySROA branch from 612a0e7 to 519fd68 Compare January 28, 2022 01:51

aviatesk force-pushed the avi/EASROA branch from ae183d8 to a19cdce Compare February 2, 2022 16:27

aviatesk force-pushed the avi/ArraySROA branch from 519fd68 to 4ac3536 Compare February 2, 2022 16:36

aviatesk force-pushed the avi/EASROA branch from b19c0d2 to ef8f7be Compare February 10, 2022 11:21

aviatesk added 2 commits February 11, 2022 00:27

aviatesk force-pushed the avi/EASROA branch from ef8f7be to 04f2d48 Compare February 10, 2022 15:44

aviatesk force-pushed the avi/ArraySROA branch from 250138a to 7b05508 Compare February 10, 2022 16:17

aviatesk force-pushed the avi/EASROA branch from 04f2d48 to 974891c Compare February 13, 2022 09:58

aviatesk force-pushed the avi/EASROA branch 2 times, most recently from 17c84ff to 325f414 Compare February 14, 2022 15:28

ianatol mentioned this pull request Feb 16, 2022

optimizer: Julia-level escape analysis (rebase) #44195

Closed

aviatesk force-pushed the avi/EASROA branch 2 times, most recently from 9c84ddc to cdef102 Compare March 23, 2022 07:11

aviatesk mentioned this pull request Feb 28, 2023

SROA for array allocation #48808

Open

oscardssmith closed this Feb 10, 2024

giordano deleted the avi/ArraySROA branch February 10, 2024 18:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

optimizer: simple array SROA #43909

optimizer: simple array SROA #43909

aviatesk commented Jan 24, 2022

ViralBShah commented Feb 10, 2024

oscardssmith commented Feb 10, 2024 •

edited

Loading

optimizer: simple array SROA #43909

optimizer: simple array SROA #43909

Conversation

aviatesk commented Jan 24, 2022

ViralBShah commented Feb 10, 2024

oscardssmith commented Feb 10, 2024 • edited Loading

oscardssmith commented Feb 10, 2024 •

edited

Loading