[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 14:22:27 +0300 |
> From: Pip Cet <address@hidden>
> Date: Mon, 2 Apr 2018 10:56:25 +0000
> Cc: Robert Pluim <address@hidden>, address@hidden
>
> I believe the currently-documented behavior is that it's undefined;
> however, merely leaving it undefined doesn't make bytecode compilation
> reproducible. To do that, right now, I redefine EQ to be true for
> same-value floats. I'd prefer the byte compiler to be fixed
> (unfortunately, flet-binding eq around the invocation of the byte
> compiler isn't an option since byte-compiled code won't let you
> redefine eq), but there appear to be several places where the
> assumption is built into it, and I haven't found them all. The
> half-fixed compiler generates obviously-suboptimal bytecode sequences
> like "const X; const X;".
>
> I think it makes sense to say that bytecode should be portable but not
> necessarily identical between implementations, provided there's also a
> way to canonicalize bytecode generation so the result is actually
> target-independent (in the sense that if there are still bytecode
> differences between targets, that's a bug in the Lisp code); I hope
> redefining EQ is sufficient for that.
Can you make a step back and explain what is it that you are trying to
achieve, and why? Making potentially backward-incompatible changes
without a very good reason is not something we should be enthusiastic
about, IMO. E.g., the fact that two floats are never EQ is burned
into too many muscle memories, and I expect subtle problems with at
least C code that uses EQ.
Thanks.