- Nov 13, 2008
-
-
rtoy authored
o Change the other complex arithmetic deftransforms not to use REAL as the type of an argument. It should be the same as the complex argument. Without this, the deftransforms were causing infinite loops during compilation where the deftransforms kept changing the code.
-
rtoy authored
(defun foo (z) (declare (double-float z)) (+ (complex 0 1) z)) o For now, don't convert real*complex to complex*real. Expand it out explicitly.
-
- Nov 12, 2008
-
-
rtoy authored
sse2-packed-2008-11-12).
-
- Jun 26, 2008
-
-
rtoy authored
o Recursively call RANDOM for the integer case to let the deftransform handle the case. compiler/float-tran.lisp: o Remove comment about modifying RANDOM to match the deftransform. We're automatically in sync now.
-
- Jun 24, 2008
-
-
rtoy authored
Fix bug in deftransform where the case for x86 and num-high > random-fixnum-max was never used. We now always use the bignum multiply code for all platforms and use that for all cases for which the deftransform applies. Simplify the constant-continuation case too so we don't have to the check. I think the bignum multiply version does not have the bias problem that rem has. code/rand-mt19937.lisp: Change the RANDOM function to compute the same value as the deftransform would. general-info/release-19f.txt: Update Make a note that both the function and the deftransform should be synchronized to match. This change also changes the sequence of numbers produced.
-
- Apr 08, 2008
-
-
rtoy authored
operations. The deftransforms were causing type-derivation to return DOUBLE-DOUBLE-FLOAT for everything. Use the suggestion from Rob: Wrap the result of the deftransform in a TRULY-THE form and use the node derived type for the type. o The FLOAT-SIGN deftransform for DOUBLE-DOUBLE-FLOAT should be conditioned on the DOUBLE-DOUBLE feature. o Remove old unused deftransform for * for two double-double args.
-
- Apr 03, 2008
-
-
rtoy authored
specifiers. To see this, try the following: (defun foo (x) (declare (type (real 0) x)) (expt 2 x)) (compile 'foo) (describe 'foo) You get error that 0 is not an appropriate type for a double-float specifier.
-
- Feb 14, 2008
-
-
rtoy authored
be the largest possible number.
-
- Feb 01, 2008
-
-
rtoy authored
used instead of %sin and friends. Simple tests showed that they gave bad answers (values > 1 or exceptions) for numbers greater than 2^63 (2^62 for tan).
-
- Jun 27, 2007
-
-
rtoy authored
o Add INHIBIT-WARNINGS for the core double-double routines to get rid of warnings about boxing numbers. I'm pretty sure the routines are all doing what they're supposed to do.
-
- Jun 21, 2007
-
-
rtoy authored
-
- Jun 20, 2007
-
-
rtoy authored
(nonexistent) block.
-
- Jun 11, 2007
-
-
rtoy authored
o Handle signed-zeroes for addition, subtraction, and multiplication of double-double floats. That is, return the correct signed zero for the result. o Try to handle overflow in addition, multiplication, and division by returning infinity, if the overflow or divide-by-zero trap is disabled. This is done by looking to see what the corresponding double-float operation would return. This probably needs more work. code/irrat-dd.lisp: o Remove the careful-mul stuff from dd-complex-atanh since we handle signed zeroes better now during double-double multiplication.
-
- May 09, 2007
-
-
rtoy authored
o Add vops to do fused multiply-add and fused multiply-subtract. (Only double-float supported.) o Add defknown's for these translations. compiler/float-tran.lisp: o Used fused multiply-subtract for two-prod and two-sqr instead of the split function.
-
- Feb 03, 2007
-
-
rtoy authored
(defun f (x y) (declare (fixnum x y)) (expt x y)) caused an error because we weren't handling member types correctly.
-
- Jan 23, 2007
-
-
rtoy authored
type of: (defun foo3 (x y) (declare (type (double-float (0d0) 1d0) x) (type (double-float (0d0)) y)) (expt x y)) to be (double-float 0d0 1d0), i.e, including -0.0, but that's not possible. With this fix, the result type is (or (member 0d0) (double-float (0d0) 1d0)), which is better.
-
- Aug 21, 2006
-
-
rtoy authored
can now read and print -0w0. code/float.lisp: o Adjust float-sign so that we get the correct sign when double-double-floats are used. o Adjust FLOAT-RATIO to call %MAKE-DOUBLE-DOUBLE-FLOAT so that we preserve the sign of the number. This is safe because the components are known to be properly scaled. compiler/float-tran.lisp: o Use %MAKE-DOUBLE-DOUBLE-FLOAT in %DOUBLE-DOUBLE-FLOAT to preserve the sign of the original float. This is safe because the components are known to be properly scaled. o Add a FLOAT-SIGN deftransform to handle DOUBLE-DOUBLE-FLOAT.
-
- Jul 07, 2006
-
-
rtoy authored
o Change the following functions to be maybe-inline instead of inline so we don't inline them by default unless the user says so by specifying (SPACE 0): ADD-DD, MUL-DD-D, MUL-DD, ADD-DD-D, SQR-DD, DIV-DD, DIV-DD-D, SQRT-DD code/irrat-dd.lisp: o Set (SPACE 0) for these functions so we inline the operations. (Should we really inline all of these?)
-
rtoy authored
double-double-floats if the arg is non-negative.
-
- Jun 30, 2006
-
-
rtoy authored
The merge is from the tag "double-double-irrat-end". The double-double branch is now obsolete. The code should build without double-double support (tested on sparc) as well as build with double-double support (tested also on sparc).
-
- Jun 26, 2005
-
-
rtoy authored
mrg32k3a test in cl-bench.
-
- Jun 19, 2005
-
-
rtoy authored
micro-optimization.
-
- Apr 29, 2005
-
-
rtoy authored
replace with a single scale-float optimizer. This enables type derivation for scale-float on x86, which wasn't transforming scale-float to scale-single-float/scale-double-float.
-
- Apr 24, 2005
-
-
rtoy authored
negative and the scale-factor caused underflow during computation of the bounds. Fix that. This fixes misc.567 test from ansi-tests, and perhaps others.
-
- Sep 23, 2004
-
-
rtoy authored
if the range of the arg were too large to fit in a float. Silently return unbounded value instead of signaling an error during compilation.
-
- Sep 03, 2004
-
-
rtoy authored
be a union type.
-
- Jun 18, 2004
-
-
rtoy authored
o Update %unary-ftruncate and the corresponding deftransform because it was not properly returning the correct sign for signed zeroes. If the number was in a good range, we used truncate, which loses the sign of zero. (Should we have leave it in and add an explicit check for a zero result and adjust the sign appropriately? That would allow us to use the fast builtin instructions at the expense of a test for zero and a fix.)
-
- Jan 10, 2004
-
-
toy authored
we don't have to call abs at all.
-
- Jan 09, 2004
-
-
toy authored
(expt <rational> <rational>). The result can be a rational, a float, or a complex single-float.
-
- Sep 12, 2003
-
-
gerd authored
is an invalid type specifier. * src/compiler/float-tran.lisp (float): Make three optimizers, one for no prototype, one for single-float prototype, and one for double-float prototype.
-
- Sep 07, 2003
-
-
gerd authored
(compile 'foo) (foo 0d0) => 0d0 Found by Paul Dietz with sqrt on complex numbers. * src/compiler/float-tran.lisp (float) <deftransform>: Test with single-float-p instead of floatp.
-
- Sep 05, 2003
-
-
toy authored
o Oops. We should subtract from 0, not 0d0 o Add the deftransform for - to the complex-fp-vops part too, because the vop gets that wrong. compiler/sparc/float.lisp: o Remove the vop for a real - complex because we get the sign of the imaginary part wrong.
-
toy authored
imaginary part instead of subtracting from 0. This is needed to get the correct sign if the imaginary part was 0. (From a bug in Paul Dietz's ansi tests.)
-
- Sep 02, 2003
-
-
toy authored
calling %SINGLE-FLOAT which converts everything to a single-float. (Noted by Christophe Rhodes on #lisp.)
-
- Jul 03, 2003
-
-
toy authored
which we weren't handling. Use bound-value to get the value. This probably still needs some work.
-
- Jul 02, 2003
-
-
toy authored
of a double-float in multiple-values. This is better than calling double-float-high/low-bits which causes 2 stores to the stack to be done.
-
- Apr 23, 2003
-
-
toy authored
decode-double-float more accurately. (Do we need defoptimizers for these? Might be useful to get at least the exponent range accurately.)
-
- Mar 14, 2002
-
-
toy authored
DEFKNOWN for it.
-
- Mar 08, 2002
-
-
toy authored
%unary-truncate has many redundant stack moves even when it's know the result will fit in a (signed-byte 32), so create vops to do the conversion directly in the floating-point registers. Also, sparc-v9 can do 64-bit integer conversions, so make the range up to 64-bits for sparc-v9.
-
- Feb 25, 2002
-
-
toy authored
instead of calling the generic TRUNCATE. Make FFLOOR, FCEILING, and FROUND use FTRUNCATE so they benefit too.
-