0.9.3.2:

[sbcl.git] / OPTIMIZATIONS

diff --git a/OPTIMIZATIONS b/OPTIMIZATIONS
index a702c7d..c79f922 100644 (file)
--- a/OPTIMIZATIONS
+++ b/OPTIMIZATIONS
@@ -231,4 +231,37 @@ 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)
\ No newline at end of file
+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.