New TN cost computation: directly take depth into account
[sbcl.git] / src / compiler / node.lisp
index 50c5598..2e5fd52 100644 (file)
 
 (in-package "SB!C")
 
-;;; The front-end data structure (IR1) is composed of nodes and
-;;; continuations. The general idea is that continuations contain
-;;; top-down information and nodes contain bottom-up, derived
-;;; information. A continuation represents a place in the code, while
-;;; a node represents code that does something.
-;;;
-;;; This representation is more of a flow-graph than an augmented
-;;; syntax tree. The evaluation order is explicitly represented in the
-;;; linkage by continuations, rather than being implicit in the nodes
-;;; which receive the the results of evaluation. This allows us to
-;;; decouple the flow of results from the flow of control. A
-;;; continuation represents both, but the continuation can represent
-;;; the case of a discarded result by having no DEST.
+;;; The front-end data structure (IR1) is composed of nodes,
+;;; representing actual evaluations. Linear sequences of nodes in
+;;; control-flow order are combined into blocks (but see
+;;; JOIN-SUCCESSOR-IF-POSSIBLE for precise conditions); control
+;;; transfers inside a block are represented with CTRANs and between
+;;; blocks -- with BLOCK-SUCC/BLOCK-PRED lists; data transfers are
+;;; represented with LVARs.
 
-(def!struct (continuation
-            (:make-load-form-fun ignore-it)
-            (:constructor make-continuation (&optional dest)))
+;;; "Lead-in" Control TRANsfer [to some node]
+(def!struct (ctran
+             (:make-load-form-fun ignore-it)
+             (:constructor make-ctran))
   ;; an indication of the way that this continuation is currently used
   ;;
   ;; :UNUSED
-  ;;   A continuation for which all control-related slots have the
-  ;;   default values. A continuation is unused during IR1 conversion
-  ;;   until it is assigned a block, and may be also be temporarily
-  ;;   unused during later manipulations of IR1. In a consistent
-  ;;   state there should never be any mention of :UNUSED
-  ;;   continuations. Next can have a non-null value if the next node
-  ;;   has already been determined.
-  ;;
-  ;; :DELETED
-  ;;   A continuation that has been deleted from IR1. Any pointers into
-  ;;   IR1 are cleared. There are two conditions under which a deleted
-  ;;   continuation may appear in code:
-  ;;    -- The CONT of the LAST node in a block may be a deleted
-  ;;       continuation when the original receiver of the continuation's
-  ;;       value was deleted. Note that DEST in a deleted continuation is
-  ;;       null, so it is easy to know not to attempt delivering any
-  ;;       values to the continuation.
-  ;;    -- Unreachable code that hasn't been deleted yet may receive
-  ;;       deleted continuations. All such code will be in blocks that
-  ;;       have DELETE-P set. All unreachable code is deleted by control
-  ;;       optimization, so the backend doesn't have to worry about this.
+  ;;    A continuation for which all control-related slots have the
+  ;;    default values. A continuation is unused during IR1 conversion
+  ;;    until it is assigned a block, and may be also be temporarily
+  ;;    unused during later manipulations of IR1. In a consistent
+  ;;    state there should never be any mention of :UNUSED
+  ;;    continuations. NEXT can have a non-null value if the next node
+  ;;    has already been determined.
   ;;
   ;; :BLOCK-START
-  ;;   The continuation that is the START of BLOCK. This is the only kind
-  ;;   of continuation that can have more than one use. The BLOCK's
-  ;;   START-USES is a list of all the uses.
-  ;;
-  ;; :DELETED-BLOCK-START
-  ;;   Like :BLOCK-START, but BLOCK has been deleted. A block
-  ;;   starting continuation is made into a deleted block start when
-  ;;   the block is deleted, but the continuation still may have
-  ;;   value semantics. Since there isn't any code left, next is
-  ;;   null.
+  ;;    The continuation that is the START of BLOCK.
   ;;
   ;; :INSIDE-BLOCK
-  ;;   A continuation that is the CONT of some node in BLOCK.
-  (kind :unused :type (member :unused :deleted :inside-block :block-start
-                             :deleted-block-start))
-  ;; The node which receives this value, if any. In a deleted
-  ;; continuation, this is null even though the node that receives
-  ;; this continuation may not yet be deleted.
-  (dest nil :type (or node null))
-  ;; If this is a NODE, then it is the node which is to be evaluated
-  ;; next. This is always null in :DELETED and :UNUSED continuations,
-  ;; and will be null in a :INSIDE-BLOCK continuation when this is the
-  ;; CONT of the LAST.
+  ;;    A continuation that is the NEXT of some node in BLOCK.
+  (kind :unused :type (member :unused :inside-block :block-start))
+  ;; A NODE which is to be evaluated next. Null only temporary.
   (next nil :type (or node null))
-  ;; an assertion on the type of this continuation's value
-  (asserted-type *wild-type* :type ctype)
-  ;; cached type of this continuation's value. If NIL, then this must
-  ;; be recomputed: see CONTINUATION-DERIVED-TYPE.
-  (%derived-type nil :type (or ctype null))
-  ;; Node where this continuation is used, if unique. This is always
-  ;; null in :DELETED and :UNUSED continuations, and is never null in
-  ;; :INSIDE-BLOCK continuations. In a :BLOCK-START continuation, the
-  ;; Block's START-USES indicate whether NIL means no uses or more
-  ;; than one use.
+  ;; the node where this CTRAN is used, if unique. This is always null
+  ;; in :UNUSED and :BLOCK-START CTRANs, and is never null in
+  ;; :INSIDE-BLOCK continuations.
   (use nil :type (or node null))
   ;; the basic block this continuation is in. This is null only in
-  ;; :DELETED and :UNUSED continuations. Note that blocks that are
-  ;; unreachable but still in the DFO may receive deleted
-  ;; continuations, so it isn't o.k. to assume that any continuation
-  ;; that you pick up out of its DEST node has a BLOCK.
-  (block nil :type (or cblock null))
-  ;; set to true when something about this continuation's value has
-  ;; changed. See REOPTIMIZE-CONTINUATION. This provides a way for IR1
+  ;; :UNUSED continuations.
+  (block nil :type (or cblock null)))
+
+(def!method print-object ((x ctran) stream)
+  (print-unreadable-object (x stream :type t :identity t)
+    (format stream "~D" (cont-num x))))
+
+;;; Linear VARiable. Multiple-value (possibly of unknown number)
+;;; temporal storage.
+(def!struct (lvar
+             (:make-load-form-fun ignore-it)
+             (:constructor make-lvar (&optional dest)))
+  ;; The node which receives this value. NIL only temporarily.
+  (dest nil :type (or node null))
+  ;; cached type of this lvar's value. If NIL, then this must be
+  ;; recomputed: see LVAR-DERIVED-TYPE.
+  (%derived-type nil :type (or ctype null))
+  ;; the node (if unique) or a list of nodes where this lvar is used.
+  (uses nil :type (or node list))
+  ;; set to true when something about this lvar's value has
+  ;; changed. See REOPTIMIZE-LVAR. This provides a way for IR1
   ;; optimize to determine which operands to a node have changed. If
   ;; the optimizer for this node type doesn't care, it can elect not
   ;; to clear this flag.
   (reoptimize t :type boolean)
-  ;; an indication of what we have proven about how this contination's
-  ;; type assertion is satisfied:
-  ;;
-  ;; NIL
-  ;;    No type check is necessary (proven type is a subtype of the assertion.)
-  ;;
-  ;; T
-  ;;    A type check is needed.
-  ;;
-  ;; :DELETED
-  ;;    Don't do a type check, but believe (intersect) the assertion.
-  ;;    A T check can be changed to :DELETED if we somehow prove the
-  ;;    check is unnecessary, or if we eliminate it through a policy
-  ;;    decision.
-  ;;
-  ;; :NO-CHECK
-  ;;    Type check generation sets the slot to this if a check is
-  ;;    called for, but it believes it has proven that the check won't
-  ;;    be done for policy reasons or because a safe implementation
-  ;;    will be used. In the latter case, LTN must ensure that a safe
-  ;;    implementation *is* used.
-  ;;
-  ;; :ERROR
-  ;;    There is a compile-time type error in some use of this
-  ;;    continuation. A type check should still be generated, but be
-  ;;    careful.
-  ;;
-  ;; This is computed lazily by CONTINUATION-DERIVED-TYPE, so use
-  ;; CONTINUATION-TYPE-CHECK instead of the %'ed slot accessor.
-  (%type-check t :type (member t nil :deleted :no-check :error))
-  ;; something or other that the back end annotates this continuation with
-  (info nil)
-  ;; uses of this continuation in the lexical environment. They are
-  ;; recorded so that when one continuation is substituted for another
-  ;; the environment may be updated properly.
-  (lexenv-uses nil :type list))
+  ;; Cached type which is checked by DEST. If NIL, then this must be
+  ;; recomputed: see LVAR-EXTERNALLY-CHECKABLE-TYPE.
+  (%externally-checkable-type nil :type (or null ctype))
+  ;; if the LVAR value is DYNAMIC-EXTENT, CLEANUP protecting it.
+  (dynamic-extent nil :type (or null cleanup))
+  ;; something or other that the back end annotates this lvar with
+  (info nil))
 
-(def!method print-object ((x continuation) stream)
-  (print-unreadable-object (x stream :type t :identity t)))
+(def!method print-object ((x lvar) stream)
+  (print-unreadable-object (x stream :type t :identity t)
+    (format stream "~D" (cont-num x))))
 
