X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcompiler%2Fnode.lisp;h=83b342122b8801d2d2d56289cb0a8054028828d8;hb=98a76d4426660876dec6649b1e228d2e5b47f579;hp=293641ea4ad96d53c31e220350ef4933dc1fa1a4;hpb=cf607a404d7518e8a18c9e362913f370eb9a5e38;p=sbcl.git

diff --git a/src/compiler/node.lisp b/src/compiler/node.lisp
index 293641e..83b3421 100644
--- a/src/compiler/node.lisp
+++ b/src/compiler/node.lisp
@@ -37,7 +37,7 @@
   ;;	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
+  ;;	continuations. NEXT can have a non-null value if the next node
   ;;	has already been determined.
   ;;
   ;; :DELETED
@@ -87,7 +87,7 @@
   ;; the 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
+  ;; BLOCK's START-USES indicate whether NIL means no uses or more
   ;; than one use.
   (use nil :type (or node null))
   ;; the basic block this continuation is in. This is null only in
@@ -276,19 +276,9 @@
   (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))
+  ;; 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)
@@ -306,8 +296,8 @@
   (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.
+  ;; constraints that hold in this block and its successors by merit
+  ;; of being tested by its IF predecessors.
   (test-constraint nil :type (or sset null)))
 (def!method print-object ((cblock cblock) stream)
   (print-unreadable-object (cblock stream :type t :identity t)
@@ -340,7 +330,9 @@
 ;;;   size of flow analysis problems, this allows back-end data
 ;;;   structures to be reclaimed after the compilation of each
 ;;;   component.
-(defstruct (component (:copier nil))
+(defstruct (component (:copier nil)
+                      (:constructor
+                       make-component (head tail &aux (last-block tail))))
   ;; unique ID for debugging
   #!+sb-show (id (new-object-id) :read-only t)
   ;; the kind of component
@@ -374,13 +366,15 @@
   ;; 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
@@ -702,8 +696,7 @@
   (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)
@@ -755,6 +748,12 @@
   ;; 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.
+  ;;
   ;; The value of this slot can be anything, except that it shouldn't
   ;; be a legal function name, since otherwise debugging gets
   ;; confusing. (If a legal function name is a good name for the