[Ecls-list] latest unboxing patch

[Brian Spilsbury]

> 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.

You may not have looked at the latest version.

I've split this into C-UNBOXED and C-FUNBOXED.
C-FUNBOXED specifies the parameter rep-types, as well as how to call it.

C-UNBOXED allows you to specify the rep-type of a variable, but there
is minimal support for this -- actually, I'm not sure that it does
anything at the moment, but it should allow you to write (let ((x 0))
(declare (si::c-unboxed fixnum x)))

That's probably mainly useful for interoperation with inline c code.

> 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.

Type inference can work in the normal case, but there isn't a 1:1
mapping between representation type and lisp-type.

Consider many built-in functions which have a lisp return type of,
say, fixnum -- but a representation return type of :object.

Inferring this from the lisp type proclamation produces the wrong
interface here, so there needs to at least be some way to override the
inferrence.

> 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

Currently I generate boxed versions of everything, except for lexical functions.

I use proclaim to infer an unboxed interface for global functions.

This avoids the system functions, which bypasses the problem above,
and it can still be overridden by an explicit si::c-funboxed proclamation.

>  - 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.

Well, we can avoid this problem by simply unboxing only the required arguments.
Optionals might be handled passing them like required arguments, but
with nargs to determine which should be overwritten locally, but I
think that I'd prefer to leave optionals boxed for now.

> 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?

I don't think that the 'outside of the compiler itself' is going to work.
The compiler needs to know how to generate and call the unboxed functions.

You could generate a wrapper function which looked essentially like
(lambda (, at required &rest arguments) (apply #'global , at requireds)),
but that might require apply to be more intelligent -- I haven't
looked yet.

Regards,
Brian.