Re: LuaJIT2 vs. vararg

[Mike Pall <mikelu-0911@...>]

Vyacheslav Egorov wrote:
> If I were developing "static" compiler for the Lua, I would try
> implement the following approach: always try to inline vararg
> functions at callsites with a fixed number of arguments, then try to
> unroll loops that iterate over varargs (apply a simple heuristic to
> find such loops: index variable is in range 1 .. #args, index variable
> is used in args[i]).
> 
> I am curious does it make sense? Can it be reformulated in terms of
> tracing JIT?

Unrolling usually only helps if the trip count is low and
constant. The latter is often not the case with varargs.

And unrolling just multiplies the problem with type-variance. Now
you get not just one decision tree, but multiple slightly
different trees.

> Tracing JIT gets an inline for free. But I don't see how to implement
> on-the-fly loop unrolling for this case.

There are already some unrolling heuristics in LJ2. The basic idea
is to give an outer loop the chance to unroll an inner loop with a
low trip count. See rec_loop_interp() in lj_record.c.

One could additionally penalize loops over varargs to provoke
unrolling. But it's unclear whether this helps the general case.

> (It seems that both Alexander's and Mark's examples will benefit from
> this optimization)

Well, maybe in Alexander's example, because inlining and unrolling
at the call site would work out there.

But Mark's example has an intermediate loop over an array that
cannot/should not be unrolled. This prevents specialization at the
call site of the 'broadcast' abstraction. As I've already said,
this is a bit too much to ask from a compiler.

This is summarized in the "Sufficiently Smart Compiler" argument:
  http://prog21.dadgum.com/40.html

--Mike