Do some constant propagation before type inference runs

[Keno]

It would be good to run some constant propagation before type inference runs for cases in which a type parameter is really constant, but we don't know because we compute with it before. E.g:

type foo{m}; end
inv{m}(x::foo{m}) = foo{-m}()
id{m}{x::foo{m}) = foo{m}()

For id, we get a nice

julia> code_typed(id,(foo{1},))
1-element Array{Any,1}:
 :($(Expr(:lambda, {:x}, {{},{{:x,foo{1},0}},{}}, quote  # /Users/kfischer/.julia/REPL/scripts/repl.jl, line 1:
        return $(Expr(:new, foo{1}))::foo{1}
    end)))

whereas for inv, we get

julia> code_typed(inv,(foo{1},))
1-element Array{Any,1}:
 :($(Expr(:lambda, {:x}, {{},{{:x,foo{1},0}},{}}, quote  # /Users/kfischer/.julia/REPL/scripts/repl.jl, line 1:
        return top(apply_type)(foo,top(box)(Int64,top(neg_int)(1))::Int64)::Type{_<:foo{m}}()::foo{m}
    end)))

[Keno]

The only problem I see is that you probably want:

Type Inference -> Inlining -> Constant Propagation -> Type Inference

[lindahua]

+1

[JeffBezanson]

There is really no limit to this --- the more you iterate inference, inlining, and constant prop, the more cases you will optimize. You can construct examples that require arbitrary numbers of these passes.
Evaluating intrinsics like neg_int at compile time is a challenge. We could pre-compile a callable version of each, implement an interpreter for all of them, or call codegen and pass the result to llvm's interpreter (though that sounds like it has a lot of overhead).

[ArchRobison]

An alternative to inlining to consider is context-sensitive inter-procedural analysis. That enables a compiler to do "what if I inlined?" analyses without necessarily paying the full cost of inlining. Of course context-sensitive analysis also has the "when to stop?" issue.

I'm wondering if there's a way to automatically generate the interpreter for the intrinsics from some kind of table.

[maleadt]

Just ran into this trying to pass a const computation to a generated function by means of a Val type:

@generated function foobar{D}(::Type{Val{D}})
    return :($D)
end

function working1()
    const size = 12
    return foobar(Val{size})
end

const size = 3*4
function working2()
    return foobar(Val{size})
end

function broken()
    const size = 3*4
    return foobar(Val{size})
end

println(@code_typed working1())
@inferred working1()

println(@code_typed working2())
@inferred working2()

println(@code_typed broken())
@inferred broken()

This broke some Julia/CUDA code where we can't perform the call to foobar dynamically. We use it to implement @cuSharedMemory(T, dims...) where we need a generated function to determine the type of T in order to allocate a certain amount of memory.

[timholy]

Might be worth pointing out that syntax like #22056 (esp. the first comment) might be a way for the programmer to specify exactly which kind of constant propagation should be performed. Presumably this makes it a finite problem.

[vtjnash]

Presumably this makes it a finite problem.

I'm pretty sure it doesn't. But with the new inference convergence, #21933 should do it.