0.9.6.37:

[sbcl.git] / OPTIMIZATIONS

diff --git a/OPTIMIZATIONS b/OPTIMIZATIONS
index eb2931f..0c8e790 100644 (file)
--- a/OPTIMIZATIONS
+++ b/OPTIMIZATIONS
@@ -224,3 +224,59 @@ 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.
 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.

+--------------------------------------------------------------------------------
+#28
+a. Accessing raw slots in structure instances is more inefficient than
+it could be; if we placed raw slots before the header word, we would
+not need to do arithmetic at runtime to access them.  (But beware:
+this would complicate handling of the interior pointer).
+
+b. (Also note that raw slots are currently disabled on HPPA)
+--------------------------------------------------------------------------------
+#29
+Python is overly zealous when converting high-level CL functions, such
+as MIN/MAX, LOGBITP, and LOGTEST, to low-level CL functions.  Reducing
+Python's aggressiveness would make it easier to effect changes such as
+
+x86-64:
+* direct MIN/MAX on {SINGLE,DOUBLE}-FLOATs ({MIN,MAX}S{S,D})
+
+x86{,-64}:
+* direct LOGBITP on word-sized integers and fixnums (BT + JC)
+
+x86{,-64}/PPC:
+* branch-free MIN/MAX on word-sized integers and fixnums
+* efficient LOGTESTs on word-sized integers and fixnums (TEST / AND.)
+
+PPC:
+* efficient LDB on word-sized integers and fixnums (RLWINM)
+
+etc., etc.
+
+The "easier" part claimed above would come about because the functions
+would be available for :TRANSLATE through a VOP or similar, whereas with
+the current architecture, one would have to pattern-match IR1.  While
+IR1 pattern-matching would be useful in other contexts, it seems better
+here to attempt the direct :TRANSLATE route.
+
+I (NJF) don't know how to implement such architecture-specific
+optimizations whilst keeping the high->low transformations for other
+architectures.  Certainly adding #!+/- magic in compiler/*.lisp could be
+done, but such a solution is somewhat inelegant.  Moving the relevant
+DEFTRANSFORMs to the architecture-specific compiler/* areas is also
+possible, but that would duplicate quite a bit of code.
+--------------------------------------------------------------------------------
+#30
+(defun foo (x y)
+  (< x y))
+
+FOO's IR1 representation is roughly:
+
+(defun foo (x y)
+  (if (< x y)
+      T
+      NIL))
+
+However, if a full call is generated for < (and similarly for other
+predicate functions), then the IF is unnecessary, since the return value
+of (< x y) is already T or NIL.