0.8.3.70:
[sbcl.git] / src / compiler / stack.lisp
index 894a8cb..b71a128 100644 (file)
@@ -1,6 +1,6 @@
 ;;;; This file implements the stack analysis phase in the compiler. We
-;;;; do a graph walk to determine which unknown-values continuations
-;;;; are on the stack at each point in the program, and then we insert
+;;;; do a graph walk to determine which unknown-values lvars are on
+;;;; the stack at each point in the program, and then we insert
 ;;;; cleanup code to pop off unused values.
 
 ;;;; This software is part of the SBCL system. See the README file for
@@ -14,9 +14,9 @@
 
 (in-package "SB!C")
 \f
-;;; Scan through BLOCK looking for uses of :UNKNOWN continuations that
-;;; have their DEST outside of the block. We do some checking to
-;;; verify the invariant that all pushes come after the last pop.
+;;; Scan through BLOCK looking for uses of :UNKNOWN lvars that have
+;;; their DEST outside of the block. We do some checking to verify the
+;;; invariant that all pushes come after the last pop.
 (defun find-pushed-lvars (block)
   (let* ((2block (block-info block))
         (popped (ir2-block-popped 2block))
 ;;;; annotation graph walk
 
 ;;; Do a backward walk in the flow graph simulating the run-time stack
-;;; of unknown-values continuations and annotating the blocks with the
-;;; result.
+;;; of unknown-values lvars and annotating the blocks with the result.
 ;;;
 ;;; BLOCK is the block that is currently being walked and STACK is the
-;;; stack of unknown-values continuations in effect immediately after
+;;; stack of unknown-values lvars in effect immediately after
 ;;; block. We simulate the stack by popping off the unknown-values
-;;; generated by this block (if any) and pushing the continuations for
+;;; generated by this block (if any) and pushing the lvars for
 ;;; values received by this block. (The role of push and pop are
 ;;; interchanged because we are doing a backward walk.)
 ;;;
-;;; If we run into a values generator whose continuation isn't on
+;;; If we run into a values generator whose lvar isn't on
 ;;; stack top, then the receiver hasn't yet been reached on any walk
 ;;; to this use. In this case, we ignore the push for now, counting on
 ;;; Annotate-Dead-Values to clean it up if we discover that it isn't
 ;;; reachable at all.
 ;;;
 ;;; If our final stack isn't empty, then we walk all the predecessor
-;;; blocks that don't have all the continuations that we have on our
+;;; blocks that don't have all the lvars that we have on our
 ;;; START-STACK on their END-STACK. This is our termination condition
 ;;; for the graph walk. We put the test around the recursive call so
 ;;; that the initial call to this function will do something even
   (values))
 
 ;;; Do stack annotation for any values generators in Block that were
-;;; unreached by all walks (i.e. the continuation isn't live at the point that
+;;; unreached by all walks (i.e. the lvar isn't live at the point that
 ;;; it is generated.)  This will only happen when the values receiver cannot be
 ;;; reached from this particular generator (due to an unconditional control
 ;;; transfer.)
 ;;;
-;;; What we do is push on the End-Stack all continuations in Pushed that
+;;; What we do is push on the End-Stack all lvars in Pushed that
 ;;; aren't already present in the End-Stack. When we find any pushed
-;;; continuation that isn't live, it must be the case that all continuations
+;;; lvar that isn't live, it must be the case that all lvars
 ;;; pushed after (on top of) it aren't live.
 ;;;
-;;; If we see a pushed continuation that is the CONT of a tail call, then we
-;;; ignore it, since the tail call didn't actually push anything. The tail
-;;; call must always the last in the block.
+;;; If we see a pushed lvar that is the LVAR of a tail call, then we
+;;; ignore it, since the tail call didn't actually push anything. The
+;;; tail call must always the last in the block.
 (defun annotate-dead-values (block)
   (declare (type cblock block))
   (let* ((2block (block-info block))
   (values))
 \f
 ;;; This is called when we discover that the stack-top unknown-values
-;;; continuation at the end of BLOCK1 is different from that at the
-;;; start of BLOCK2 (its successor).
+;;; lvar at the end of BLOCK1 is different from that at the start of
+;;; BLOCK2 (its successor).
 ;;;
 ;;; We insert a call to a funny function in a new cleanup block
 ;;; introduced between BLOCK1 and BLOCK2. Since control analysis and
 ;;; LTN have already run, we must do make an IR2 block, then do
-;;; ADD-TO-EMIT-ORDER and LTN-ANALYZE-BELATED-BLOCK on the new block.
-;;; The new block is inserted after BLOCK1 in the emit order.
+;;; ADD-TO-EMIT-ORDER and LTN-ANALYZE-BELATED-BLOCK on the new
+;;; block. The new block is inserted after BLOCK1 in the emit order.
 ;;;
 ;;; If the control transfer between BLOCK1 and BLOCK2 represents a
-;;; tail-recursive return (:DELETED IR2-continuation) or a non-local
-;;; exit, then the cleanup code will never actually be executed. It
-;;; doesn't seem to be worth the risk of trying to optimize this,
-;;; since this rarely happens and wastes only space.
+;;; tail-recursive return or a non-local exit, then the cleanup code
+;;; will never actually be executed. It doesn't seem to be worth the
+;;; risk of trying to optimize this, since this rarely happens and
+;;; wastes only space.
 (defun discard-unused-values (block1 block2)
   (declare (type cblock block1 block2))
   (let* ((block1-stack (ir2-block-end-stack (block-info block1)))
 \f
 ;;;; stack analysis
 
-;;; Return a list of all the blocks containing genuine uses of one of the
-;;; RECEIVERS. Exits are excluded, since they don't drop through to the
-;;; receiver.
+;;; Return a list of all the blocks containing genuine uses of one of
+;;; the RECEIVERS. Exits are excluded, since they don't drop through
+;;; to the receiver.
 (defun find-values-generators (receivers)
   (declare (list receivers))
   (collect ((res nil adjoin))
            (res (node-block use))))))
     (res)))
 
-;;; Analyze the use of unknown-values continuations in COMPONENT,
-;;; inserting cleanup code to discard values that are generated but
-;;; never received. This phase doesn't need to be run when
-;;; Values-Receivers is null, i.e. there are no unknown-values
-;;; continuations used across block boundaries.
+;;; Analyze the use of unknown-values lvars in COMPONENT, inserting
+;;; cleanup code to discard values that are generated but never
+;;; received. This phase doesn't need to be run when Values-Receivers
+;;; is null, i.e. there are no unknown-values lvars used across block
+;;; boundaries.
 ;;;
 ;;; Do the backward graph walk, starting at each values receiver. We
 ;;; ignore receivers that already have a non-null START-STACK. These