[Ecls-list] latest unboxing patch

[Juan Jose Garcia-Ripoll]

Hi Brian,

I have reviewed your patch more or less carefully. I would say it
consists on these sets of modifications:

1* The var-kind field in variables admits a new type 'LOCAL, which is
to be used for all local variables instead of the former kind which
specified the C type to use. At first I was concerned about this, but
now I realize closure variables get a different kind in the compiler
and this is the right way.

2* Functions contain another declaration which is C-UNBOXED where one
specifies the C types of each argument. If this declaration is
present, the function arguments are unboxed.

3* Lexical environments, which is the kind of environment used by
local functions (unless they are turned into closures) are now
compound of unions with all possible unboxed types. Since they are
stack allocated, they are automatically aligned and should be detected
by the garbage collector.

4* Unboxed declarations can in principle be exported. I mean that a
function in a different module can be compiled to call an unboxed
function from other module.

What I would do next is to simplify the mechanism. I would not make a
distinction between boxed and unboxed functions: all functions should
be treated on equal footing. The C types of the arguments and return
values of the function should be decided from the function declaration
or inferred types. The choice of boxing the function can then be
confined to a single test function which would check these conditions,
from most important to less relevant:
 - Is the function a global one? Then all boxed
 - Is the function a closure? Then all boxed
 - Atomic declaration C:BOX / C:UNBOXED as in (lambda (...) (declare
(c:box)) ...)
 - If the function arguments / return values are unspecified, or has
&rest, &key, etc, box.
 - If low safety, high optimization or low debug values, try to box.

To get unboxed globals one can then perform code transformations at
the lisp level, outside of the compiler itself:
 - Check whether there exist global proclamations for this function,
and whether unboxing can bring some gain to the function. Otherwise,
proceed as usual.
 - Replace the function with a wrapper that calls another function.
 - This other function will contain the actual code,  with some
mangled name, and appropiate compiler flags for unboxing.
 - When the module is loaded, ensure that the proclamations are as well.
 - Add a new global declaration (DECLARE (C:OPTIMIZED orig boxed))
which tells the compiler to use "boxed" instead of "orig" whenever
optimization valures are high enough.

What do you think?

Juanjo