[cmucl-imp] Unboxed float arguments

[Helmut Eller]

* Marco Antoniotti [2012-06-10 06:39] writes:

> Cool.
>
> I have not really looked at the code, but how generalizable would this
> approach be?  I.e.  why stop at FTYPEd floats?

For named calls we could delay some decisions to link-time.  At link
time we know more about the entry-point/callee and don't need to be
quite so conservative.  E.g. we could perform the argument count check
only at link time and then skip it at runtime.  Also optional/keyword
parsing could be avoided or at least be more efficient.  If we can patch
all callsites we could also use direct calls instead of indirect calls
(though that would probably be problematic GC-wise).  It might also be
useful for generic functions, e.g. if the static type of a call-site
determines a unique method we could link the two directly.

We can't easily change the representations that are used immediately
before the callsite, though.  E.g. situations like this are problematic:

(declaim (ftype (function (double-float) double-float) f))
(defun g () (f 1))
(declaim (ftype (function (number) number) f))
(defun h () (f 1))

Although G and H look the same, in G execution will never reach the
callsite because at compile-time we have committed to unboxed
double-float representation.  Since there is no way to convert an
integer to an unboxed double-float we will generate code that signals an
error before the call.  In H we choose boxed representation and the call
works just fine.

I think the link-time tricks are quite neat, but what really matters are
representation choices and those have to be made at compile-time.
Therefore I focus on (trustworthy) ftype declarations.

> I am asking because of Pascal Costanza's recent post on the PRO
> mailing list about stack-allocation of values (a DYNAMIC-EXTENT on
> steroids)

I don't know the details of that message, but stack-allocation is also a
kind of representation choice.  To make it work efficiently we'd also
need to make assumptions and choices at compile time.  If those
assumptions turn out to be wrong, linker tricks will probably not
suffice.  I guess a JIT compiler with deoptimization support is needed
for the hard cases.

Helmut