From 0f534f7e3e8298e8acdd2abb8316e50bcfbc1603 Mon Sep 17 00:00:00 2001 From: Christophe Rhodes Date: Thu, 5 Aug 2004 16:37:04 +0000 Subject: [PATCH 1/1] 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. --- src/compiler/x86/macros.lisp | 10 ++++++++-- version.lisp-expr | 2 +- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/compiler/x86/macros.lisp b/src/compiler/x86/macros.lisp index 137a0e8..028d6b7 100644 --- 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 --- 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" -- 1.7.10.4