On Fri, Dec 13, 2002 at 11:09:10AM -0500, Raymond Toy wrote:
> >>>>> "Christophe" == Christophe Rhodes <csr21@...> writes:
> > I'm obviously worried about bogus optimizers -- it's terribly easy to
> > destroy the ability to compile things that one doesn't notice... on the
> > other hand, this is what a test suite and a code freeze is for :-)
> Only if the test suite has entries for bogus optimizers. :-)
> I used the coerce optimizer for quite a while on my own code without
> problems. Then one day on some innocent code, it just barfed. I was
> too busy at the time to figure it out so I just backed out that
> change. I never went back to figure it out.
OK. Well, as it turns out, SBCL has had your version of the coerce
defoptimizer for about a year and a half now, with no reported problems.
So it works to at least some extent.
The flip side of this is that there's a bug in CMUCL's current
optimizer, exposed by the following transcript:
* (defun foo (x) (let ((y (coerce x 'complex))) (complexp y)))
* (compile 'foo)
Compiling LAMBDA (X):
Compiling Top-Level Form:
* (foo 1)
The correct answer here is NIL. The problem is that the COERCE
:DERIVE-TYPE-OPTIMIZER in fndb.lisp [(RESULT-SPECIFIER-NTH-ARG 2) or
something like that] doesn't take account of complex canonicalization.
I have an updated version of a patch that I plan to commit to sbcl
(which is essentially mixing in your original one to deal with return
types from ARRAY-ELEMENT-TYPE with something that is almost
(RESULT-SPECIFER-NTH-ARG 2), but taught to deal with COMPLEX types
(more-or-less as in the previous posted patch). I plan to test it with
as much code as I can find -- but do let me know if you can dig up the
code on which your defoptimizer used to fail...
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)