Update of /cvsroot/sbcl/sbcl/src/compiler
In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv25594/src/compiler
184.108.40.206: physenvanal: Treat all functions without XEPs as being D-X.
* In order for a function to be returned or passed as a parameter,
it must have an XEP.
* Functions without XEPs, therefore, can only be called directly
from within their lexical scope. They are, therefore,
* But wait, you say, they could be called from a closure that is
not dynamic-extent, which clearly shows such an analysis to be false.
* It turns out that this doesn't matter, because the non-dynamic-
extent closure also has to close over the variables passed to the
supposedly-dynamic-extent closure, and that will cause explicit
value-cells to be allocated anyway.
* So, it's a bit of an abuse to say that the functions have dynamic
extent, but it does no harm (and quite a bit of good) to treat them
as if they do.
RCS file: /cvsroot/sbcl/sbcl/src/compiler/physenvanal.lisp,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -d -r1.33 -r1.34
--- physenvanal.lisp 9 Nov 2010 19:46:33 -0000 1.33
+++ physenvanal.lisp 21 Jan 2011 16:40:54 -0000 1.34
@@ -230,8 +230,16 @@
;; functions), or a pointer from an underlying function to its
;; XEP (for non-:TOPLEVEL functions with XEPs).
(unless (or (leaf-dynamic-extent fun)
- (and entry-fun
- (leaf-dynamic-extent entry-fun)))
+ ;; Functions without XEPs can be treated as if they
+ ;; are DYNAMIC-EXTENT, even without being so
+ ;; declared, as any escaping closure which /isn't/
+ ;; DYNAMIC-EXTENT but calls one of these functions
+ ;; will also close over the required variables, thus
+ ;; forcing the allocation of value cells. Since the
+ ;; XEP is stored in the ENTRY-FUN slot, we can pick
+ ;; off the non-XEP case here.
+ (not entry-fun)
+ (leaf-dynamic-extent entry-fun))
(let ((closure (physenv-closure (lambda-physenv fun))))
(dolist (var closure)
(when (and (lambda-var-p var)