0.8.13.29:

	Inline allocation on the x86 isn't a universal win.
	... OK, then, optimize for the increasingly-common case
		(high-spec machines)
	... and provide a backend-subfeature for those advanced users
		who know where their sbcl is going to run.

diff --git a/src/compiler/x86/macros.lisp b/src/compiler/x86/macros.lisp
index 137a0e8..028d6b7 100644 (file)
--- a/src/compiler/x86/macros.lisp
+++ b/src/compiler/x86/macros.lisp
@@ -143,7 +143,7 @@
 ;;; which time all calls to alloc() would have needed a syscall to
 ;;; mask signals for the duration.  Now we have pseudoatomic there's
 ;;; no need for that overhead.  Still, inline alloc would be a neat
-;;; addition someday
+;;; addition someday (except see below).
 
 (defun allocation-dynamic-extent (alloc-tn size)
   (inst sub esp-tn size)
@@ -228,7 +228,13 @@
 (defun allocation (alloc-tn size &optional inline dynamic-extent)
   (cond
     (dynamic-extent (allocation-dynamic-extent alloc-tn size))
-    ((or (null inline) (policy inline (>= speed space)))
+    ;; FIXME: for reasons unknown, inline allocation is a speed win on
+    ;; non-P4s, and a speed loss on P4s (and probably other such
+    ;; high-spec high-cache machines).  :INLINE-ALLOCATION-IS-GOOD is
+    ;; a bit of a KLUDGE, really.  -- CSR, 2004-08-05 (following
+    ;; observations made by ASF and Juho Snellman)
+    ((and (member :inline-allocation-is-good *backend-subfeatures*)
+         (or (null inline) (policy inline (>= speed space))))
      (allocation-inline alloc-tn size))
     (t (allocation-notinline alloc-tn size)))
   (values))

diff --git a/version.lisp-expr b/version.lisp-expr
index be62a90..7df5dda 100644 (file)
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -17,4 +17,4 @@
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.13.28"
+"0.8.13.29"