Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

Re: [Sbcl-devel] [Sbcl-commits] CVS: sbcl/src/compiler float-tran.lisp, 1.46, 1.47

 Re: [Sbcl-devel] [Sbcl-commits] CVS: sbcl/src/compiler float-tran.lisp, 1.46, 1.47 From: Nikodemus Siivola - 2009-07-29 13:44:16 ```2009/7/28 Paul Khuong : >> * Convert (/ ) to (+ ), and similarly for *. > > Multiplication and division by 1 preserve the sign of zeros, but addition > doesn't. This one should probably depend on FLOAT-ACCURACY, converting the Oops... > 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 maybe-exact-reciprocal (x) > If FLOAT-ACCURACY is 1, then (/ ) can be converted > to (* float (/ )) if the above doesn't return NIL (if > FLOAT-ACCURACY is 0, then multiplication by reciprocal would probably always > make sense, with a direct elimination of (* <+/- one>)). I'm fairly > certain the transformation can be extended to complex floats without > breaking anything that isn't already broken, and even for non-constant > complex-real division. I've implemented this (though not the extensions) in 1.0.30.8. >> * Convert (/ ) to (+ (%negate ) ), and >>  similarly for *. > > I don't see why that shouldn't be converted to (%negate ), which > computes the sign of zeros correctly. I mentioned this on IRC, but for the record: I did that to catch SNaNs. > As for FLOAT-ACCURACY, since the "default" case is 1 and the minimal value > 0, we're only left with a binary toggle... FLOAT-INACCURACY/-SPEED would > give us a more useful range. Actually, the default is --unintuitively-- 3, currently. The only thing it affected prior to this commit was the setting of FPU control word on x86 for alien calls: 53 bits for lisp, and 64 for C. (There's a bug there, actually: if the foreign function unwinds, the FPU is left in 64 bit mode for lisp.) Christophe pointed this out: http://gcc.gnu.org/wiki/FloatingPointMath I think most interesting toggles are: inexact results SNaN behaviour treatment of signed zeros For now these are all on F-A=0, but perhaps they should be separate qualities? Cheers, -- Nikodemus ```

 Re: [Sbcl-devel] [Sbcl-commits] CVS: sbcl/src/compiler float-tran.lisp, 1.46, 1.47 From: Paul Khuong - 2009-07-28 18:05:02 ```On 28-Jul-09, at 1:12 PM, Nikodemus Siivola wrote: > Update of /cvsroot/sbcl/sbcl/src/compiler > In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv7449/src/ > compiler > > Modified Files: > float-tran.lisp > Log Message: > 1.0.30.5: optimize some floating point operations > > * Convert (/ ) to (+ ), and similarly for > *. Multiplication and division by 1 preserve the sign of zeros, but addition doesn't. This one should probably depend on FLOAT-ACCURACY, 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 maybe-exact-reciprocal (x) "Return the reciprocal of X if it can be represented exactly, NIL otherwise." (multiple-value-bind (significand exponent sign) (integer-decode-float x) ; must special case infinities/zeros, and fail on NaNs (let ((expected (/ sign significand (expt 2 exponent)))) (let ((reciprocal (/ 1 x))) (multiple-value-bind (significand exponent sign) (integer-decode-float reciprocal) (and (eql expected (* sign significand (expt 2 exponent))) reciprocal)))))) If FLOAT-ACCURACY is 1, then (/ ) can be converted to (* float (/ )) if the above doesn't return NIL (if FLOAT-ACCURACY is 0, then multiplication by reciprocal would probably always make sense, with a direct elimination of (* <+/- one>)). I'm fairly certain the transformation can be extended to complex floats without breaking anything that isn't already broken, and even for non-constant complex-real division. > * Convert (/ ) to (+ (%negate ) ), and > similarly for *. I don't see why that shouldn't be converted to (%negate ), which computes the sign of zeros correctly. As for FLOAT-ACCURACY, since the "default" case is 1 and the minimal value 0, we're only left with a binary toggle... FLOAT-INACCURACY/- SPEED would give us a more useful range. Paul Khuong ```
 Re: [Sbcl-devel] [Sbcl-commits] CVS: sbcl/src/compiler float-tran.lisp, 1.46, 1.47 From: Nikodemus Siivola - 2009-07-29 13:44:16 ```2009/7/28 Paul Khuong : >> * Convert (/ ) to (+ ), and similarly for *. > > Multiplication and division by 1 preserve the sign of zeros, but addition > doesn't. This one should probably depend on FLOAT-ACCURACY, converting the Oops... > 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 maybe-exact-reciprocal (x) > If FLOAT-ACCURACY is 1, then (/ ) can be converted > to (* float (/ )) if the above doesn't return NIL (if > FLOAT-ACCURACY is 0, then multiplication by reciprocal would probably always > make sense, with a direct elimination of (* <+/- one>)). I'm fairly > certain the transformation can be extended to complex floats without > breaking anything that isn't already broken, and even for non-constant > complex-real division. I've implemented this (though not the extensions) in 1.0.30.8. >> * Convert (/ ) to (+ (%negate ) ), and >>  similarly for *. > > I don't see why that shouldn't be converted to (%negate ), which > computes the sign of zeros correctly. I mentioned this on IRC, but for the record: I did that to catch SNaNs. > As for FLOAT-ACCURACY, since the "default" case is 1 and the minimal value > 0, we're only left with a binary toggle... FLOAT-INACCURACY/-SPEED would > give us a more useful range. Actually, the default is --unintuitively-- 3, currently. The only thing it affected prior to this commit was the setting of FPU control word on x86 for alien calls: 53 bits for lisp, and 64 for C. (There's a bug there, actually: if the foreign function unwinds, the FPU is left in 64 bit mode for lisp.) Christophe pointed this out: http://gcc.gnu.org/wiki/FloatingPointMath I think most interesting toggles are: inexact results SNaN behaviour treatment of signed zeros For now these are all on F-A=0, but perhaps they should be separate qualities? Cheers, -- Nikodemus ```