wanted: stack allocation in move vops

[Nikodemus Siivola]

Would allow stack allocated floats, complexes, ratios, etc.

Looks tricky to do, tough. As in eg.

(defun foo (x y)
  (declare (single-float x y))
  (let ((c (complex x y)))
    (declare (dynamic-extent c))
    (quux c)))

the move is from C to the argument of QUUX. Either the DX declaration would have to force stack allocation of C in the first place (instead of keeping it in registers/complex-stack), or -- more interestingly, I think -- we would need an extended FUNCTION type specifier along the lines of

  (FUNCTION ((DYNAMIC-EXTENT (COMPLEX SINGLE-FLOAT)) T)

for QUUX. That is, allow (DYNAMIC-EXTENT <TYPE-SPECIFIER>) as argument specifier in FUNCTION types, indicating that the argument can be safely stack allocated by the caller.

This would seem like a semi-decent solution to the perpetual request for "unboxed arguments": the callee does not have to deal with unboxed arguments, but the cost of boxing is mostly eliminated by using the stack instead of the heap.

[Tobias C. Rittweiler (tcr)]

I have a question regarding this.

Declaimed FTYPE are always trusted, right? "Trusted" in so far as
function redefinition must not change the function's signature
incompatibly.

So if I declaim FOO like

  (declaim (ftype (function (float float) (values float &optional)) FOO))

the obvious thing in my imagination would be to always assume that the
floats come and go on the stack. Then also emit special entry and exit
points for the function which look at the arguments, and if the
arguments are boxed, get them down to the stack first before entering
the main entry. The exit point should put it on the heap by default.

Then on call sites it should skip the get-em-on-stack entry point if
the arguments are statically known to be on the stack already (either
due to dx declarations, or due to the above assumption for the main
entry.)

That probably does not play well with hairy-lambdas, but I wouldn't
find it too restrictful to avoid those in fp critical code.

What am I missing?

[Nikodemus Siivola (nikodemus)]

I'm not sure what you are asking. What you describe is definitely not what SBCL currently does, and notion of variable entry points (depending on call-sites) is something we currently have zero support for -- but I think you knew that, so I'm confused.

[Tobias C. Rittweiler (tcr)]

No I didn't know that. I wrongly extrapolated from CLAMBDA-ENTRIES and the ir1-convert-hairy-lambda stuff.