RFC: specialized calling convention for pure functions that return a constant

[JeffBezanson]

This allows deleting their code and avoiding native code gen entirely. This happens a fair amount due to functions like promote_type, zero, trait functions, etc. It's about 8% of all inferred functions in the system image. However since such functions tend to be very small, the gains are not as much as that number might imply.

[andyferris]

Hi Jeff,

Just a general question as to the design of constant propagation and where this is going - are you planning on allowing constant propagation and inlining during inference, here, or just afterwards? I see the post-inference optimizations are very useful, but sometimes these calculations affect type.

For instance, a simple example that I would love to see be inferrable:

addval{M,N}(::Type{Val{M}}, ::Type{Val{N}}) = Val{M+N}

If this constant is inlined post-inference, then can its type parameter be used for later calculations? e.g.

function foo()
    a = Val{2}
    b = Val{3}
    c = Val{4}
    d = addval(a,b)
    return addval(d,c)
end

(Where I really want to end up with is:

@inline Base.getindex{Idx}(table::Table{Idx}, field::Symbol) = Table.data[find_index(Idx, field)]

where Idx is a tuple of symbols and table.data is a tuple of data and field is written by the user as a literal, so they can extract column :a with table[:a]. I can't get any combination of @pure, @inline and @generated to do the compile-time processing that I want (the user needs to type field as Val{:a} instead of :a). The problem with this last one is that table is not constant, and I can't get getindex() to inline during inference to make a call to find_index(Idx, field), which is a pure function of constants... )

[JeffBezanson]

This change is actually orthogonal to inference and constant propagation. It just says that if we can infer the result of a pure function to be a constant, then we don't need to generate native code for it or keep its IR around.

Separately, we do hope to improve constant propagation over time. I think Val{M+N} will definitely be inferred sooner or later. Unfortunately the case of table[:a] is especially difficult, since it is extremely expensive to analyze functions for all argument values, and it's hard to know when it will be profitable to do so. We might in fact need a new feature for specialization and/or inference on values.

[andyferris]

OK, thanks, I get it now - this is an internal optimization for things like pure functions that only depend on the types of their inputs.

Separately, we do hope to improve constant propagation over time. I think Val{M+N} will definitely be inferred sooner or later.

Cool, I'm really looking forward to this. :)

Unfortunately the case of table[:a] is especially difficult, since it is extremely expensive to analyze functions for all argument values, and it's hard to know when it will be profitable to do so. We might in fact need a new feature for specialization and/or inference on values.

Yes, I realize it is difficult (expensive, rather) to analyze based on value. I was more saying that if my @inline in the above explicitly copy-pasted the IR from the function to the destination during the inference phase, then inference would run over find_index(Idx, field) and realize it is a pure function of constants before it converged. As I understand it (please correct me if I'm wrong), most inlining happens post-inference but pre-codegen, currently.

[tkelman]

is 10 just an arbitrarily chosen cutoff for this?

[vtjnash]

:gotoifnot isn't effect-free

[JeffBezanson]

Fixed.

[vtjnash]

LabelNode too?

[vtjnash]

lgtm. just needs a rebase