From: Paul Khuong <pkhuong@gm...>  20090728 18:05:02

On 28Jul09, at 1:12 PM, Nikodemus Siivola wrote: > Update of /cvsroot/sbcl/sbcl/src/compiler > In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvsserv7449/src/ > compiler > > Modified Files: > floattran.lisp > Log Message: > 1.0.30.5: optimize some floating point operations > > * Convert (/ <float> <one>) to (+ <float> <zero>), and similarly for > *. Multiplication and division by 1 preserve the sign of zeros, but addition doesn't. This one should probably depend on FLOATACCURACY, converting the division to a multiplication, which always preserves signs in the default case. In fact, the optimisation could be generalised to division by any number that can be exactly reciprocated, using something like the following. (defun maybeexactreciprocal (x) "Return the reciprocal of X if it can be represented exactly, NIL otherwise." (multiplevaluebind (significand exponent sign) (integerdecodefloat x) ; must special case infinities/zeros, and fail on NaNs (let ((expected (/ sign significand (expt 2 exponent)))) (let ((reciprocal (/ 1 x))) (multiplevaluebind (significand exponent sign) (integerdecodefloat reciprocal) (and (eql expected (* sign significand (expt 2 exponent))) reciprocal)))))) If FLOATACCURACY is 1, then (/ <float> <constantfloat>) can be converted to (* float (/ <constantfloat>)) if the above doesn't return NIL (if FLOATACCURACY is 0, then multiplication by reciprocal would probably always make sense, with a direct elimination of (* <float> <+/ one>)). I'm fairly certain the transformation can be extended to complex floats without breaking anything that isn't already broken, and even for nonconstant complexreal division. > * Convert (/ <float> <minusone>) to (+ (%negate <float>) <zero>), and > similarly for *. I don't see why that shouldn't be converted to (%negate <float>), which computes the sign of zeros correctly. As for FLOATACCURACY, since the "default" case is 1 and the minimal value 0, we're only left with a binary toggle... FLOATINACCURACY/ SPEED would give us a more useful range. Paul Khuong 