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.