0.7.13.pcl-class.1
[sbcl.git] / src / compiler / node.lisp
index 293641e..83b3421 100644 (file)
@@ -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
   (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)
   (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)
 ;;;   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
   ;; 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
   (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)
   ;; 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