Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Hello Andy and Mark,

Thanks for taking the time to review this patch and bearing with me as
a I stumble around the compiler.  I've attached a new patch and have
some additionally commentary below:

On Wed, Dec 21, 2016 at 4:12 PM, Mark H Weaver <address@hidden> wrote:
> Andy Wingo <address@hidden> writes:
>
>> I think &min/0 should be replaced by (&min/f64).  Probably also you need
>> a good +nan.0 story here; does this do the right thing?  e.g.
>>
>>   (let ((a +nan.0))
>>     (if (< a 100.0)
>>         (< a 200.0)
>>         (> a 50.0)))
>>
>> Does this fold to #t?  I think for +nan.0 it should not,
>
> Right, any numerical comparison involving a NaN must return false.
>
>> but AFAIU with
>> your patch it does fold.  (Guile has some optimizer problems related to
>> flonums, I think; this patch doesn't have to fix them all, but it
>> shouldn't make them worse, or if it does, we need a nice story.)

This returns false with my patch applied, but I noticed that the
compiler has optimized everything away.  Is this what you expected,
Andy?


Disassembly of #<procedure 1a79228 at <unknown port>:13:3 ()> at #x1a7919c:

   0    (assert-nargs-ee/locals 1 1)    ;; 2 slots (0 args)   at
(unknown file):13:3
   1    (make-short-immediate 0 4)      ;; #f                 at
(unknown file):17:6
   2    (handle-interrupts)
   3    (return-values 2)               ;; 1 value


>>> +(define-simple-type-checker (f64-< &f64 &f64))
>>> +(define-f64-comparison-inferrer (f64-< < >=))
>>
>> Likewise we need an understanding that the inverse of < is in fact >=.
>> Maybe it is indeed :)
>
> No, it is not, because of NaNs.  What we can say is that (< x y) is
> equivalent to (> y x) and (<= x y) is equivalent to (>= y x).
>
> Also, inexact numerical operations are not associative.  There's a lot
> more that could be said about this topic, but in general please be aware
> that the usual mathematical intuitions are a poor guide, and it is easy
> for a naive compiler to destroy the properties of carefully written
> numerical codes.

I was more ignorant of floating point arithmetic than I realized, so
thanks for the education here.   The good news is that I was able to
just remove all changes to types.scm to resolve these issues (I
think).

How does this new patch look?

Thanks!

- Dave

0001-Add-unboxed-floating-point-comparison-instructions.patch
Description: Text Data