optimizer: Julia-level escape analysis #43800

aviatesk · 2022-01-13T20:25:23Z

This commit ports EscapeAnalysis.jl into Julia base.
You can find the documentation of this escape analysis at this GitHub page¹.

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².

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 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.

IPO cache generation
improve performance (reduce additional allocations to ~105% or such)

The same documentation will be included into Julia's developer
documentation by this commit. ↩
It would be also interesting if LLVM-level optimizations can consume
IPO information derived by this escape analysis to broaden
optimization possibilities. ↩

aviatesk · 2022-01-13T20:46:33Z

@nanosoldier runtests(ALL, vs = ":master")

nanosoldier · 2022-01-14T05:38:11Z

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

KristofferC · 2022-01-14T08:21:22Z

@nanosoldier runtests(["AdvancedHMC", "Cambrian", "DelayDiffEq", "Evolutionary", "FastFloat16s", "GalacticOptim", "HydrophoneCalibrations", "ITensors", "IonSim", "LoopVectorization", "MatrixPencils", "MemPool", "MetaArrays", "NarrativeTest", "POMDPPolicies", "Pfam", "PotentialFlow", "Qaintessent", "QuadEig", "RuntimeGeneratedFunctions", "SparseDiffTools", "SpatialJackknife", "StochasticPrograms", "SymbolicRegression", "VoronoiGraph", "WavePropBase"], vs = ":master")

vchuravy · 2022-01-14T13:12:00Z

base/compiler/optimize.jl

+
+const IR_FLAG_NULL        = 0x00
+# This statement is marked as @inbounds by user.
+# Ff replaced by inlining, any contained boundschecks may be removed.


vchuravy · 2022-01-14T13:12:42Z

base/compiler/optimize.jl

+# If this is not set, all the uses are (statically) dominated by the defs.
+# In particular, if a slot has `AssignedOnce && !StaticUndef`, it is an SSA.
+const SLOT_STATICUNDEF  = 1 # slot might be used before it is defined (structurally)
+const SLOT_ASSIGNEDONCE = 16 # slot is assigned to only once


Can we also do 0x01 << 0

base/compiler/ssair/EscapeAnalysis/EAUtils.jl

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

nanosoldier · 2022-01-14T23:30:16Z

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

ianatol · 2022-01-17T23:54:59Z

base/compiler/optimize.jl

+const IR_FLAG_EFFECT_FREE = 0x01 << 4
+
+# known to be always effect-free (in particular nothrow)
+const _PURE_BUILTINS = Any[tuple, svec, ===, typeof, nfields]


Does this usage of typeof in ImmutableArrays PR have relevance / problems here?
https://github.com/JuliaLang/julia/pull/42465/files#diff-b6cb5d410b973b5987bc13b1eba0f156fcaece59cfbd6cb12ac503ff44fd13caR1696-R1698

I know there was prior conversation about that kind of usage being purity-violating

The primary concern at the comment was the use of jl_set_typeof and not uses of typeof queries.
Basically the runtime system may have made some assumptions based on type of already allocated objects, and that use of jl_set_typeof (after allocating object) might cause some problem.

base/compiler/ssair/EscapeAnalysis/EAUtils.jl

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

@allocated

