add static codegen for jl_is_leaf_type and jl_subtype

[carnaval]

solves some part of #7060. I'm not so sure about method_exists because you can add methods after codegen.

[JeffBezanson]

Failure is linalg-test-threshold-related.

[JeffBezanson]

Nice, I was hoping somebody would get around to adding this.

[stevengj]

Regarding method_exists, I'm not sure I see the issue with methods being added after codegen. Adding methods after codegen does not affect other previously generated method calls, after all, e.g.:

f(x) = x + 1
g(x) = f(x) + 2
println(g(1))
f(x::Int) = x + 7
println(g(1))

prints

4
4

So why should method_exists be any different?

[stevengj]

Is the isleaftype codegen really done statically now? It doesn't seem to be:

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

still spits out a lot more code than it should.

[jiahao]

OT: test failure should be addressed by 454d307.

[JeffBezanson]

You will need to try code_native(g, (Array{Int,1},)).

[JeffBezanson]

But yes, we are being too conservative in the Array{Int} case.

[timholy]

Sweet!

Hanging out with Julians makes me feel like I've got a whole flock of fairy godmothers making my life better. Let's see, what have they done today? Faster regex, better static codegen, improved SIMD, more special functions, lifetime supply of jellybeans, better reduction functions...hmm, all in all, a pretty good day.

[ViralBShah]

You should tweet that!

[timholy]

What's a tweet? 😄 When it comes to social media, email is about as sophisticated as I get.

[carnaval]

@stevengj For method_exists, I guess it probably wouldn't hurt to evaluate it at compile time, but it does change current behavior which some programs may rely on. If it is not deemed too breaking, I can probably make that change too.
The Array{Int} case seems to be codegen hitting a fallback path because the type is not concrete. No other known_call works in that case either IIUC.

@timholy Am I the only one not aware of the jellybeans thing ?! :-)

[timholy]

@carnaval, just checking to see if anyone noticed.

[stevengj]

One option would be to evaluate method_exists at compile time and only substitute the value into the codegen if it is true, and otherwise leave it as a runtime call.

[stevengj]

Also for

g(x::Array) = isleaftype(eltype(x)) ? 1 : 2

the code_native(g, (Array{Int,1},)) output is more than it needs to be.

[KristofferC]

Was this meant to "fix" this?

julia> f{T}(x::T) = T <: Real ? 1 : 2.0

julia> @code_warntype f(1.0)
Variables:
  x::Float64

Body:
  begin  # none, line 1:
      unless T <: Main.AbstractFloat::Bool goto 0
      return 1
      0: 
      return 2.0
  end::Union{Float64,Int64}

Is there any good way to do what I am trying to do here? I am wrapping a library where the function calls will look very similar except that I need to change the type of a parameter depending on the type of the input. Basically I want to do :

for t in (:StridedVector, :StridedMatrix)
    @eval begin
        function f{T}(B::$t(){T})
            # bunch of stuff same for vector and matrix
            if T <: StridedVector
                 C = zeros(10) # vector
            else
                 C = zeros(10, 10) # matrix
            end
            ccall(blah blah, C, ..)
        end
    end
end

and have it be type stable.