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

better compile-time evaluation of type expressions #7060

Closed
stevengj opened this issue May 31, 2014 · 6 comments
Closed

better compile-time evaluation of type expressions #7060

stevengj opened this issue May 31, 2014 · 6 comments
Labels
performance Must go faster

Comments

@stevengj
Copy link
Member

Right now, Julia does not seem to do a good job of partially evaluating type expressions that are known at compile time. For example:

f{T}(x::T) = T <: Real ? 1 : 2

should be compiled to f(x) = 1 for f(3) or f(x) = 2 for f(4+5im), but code_native(f, (Int,)) reveals that this is not the case: in fact, the code for this function is quite involved. Fixed by #7088.

It would be nice to have this work for cases where using dispatch is impractical, especially in macros. For example, as discussed in #7033, I would like to generalize the @horner macro to use a better algorithm for cases where the argument is complex but the coefficients are real, but it should inline to the correct code depending upon the argument type.

Another example that should be possible to evaluate at compile time is:

g{T}(x::T) = method_exists(one, (T,)) ? 1 : 2

Explicit method_exists checks are used, for example, in reducedim.jl and multimedia.jl. (It might be good to evaluate this statically only if method_exists returns true, to preserve the current dynamic behavior.)

A third example mentioned on the mailing list in the context of better type promotion for Array*Number for SIUnits quantities is that it would be nice to have isleaftype(T) evaluated at compile time. (Partially fixed by #7088.)

@stevengj
Copy link
Member Author

stevengj commented Jun 2, 2014

On the other hand, it looks like isa does, in fact, inline to a constant expression that gets optimized out. For example, with

f(x) = isa(x, Real) ? 1 : 2

if you do code_native(f, (Int,)) it is clear that the conditional has been optimized out.

@stevengj
Copy link
Member Author

stevengj commented Jun 3, 2014

Thanks to @carnaval for his improvements! Some things that are still not compiled statically:

g{T}(x::Array{T}) = isleaftype(T) ? 1 : 2
code_native(g, (Array{Int},))

or

g(x::Array) = isleaftype(eltype(x)) ? 1 : 2
code_native(g, (Array{Int,1},))

@stevengj
Copy link
Member Author

stevengj commented Jun 5, 2014

Another one that just bit me in #7125: type-inference is performed before dead-code elimination. Hence, for example:

julia> f(x) = isa(x, Integer) ? 1 : 1.0
f (generic function with 1 method)

julia> [f(i) for i in 1:2]
2-element Array{Union(Float64,Int64),1}:
 1
 1

instead of the return type being Array{Int}.

@JeffBezanson
Copy link
Sponsor Member

Type inference and DCE can be iterated any number of times to improve the resulting code --- there is no one correct ordering. But doing constant prop as part of type inference would fix this case (constant prop being type inference with singleton types).

@stevengj
Copy link
Member Author

stevengj commented Jun 5, 2014

Another oddity:

f(x) = isa(x, Complex) ? 1 : 2

does not get statically evaluated, as code_native(f, (Int,)) shows, even though static evaluation worked for the isa(x, Real) case above.

Update: Fixed by 98189bc

@JeffBezanson
Copy link
Sponsor Member

This issue is covered by #6822 and #5560.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Must go faster
Projects
None yet
Development

No branches or pull requests

2 participants