Unleashes the potential for 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 non-escaping 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 powerful alias analysis and ϕ-node handling, the following realistic examples will be fully 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) add (generic function with 1 method) 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 compute_point (generic function with 2 methods) 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 compute_point (generic function with 2 methods) 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 compute_point! (generic function with 1 method) 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> @test @allocated(compute_point(MPoint, 10000, 1+.5, 2+.5, 2+.25, 4+.75)) == 0 Test Passed julia> @test @allocated(compute_point(MPoint, 10000, 1+.5im, 2+.5im, 2+.25im, 4+.75im)) == 0 Test Passed 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> @test @allocated(compute_point(10000, MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75))) == 0 Test Passed julia> @test @allocated(compute_point(10000, MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im))) == 0 Test Passed 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> @test @allocated(compute_point!(10000, af, bf)) == 0 Test Passed julia> @test @allocated(compute_point!(10000, ac, bc)) == 0 Test Passed ``` 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 non-escaping 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.

@allocated

Unleashes the potential for 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 non-escaping 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 powerful alias analysis and ϕ-node handling, the following realistic examples will be fully 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) add (generic function with 1 method) 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 compute_point (generic function with 2 methods) 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 compute_point (generic function with 2 methods) 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 compute_point! (generic function with 1 method) 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> @test @allocated(compute_point(MPoint, 10000, 1+.5, 2+.5, 2+.25, 4+.75)) == 0 Test Passed julia> @test @allocated(compute_point(MPoint, 10000, 1+.5im, 2+.5im, 2+.25im, 4+.75im)) == 0 Test Passed 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> @test @allocated(compute_point(10000, MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75))) == 0 Test Passed julia> @test @allocated(compute_point(10000, MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im))) == 0 Test Passed 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> @test @allocated(compute_point!(10000, af, bf)) == 0 Test Passed julia> @test @allocated(compute_point!(10000, ac, bc)) == 0 Test Passed ``` 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 non-escaping 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.

@allocated

Unleashes the potential for 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 non-escaping 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 powerful alias analysis and ϕ-node handling, the following realistic examples will be fully 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) add (generic function with 1 method) 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 compute_point (generic function with 2 methods) 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 compute_point (generic function with 2 methods) 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 compute_point! (generic function with 1 method) 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> @test @allocated(compute_point(MPoint, 10000, 1+.5, 2+.5, 2+.25, 4+.75)) == 0 Test Passed julia> @test @allocated(compute_point(MPoint, 10000, 1+.5im, 2+.5im, 2+.25im, 4+.75im)) == 0 Test Passed 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> @test @allocated(compute_point(10000, MPoint(1+.5, 2+.5), MPoint(2+.25, 4+.75))) == 0 Test Passed julia> @test @allocated(compute_point(10000, MPoint(1+.5im, 2+.5im), MPoint(2+.25im, 4+.75im))) == 0 Test Passed 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> @test @allocated(compute_point!(10000, af, bf)) == 0 Test Passed julia> @test @allocated(compute_point!(10000, ac, bc)) == 0 Test Passed ``` 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 non-escaping 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.

JeffBezanson · 2022-01-21T20:44:21Z

I get this during build:

Generating REPL precompile statements... 36/36
Executing precompile statements... 121/1349[EA] bad EA: Array{Any, (2,)}[
  LibGit2.var"#148#149"{LibGit2.GitRepo, String, String},
  LibGit2.GitReference] at 134
[EA] bad EA: Array{Any, (2,)}[
  LibGit2.var"#148#149"{LibGit2.GitRepo, String, String},
  LibGit2.GitReference] at 162

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

base/Base.jl

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

vtjnash · 2022-01-21T22:02:51Z

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

+# end
+
+# linear scan to find regions in which potential throws will be caught
+function compute_tryregions(ir::IRCode)


Can this use Core.Compiler.compute_trycatch now?

Core.Compiler.compute_trycatch somehow sometimes throws unbalanced try/catch assertion error when applied to IRCode (should be easily reproduced). It may be worth digging into what's happening there, but for escape analysis we only need to know the locations of :enter expressions and that analysis can be done as a simple linear scan of compute_frameinfo.

vtjnash · 2022-01-21T22:04:17Z

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl

+            arg = args[i]
+            if i-1 ≤ nargs
+                argi = i-1
+            else # handle isva signature: COMBAK will this be invalid once we take alias information into account ?


so, this this invalid now?

doc/src/devdocs/EscapeAnalysis/README.md

aviatesk · 2022-01-22T05:25:19Z

I get this during build:

Generating REPL precompile statements... 36/36
Executing precompile statements... 121/1349[EA] bad EA: Array{Any, (2,)}[
  LibGit2.var"#148#149"{LibGit2.GitRepo, String, String},
  LibGit2.GitReference] at 134
[EA] bad EA: Array{Any, (2,)}[
  LibGit2.var"#148#149"{LibGit2.GitRepo, String, String},
  LibGit2.GitReference] at 162

This is because this PR uses the simple is_load_forwardable to check if EA covers all load-forwardable structs that the currently existing sroa_pass! can find, but that simple is_load_forwardable check doesn't account for ccall-preserve uses, which sroa_pass! can sometimes rewrite with forwarded loads by some extra efforts. #43888 will rewrite mutable SROA pass based on EA, and it is able to account for such ccall-preserve uses and we won't miss this optimization opportunity.

@allocated

Unleashes the potential for 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.

JuliaLang/julia#43800 will define new module `EscapeAnalysis` inside `Core.Compiler`, and it requires this minor special handling.

nanosoldier · 2022-02-15T21:34:04Z

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

nanosoldier · 2022-02-16T00:06:05Z

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

ianatol · 2022-02-16T00:49:23Z

This needed a rebase, but I can't push to avi/EscapeAnalysis, so I opened #44195 in case this can still be merged prior to the freeze

aviatesk · 2022-02-16T02:44:00Z

@nanosoldier runtests(["DataDeps", "DynamicAxisWarping", "ExponentialUtilities", "FileIO", "Geotherm", "HorseML", "InformationGeometry", "JuliaCon", "PSDMatrices", "Pluto", "ProgressiveHedging", "QuantumTomography", "Reactive", "SetIntersectionProjection"], vs = ":master")

aviatesk · 2022-02-16T09:59:26Z

We discussed that we are going to merge and include this PR for 1.8 without enabling the escape analysis at all, but still allowing developers and external consumers to test and experiment with it.
Since this PR doesn't run EA at all, it shouldn't affect the compilation behavior or latency in any way. It is even not be bootstrapped and so it doesn't affect bootstrapping time neither.

I will merge this once CI turns green.

nanosoldier · 2022-02-16T10:13:57Z

Your package evaluation job has completed - possible new issues were detected. A full report can be found 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 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`.

