[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Floating-point constant folding in Emacs byte compiler

From: Eli Zaretskii
Subject: Re: Floating-point constant folding in Emacs byte compiler
Date: Mon, 02 Apr 2018 15:50:58 +0300

> From: Pip Cet <address@hidden>
> Date: Mon, 2 Apr 2018 11:42:59 +0000
> Cc: address@hidden, address@hidden, address@hidden
> I'm trying to make bytecode reproducible for my code, which uses
> SpiderMonkey's JS::Value type, and in which two same-value floats are
> always equal (because their bit representations are), and standard
> Emacs on a standard GNU/Linux machine, where, as I've just learned,
> two same-value floats are never eq (I'd previously thought that was
> undefined, and actually unpredictable in practice).

Well, maybe what I said could be misinterpreted: they _can_ be EQ iff
they reference the same Lisp_Float object.  If they reference
different objects, they aren't EQ.  When these floats come from Lisp,
it's extremely unlikely for them to reference the same object, though.

> Again, this is the first time I hear that "two floats are never EQ" is
> actually intentional behavior that some code might rely on, rather
> than a mere accident of the current float implementation. Do you
> happen to have any examples at hand for code that relies on this?

Not off the top of my head, no.  But IME such implementation details
tend to leak into the code, and I would be surprised if we didn't have
something like that in Emacs.

> In the case of byte code, what I've seen so far is that the code
> generated is actually suboptimal, and runs fine without duplicated
> float constants in the constants vector.

Comparing FP values for equivalence on the C level is tricky at best,
due to extended precision, guard bits, etc.  What is your plan for
overcoming these obstacles in a predictable and reliable manner?  Did
you consider solving the problem the other way around, i.e. teaching
JS::Value about this issue?  (Caveat: I know nothing about JS.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]