1.0.16.17: log bug #426: inlining failure involing multiple nested calls

 * Not a regression, but apparently of CMUCL vintage.

diff --git a/BUGS b/BUGS
index 0ec868e..75a62e0 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1927,3 +1927,27 @@ generally try to check returns in safe code, so we should here too.)
 
  The problem is with the fast path using ansi-stream-cin-buffer not hitting
  closed-flame.
+
+426: inlining failure involving multiple nested calls
+
+   (declaim (inline foo))
+   (defun foo (x y)
+     (cons x y))
+   (defun bar (x)
+     (foo (foo x x) (foo x x)))
+   ;; shows a full call to FOO
+   (disassemble 'bar)
+   ;; simple way to test this programmatically
+   (let ((code (sb-c::fun-code-header #'bar))
+         (foo (sb-impl::fdefinition-object 'foo nil)))
+     (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code)
+           do (assert (not (eq foo (sb-kernel:code-header-ref code i))))))
+
+ This appears to be an ancient bug, inherited from CMUCL: reportedly
+ 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only
+ one of the calls, but local call analysis fails to inline the call
+ for the second time. Nikodemus thinks (but is not 100% sure based on
+ very brief investigation) that the call that is not inlined is the
+ second nested one. A trivial fix is to call CHANGE-REF-LEAF in known
+ call for functions already inline converted there, but he is not sure
+ if this has adverse effects elsewhere.

diff --git a/version.lisp-expr b/version.lisp-expr
index 5434840..7257239 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".)
-"1.0.16.16"
+"1.0.16.17"