0.6.11.34:
[sbcl.git] / src / compiler / locall.lisp
index d848bf6..8c18432 100644 (file)
 ;;; then associate this lambda with FUN as its XEP. After the
 ;;; conversion, we iterate over the function's associated lambdas,
 ;;; redoing local call analysis so that the XEP calls will get
-;;; converted. We also bind *LEXENV* to change the compilation policy
-;;; over to the interface policy.
+;;; converted. 
 ;;;
 ;;; We set REANALYZE and REOPTIMIZE in the component, just in case we
 ;;; discover an XEP after the initial local call analyze pass.
   (declare (type functional fun))
   (aver (not (functional-entry-function fun)))
   (with-ir1-environment (lambda-bind (main-entry fun))
-    (let* ((*lexenv* (make-lexenv :policy (make-interface-policy *lexenv*)))
-          (res (ir1-convert-lambda (make-xep-lambda fun))))
-      (setf (functional-kind res) :external)
-      (setf (leaf-ever-used res) t)
-      (setf (functional-entry-function res) fun)
-      (setf (functional-entry-function fun) res)
-      (setf (component-reanalyze *current-component*) t)
-      (setf (component-reoptimize *current-component*) t)
+    (let ((res (ir1-convert-lambda (make-xep-lambda fun))))
+      (setf (functional-kind res) :external
+           (leaf-ever-used res) t
+           (functional-entry-function res) fun
+           (functional-entry-function fun) res
+           (component-reanalyze *current-component*) t
+           (component-reoptimize *current-component*) t)
       (etypecase fun
        (clambda (local-call-analyze-1 fun))
        (optional-dispatch
               (won nil)
               (res (catch 'local-call-lossage
                      (prog1
-                         (ir1-convert-lambda (functional-inline-expansion fun))
+                         (ir1-convert-lambda (functional-inline-expansion
+                                              fun))
                        (setq won t)))))
          (cond (won
                 (change-ref-leaf ref res)
 \f
 ;;;; LET conversion
 ;;;;
-;;;; Converting to a LET has differing significance to various parts of the
-;;;; compiler:
-;;;; -- The body of a LET is spliced in immediately after the corresponding
-;;;;    combination node, making the control transfer explicit and allowing
-;;;;    LETs to be mashed together into a single block. The value of the LET is
-;;;;    delivered directly to the original continuation for the call,
-;;;;    eliminating the need to propagate information from the dummy result
-;;;;    continuation.
-;;;; -- As far as IR1 optimization is concerned, it is interesting in that
-;;;;    there is only one expression that the variable can be bound to, and
-;;;;    this is easily substitited for.
-;;;; -- LETs are interesting to environment analysis and to the back end
-;;;;    because in most ways a LET can be considered to be "the same function"
-;;;;    as its home function.
-;;;; -- LET conversion has dynamic scope implications, since control transfers
-;;;;    within the same environment are local. In a local control transfer,
-;;;;    cleanup code must be emitted to remove dynamic bindings that are no
-;;;;    longer in effect.
-
-;;; Set up the control transfer to the called lambda. We split the call
-;;; block immediately after the call, and link the head of FUN to the call
-;;; block. The successor block after splitting (where we return to) is
-;;; returned.
-;;;
-;;; If the lambda is is a different component than the call, then we call
-;;; JOIN-COMPONENTS. This only happens in block compilation before
-;;; FIND-INITIAL-DFO.
+;;;; Converting to a LET has differing significance to various parts
+;;;; of the compiler:
+;;;; -- The body of a LET is spliced in immediately after the
+;;;;    corresponding combination node, making the control transfer
+;;;;    explicit and allowing LETs to be mashed together into a single
+;;;;    block. The value of the LET is delivered directly to the
+;;;;    original continuation for the call,eliminating the need to
+;;;;    propagate information from the dummy result continuation.
+;;;; -- As far as IR1 optimization is concerned, it is interesting in
+;;;;    that there is only one expression that the variable can be bound
+;;;;    to, and this is easily substitited for.
+;;;; -- LETs are interesting to environment analysis and to the back
+;;;;    end because in most ways a LET can be considered to be "the
+;;;;    same function" as its home function.
+;;;; -- LET conversion has dynamic scope implications, since control
+;;;;    transfers within the same environment are local. In a local
+;;;;    control transfer, cleanup code must be emitted to remove
+;;;;    dynamic bindings that are no longer in effect.
+
+;;; Set up the control transfer to the called lambda. We split the
+;;; call block immediately after the call, and link the head of FUN to
+;;; the call block. The successor block after splitting (where we
+;;; return to) is returned.
+;;;
+;;; If the lambda is is a different component than the call, then we
+;;; call JOIN-COMPONENTS. This only happens in block compilation
+;;; before FIND-INITIAL-DFO.
 (defun insert-let-body (fun call)
   (declare (type clambda fun) (type basic-combination call))
   (let* ((call-block (node-block call))