Skip to content
Snippets Groups Projects
  1. Jun 15, 2009
    • rtoy's avatar
      compiler/float-tran.lisp: · 5a98a234
      rtoy authored
      o Sparc has a vop for complex conjugate, so we can disable the
        deftransform.
      o Both sparc and x86 have a vop to do float - complex, so disable that
        transform too.
      
      compiler/sparc/float.lisp:
      o Fix the float-complex vop to do the right thing wrt contagion.
      o Remove some old commented out vop for complex*complex and
        complex/complex.
      5a98a234
    • rtoy's avatar
      o Fix deftransforms to do contagion correctly: · 2b772630
      rtoy authored
        - complex + real
        - complex - real
        - real + complex
      o Clean up comments and fix erroneous ones.
      2b772630
  2. Mar 18, 2009
    • rtoy's avatar
      code/irrat-dd.lisp: · 8bd5d96d
      rtoy authored
      o Declare POLY-EVAL and POLY-EVAL-1 as maybe-inline functions so they
        can be semi-inlined.
      
      code/irrat.lisp:
      o I don't think there's any real reason to make the local function
        REAL-EXPT inline.  It's very big and local function call is already
        good enough.
      
      compiler/float-tran.lisp:
      o Change some functions to be maybe-inline instead of inline to save
        on space for the the larger double-double functions:  SUB-DD,
        SUB-D-DD, SUB-DD-D, SPLIT.  Semi-inline should be good enough for
        these large functions, saving on cache memory, local function
        calling sequence should be good enough.
      8bd5d96d
  3. Dec 30, 2008
  4. Dec 22, 2008
  5. Nov 16, 2008
  6. Nov 14, 2008
    • rtoy's avatar
      float-tran.lisp: · 7264ddad
      rtoy authored
      o Remove the deftransform for real + complex and real * complex.
      o Always enable the transform for real - complex.
      
      x86/float-sse2.lisp:
      o Add vop to do real + complex
      o Add vop to do real * complex
      7264ddad
  7. 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
  8. Nov 12, 2008
  9. 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
  10. 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
  11. 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
  12. Apr 03, 2008
  13. Feb 14, 2008
  14. Feb 01, 2008
  15. Jun 27, 2007
  16. Jun 21, 2007
  17. Jun 20, 2007
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. Jun 30, 2006
  25. Jun 26, 2005
  26. Jun 19, 2005
  27. Apr 29, 2005
  28. Apr 24, 2005
  29. Sep 23, 2004
  30. Sep 03, 2004
  31. 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
  32. Jan 10, 2004
  33. Jan 09, 2004
  34. Sep 12, 2003
  35. 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
  36. 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
Loading