Skip to content
Snippets Groups Projects
  1. Nov 13, 2008
    • rtoy's avatar
      o Enable the complex-contagion deftransforms · ea96ab08
      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.
      ea96ab08
    • rtoy's avatar
      o Turn off complex contagion stuff because it breaks things like · 66793933
      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.
      66793933
  2. Nov 12, 2008
  3. Jun 26, 2008
    • rtoy's avatar
      code/rand-mt19937.lisp: · d4cb5a5e
      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.
      d4cb5a5e
  4. Jun 24, 2008
    • rtoy's avatar
      compiler/float-tran.lisp: · a282fdc9
      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.
      a282fdc9
  5. Apr 08, 2008
    • rtoy's avatar
      o Fix type-derivation for the basic DOUBLE-DOUBLE-FLOAT arithmetic · 5c34c685
      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.
      5c34c685
  6. Apr 03, 2008
  7. Feb 14, 2008
  8. Feb 01, 2008
  9. Jun 27, 2007
  10. Jun 21, 2007
  11. Jun 20, 2007
  12. Jun 11, 2007
    • rtoy's avatar
      compiler/float-tran.lisp: · 599a4a72
      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.
      599a4a72
  13. May 09, 2007
    • rtoy's avatar
      compiler/ppc/float.lisp: · 6574f257
      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.
      6574f257
  14. Feb 03, 2007
    • rtoy's avatar
      Fix bug in expt type derivation. · 99d4c4c8
      rtoy authored
      (defun f (x y)
         (declare (fixnum x y))
         (expt x y))
      
      caused an error because we weren't handling member types correctly.
      99d4c4c8
  15. Jan 23, 2007
    • rtoy's avatar
      Fix expt derive-type optimizer. The compiler was deriving the result · 4ece2b2c
      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.
      4ece2b2c
  16. Aug 21, 2006
    • rtoy's avatar
      Some very basic support for signed zeroes for DOUBLE-DOUBLE-FLOAT. We · e14ba2a5
      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.
      e14ba2a5
  17. Jul 07, 2006
    • rtoy's avatar
      compiler/float-tran.lisp: · bbb89ea5
      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?)
      bbb89ea5
    • rtoy's avatar
      Oops. We can only apply the sqrt deftransform for · 0b4eefba
      rtoy authored
      double-double-floats if the arg is non-negative.
      0b4eefba
  18. Jun 30, 2006
  19. Jun 26, 2005
  20. Jun 19, 2005
  21. Apr 29, 2005
  22. Apr 24, 2005
  23. Sep 23, 2004
  24. Sep 03, 2004
  25. Jun 18, 2004
    • rtoy's avatar
      o Fix a misplaced declaration in %unary-ftruncate/single-float · a71e3e77
      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.)
      a71e3e77
  26. Jan 10, 2004
  27. Jan 09, 2004
  28. Sep 12, 2003
  29. Sep 07, 2003
    • gerd's avatar
      (defun foo (x) (float x 1f0)) · 18894485
      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.
      18894485
  30. Sep 05, 2003
    • toy's avatar
      compiler/float-tran.lisp: · c640d0f2
      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.
      c640d0f2
    • toy's avatar
      The deftransform for - with a float and complex arg was negating the · dd95c758
      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.)
      dd95c758
  31. Sep 02, 2003
  32. Jul 03, 2003
  33. Jul 02, 2003
  34. Apr 23, 2003
  35. Mar 14, 2002
  36. Mar 08, 2002
    • toy's avatar
      Micro optimization for Sparc. The ftruncate code using · 95f890d7
      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.
      95f890d7
  37. Feb 25, 2002
Loading