-(defstruct (node (:constructor nil)
-                (:copier nil))
-  ;; the bottom-up derived type for this node. This does not take into
-  ;; consideration output type assertions on this node (actually on its CONT).
-  (derived-type *wild-type* :type ctype)
+(def!struct (node (:constructor nil)
+                  (:include sset-element (number (incf *compiler-sset-counter*)))
+                  (:copier nil))
+  ;; unique ID for debugging
+  #!+sb-show (id (new-object-id) :read-only t)
   ;; True if this node needs to be optimized. This is set to true
-  ;; whenever something changes about the value of a continuation
-  ;; whose DEST is this node.
+  ;; whenever something changes about the value of an lvar whose DEST
+  ;; is this node.
   (reoptimize t :type boolean)
-  ;; the continuation which receives the value of this node. This also
-  ;; indicates what we do controlwise after evaluating this node. This
-  ;; may be null during IR1 conversion.
-  (cont nil :type (or continuation null))
-  ;; the continuation that this node is the next of. This is null
-  ;; during IR1 conversion when we haven't linked the node in yet or
-  ;; in nodes that have been deleted from the IR1 by UNLINK-NODE.
-  (prev nil :type (or continuation null))
+  ;; the ctran indicating what we do controlwise after evaluating this
+  ;; node. This is null if the node is the last in its block.
+  (next nil :type (or ctran null))
+  ;; the ctran that this node is the NEXT of. This is null during IR1
+  ;; conversion when we haven't linked the node in yet or in nodes
+  ;; that have been deleted from the IR1 by UNLINK-NODE.
+  (prev nil :type (or ctran null))
   ;; the lexical environment this node was converted in
   (lexenv *lexenv* :type lexenv)
   ;; a representation of the source code responsible for generating
   ;; can null out this slot.
   (tail-p nil :type boolean))
 
+(def!struct (valued-node (:conc-name node-)
+                         (:include node)
+                         (:constructor nil)
+                         (:copier nil))
+  ;; the bottom-up derived type for this node.
+  (derived-type *wild-type* :type ctype)
+  ;; Lvar, receiving the values, produced by this node. May be NIL if
+  ;; the value is unused.
+  (lvar nil :type (or lvar null)))
+
 ;;; Flags that are used to indicate various things about a block, such
 ;;; as what optimizations need to be done on it:
 ;;; -- REOPTIMIZE is set when something interesting happens the uses of a
-;;;    continuation whose Dest is in this block. This indicates that the
+;;;    lvar whose DEST is in this block. This indicates that the
 ;;;    value-driven (forward) IR1 optimizations should be done on this block.
 ;;; -- FLUSH-P is set when code in this block becomes potentially flushable,
-;;;    usually due to a continuation's DEST becoming null.
+;;;    usually due to an lvar's DEST becoming null.
 ;;; -- TYPE-CHECK is true when the type check phase should be run on this
 ;;;    block. IR1 optimize can introduce new blocks after type check has
 ;;;    already run. We need to check these blocks, but there is no point in
 ;;;    checking blocks we have already checked.
 ;;; -- DELETE-P is true when this block is used to indicate that this block
 ;;;    has been determined to be unreachable and should be deleted. IR1
-;;;    phases should not attempt to  examine or modify blocks with DELETE-P
+;;;    phases should not attempt to examine or modify blocks with DELETE-P
 ;;;    set, since they may:
 ;;;     - be in the process of being deleted, or
-;;;     - have no successors, or
-;;;     - receive :DELETED continuations.
+;;;     - have no successors.
 ;;; -- TYPE-ASSERTED, TEST-MODIFIED
 ;;;    These flags are used to indicate that something in this block
 ;;;    might be of interest to constraint propagation. TYPE-ASSERTED
-;;;    is set when a continuation type assertion is strengthened.
+;;;    is set when an lvar type assertion is strengthened.
 ;;;    TEST-MODIFIED is set whenever the test for the ending IF has
 ;;;    changed (may be true when there is no IF.)
-(def-boolean-attribute block
+(!def-boolean-attribute block
   reoptimize flush-p type-check delete-p type-asserted test-modified)
 
-(macrolet ((frob (slot)
-            `(defmacro ,(symbolicate "BLOCK-" slot) (block)
-               `(block-attributep (block-flags ,block) ,',slot))))
-  (frob reoptimize)
-  (frob flush-p)
-  (frob type-check)
-  (frob delete-p)
-  (frob type-asserted)
-  (frob test-modified))
+(macrolet ((defattr (block-slot)
+             `(defmacro ,block-slot (block)
+                `(block-attributep
+                  (block-flags ,block)
+                  ,(symbolicate (subseq (string ',block-slot) 6))))))
+  (defattr block-reoptimize)
+  (defattr block-flush-p)
+  (defattr block-type-check)
+  (defattr block-delete-p)
+  (defattr block-type-asserted)
+  (defattr block-test-modified))
 
 ;;; The CBLOCK structure represents a basic block. We include
 ;;; SSET-ELEMENT so that we can have sets of blocks. Initially the
 ;;; order. This latter numbering also forms the basis of the block
 ;;; numbering in the debug-info (though that is relative to the start
 ;;; of the function.)
-(defstruct (cblock (:include sset-element)
-                  (:constructor make-block (start))
-                  (:constructor make-block-key)
-                  (:conc-name block-)
-                  (:predicate block-p)
-                  (:copier copy-block))
+(def!struct (cblock (:include sset-element)
+                    (:constructor make-block (start))
+                    (:constructor make-block-key)
+                    (:conc-name block-)
+                    (:predicate block-p))
   ;; a list of all the blocks that are predecessors/successors of this
   ;; block. In well-formed IR1, most blocks will have one successor.
   ;; The only exceptions are:
   ;;  3. blocks with DELETE-P set (zero)
   (pred nil :type list)
   (succ nil :type list)
-  ;; the continuation which heads this block (either a :BLOCK-START or
-  ;; :DELETED-BLOCK-START), or NIL when we haven't made the start
-  ;; continuation yet (and in the dummy component head and tail
-  ;; blocks)
-  (start nil :type (or continuation null))
-  ;; a list of all the nodes that have START as their CONT
-  (start-uses nil :type list)
+  ;; the ctran which heads this block (a :BLOCK-START), or NIL when we
+  ;; haven't made the start ctran yet (and in the dummy component head
+  ;; and tail blocks)
+  (start nil :type (or ctran null))
   ;; the last node in this block. This is NIL when we are in the
   ;; process of building a block (and in the dummy component head and
   ;; tail blocks.)
   (prev nil :type (or null cblock))
   ;; This block's attributes: see above.
   (flags (block-attributes reoptimize flush-p type-check type-asserted
-                          test-modified)
-        :type attributes)
-  ;; CMU CL had a KILL slot here, documented as "set used by
-  ;; constraint propagation", which was used in constraint propagation
-  ;; as a list of LAMBDA-VARs killed, and in copy propagation as an
-  ;; SSET, representing I dunno what. I (WHN) found this confusing,
-  ;; and furthermore it caused type errors when I was trying to make
-  ;; the compiler produce fully general LAMBDA functions directly
-  ;; (instead of doing as CMU CL always did, producing extra little
-  ;; functions which return the LAMDBA you need) and therefore taking
-  ;; a new path through the compiler. So I split this into two:
-  ;;   KILL-LIST = list of LAMBDA-VARs killed, used in constraint propagation
-  ;;   KILL-SSET = an SSET value, used in copy propagation
-  (kill-list nil :type list)
-  (kill-sset nil :type (or sset null))
+                           test-modified)
+         :type attributes)
+  ;; in constraint propagation: list of LAMBDA-VARs killed in this block
+  ;; in copy propagation: list of killed TNs
+  (kill nil)
   ;; other sets used in constraint propagation and/or copy propagation
   (gen nil)
   (in nil)
   (out nil)
+  ;; Set of all blocks that dominate this block. NIL is interpreted
+  ;; as "all blocks in component".
+  (dominators nil :type (or null sset))
+  ;; the LOOP that this block belongs to
+  (loop nil :type (or null cloop))
+  ;; next block in the loop.
+  (loop-next nil :type (or null cblock))
   ;; the component this block is in, or NIL temporarily during IR1
   ;; conversion and in deleted blocks
-  (component *current-component* :type (or component null))
+  (component (progn
+               (aver-live-component *current-component*)
+               *current-component*)
+             :type (or component null))
   ;; a flag used by various graph-walking code to determine whether
   ;; this block has been processed already or what. We make this
   ;; initially NIL so that FIND-INITIAL-DFO doesn't have to scan the
   (flag nil)
   ;; some kind of info used by the back end
   (info nil)
-  ;; If true, then constraints that hold in this block and its
-  ;; successors by merit of being tested by its IF predecessor.
-  (test-constraint nil :type (or sset null)))
+  ;; what macroexpansions and source transforms happened "in" this block, used
+  ;; for xref
+  (xrefs nil :type list)
+  ;; Cache the physenv of a block during lifetime analysis. :NONE if
+  ;; no cached value has been stored yet.
+  (physenv-cache :none :type (or null physenv (member :none))))
 (def!method print-object ((cblock cblock) stream)
   (print-unreadable-object (cblock stream :type t :identity t)
-    (format stream ":START c~D" (cont-num (block-start cblock)))))
+    (format stream "~W :START c~W"
+            (block-number cblock)
+            (cont-num (block-start cblock)))))
 
 ;;; The BLOCK-ANNOTATION class is inherited (via :INCLUDE) by
 ;;; different BLOCK-INFO annotation structures so that code
 ;;; (specifically control analysis) can be shared.
-(defstruct (block-annotation (:constructor nil)
-                            (:copier nil))
+(def!struct (block-annotation (:constructor nil)
+                              (:copier nil))
   ;; The IR1 block that this block is in the INFO for.
   (block (missing-arg) :type cblock)
   ;; the next and previous block in emission order (not DFO). This
-  ;; determines which block we drop though to, and also used to chain
-  ;; together overflow blocks that result from splitting of IR2 blocks
-  ;; in lifetime analysis.
+  ;; determines which block we drop though to, and is also used to
+  ;; chain together overflow blocks that result from splitting of IR2
+  ;; blocks in lifetime analysis.
   (next nil :type (or block-annotation null))
   (prev nil :type (or block-annotation null)))
 
 ;;; A COMPONENT structure provides a handle on a connected piece of
 ;;; the flow graph. Most of the passes in the compiler operate on
 ;;; COMPONENTs rather than on the entire flow graph.
-(defstruct (component (:copier nil))
+;;;
+;;; According to the CMU CL internals/front.tex, the reason for
+;;; separating compilation into COMPONENTs is
+;;;   to increase the efficiency of large block compilations. In
+;;;   addition to improving locality of reference and reducing the
+;;;   size of flow analysis problems, this allows back-end data
+;;;   structures to be reclaimed after the compilation of each
+;;;   component.
+(def!struct (component (:copier nil)
+                       (:constructor
+                        make-component
+                        (head
+                         tail &aux
+                         (last-block tail)
+                         (outer-loop (make-loop :kind :outer :head head)))))
+  ;; unique ID for debugging
+  #!+sb-show (id (new-object-id) :read-only t)
   ;; the kind of component
   ;;
   ;; (The terminology here is left over from before
   ;; the blocks that are the dummy head and tail of the DFO
   ;;
   ;; Entry/exit points have these blocks as their
-  ;; predecessors/successors. Null temporarily. The start and return
-  ;; from each non-deleted function is linked to the component head
-  ;; and tail. Until physical environment analysis links NLX entry
-  ;; stubs to the component head, every successor of the head is a
-  ;; function start (i.e. begins with a BIND node.)
-  (head nil :type (or null cblock))
-  (tail nil :type (or null cblock))
+  ;; predecessors/successors. The start and return from each
+  ;; non-deleted function is linked to the component head and
+  ;; tail. Until physical environment analysis links NLX entry stubs
+  ;; to the component head, every successor of the head is a function
+  ;; start (i.e. begins with a BIND node.)
+  (head (missing-arg) :type cblock)
+  (tail (missing-arg) :type cblock)
+  ;; New blocks are inserted before this.
+  (last-block (missing-arg) :type cblock)
   ;; This becomes a list of the CLAMBDA structures for all functions
   ;; in this component. OPTIONAL-DISPATCHes are represented only by
   ;; their XEP and other associated lambdas. This doesn't contain any
   ;; deleted or LET lambdas.
   ;;
   ;; Note that logical associations between CLAMBDAs and COMPONENTs
-  ;; seem to exist for a while before this is initialized. In
-  ;; particular, I got burned by writing some code to use this value
-  ;; to decide which components need LOCAL-CALL-ANALYZE, when it turns
-  ;; out that LOCAL-CALL-ANALYZE had a role in initializing this value
+  ;; seem to exist for a while before this is initialized. See e.g.
+  ;; the NEW-FUNCTIONALS slot. In particular, I got burned by writing
+  ;; some code to use this value to decide which components need
+  ;; LOCALL-ANALYZE-COMPONENT, when it turns out that
+  ;; LOCALL-ANALYZE-COMPONENT had a role in initializing this value
   ;; (and DFO stuff does too, maybe). Also, even after it's
   ;; initialized, it might change as CLAMBDAs are deleted or merged.
   ;; -- WHN 2001-09-30
   (lambdas () :type list)
-  ;; a list of FUNCTIONAL structures for functions that are newly
-  ;; converted, and haven't been local-call analyzed yet. Initially
-  ;; functions are not in the LAMBDAS list. LOCAL-CALL-ANALYZE moves
-  ;; them there (possibly as LETs, or implicitly as XEPs if an
-  ;; OPTIONAL-DISPATCH.) Between runs of LOCAL-CALL-ANALYZE there may
-  ;; be some debris of converted or even deleted functions in this
-  ;; list.
-  (new-functions () :type list)
-  ;; If this is true, then there is stuff in this component that could
-  ;; benefit from further IR1 optimization.
-  (reoptimize t :type boolean)
+  ;; a list of FUNCTIONALs for functions that are newly converted, and
+  ;; haven't been local-call analyzed yet. Initially functions are not
+  ;; in the LAMBDAS list. Local call analysis moves them there
+  ;; (possibly as LETs, or implicitly as XEPs if an OPTIONAL-DISPATCH.)
+  ;; Between runs of local call analysis there may be some debris of
+  ;; converted or even deleted functions in this list.
+  (new-functionals () :type list)
+  ;; If this is :MAYBE, then there is stuff in this component that
+  ;; could benefit from further IR1 optimization. T means that
+  ;; reoptimization is necessary.
+  (reoptimize t :type (member nil :maybe t))
   ;; If this is true, then the control flow in this component was
   ;; messed up by IR1 optimizations, so the DFO should be recomputed.
   (reanalyze nil :type boolean)
   ;; some sort of name for the code in this component
-  (name "<unknown>" :type simple-string)
-  ;; some kind of info used by the back end
-  (info nil)
-  ;; the SOURCE-INFO structure describing where this component was
-  ;; compiled from
-  (source-info *source-info* :type source-info)
+  (name "<unknown>" :type t)
+  ;; When I am a child, this is :NO-IR2-YET.
+  ;; In my adulthood, IR2 stores notes to itself here.
+  ;; After I have left the great wheel and am staring into the GC, this
+  ;;   is set to :DEAD to indicate that it's a gruesome error to operate
+  ;;   on me (e.g. by using me as *CURRENT-COMPONENT*, or by pushing
+  ;;   LAMBDAs onto my NEW-FUNCTIONALS, as in sbcl-0.pre7.115).
+  (info :no-ir2-yet :type (or ir2-component (member :no-ir2-yet :dead)))
   ;; count of the number of inline expansions we have done while
   ;; compiling this component, to detect infinite or exponential
   ;; blowups
   ;; arguments for the note, or the FUN-TYPE that would have
   ;; enabled the transformation but failed to match.
   (failed-optimizations (make-hash-table :test 'eq) :type hash-table)
-  ;; This is similar to NEW-FUNCTIONS, but is used when a function has
-  ;; already been analyzed, but new references have been added by
-  ;; inline expansion. Unlike NEW-FUNCTIONS, this is not disjoint from
-  ;; COMPONENT-LAMBDAS.
-  (reanalyze-functions nil :type list))
+  ;; This is similar to NEW-FUNCTIONALS, but is used when a function
+  ;; has already been analyzed, but new references have been added by
+  ;; inline expansion. Unlike NEW-FUNCTIONALS, this is not disjoint
+  ;; from COMPONENT-LAMBDAS.
+  (reanalyze-functionals nil :type list)
+  (delete-blocks nil :type list)
+  (nlx-info-generated-p nil :type boolean)
+  ;; this is filled by physical environment analysis
+  (dx-lvars nil :type list)
+  ;; The default LOOP in the component.
+  (outer-loop (missing-arg) :type cloop)
+  ;; The current sset index
+  (sset-number 0 :type fixnum))
 (defprinter (component :identity t)
   name
+  #!+sb-show id
   (reanalyze :test reanalyze))
 
+;;; Check that COMPONENT is suitable for roles which involve adding
+;;; new code. (gotta love imperative programming with lotso in-place
+;;; side effects...)
+(defun aver-live-component (component)
+  ;; FIXME: As of sbcl-0.pre7.115, we're asserting that
+  ;; COMPILE-COMPONENT hasn't happened yet. Might it be even better
+  ;; (certainly stricter, possibly also correct...) to assert that
+  ;; IR1-FINALIZE hasn't happened yet?
+  (aver (not (eql (component-info component) :dead))))
+
 ;;; Before sbcl-0.7.0, there were :TOPLEVEL things which were magical
 ;;; in multiple ways. That's since been refactored into the orthogonal
 ;;; properties "optimized for locall with no arguments" and "externally
       (lambda-has-external-references-p clambda)))
 (defun component-toplevelish-p (component)
   (member (component-kind component)
-         '(:toplevel :complex-toplevel)))
+          '(:toplevel :complex-toplevel)))
 
 ;;; A CLEANUP structure represents some dynamic binding action. Blocks
 ;;; are annotated with the current CLEANUP so that dynamic bindings
 ;;; The "mess-up" action is explicitly represented by a funny function
 ;;; call or ENTRY node.
 ;;;
-;;; We guarantee that CLEANUPs only need to be done at block boundaries
-;;; by requiring that the exit continuations initially head their
+;;; We guarantee that CLEANUPs only need to be done at block
+;;; boundaries by requiring that the exit ctrans initially head their
 ;;; blocks, and then by not merging blocks when there is a cleanup
 ;;; change.
-(defstruct (cleanup (:copier nil))
+(def!struct (cleanup (:copier nil))
   ;; the kind of thing that has to be cleaned up
   (kind (missing-arg)
-       :type (member :special-bind :catch :unwind-protect :block :tagbody))
+        :type (member :special-bind :catch :unwind-protect
+                      :block :tagbody :dynamic-extent))
   ;; the node that messes things up. This is the last node in the
   ;; non-messed-up environment. Null only temporarily. This could be
   ;; deleted due to unreachability.
   (mess-up nil :type (or node null))
-  ;; a list of all the NLX-INFO structures whose NLX-INFO-CLEANUP is
-  ;; this cleanup. This is filled in by physical environment analysis.
-  (nlx-info nil :type list))
+  ;; For all kinds, except :DYNAMIC-EXTENT: a list of all the NLX-INFO
+  ;; structures whose NLX-INFO-CLEANUP is this cleanup. This is filled
+  ;; in by physical environment analysis.
+  ;;
+  ;; For :DYNAMIC-EXTENT: a list of all DX LVARs, preserved by this
+  ;; cleanup. This is filled when the cleanup is created (now by
+  ;; locall call analysis) and is rechecked by physical environment
+  ;; analysis. (For closures this is a list of the allocating node -
+  ;; during IR1, and a list of the argument LVAR of the allocator -
+  ;; after physical environment analysis.)
+  (info nil :type list))
 (defprinter (cleanup :identity t)
   kind
   mess-up
-  (nlx-info :test nlx-info))
+  (info :test info))
 
 ;;; A PHYSENV represents the result of physical environment analysis.
 ;;;
 ;;; structure is attached to INFO and used to keep track of
 ;;; associations between these names and less-abstract things (like
 ;;; TNs, or eventually stack slots and registers). -- WHN 2001-09-29
-(defstruct (physenv (:copier nil))
+(def!struct (physenv (:copier nil))
   ;; the function that allocates this physical environment
-  (function (missing-arg) :type clambda)
-  #| ; seems not to be used as of sbcl-0.pre7.51
-  ;; a list of all the lambdas that allocate variables in this
-  ;; physical environment
-  (lambdas nil :type list)
-  |#
+  (lambda (missing-arg) :type clambda :read-only t)
   ;; This ultimately converges to a list of all the LAMBDA-VARs and
   ;; NLX-INFOs needed from enclosing environments by code in this
   ;; physical environment. In the meantime, it may be
   ;; some kind of info used by the back end
   (info nil))
 (defprinter (physenv :identity t)
-  function
+  lambda
   (closure :test closure)
   (nlx-info :test nlx-info))
 
 ;;; The tail set is somewhat approximate, because it is too early to
 ;;; be sure which calls will be tail-recursive. Any call that *might*
 ;;; end up tail-recursive causes TAIL-SET merging.
-(defstruct (tail-set)
+(def!struct (tail-set)
   ;; a list of all the LAMBDAs in this tail set
-  (functions nil :type list)
+  (funs nil :type list)
   ;; our current best guess of the type returned by these functions.
   ;; This is the union across all the functions of the return node's
   ;; RESULT-TYPE, excluding local calls.
   ;; some info used by the back end
   (info nil))
 (defprinter (tail-set :identity t)
-  functions
+  funs
   type
   (info :test info))
 
-;;; The NLX-Info structure is used to collect various information
-;;; about non-local exits. This is effectively an annotation on the
-;;; CONTINUATION, although it is accessed by searching in the
+;;; An NLX-INFO structure is used to collect various information about
+;;; non-local exits. This is effectively an annotation on the
+;;; continuation, although it is accessed by searching in the
 ;;; PHYSENV-NLX-INFO.
-(def!struct (nlx-info (:make-load-form-fun ignore-it))
+(def!struct (nlx-info
+             (:constructor make-nlx-info (cleanup
+                                          exit
+                                          &aux
+                                          (block (first (block-succ
+                                                         (node-block exit))))))
+             (:make-load-form-fun ignore-it))
   ;; the cleanup associated with this exit. In a catch or
   ;; unwind-protect, this is the :CATCH or :UNWIND-PROTECT cleanup,
   ;; and not the cleanup for the escape block. The CLEANUP-KIND of
   ;; this thus provides a good indication of what kind of exit is
   ;; being done.
   (cleanup (missing-arg) :type cleanup)
-  ;; the continuation exited to (the CONT of the EXIT nodes). If this
-  ;; exit is from an escape function (CATCH or UNWIND-PROTECT), then
-  ;; physical environment analysis deletes the escape function and
-  ;; instead has the %NLX-ENTRY use this continuation.
+  ;; the ``continuation'' exited to (the block, succeeding the EXIT
+  ;; nodes). If this exit is from an escape function (CATCH or
+  ;; UNWIND-PROTECT), then physical environment analysis deletes the
+  ;; escape function and instead has the %NLX-ENTRY use this
+  ;; continuation.
   ;;
-  ;; This slot is primarily an indication of where this exit delivers
-  ;; its values to (if any), but it is also used as a sort of name to
-  ;; allow us to find the NLX-Info that corresponds to a given exit.
-  ;; For this purpose, the Entry must also be used to disambiguate,
-  ;; since exits to different places may deliver their result to the
-  ;; same continuation.
-  (continuation (missing-arg) :type continuation)
+  ;; This slot is used as a sort of name to allow us to find the
+  ;; NLX-INFO that corresponds to a given exit. For this purpose, the
+  ;; ENTRY must also be used to disambiguate, since exits to different
+  ;; places may deliver their result to the same continuation.
+  (block (missing-arg) :type cblock)
   ;; the entry stub inserted by physical environment analysis. This is
-  ;; a block containing a call to the %NLX-Entry funny function that
+  ;; a block containing a call to the %NLX-ENTRY funny function that
   ;; has the original exit destination as its successor. Null only
   ;; temporarily.
   (target nil :type (or cblock null))
+  ;; for a lexical exit it determines whether tag existence check is
+  ;; needed
+  (safe-p nil :type boolean)
   ;; some kind of info used by the back end
   info)
 (defprinter (nlx-info :identity t)
-  continuation
+  block
   target
   info)
 \f
 ;;; allows us to easily substitute one for the other without actually
 ;;; hacking the flow graph.
 (def!struct (leaf (:make-load-form-fun ignore-it)
-                 (:constructor nil))
-  ;; some name for this leaf. The exact significance of the name
-  ;; depends on what kind of leaf it is. In a LAMBDA-VAR or
-  ;; GLOBAL-VAR, this is the symbol name of the variable. In a
-  ;; functional that is from a DEFUN, this is the defined name. In
-  ;; other functionals, this is a descriptive string.
+                  (:include sset-element (number (incf *compiler-sset-counter*)))
+                  (:constructor nil))
+  ;; unique ID for debugging
+  #!+sb-show (id (new-object-id) :read-only t)
+  ;; (For public access to this slot, use LEAF-SOURCE-NAME.)
+  ;;
+  ;; the name of LEAF as it appears in the source, e.g. 'FOO or '(SETF
+  ;; FOO) or 'N or '*Z*, or the special .ANONYMOUS. value if there's
+  ;; no name for this thing in the source (as can happen for
+  ;; FUNCTIONALs, e.g. for anonymous LAMBDAs or for functions for
+  ;; top-level forms; and can also happen for anonymous constants) or
+  ;; perhaps also if the match between the name and the thing is
+  ;; skewed enough (e.g. for macro functions or method functions) that
+  ;; we don't want to have that name affect compilation
   ;;
-  ;; KLUDGE: Note that at least for LAMBDA-VARs, this is important not
-  ;; just for debugging but for ordinary compilation as well. In
-  ;; particular, in RECOGNIZE-KNOWN-CALL function calls are compiled
-  ;; differently based on the LEAF-NAME.
-  (name nil :type t)
+  ;; (We use .ANONYMOUS. here more or less the way we'd ordinarily use
+  ;; NIL, but we're afraid to use NIL because it's a symbol which could
+  ;; be the name of a leaf, if only the constant named NIL.)
+  ;;
+  ;; The value of this slot in can affect ordinary runtime behavior,
+  ;; e.g. of special variables and known functions, not just debugging.
+  ;;
+  ;; See also the LEAF-DEBUG-NAME function and the
+  ;; FUNCTIONAL-%DEBUG-NAME slot.
+  (%source-name (missing-arg)
+                :type (or symbol (and cons (satisfies legal-fun-name-p)))
+                :read-only t)
   ;; the type which values of this leaf must have
   (type *universal-type* :type ctype)
-  ;; where the TYPE information came from:
+  ;; the type which values of this leaf have last been defined to have
+  ;; (but maybe won't have in future, in case of redefinition)
+  (defined-type *universal-type* :type ctype)
+  ;; where the TYPE information came from (in order, from strongest to weakest):
   ;;  :DECLARED, from a declaration.
+  ;;  :DEFINED-HERE, from examination of the definition in the same file.
+  ;;  :DEFINED, from examination of the definition elsewhere.
+  ;;  :DEFINED-METHOD, implicit, piecemeal declarations from CLOS.
   ;;  :ASSUMED, from uses of the object.
-  ;;  :DEFINED, from examination of the definition.
-  ;; FIXME: This should be a named type. (LEAF-WHERE-FROM? Or
-  ;; perhaps just WHERE-FROM, since it's not just used in LEAF,
-  ;; but also in various DEFINE-INFO-TYPEs in globaldb.lisp,
-  ;; and very likely elsewhere too.)
-  (where-from :assumed :type (member :declared :assumed :defined))
+  (where-from :assumed :type (member :declared :assumed :defined-here :defined :defined-method))
   ;; list of the REF nodes for this leaf
   (refs () :type list)
   ;; true if there was ever a REF or SET node for this leaf. This may
   ;; be true when REFS and SETS are null, since code can be deleted.
   (ever-used nil :type boolean)
+  ;; is it declared dynamic-extent, or truly-dynamic-extent?
+  (extent nil :type (member nil :maybe-dynamic :always-dynamic :indefinite))
   ;; some kind of info used by the back end
   (info nil))
 
+(defun leaf-dynamic-extent (leaf)
+  (let ((extent (leaf-extent leaf)))
+    (unless (member extent '(nil :indefinite))
+      extent)))
+
+;;; LEAF name operations
+;;;
+;;; KLUDGE: wants CLOS..
+(defun leaf-has-source-name-p (leaf)
+  (not (eq (leaf-%source-name leaf)
+           '.anonymous.)))
+(defun leaf-source-name (leaf)
+  (aver (leaf-has-source-name-p leaf))
+  (leaf-%source-name leaf))
+(defun leaf-debug-name (leaf)
+  (if (functional-p leaf)
+      ;; FUNCTIONALs have additional %DEBUG-NAME behavior.
+      (functional-debug-name leaf)
+      ;; Other objects just use their source name.
+      ;;
+      ;; (As of sbcl-0.pre7.85, there are a few non-FUNCTIONAL
+      ;; anonymous objects, (anonymous constants..) and those would
+      ;; fail here if we ever tried to get debug names from them, but
+      ;; it looks as though it's never interesting to get debug names
+      ;; from them, so it's moot. -- WHN)
+      (leaf-source-name leaf)))
+(defun leaf-%debug-name (leaf)
+  (when (functional-p leaf)
+    (functional-%debug-name leaf)))
+
 ;;; The CONSTANT structure is used to represent known constant values.
-;;; If NAME is not null, then it is the name of the named constant
-;;; which this leaf corresponds to, otherwise this is an anonymous
-;;; constant.
-(def!struct (constant (:include leaf))
+;;; Since the same constant leaf may be shared between named and anonymous
+;;; constants, %SOURCE-NAME is never used.
+(def!struct (constant (:constructor make-constant (value
+                                                   &aux
+                                                   (type (ctype-of value))
+                                                   (%source-name '.anonymous.)
+                                                   (where-from :defined)))
+                      (:include leaf))
   ;; the value of the constant
-  (value nil :type t))
+  (value (missing-arg) :type t)
+  ;; Boxed TN for this constant, if any.
+  (boxed-tn nil :type (or null tn)))
 (defprinter (constant :identity t)
-  (name :test name)
   value)
 
 ;;; The BASIC-VAR structure represents information common to all
 ;;; variables which don't correspond to known local functions.
-(def!struct (basic-var (:include leaf) (:constructor nil))
+(def!struct (basic-var (:include leaf)
+                       (:constructor nil))
   ;; Lists of the set nodes for this variable.
   (sets () :type list))
 
 ;;; The GLOBAL-VAR structure represents a value hung off of the symbol
-;;; NAME. We use a :CONSTANT VAR when we know that the thing is a
-;;; constant, but don't know what the value is at compile time.
+;;; NAME.
 (def!struct (global-var (:include basic-var))
   ;; kind of variable described
   (kind (missing-arg)
-       :type (member :special :global-function :global)))
+        :type (member :special :global-function :global :unknown)))
 (defprinter (global-var :identity t)
-  name
+  %source-name
+  #!+sb-show id
   (type :test (not (eq type *universal-type*)))
+  (defined-type :test (not (eq defined-type *universal-type*)))
   (where-from :test (not (eq where-from :assumed)))
   kind)
 
-;;; The SLOT-ACCESSOR structure represents slot accessor functions. It
-;;; is a subtype of GLOBAL-VAR to make it look more like a normal
-;;; function.
-(def!struct (slot-accessor (:include global-var
-                                    (where-from :defined)
-                                    (kind :global-function)))
-  ;; The description of the structure that this is an accessor for.
-  (for (missing-arg) :type sb!xc:class)
-  ;; The slot description of the slot.
-  (slot (missing-arg)))
-(defprinter (slot-accessor :identity t)
-  name
-  for
-  slot)
-
 ;;; A DEFINED-FUN represents a function that is defined in the same
 ;;; compilation block, or that has an inline expansion, or that has a
 ;;; non-NIL INLINEP value. Whenever we change the INLINEP state (i.e.
 ;;; an inline proclamation) we copy the structure so that former
 ;;; INLINEP values are preserved.
 (def!struct (defined-fun (:include global-var
-                                  (where-from :defined)
-                                  (kind :global-function)))
+                                   (where-from :defined)
+                                   (kind :global-function)))
   ;; The values of INLINEP and INLINE-EXPANSION initialized from the
   ;; global environment.
   (inlinep nil :type inlinep)
   (inline-expansion nil :type (or cons null))
-  ;; the block-local definition of this function (either because it
-  ;; was semi-inline, or because it was defined in this block). If
-  ;; this function is not an entry point, then this may be deleted or
-  ;; LET-converted. Null if we haven't converted the expansion yet.
-  (functional nil :type (or functional null)))
+  ;; List of functionals corresponding to this DEFINED-FUN: either from the
+  ;; conversion of a NAMED-LAMBDA, or from inline-expansion (see
+  ;; RECOGNIZE-KNOWN-CALL) - we need separate functionals for each policy in
+  ;; which the function is used.
+  (functionals nil :type list))
 (defprinter (defined-fun :identity t)
-  name
+  %source-name
+  #!+sb-show id
   inlinep
-  (functional :test functional))
+  (functionals :test functionals))
 \f
 ;;;; function stuff
 
 ;;; We don't normally manipulate function types for defined functions,
 ;;; but if someone wants to know, an approximation is there.
 (def!struct (functional (:include leaf
-                                 (where-from :defined)
-                                 (type (specifier-type 'function))))
+                                  (%source-name '.anonymous.)
+                                  (where-from :defined)
+                                  (type (specifier-type 'function))))
+  ;; (For public access to this slot, use LEAF-DEBUG-NAME.)
+  ;;
+  ;; the name of FUNCTIONAL for debugging purposes, or NIL if we
+  ;; should just let the SOURCE-NAME fall through
+  ;;
+  ;; Unlike the SOURCE-NAME slot, this slot's value should never
+  ;; affect ordinary code behavior, only debugging/diagnostic behavior.
+  ;;
+  ;; Ha.  Ah, the starry-eyed idealism of the writer of the above
+  ;; paragraph.  FUNCTION-LAMBDA-EXPRESSION's behaviour, as of
+  ;; sbcl-0.7.11.x, differs if the name of the a function is a string
+  ;; or not, as if it is a valid function name then it can look for an
+  ;; inline expansion.
+  ;;
+  ;; E.g. for the function which implements (DEFUN FOO ...), we could
+  ;; have
+  ;;   %SOURCE-NAME=FOO
+  ;;   %DEBUG-NAME=NIL
+  ;; for the function which implements the top level form
+  ;; (IN-PACKAGE :FOO) we could have
+  ;;   %SOURCE-NAME=NIL
+  ;;   %DEBUG-NAME=(TOP-LEVEL-FORM (IN-PACKAGE :FOO)
+  ;; for the function which implements FOO in
+  ;;   (DEFUN BAR (...) (FLET ((FOO (...) ...)) ...))
+  ;; we could have
+  ;;   %SOURCE-NAME=FOO
+  ;;   %DEBUG-NAME=(FLET FOO)
+  ;; and for the function which implements FOO in
+  ;;   (DEFMACRO FOO (...) ...)
+  ;; we could have
+  ;;   %SOURCE-NAME=FOO (or maybe .ANONYMOUS.?)
+  ;;   %DEBUG-NAME=(MACRO-FUNCTION FOO)
+  (%debug-name nil
+               :type (or null (not (satisfies legal-fun-name-p)))
+               :read-only t)
   ;; some information about how this function is used. These values
   ;; are meaningful:
   ;;
   ;;    NIL
-  ;;   an ordinary function, callable using local call
+  ;;    an ordinary function, callable using local call
   ;;
   ;;    :LET
-  ;;   a lambda that is used in only one local call, and has in
-  ;;   effect been substituted directly inline. The return node is
-  ;;   deleted, and the result is computed with the actual result
-  ;;   continuation for the call.
+  ;;    a lambda that is used in only one local call, and has in
+  ;;    effect been substituted directly inline. The return node is
+  ;;    deleted, and the result is computed with the actual result
+  ;;    lvar for the call.
   ;;
   ;;    :MV-LET
-  ;;   Similar to :LET, but the call is an MV-CALL.
+  ;;    Similar to :LET (as per FUNCTIONAL-LETLIKE-P), but the call
+  ;;    is an MV-CALL.
   ;;
   ;;    :ASSIGNMENT
-  ;;   similar to a LET, but can have other than one call as long as
-  ;;   there is at most one non-tail call.
+  ;;    similar to a LET (as per FUNCTIONAL-SOMEWHAT-LETLIKE-P), but
+  ;;    can have other than one call as long as there is at most
+  ;;    one non-tail call.
   ;;
   ;;    :OPTIONAL
-  ;;   a lambda that is an entry-point for an optional-dispatch.
-  ;;   Similar to NIL, but requires greater caution, since local call
-  ;;   analysis may create new references to this function. Also, the
-  ;;   function cannot be deleted even if it has *no* references. The
-  ;;   OPTIONAL-DISPATCH is in the LAMDBA-OPTIONAL-DISPATCH.
+  ;;    a lambda that is an entry point for an OPTIONAL-DISPATCH.
+  ;;    Similar to NIL, but requires greater caution, since local call
+  ;;    analysis may create new references to this function. Also, the
+  ;;    function cannot be deleted even if it has *no* references. The
+  ;;    OPTIONAL-DISPATCH is in the LAMDBA-OPTIONAL-DISPATCH.
   ;;
   ;;    :EXTERNAL
-  ;;   an external entry point lambda. The function it is an entry
-  ;;   for is in the ENTRY-FUNCTION slot.
+  ;;    an external entry point lambda. The function it is an entry
+  ;;    for is in the ENTRY-FUN slot.
   ;;
   ;;    :TOPLEVEL
-  ;;   a top level lambda, holding a compiled top level form.
-  ;;   Compiled very much like NIL, but provides an indication of
-  ;;   top level context. A :TOPLEVEL lambda should have *no*
-  ;;   references. Its ENTRY-FUNCTION is a self-pointer.
+  ;;    a top level lambda, holding a compiled top level form.
+  ;;    Compiled very much like NIL, but provides an indication of
+  ;;    top level context. A :TOPLEVEL lambda should have *no*
+  ;;    references. Its ENTRY-FUN is a self-pointer.
   ;;
   ;;    :TOPLEVEL-XEP
-  ;;   After a component is compiled, we clobber any top level code
-  ;;   references to its non-closure XEPs with dummy FUNCTIONAL
-  ;;   structures having this kind. This prevents the retained
-  ;;   top level code from holding onto the IR for the code it
-  ;;   references.
+  ;;    After a component is compiled, we clobber any top level code
+  ;;    references to its non-closure XEPs with dummy FUNCTIONAL
+  ;;    structures having this kind. This prevents the retained
+  ;;    top level code from holding onto the IR for the code it
+  ;;    references.
   ;;
   ;;    :ESCAPE
   ;;    :CLEANUP
-  ;;   special functions used internally by CATCH and UNWIND-PROTECT.
-  ;;   These are pretty much like a normal function (NIL), but are
-  ;;   treated specially by local call analysis and stuff. Neither
-  ;;   kind should ever be given an XEP even though they appear as
-  ;;   args to funny functions. An :ESCAPE function is never actually
-  ;;   called, and thus doesn't need to have code generated for it.
+  ;;    special functions used internally by CATCH and UNWIND-PROTECT.
+  ;;    These are pretty much like a normal function (NIL), but are
+  ;;    treated specially by local call analysis and stuff. Neither
+  ;;    kind should ever be given an XEP even though they appear as
+  ;;    args to funny functions. An :ESCAPE function is never actually
+  ;;    called, and thus doesn't need to have code generated for it.
   ;;
   ;;    :DELETED
-  ;;   This function has been found to be uncallable, and has been
-  ;;   marked for deletion.
+  ;;    This function has been found to be uncallable, and has been
+  ;;    marked for deletion.
+  ;;
+  ;;    :ZOMBIE
+  ;;    Effectless [MV-]LET; has no BIND node.
   (kind nil :type (member nil :optional :deleted :external :toplevel
-                         :escape :cleanup :let :mv-let :assignment
-                         :toplevel-xep))
+                          :escape :cleanup :let :mv-let :assignment
+                          :zombie :toplevel-xep))
   ;; Is this a function that some external entity (e.g. the fasl dumper)
   ;; refers to, so that even when it appears to have no references, it
   ;; shouldn't be deleted? In the old days (before
   ;; KIND was :TOPLEVEL. Now it must be set explicitly, both for
   ;; :TOPLEVEL functions and for any other kind of functions that we
   ;; want to dump or return from #'CL:COMPILE or whatever.
-  (has-external-references-p nil) 
+  (has-external-references-p nil)
   ;; In a normal function, this is the external entry point (XEP)
   ;; lambda for this function, if any. Each function that is used
   ;; other than in a local call has an XEP, and all of the
   ;; :TOPLEVEL lambda (which is its own XEP) this is a self-pointer.
   ;;
   ;; With all other kinds, this is null.
-  (entry-function nil :type (or functional null))
-  ;; the value of any inline/notinline declaration for a local function
+  (entry-fun nil :type (or functional null))
+  ;; the value of any inline/notinline declaration for a local
+  ;; function (or NIL in any case if no inline expansion is available)
   (inlinep nil :type inlinep)
   ;; If we have a lambda that can be used as in inline expansion for
   ;; this function, then this is it. If there is no source-level
-  ;; lambda corresponding to this function then this is Null (but then
+  ;; lambda corresponding to this function then this is null (but then
   ;; INLINEP will always be NIL as well.)
   (inline-expansion nil :type list)
-  ;; the lexical environment that the inline-expansion should be converted in
+  ;; the lexical environment that the INLINE-EXPANSION should be converted in
   (lexenv *lexenv* :type lexenv)
   ;; the original function or macro lambda list, or :UNSPECIFIED if
   ;; this is a compiler created function
   (arg-documentation nil :type (or list (member :unspecified)))
+  ;; the documentation string for the lambda
+  (documentation nil :type (or null string))
+  ;; Node, allocating closure for this lambda. May be NIL when we are
+  ;; sure that no closure is needed.
+  (allocator nil :type (or null combination))
   ;; various rare miscellaneous info that drives code generation & stuff
-  (plist () :type list))
+  (plist () :type list)
+  ;; xref information for this functional (only used for functions with an
+  ;; XEP)
+  (xref () :type list)
+  ;; True if this functional was created from an inline expansion. This
+  ;; is either T, or the GLOBAL-VAR for which it is an expansion.
+  (inline-expanded nil))
 (defprinter (functional :identity t)
-  name)
+  %source-name
+  %debug-name
+  #!+sb-show id)
+
+;;; Is FUNCTIONAL LET-converted? (where we're indifferent to whether
+;;; it returns one value or multiple values)
+(defun functional-letlike-p (functional)
+  (member (functional-kind functional)
+          '(:let :mv-let)))
+
+;;; Is FUNCTIONAL sorta LET-converted? (where even an :ASSIGNMENT counts)
+;;;
+;;; FIXME: I (WHN) don't understand this one well enough to give a good
+;;; definition or even a good function name, it's just a literal copy
+;;; of a CMU CL idiom. Does anyone have a better name or explanation?
+(defun functional-somewhat-letlike-p (functional)
+  (or (functional-letlike-p functional)
+      (eql (functional-kind functional) :assignment)))
+
+;;; FUNCTIONAL name operations
+(defun functional-debug-name (functional)
+  ;; FUNCTIONAL-%DEBUG-NAME takes precedence over FUNCTIONAL-SOURCE-NAME
+  ;; here because we want different debug names for the functions in
+  ;; DEFUN FOO and FLET FOO even though they have the same source name.
+  (or (functional-%debug-name functional)
+      ;; Note that this will cause an error if the function is
+      ;; anonymous. In SBCL (as opposed to CMU CL) we make all
+      ;; FUNCTIONALs have debug names. The CMU CL code didn't bother
+      ;; in many FUNCTIONALs, especially those which were likely to be
+      ;; optimized away before the user saw them. However, getting
+      ;; that right requires a global understanding of the code,
+      ;; which seems bad, so we just require names for everything.
+      (leaf-source-name functional)))
 
 ;;; The CLAMBDA only deals with required lexical arguments. Special,
 ;;; optional, keyword and rest arguments are handled by transforming
 ;;; into simpler stuff.
 (def!struct (clambda (:include functional)
-                    (:conc-name lambda-)
-                    (:predicate lambda-p)
-                    (:constructor make-lambda)
-                    (:copier copy-lambda))
-  ;; list of LAMBDA-VAR descriptors for args
-  (vars nil :type list)
+                     (:conc-name lambda-)
+                     (:predicate lambda-p)
+                     (:constructor make-lambda)
+                     (:copier copy-lambda))
+  ;; list of LAMBDA-VAR descriptors for arguments
+  (vars nil :type list :read-only t)
   ;; If this function was ever a :OPTIONAL function (an entry-point
   ;; for an OPTIONAL-DISPATCH), then this is that OPTIONAL-DISPATCH.
   ;; The optional dispatch will be :DELETED if this function is no
   ;; bind (because there are no variables left), but have not yet
   ;; actually deleted the LAMBDA yet.
   (bind nil :type (or bind null))
-  ;; the RETURN node for this LAMBDA, or NIL if it has been deleted.
-  ;; This marks the end of the lambda, receiving the result of the
-  ;; body. In a LET, the return node is deleted, and the body delivers
-  ;; the value to the actual continuation. The return may also be
+  ;; the RETURN node for this LAMBDA, or NIL if it has been
+  ;; deleted. This marks the end of the lambda, receiving the result
+  ;; of the body. In a LET, the return node is deleted, and the body
+  ;; delivers the value to the actual lvar. The return may also be
   ;; deleted if it is unreachable.
   (return nil :type (or creturn null))
   ;; If this CLAMBDA is a LET, then this slot holds the LAMBDA whose
   ;; LETS list we are in, otherwise it is a self-pointer.
   (home nil :type (or clambda null))
-  ;; a list of all the all the lambdas that have been LET-substituted
-  ;; in this lambda. This is only non-null in lambdas that aren't
-  ;; LETs.
-  (lets () :type list)
-  ;; a list of all the ENTRY nodes in this function and its LETs, or
-  ;; null in a LET
-  (entries () :type list)
-  ;; a list of all the functions directly called from this function
-  ;; (or one of its LETs) using a non-LET local call. This may include
-  ;; deleted functions because nobody bothers to clear them out.
-  (calls () :type list)
+  ;; all the lambdas that have been LET-substituted in this lambda.
+  ;; This is only non-null in lambdas that aren't LETs.
+  (lets nil :type list)
+  ;; all the ENTRY nodes in this function and its LETs, or null in a LET
+  (entries nil :type list)
+  ;; CLAMBDAs which are locally called by this lambda, and other
+  ;; objects (closed-over LAMBDA-VARs and XEPs) which this lambda
+  ;; depends on in such a way that DFO shouldn't put them in separate
+  ;; components.
+  (calls-or-closes (make-sset) :type (or null sset))
   ;; the TAIL-SET that this LAMBDA is in. This is null during creation.
   ;;
   ;; In CMU CL, and old SBCL, this was also NILed out when LET
   ;; retain it so that if the LET is deleted (due to a lack of vars),
   ;; we will still have caller's lexenv to figure out which cleanup is
   ;; in effect.
-  (call-lexenv nil :type (or lexenv null)))
+  (call-lexenv nil :type (or lexenv null))
+  ;; list of embedded lambdas
+  (children nil :type list)
+  (parent nil :type (or clambda null))
+  (allow-instrumenting *allow-instrumenting* :type boolean)
+  ;; True if this is a system introduced lambda: it may contain user code, but
+  ;; the lambda itself is not, and the bindings introduced by it are considered
+  ;; transparent by the nested DX analysis.
+  (system-lambda-p nil :type boolean))
 (defprinter (clambda :conc-name lambda- :identity t)
-  name
+  %source-name
+  %debug-name
+  #!+sb-show id
+  kind
   (type :test (not (eq type *universal-type*)))
   (where-from :test (not (eq where-from :assumed)))
-  (vars :prin1 (mapcar #'leaf-name vars)))
+  (vars :prin1 (mapcar #'leaf-source-name vars)))
 
 ;;; The OPTIONAL-DISPATCH leaf is used to represent hairy lambdas. It
 ;;; is a FUNCTIONAL, like LAMBDA. Each legal number of arguments has a
   ;; the total number of required and optional arguments. Args at
   ;; positions >= to this are &REST, &KEY or illegal args.
   (max-args 0 :type unsigned-byte)
-  ;; list of the LAMBDAs which are the entry points for non-rest,
-  ;; non-key calls. The entry for MIN-ARGS is first, MIN-ARGS+1
-  ;; second, ... MAX-ARGS last. The last entry-point always calls the
-  ;; main entry; in simple cases it may be the main entry.
+  ;; list of the (maybe delayed) LAMBDAs which are the entry points
+  ;; for non-rest, non-key calls. The entry for MIN-ARGS is first,
+  ;; MIN-ARGS+1 second, ... MAX-ARGS last. The last entry-point always
+  ;; calls the main entry; in simple cases it may be the main entry.
   (entry-points nil :type list)
   ;; an entry point which takes MAX-ARGS fixed arguments followed by
   ;; an argument context pointer and an argument count. This entry
   ;; know what they are doing.
   (main-entry nil :type (or clambda null)))
 (defprinter (optional-dispatch :identity t)
-  name
+  %source-name
+  %debug-name
+  #!+sb-show id
   (type :test (not (eq type *universal-type*)))
   (where-from :test (not (eq where-from :assumed)))
   arglist
   ;; the kind of argument being described. Required args only have arg
   ;; info structures if they are special.
   (kind (missing-arg)
-       :type (member :required :optional :keyword :rest
-                     :more-context :more-count))
+        :type (member :required :optional :keyword :rest
+                      :more-context :more-count))
   ;; If true, this is the VAR for SUPPLIED-P variable of a keyword or
   ;; optional arg. This is true for keywords with non-constant
   ;; defaults even when there is no user-specified supplied-p var.
   ;; the default for a keyword or optional, represented as the
   ;; original Lisp code. This is set to NIL in &KEY arguments that are
   ;; defaulted using the SUPPLIED-P arg.
+  ;;
+  ;; For &REST arguments this may contain information about more context
+  ;; the rest list comes from.
   (default nil :type t)
-  ;; the actual key for a &KEY argument. Note that in ANSI CL this is not
-  ;; necessarily a keyword: (DEFUN FOO (&KEY ((BAR BAR))) ..).
+  ;; the actual key for a &KEY argument. Note that in ANSI CL this is
+  ;; not necessarily a keyword: (DEFUN FOO (&KEY ((BAR BAR))) ...).
   (key nil :type symbol))
 (defprinter (arg-info :identity t)
   (specialp :test specialp)
 ;;; LAMBDA-VARs with no REFs are considered to be deleted; physical
 ;;; environment analysis isn't done on these variables, so the back
 ;;; end must check for and ignore unreferenced variables. Note that a
-;;; deleted lambda-var may have sets; in this case the back end is
-;;; still responsible for propagating the Set-Value to the set's Cont.
-(def!struct (lambda-var (:include basic-var))
+;;; deleted LAMBDA-VAR may have sets; in this case the back end is
+;;; still responsible for propagating the SET-VALUE to the set's CONT.
+(!def-boolean-attribute lambda-var
   ;; true if this variable has been declared IGNORE
-  (ignorep nil :type boolean)
-  ;; the CLAMBDA that this var belongs to. This may be null when we are
-  ;; building a lambda during IR1 conversion.
-  (home nil :type (or null clambda))
+  ignore
   ;; This is set by physical environment analysis if it chooses an
   ;; indirect (value cell) representation for this variable because it
   ;; is both set and closed over.
-  (indirect nil :type boolean)
+  indirect
+  ;; true if the last reference has been deleted (and new references
+  ;; should not be made)
+  deleted
+  ;; This is set by physical environment analysis if, should it be an
+  ;; indirect lambda-var, an actual value cell object must be
+  ;; allocated for this variable because one or more of the closures
+  ;; that refer to it are not dynamic-extent.  Note that both
+  ;; attributes must be set for the value-cell object to be created.
+  explicit-value-cell
+  )
+
+(def!struct (lambda-var (:include basic-var))
+  (flags (lambda-var-attributes)
+         :type attributes)
+  ;; the CLAMBDA that this var belongs to. This may be null when we are
+  ;; building a lambda during IR1 conversion.
+  (home nil :type (or null clambda))
   ;; The following two slots are only meaningful during IR1 conversion
   ;; of hairy lambda vars:
   ;;
   ;; propagation. This is left null by the lambda pre-pass if it
   ;; determine that this is a set closure variable, and is thus not a
   ;; good subject for flow analysis.
-  (constraints nil :type (or sset null)))
+  (constraints nil :type (or null t #| FIXME: conset |#))
+  ;; Content-addressed indices for the CONSTRAINTs on this variable.
+  ;; These are solely used by FIND-CONSTRAINT
+  (ctype-constraints nil :type (or null hash-table))
+  (eq-constraints    nil :type (or null hash-table))
+  ;; sorted sets of constraints we like to iterate over
+  (eql-var-constraints     nil :type (or null (array t 1)))
+  (inheritable-constraints nil :type (or null (array t 1)))
+  (private-constraints     nil :type (or null (array t 1)))
+  ;; Initial type of a LET variable as last seen by PROPAGATE-FROM-SETS.
+  (last-initial-type *universal-type* :type ctype)
+  ;; The FOP handle of the lexical variable represented by LAMBDA-VAR
+  ;; in the fopcompiler.
+  (fop-value nil))
 (defprinter (lambda-var :identity t)
-  name
+  %source-name
+  #!+sb-show id
   (type :test (not (eq type *universal-type*)))
   (where-from :test (not (eq where-from :assumed)))
-  (ignorep :test ignorep)
+  (flags :test (not (zerop flags))
+         :prin1 (decode-lambda-var-attributes flags))
   (arg-info :test arg-info)
   (specvar :test specvar))
+
+(defmacro lambda-var-ignorep (var)
+  `(lambda-var-attributep (lambda-var-flags ,var) ignore))
+(defmacro lambda-var-indirect (var)
+  `(lambda-var-attributep (lambda-var-flags ,var) indirect))
+(defmacro lambda-var-deleted (var)
+  `(lambda-var-attributep (lambda-var-flags ,var) deleted))
+(defmacro lambda-var-explicit-value-cell (var)
+  `(lambda-var-attributep (lambda-var-flags ,var) explicit-value-cell))
 \f
 ;;;; basic node types
 
 ;;; A REF represents a reference to a LEAF. REF-REOPTIMIZE is
 ;;; initially (and forever) NIL, since REFs don't receive any values
 ;;; and don't have any IR1 optimizer.
-(defstruct (ref (:include node (:reoptimize nil))
-               (:constructor make-ref (derived-type leaf))
-               (:copier nil))
+(def!struct (ref (:include valued-node (reoptimize nil))
+                 (:constructor make-ref
+                               (leaf
+                                &optional (%source-name '.anonymous.)
+                                &aux (leaf-type (leaf-type leaf))
+                                (derived-type
+                                 (make-single-value-type leaf-type))))
+                 (:copier nil))
   ;; The leaf referenced.
-  (leaf nil :type leaf))
+  (leaf nil :type leaf)
+  ;; CONSTANT nodes are always anonymous, since we wish to coalesce named and
+  ;; unnamed constants that are equivalent, we need to keep track of the
+  ;; reference name for XREF.
+  (%source-name (missing-arg) :type symbol :read-only t))
 (defprinter (ref :identity t)
+  #!+sb-show id
+  (%source-name :test (neq %source-name '.anonymous.))
   leaf)
 
 ;;; Naturally, the IF node always appears at the end of a block.
-;;; NODE-CONT is a dummy continuation, and is there only to keep
-;;; people happy.
-(defstruct (cif (:include node)
-               (:conc-name if-)
-               (:predicate if-p)
-               (:constructor make-if)
-               (:copier copy-if))
-  ;; CONTINUATION for the predicate
-  (test (missing-arg) :type continuation)
+(def!struct (cif (:include node)
+                 (:conc-name if-)
+                 (:predicate if-p)
+                 (:constructor make-if)
+                 (:copier copy-if))
+  ;; LVAR for the predicate
+  (test (missing-arg) :type lvar)
   ;; the blocks that we execute next in true and false case,
   ;; respectively (may be the same)
   (consequent (missing-arg) :type cblock)
-  (alternative (missing-arg) :type cblock))
+  (consequent-constraints nil :type (or null t #| FIXME: conset |#))
+  (alternative (missing-arg) :type cblock)
+  (alternative-constraints nil :type (or null t #| FIXME: conset |#)))
 (defprinter (cif :conc-name if- :identity t)
-  (test :prin1 (continuation-use test))
+  (test :prin1 (lvar-uses test))
   consequent
   alternative)
 
-(defstruct (cset (:include node
-                          (derived-type *universal-type*))
-                (:conc-name set-)
-                (:predicate set-p)
-                (:constructor make-set)
-                (:copier copy-set))
+(def!struct (cset (:include valued-node
+                           (derived-type (make-single-value-type
+                                          *universal-type*)))
+                  (:conc-name set-)
+                  (:predicate set-p)
+                  (:constructor make-set)
+                  (:copier copy-set))
   ;; descriptor for the variable set
   (var (missing-arg) :type basic-var)
-  ;; continuation for the value form
-  (value (missing-arg) :type continuation))
+  ;; LVAR for the value form
+  (value (missing-arg) :type lvar))
 (defprinter (cset :conc-name set- :identity t)
   var
-  (value :prin1 (continuation-use value)))
+  (value :prin1 (lvar-uses value)))
 
 ;;; The BASIC-COMBINATION structure is used to represent both normal
-;;; and multiple value combinations. In a local function call, this
+;;; and multiple value combinations. In a let-like function call, this
 ;;; node appears at the end of its block and the body of the called
-;;; function appears as the successor. The NODE-CONT remains the
-;;; continuation which receives the value of the call.
-(defstruct (basic-combination (:include node)
-                             (:constructor nil)
-                             (:copier nil))
-  ;; continuation for the function
-  (fun (missing-arg) :type continuation)
-  ;; list of CONTINUATIONs for the args. In a local call, an argument
-  ;; continuation may be replaced with NIL to indicate that the
-  ;; corresponding variable is unreferenced, and thus no argument
-  ;; value need be passed.
+;;; function appears as the successor; the NODE-LVAR is null.
+(def!struct (basic-combination (:include valued-node)
+                               (:constructor nil)
+                               (:copier nil))
+  ;; LVAR for the function
+  (fun (missing-arg) :type lvar)
+  ;; list of LVARs for the args. In a local call, an argument lvar may
+  ;; be replaced with NIL to indicate that the corresponding variable
+  ;; is unreferenced, and thus no argument value need be passed.
   (args nil :type list)
   ;; the kind of function call being made. :LOCAL means that this is a
   ;; local call to a function in the same component, and that argument
-  ;; syntax checking has been done, etc. Calls to known global
-  ;; functions are represented by storing the FUNCTION-INFO for the
-  ;; function in this slot. :FULL is a call to an (as yet) unknown
-  ;; function. :ERROR is like :FULL, but means that we have discovered
-  ;; that the call contains an error, and should not be reconsidered
-  ;; for optimization.
-  (kind :full :type (or (member :local :full :error) function-info))
+  ;; syntax checking has been done, etc.  Calls to known global
+  ;; functions are represented by storing :KNOWN in this slot and the
+  ;; FUN-INFO for that function in the FUN-INFO slot.  :FULL is a call
+  ;; to an (as yet) unknown function, or to a known function declared
+  ;; NOTINLINE. :ERROR is like :FULL, but means that we have
+  ;; discovered that the call contains an error, and should not be
+  ;; reconsidered for optimization.
+  (kind :full :type (member :local :full :error :known))
+  ;; if a call to a known global function, contains the FUN-INFO.
+  (fun-info nil :type (or fun-info null))
+  ;; Untrusted type we have asserted for this combination.
+  (type-validated-for-leaf nil)
   ;; some kind of information attached to this node by the back end
-  (info nil))
+  (info nil)
+  (step-info))
 
 ;;; The COMBINATION node represents all normal function calls,
 ;;; including FUNCALL. This is distinct from BASIC-COMBINATION so that
 ;;; an MV-COMBINATION isn't COMBINATION-P.
-(defstruct (combination (:include basic-combination)
-                       (:constructor make-combination (fun))
-                       (:copier nil)))
+(def!struct (combination (:include basic-combination)
+                         (:constructor make-combination (fun))
+                         (:copier nil)))
 (defprinter (combination :identity t)
-  (fun :prin1 (continuation-use fun))
+  #!+sb-show id
+  (fun :prin1 (lvar-uses fun))
   (args :prin1 (mapcar (lambda (x)
-                        (if x
-                            (continuation-use x)
-                            "<deleted>"))
-                      args)))
+                         (if x
+                             (lvar-uses x)
+                             "<deleted>"))
+                       args)))
 
 ;;; An MV-COMBINATION is to MULTIPLE-VALUE-CALL as a COMBINATION is to
 ;;; FUNCALL. This is used to implement all the multiple-value
 ;;; receiving forms.
-(defstruct (mv-combination (:include basic-combination)
-                          (:constructor make-mv-combination (fun))
-                          (:copier nil)))
+(def!struct (mv-combination (:include basic-combination)
+                            (:constructor make-mv-combination (fun))
+                            (:copier nil)))
 (defprinter (mv-combination)
-  (fun :prin1 (continuation-use fun))
-  (args :prin1 (mapcar #'continuation-use args)))
+  (fun :prin1 (lvar-uses fun))
+  (args :prin1 (mapcar #'lvar-uses args)))
 
 ;;; The BIND node marks the beginning of a lambda body and represents
 ;;; the creation and initialization of the variables.
-(defstruct (bind (:include node)
-                (:copier nil))
+(def!struct (bind (:include node)
+                  (:copier nil))
   ;; the lambda we are binding variables for. Null when we are
   ;; creating the LAMBDA during IR1 translation.
   (lambda nil :type (or clambda null)))
 ;;; return values and represents the control transfer on return. This
 ;;; is also where we stick information used for TAIL-SET type
 ;;; inference.
-(defstruct (creturn (:include node)
-                   (:conc-name return-)
-                   (:predicate return-p)
-                   (:constructor make-return)
-                   (:copier copy-return))
+(def!struct (creturn (:include node)
+                     (:conc-name return-)
+                     (:predicate return-p)
+                     (:constructor make-return)
+                     (:copier copy-return))
   ;; the lambda we are returning from. Null temporarily during
   ;; ir1tran.
   (lambda nil :type (or clambda null))
-  ;; the continuation which yields the value of the lambda
-  (result (missing-arg) :type continuation)
+  ;; the lvar which yields the value of the lambda
+  (result (missing-arg) :type lvar)
   ;; the union of the node-derived-type of all uses of the result
   ;; other than by a local call, intersected with the result's
   ;; asserted-type. If there are no non-call uses, this is
 (defprinter (creturn :conc-name return- :identity t)
   lambda
   result-type)
+
+;;; The CAST node represents type assertions. The check for
+;;; TYPE-TO-CHECK is performed and then the VALUE is declared to be of
+;;; type ASSERTED-TYPE.
+(def!struct (cast (:include valued-node)
+                  (:constructor %make-cast))
+  (asserted-type (missing-arg) :type ctype)
+  (type-to-check (missing-arg) :type ctype)
+  ;; an indication of what we have proven about how this type
+  ;; assertion is satisfied:
+  ;;
+  ;; NIL
+  ;;    No type check is necessary (VALUE type is a subtype of the TYPE-TO-CHECK.)
+  ;;
+  ;; :EXTERNAL
+  ;;    Type check will be performed by NODE-DEST.
+  ;;
+  ;; T
+  ;;    A type check is needed.
+  (%type-check t :type (member t :external nil))
+  ;; the lvar which is checked
+  (value (missing-arg) :type lvar))
+(defprinter (cast :identity t)
+  %type-check
+  value
+  asserted-type
+  type-to-check)
 \f
 ;;;; non-local exit support
 ;;;;
 ;;;; lexical exits.
 
 ;;; The ENTRY node serves to mark the start of the dynamic extent of a
-;;; lexical exit. It is the mess-up node for the corresponding :Entry
+;;; lexical exit. It is the mess-up node for the corresponding :ENTRY
 ;;; cleanup.
-(defstruct (entry (:include node)
-                 (:copier nil))
-  ;; All of the Exit nodes for potential non-local exits to this point.
+(def!struct (entry (:include node)
+                   (:copier nil))
+  ;; All of the EXIT nodes for potential non-local exits to this point.
   (exits nil :type list)
   ;; The cleanup for this entry. NULL only temporarily.
   (cleanup nil :type (or cleanup null)))
-(defprinter (entry :identity t))
+(defprinter (entry :identity t)
+  #!+sb-show id)
 
 ;;; The EXIT node marks the place at which exit code would be emitted,
 ;;; if necessary. This is interposed between the uses of the exit
 ;;; continuation and the exit continuation's DEST. Instead of using
 ;;; the returned value being delivered directly to the exit
-;;; continuation, it is delivered to our VALUE continuation. The
-;;; original exit continuation is the exit node's CONT.
-(defstruct (exit (:include node)
-                (:copier nil))
-  ;; The Entry node that this is an exit for. If null, this is a
+;;; continuation, it is delivered to our VALUE lvar. The original exit
+;;; lvar is the exit node's LVAR; physenv analysis also makes it the
+;;; lvar of %NLX-ENTRY call.
+(def!struct (exit (:include valued-node)
+                  (:copier nil))
+  ;; the ENTRY node that this is an exit for. If null, this is a
   ;; degenerate exit. A degenerate exit is used to "fill" an empty
   ;; block (which isn't allowed in IR1.) In a degenerate exit, Value
   ;; is always also null.
   (entry nil :type (or entry null))
-  ;; The continuation yeilding the value we are to exit with. If NIL,
-  ;; then no value is desired (as in GO).
-  (value nil :type (or continuation null)))
+  ;; the lvar yielding the value we are to exit with. If NIL, then no
+  ;; value is desired (as in GO).
+  (value nil :type (or lvar null))
+  (nlx-info nil :type (or nlx-info null)))
 (defprinter (exit :identity t)
+  #!+sb-show id
   (entry :test entry)
   (value :test value))
 \f
 ;;;; miscellaneous IR1 structures
 
-(defstruct (undefined-warning
-           #-no-ansi-print-object
-           (:print-object (lambda (x s)
-                            (print-unreadable-object (x s :type t)
-                              (prin1 (undefined-warning-name x) s))))
-           (:copier nil))
+(def!struct (undefined-warning
+            #-no-ansi-print-object
+            (:print-object (lambda (x s)
+                             (print-unreadable-object (x s :type t)
+                               (prin1 (undefined-warning-name x) s))))
+            (:copier nil))
   ;; the name of the unknown thing
   (name nil :type (or symbol list))
   ;; the kind of reference to NAME
 ;;; a helper for the POLICY macro, defined late here so that the
 ;;; various type tests can be inlined
 (declaim (ftype (function ((or list lexenv node functional)) list)
-               %coerce-to-policy))
+                %coerce-to-policy))
 (defun %coerce-to-policy (thing)
   (let ((result (etypecase thing
-                 (list thing)
-                 (lexenv (lexenv-policy thing))
-                 (node (lexenv-policy (node-lexenv thing)))
-                 (functional (lexenv-policy (functional-lexenv thing))))))
+                  (list thing)
+                  (lexenv (lexenv-policy thing))
+                  (node (lexenv-policy (node-lexenv thing)))
+                  (functional (lexenv-policy (functional-lexenv thing))))))
     ;; Test the first element of the list as a rudimentary sanity
     ;; that it really does look like a valid policy.
     (aver (or (null result) (policy-quality-name-p (caar result))))
 ;;;; Freeze some structure types to speed type testing.
 
 #!-sb-fluid
-(declaim (freeze-type node leaf lexenv continuation cblock component cleanup
-                     physenv tail-set nlx-info))
+(declaim (freeze-type node leaf lexenv ctran lvar cblock component cleanup
+                      physenv tail-set nlx-info))