optimizer: compute side-effect-freeness for array allocations#43565
Merged
optimizer: compute side-effect-freeness for array allocations#43565
Conversation
8175f31 to
d0866b9
Compare
KristofferC
reviewed
Dec 27, 2021
base/reflection.jl
Outdated
| end | ||
| end | ||
|
|
||
| LLT_ALIGN(x, sz) = (x + sz - 1) & -sz |
Member
There was a problem hiding this comment.
Perhaps put this before it is used?
29d711b to
066cdba
Compare
This was referenced Dec 28, 2021
Member
Author
|
@nanosoldier |
02318a0 to
6754e8a
Compare
This would be useful for Julia-level optimizations on arrays. Initially I want to have this in order to add array primitives support in EscapeAnalysis.jl, which should help us implement a variety of array optimizations including dead array allocation elimination, copy-elision from `Array` to `ImmutableArray` conversion (#42465), etc., but I found this might be already useful for us since this enables some DCE in very simple cases like: ```julia julia> function simple!(x::T) where T d = IdDict{T,T}() # dead alloc # ... computations that don't use `d` at all return nothing end simple! (generic function with 1 method) julia> @code_typed simple!("foo") CodeInfo( 1 ─ return Main.nothing ) => Nothing ``` This enhancement is super limited though, e.g. DCE won't happen when array allocation involves other primitive operations like `arrayset`: ```julia julia> code_typed() do a = Int[0,1,2] nothing end 1-element Vector{Any}: CodeInfo( 1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Int64}, svec(Any, Int64), 0, :(:ccall), Vector{Int64}, 3, 3))::Vector{Int64} │ Base.arrayset(false, %1, 0, 1)::Vector{Int64} │ Base.arrayset(false, %1, 1, 2)::Vector{Int64} │ Base.arrayset(false, %1, 2, 3)::Vector{Int64} └── return Main.nothing ) => Nothing ``` Further enhancement o optimize cases like above will be based on top of incoming EA.jl (Julia-level escape analysis) or LLVM-level escape analysis.
6754e8a to
ff3cf17
Compare
vtjnash
reviewed
Jan 10, 2022
| return true | ||
| end | ||
|
|
||
| function foreigncall_effect_free(stmt::Expr, @nospecialize(rt), src::Union{IRCode,IncrementalCompact}) |
Member
There was a problem hiding this comment.
what is the purpose of rt here? It does not look used.
vtjnash
reviewed
Jan 10, 2022
Comment on lines
+296
to
+298
| atype = widenconst(argextype(args[6], src)) | ||
| isType(atype) || return false | ||
| atype = atype.parameters[1] |
vtjnash
reviewed
Jan 10, 2022
Comment on lines
+312
to
+314
| atype = widenconst(argextype(args[6], src)) | ||
| isType(atype) || return false | ||
| atype = atype.parameters[1] |
| YY(LLVMExtraAddGCInvariantVerifierPass) \ | ||
| YY(LLVMExtraAddDemoteFloat16Pass) \ | ||
| YY(LLVMExtraAddCPUFeaturesPass) \ | ||
|
|
Member
There was a problem hiding this comment.
this line is significant, don't remove it
Member
Author
|
Thanks for your review @vtjnash . I will make a follow up PR. |
Merged
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this pull request
Feb 22, 2022
…ang#43565) This would be useful for Julia-level optimizations on arrays. Initially I want to have this in order to add array primitives support in EscapeAnalysis.jl, which should help us implement a variety of array optimizations including dead array allocation elimination, copy-elision from `Array` to `ImmutableArray` conversion (JuliaLang#42465), etc., but I found this might be already useful for us since this enables some DCE in very simple cases like: ```julia julia> function simple!(x::T) where T d = IdDict{T,T}() # dead alloc # ... computations that don't use `d` at all return nothing end simple! (generic function with 1 method) julia> @code_typed simple!("foo") CodeInfo( 1 ─ return Main.nothing ) => Nothing ``` This enhancement is super limited though, e.g. DCE won't happen when array allocation involves other primitive operations like `arrayset`: ```julia julia> code_typed() do a = Int[0,1,2] nothing end 1-element Vector{Any}: CodeInfo( 1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Int64}, svec(Any, Int64), 0, :(:ccall), Vector{Int64}, 3, 3))::Vector{Int64} │ Base.arrayset(false, %1, 0, 1)::Vector{Int64} │ Base.arrayset(false, %1, 1, 2)::Vector{Int64} │ Base.arrayset(false, %1, 2, 3)::Vector{Int64} └── return Main.nothing ) => Nothing ``` Further enhancement o optimize cases like above will be based on top of incoming EA.jl (Julia-level escape analysis) or LLVM-level escape analysis.
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this pull request
Feb 22, 2022
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this pull request
Mar 8, 2022
…ang#43565) This would be useful for Julia-level optimizations on arrays. Initially I want to have this in order to add array primitives support in EscapeAnalysis.jl, which should help us implement a variety of array optimizations including dead array allocation elimination, copy-elision from `Array` to `ImmutableArray` conversion (JuliaLang#42465), etc., but I found this might be already useful for us since this enables some DCE in very simple cases like: ```julia julia> function simple!(x::T) where T d = IdDict{T,T}() # dead alloc # ... computations that don't use `d` at all return nothing end simple! (generic function with 1 method) julia> @code_typed simple!("foo") CodeInfo( 1 ─ return Main.nothing ) => Nothing ``` This enhancement is super limited though, e.g. DCE won't happen when array allocation involves other primitive operations like `arrayset`: ```julia julia> code_typed() do a = Int[0,1,2] nothing end 1-element Vector{Any}: CodeInfo( 1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Int64}, svec(Any, Int64), 0, :(:ccall), Vector{Int64}, 3, 3))::Vector{Int64} │ Base.arrayset(false, %1, 0, 1)::Vector{Int64} │ Base.arrayset(false, %1, 1, 2)::Vector{Int64} │ Base.arrayset(false, %1, 2, 3)::Vector{Int64} └── return Main.nothing ) => Nothing ``` Further enhancement o optimize cases like above will be based on top of incoming EA.jl (Julia-level escape analysis) or LLVM-level escape analysis.
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this pull request
Mar 8, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This would be useful for future Julia-level optimizations on arrays.
Initially I want to have this in order to add array primitives support
in EscapeAnalysis.jl, which should help us implement a variety of array
optimizations including dead array allocation elimination, copy-elision
from
ArraytoImmutableArrayconversion (#42465), etc., but I foundthis might be already useful for us since this enables some DCE in very
simple cases for free:
This enhancement is super limited though, e.g. DCE won't happen when
array allocation involves other primitive operations like
arrayset:Further enhancement o optimize cases like above will be based on top of
incoming EA.jl (Julia-level escape analysis) or LLVM-level escape analysis.
@pchintalapudi So we're working more and more similar kinds of optimizations (e.g. this could be considered as a very limited version of #43548).
Maybe we want to have some meeting to discuss which parts should be done on Julia-level or LLVM-level?