a lowered AST with types, or switches for optimizations #10392
Comments
|
I believe exactly the representation you want is available right before the inlining pass runs. All you need is some kind of hook to make |
|
That would be wonderful! Could you make that change? Thanks! I believe exactly the representation you want is available right before the inlining pass runs. All you need is some kind of hook to make typeinf return the AST at that point. — |
|
Done! You can now get this with |
|
It works beautifully. The AST is exactly a lowered but typed tree. Thanks, Jeff, for the prompt response and the great work! Hongbo Done! You can now get this with code_typed(f, (types...), optimize=false). — |
|
With the typed lowered AST, we have done some transformation on it (inserted/removed nodes). Now it is time to get performance. How to let Julia do the optimizations on the tree (like inlining, tuple elimination, etc. which we disabled during type inference)? Thanks, Done! You can now get this with code_typed(f, (types...), optimize=false). — |
Hello,
We are working on some analyses on Julia typed AST. We like the type info (Great job!), but dislike the details exposed in the tree, compared to lowered AST.
Our analyses and optimizations are working at mathematical level and expect users to write code like writing math equations. The lowered AST is quite close to that level, while typed AST will have more details (and much more efficient for sure). For example, here is a source code:
r = b - A * x
Here is the corresponding lowered AST statement:
r = b - A * x::ANY::ANY # line 40:
Here are the corresponding typed AST statements:
_var3 = x::Array{Float64,1}
_var2 = (top(getfield))(A::Base.SparseMatrix.SparseMatrixCSC{Float64,Int64},:m)::Int64
r = b::Array{Float64,1} - A_mul_B!((top(box))(Float64,(top(sitofp))(Float64,1)),A::Base.SparseMatrix.SparseMatrixCSC{Float64,Int64},_var3::Array{Float64,1},(top(box))(Float64,(top(sitofp))(Float64,0)),(top(ccall))(:jl_alloc_array_1d,$(Expr(:call1, :(top(apply_type)), :Array, Float64, 1)),$(Expr(:call1, :(top(tuple)), :Any, :Int)),Array{Float64,1},0,_var2::Int64,0)::Array{Float64,1})::Array{Float64,1}::Array{Float64,1} # line 40:
You can see object allocation, function call, intrinsics, internal representation (getfield m of A), etc. They are valuable information, but far more than what we need: types.
The details seem to be brought in by some optimizations (like inlining, tuple elimination, etc.) during type inference. I am not sure if there are other optimizations before type inference that also contribute. These optimizations are important for performance. On the other hand, Julia as a framework might provide more flexibility to external packages by decoupling them from type inference (and any other contributing modules).
Could you consider the following options?
(1) Option 1: adding some switches to all these optimizations.
By default, they are on, and Julia behaves as usual. But an external package can choose to turn off some or all of them, and get a much cleaner AST for its own analyses and optimizations. This makes Julia more flexible.
(2) Option 2: provide another level of AST that is lowered but with types.
For the above example, something like this would be wonderful:
r::Array{Float64,1} = b::Array{Float64,1} - A::Base.SparseMatrix.SparseMatrixCSC{Float64,Int64} * x::Array{Float64,1}
Then you can provide other important optimizations (like inlining, etc.) upon this AST, and get the full detailed typed AST today. This can happen transparently: when code_typed() runs, it checks if an AST at the new level exists; if yes, it avoids type inference, and directly performs optimizations.
I personally like Option 2 much better, since it provides a new level of intermediate representation that many similar packages may be interested in, and it avoids exposing many internal switches.
Thanks for consideration.
Hongbo
The text was updated successfully, but these errors were encountered: