[cmucl-imp] Unboxed float arguments

[Helmut Eller]

* Raymond Toy [2012-06-22 04:36] writes:

>> I could use a bit of feedback regarding the names.  Currently I use
>> "typed calling convention" resp. "typed entry point" and for the regular
>> entry point I use "external entry point" or XEP.  For the :typed-no-xep
>> case the naming is a bit misleading as the typed entry point is the only
>> entry point and in the IR has the lambda-kind set to :external, i.e. the
>> XEP is a typed entry.  Is there a better word for it?
>
> Sorry that I still haven't had a chance to look at your code or even
> play with it.
>
> I find the :typed and :typed-no-xep hard to remember, though.  Could it
> be :unboxed instead?  That makes it pretty clear that you're using
> calling convention that supports unboxed args.

The only issue I have with "unboxed" is that the calling convention also
supports boxed values, e.g. arrays, for which the type check was already
done in the caller.

> Also, how complex is it to keep track of this information so that the
> compiler can make the appropriate call?

I added a new info type in the globaldb that keeps track of the calling
convention.  Essentially one bit that says that this name should be
called with the unboxed convention.  Currently I do this in a way that
is similar to how struct accessors/setters are inlined: when the
compiler sees a call it recognizes that that name has the bit set and
puts the function-info for %typed-call in the combination-kind slot.
The ir2-converter for %typed-call then looks at the type for the
global-var name.  We keep track of the type anyway, i.e. this isn't new.
The type determines the representation for the call.

The other new information is the linker table.  For callsites we also
record the type.  The callsites that call the same function and the same
type share one entry.  I expect that without redefinitions that all
callsite of the same function will share a single entry.

We also need to inspect the type of function objects during linking.
Functions carry the type, expect if compiled with (optimize space).  The
only new bit here is that we disable the space optimization for the new
calling convention.

In the IR I need to mark some lambdas as unboxed entry points.
Currently I put something in the lambda-plist for that.  Right now, I'm
thinking about making the unboxed entry a new slot of the
optional-dispatch struct which might be a bit cleaner.

There are a couple of new VOPs which must still be written for the
non-x86 ports.

> Oh, and is there a use case you're interested in where block compilation
> doesn't do what you want?  (In my particular, hypothetical use case, I
> can see doing this with f2cl'ed code where the preferred technique is
> putting one Fortran function per file.  But this seems to rather
> uncommon but would be very useful.)

Say we have a math library with dozens of functions that operate on
floats.  To get the benefits of block compilation, we would need to
compile the library together with the caller of the library in one
block.  Also, if we change something we need to recompile the entire
block.  Yes, that's possible, but not very convenient.

Helmut