1.0.13.49: save source-locations for accessor methods defined via DEFCLASS

[sbcl.git] / OPTIMIZATIONS

diff --git a/OPTIMIZATIONS b/OPTIMIZATIONS
index 623e433..0308f85 100644 (file)
--- a/OPTIMIZATIONS
+++ b/OPTIMIZATIONS
@@ -162,15 +162,6 @@ through TYPEP UNBOXED-ARRAY, within the compiler itself.
 rather than either constant-folding or manipulating NIL-VALUE or
 NULL-TN directly.
 --------------------------------------------------------------------------------
-#19
-  (let ((dx (if (foo)
-                (list x)
-                (list y z))))
-    (declare (dynamic-extent dx))
-    ...)
-
-DX is not allocated on stack.
---------------------------------------------------------------------------------
 #20
 (defun-with-dx foo (x)
   (flet ((make (x)
@@ -185,14 +176,6 @@ DX is not allocated on stack.
 Result of MAKE is not stack allocated, which means that
 stack-allocation of structures is impossible.
 --------------------------------------------------------------------------------
-#21
-(defun-with-dx foo ()
-  (let ((dx (list (list 1 2) (list 3 4))))
-    (declare (dynamic-extent dx))
-    ...))
-
-External list in DX is allocated on stack, but internal are not.
---------------------------------------------------------------------------------
 #22
 IR2 does not perform unused code flushing.
 --------------------------------------------------------------------------------
@@ -220,13 +203,16 @@ SBCL cannot derive upper bound for I and uses generic arithmetic here:
 should know the connection between an NLE and its CLEANUP.)
 --------------------------------------------------------------------------------
 #27
-(We always zeroize stack-allocated arrays of boxed elements.  The
-previous note here suggested that we could avoid that step on
-platforms with conservative GC; it's not clear to me (NJF) that
-doing so is a wise idea.)
-
-x86 and x86-64 do not zeroize stack-allocated arrays of unboxed
-elements; other platforms could copy what they do.
+Initialization of stack-allocated arrays is inefficient: we always
+fill the vector with zeroes, even when it is not needed (as for
+platforms with conservative GC or for arrays of unboxed objectes) and
+is performed later explicitely.
+
+(This is harder than it might look at first glance, as MAKE-ARRAY is smart
+enough to eliminate something like ':initial-element 0'.  Such an optimization
+is valid if the vector is being allocated in the heap, but not if it is being
+allocated on the stack.  You could remove this optimization, but that makes
+the heap-allocated case somewhat slower...)
 --------------------------------------------------------------------------------
 #28
 a. Accessing raw slots in structure instances is more inefficient than
@@ -408,8 +394,25 @@ all three comparisons or b) eliminated the necessity of the MOV(s)
 altogether.  The former option is probably easier than the latter.
 
 --------------------------------------------------------------------------------
-#37
+#38
+
+(setf (subseq s1 start1 end1) (subseq s2 start2 end1))
+
+could be transformed into
+
+(let ((#:s2 s2)
+      (#:start2 start2)
+      (#:end2 end2))
+ (replace s1 #:s2 :start1 start1 :end1 end1 :start2 #:start2 :end2 #:end2))
+
+when the return value is unused, avoiding the need to cons up the new sequence.
+
+--------------------------------------------------------------------------------
+#39
+
+(let ((*foo* 42)) ...)
 
-Dynamic extent allocation doesn't currently work for one-element lists,
-since there's a source transform from (LIST X) to (CONS X NIL).
+currently compiles to code that ensures the TLS index at runtime, which
+is both a decently large chunk of code and unnecessary, as we could ensure
+the TLS index at load-time as well.