wanted: stack allocation in move vops
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| SBCL |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
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/
(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.
| description: | updated |
| Tobias C. Rittweiler (tcr) wrote | #1 |
| Nikodemus Siivola (nikodemus) wrote | #2 |
| Tobias C. Rittweiler (tcr) wrote | #3 |
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?