Re: [Sbcl-devel] fix for bug 87 (byte compile status?)

[William H. N. <wil...@ai...>]

(I've merged the package cleanup patch and the bug 94 fix into
sbcl-0.6.11.32, just checked into CVS.)

On Wed, Apr 04, 2001 at 01:11:04AM +0200, Martin Atzmueller wrote:
> attached is a patch that should fix Bug#87, such that byte-compilation
> by a declaration (OPTIMIZE (SPEED 0)) works.

I don't think that patch is right. You write
              (dolist (fun (component-lambdas component) t)
                (unless (policy (lambda-bind fun)
                                (and (zerop speed) (<= debug 1)))
                  (return nil))
                (return t))
So the DOLIST always terminates after the first iteration, and only
checks the first lambda. If you wanted to do that, you needn't bother
with the DOLIST, at least as long as (as I think is the case) the list
is never empty; you could just do
	(policy (lambda-bind (first (component-lambdas component)))
                (and (zerop speed) (<= debug 1)))
instead.

I think the basic idea of the original code, of checking every LAMBDA
in the COMPONENT, not just the first LAMBDA, is probably sound. I'm
not actually sure where it makes a difference, though I'd guess
something like
  (declaim (optimize (speed 0)))
  (defun mostly-slow (x y z)
    ;; Do a lot of linear stuff which doesn't have to be fast.
    (frob 1)
    (frob 2)
    (frob 4)
    (snarf 3)
    (frob 5 "yes")
    (frob 7)
    (frob 9)
    (frob 14)
    (frob 15)
    ..
    (frob 97 '(yes no))
    (snarf 97)
    (frob 97 '(yes yes))
    (frob 101)
    ;; more slow redundant stuff
    ..
    ;; something which might actually benefit from native compilation
    (when (some (lambda (foo)
                  (declare (optimize (speed 3)))
                  (>= (foo-north foo) (foo-east foo)))
                *remaining-foos*)
      ;; gotta try again!?
      (mostly-slow (1- x) (1- y) (1- z)))
    ;; more slow redundant stuff
    ..
    )
In this case the ideal would be to byte-compile the outer function
and native-compile the inner LAMBDA, but the system doesn't currently
support that as far as I can tell, so you have to either byte-compile
both or native-compile both, and native-compiling them both seems
like the better choice.

I haven't figured out why the original code doesn't do the right
thing. I've been testing it on variants of
  (in-package :cl-user)
  (declaim (optimize (speed 0)))
  (defun foo (x)
    (declare (type integer x) (optimize (speed 0)))
    (values x))
  (defun bar (y)
    (values y y))
For some reason one of the component lambdas here has optimization
policy (SPEED 1), even though everything is declared (SPEED 0). If the
outer DECLAIM is changed to (SPEED 3), though, the (SPEED 1) thing
goes away. Some sort of weird do-what-I-think-they-should-mean logic
deep in Python, probably. I rewrote the original code to make it
easier to read and much easier to TRACE; maybe I'll figure out what's
going on eventually.

-- 
William Harold Newman <wil...@ai...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C