improve codegen of varargs functions

[JeffBezanson]

The code generator currently pessimizes varargs functions in various ways.
For example:

function f(a...)
    z = a[1]+a[2]
    z
end

function g()
    x = f(3,5)
end

We don't generate a specialized signature for f, and its return value is even boxed.

We should generate a specialized f(Int,Int) (if the function is specialized for 2 Int arguments), or f(Int...) (using llvm varargs).

For cases where we can't generate an especially nice signature (e.g. for f(Any...)), we could keep using the julia calling convention for arguments but specialize the return type.

[KristofferC]

FWIW, this example currently generates:

julia> @code_llvm g()

define i64 @julia_g_53587() #0 {
top:
  ret i64 8
}

[andyferris]

Just a checkup - is there any progress on this issue?

We should generate a specialized f(Int,Int) (if the function is specialized for 2 Int arguments)

Indeed! This would be really awesome. It can just specialize to invoking f(a::Tuple{Int,Int}) which has similar ABI (right? tuples are flattened and the same as C calling convention, at least for immutables, no?) and the correct syntax (a[1], a[2]).

I find I have to avoid varargs functions in a lot of performance critical code (e.g. map and broadcast for StaticArrays) which makes life painful. :(

[timholy]

I suspect #265 is ahead of this one in the queue. Seems appropriate, since most varargs performance problems can be circumvented by forced inlining.

[andyferris]

Oh? I didn't know that - thanks! That helps a lot (but makes using @code_x a bit more arduous... maybe we need a macro for that... (actually that's not a bad idea!)).

[KristofferC]

Is there anything left to do here?

[KristofferC]

Closing since original example is fixed. Can always open more specific examples if they are encounted.