JuliaLang/julia#43800 will define new module `EscapeAnalysis` inside `Core.Compiler`, and it requires this minor special handling.

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`.

@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.

@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.

aviatesk requested review from JeffBezanson, vchuravy, vtjnash and ianatol January 13, 2022 20:25

aviatesk added compiler:optimizer Optimization passes (mostly in base/compiler/ssair/) needs nanosoldier run This PR should have benchmarks run on it labels Jan 13, 2022

vchuravy reviewed Jan 14, 2022

View reviewed changes

aviatesk force-pushed the avi/EscapeAnalysis branch 3 times, most recently from a07cfa3 to 2556a1a Compare January 17, 2022 10:48

ianatol reviewed Jan 17, 2022

View reviewed changes

ianatol reviewed Jan 18, 2022

View reviewed changes

aviatesk force-pushed the avi/EscapeAnalysis branch 2 times, most recently from 0a36203 to eccc077 Compare January 21, 2022 15:15

aviatesk mentioned this pull request Jan 21, 2022

optimizer: alias-aware SROA #43888

Draft

JeffBezanson reviewed Jan 21, 2022

View reviewed changes

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl Outdated Show resolved Hide resolved

JeffBezanson reviewed Jan 21, 2022

View reviewed changes

base/compiler/ssair/EscapeAnalysis/EscapeAnalysis.jl Outdated Show resolved Hide resolved

vtjnash reviewed Jan 21, 2022

View reviewed changes

aviatesk force-pushed the avi/EscapeAnalysis branch 2 times, most recently from e343279 to 007fa58 Compare January 22, 2022 05:15

aviatesk added a commit to aviatesk/Revise.jl that referenced this pull request Feb 15, 2022

tweak for upcoming Core.Compiler change

13f42a7

JuliaLang/julia#43800 will define new module `EscapeAnalysis` inside `Core.Compiler`, and it requires this minor special handling.

ianatol removed the needs nanosoldier run This PR should have benchmarks run on it label Feb 16, 2022

ianatol mentioned this pull request Feb 16, 2022

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

Closed

aviatesk force-pushed the avi/EscapeAnalysis branch 2 times, most recently from bad5206 to 05f22d5 Compare February 16, 2022 02:41

aviatesk added this to the 1.8 milestone Feb 16, 2022

aviatesk force-pushed the avi/EscapeAnalysis branch from 05f22d5 to d14fda8 Compare February 16, 2022 09:56

KristofferC added the backport 1.8 Change should be backported to release-1.8 label Feb 16, 2022

aviatesk force-pushed the avi/EscapeAnalysis branch from d14fda8 to 6f90d83 Compare February 16, 2022 10:50

KristofferC mentioned this pull request Feb 16, 2022

Backports for 1.8-beta1 #44202

Closed

7 tasks

JeffBezanson merged commit 8207f5d into master Feb 16, 2022

JeffBezanson deleted the avi/EscapeAnalysis branch February 16, 2022 16:04

KristofferC removed the backport 1.8 Change should be backported to release-1.8 label Feb 17, 2022

timholy pushed a commit to timholy/Revise.jl that referenced this pull request Feb 18, 2022

tweak for upcoming Core.Compiler change (#671)

b11e1a5

JuliaLang/julia#43800 will define new module `EscapeAnalysis` inside `Core.Compiler`, and it requires this minor special handling.

ianatol mentioned this pull request Mar 4, 2022

Non-capturing BoundsError API #44439

Closed

aviatesk mentioned this pull request Mar 25, 2022

add entry point to construct an OpaqueClosure from pre-optimized IRCode #44197

Merged

aviatesk mentioned this pull request Nov 9, 2022

Port EscapeAnalysis to Core.Compiler with Optimization TH3CHARLie/julia#3

Open

maleadt mentioned this pull request Dec 31, 2022

1.9 compatibility JuliaGPU/CUDA.jl#1710

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

optimizer: Julia-level escape analysis #43800

optimizer: Julia-level escape analysis #43800

aviatesk commented Jan 13, 2022 •

edited

Loading

aviatesk commented Jan 13, 2022

nanosoldier commented Jan 14, 2022

KristofferC commented Jan 14, 2022

vchuravy Jan 14, 2022

vchuravy Jan 14, 2022

nanosoldier commented Jan 14, 2022

ianatol Jan 17, 2022

aviatesk Jan 27, 2022

JeffBezanson commented Jan 21, 2022

vtjnash Jan 21, 2022

aviatesk Jan 27, 2022

vtjnash Jan 21, 2022

aviatesk commented Jan 22, 2022

nanosoldier commented Feb 15, 2022

nanosoldier commented Feb 16, 2022

ianatol commented Feb 16, 2022 •

edited

Loading

aviatesk commented Feb 16, 2022

aviatesk commented Feb 16, 2022 •

edited

Loading

nanosoldier commented Feb 16, 2022

optimizer: Julia-level escape analysis #43800

optimizer: Julia-level escape analysis #43800

Conversation

aviatesk commented Jan 13, 2022 • edited Loading

Footnotes

aviatesk commented Jan 13, 2022

nanosoldier commented Jan 14, 2022

KristofferC commented Jan 14, 2022

vchuravy Jan 14, 2022

Choose a reason for hiding this comment

vchuravy Jan 14, 2022

Choose a reason for hiding this comment

nanosoldier commented Jan 14, 2022

ianatol Jan 17, 2022

Choose a reason for hiding this comment

aviatesk Jan 27, 2022

Choose a reason for hiding this comment

JeffBezanson commented Jan 21, 2022

vtjnash Jan 21, 2022

Choose a reason for hiding this comment

aviatesk Jan 27, 2022

Choose a reason for hiding this comment

vtjnash Jan 21, 2022

Choose a reason for hiding this comment

aviatesk commented Jan 22, 2022

nanosoldier commented Feb 15, 2022

nanosoldier commented Feb 16, 2022

ianatol commented Feb 16, 2022 • edited Loading

aviatesk commented Feb 16, 2022

aviatesk commented Feb 16, 2022 • edited Loading

nanosoldier commented Feb 16, 2022

aviatesk commented Jan 13, 2022 •

edited

Loading

ianatol commented Feb 16, 2022 •

edited

Loading

aviatesk commented Feb 16, 2022 •

edited

Loading