bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Paul Eggert]

On 7/4/20 11:37 AM, Pip Cet wrote:

> So it's a GCC bug? Wouldn't it be better to fix that?

Not without such a performance hit that nobody has wanted to do it. I expect it
would need software emulation for most floating-point operations.

Also, in theory the Linux kernel could emulate missing SSE2 instructions.
However, this is another workaround that nobody has wanted to do because it's
not worth the hassle to support these old CPUs.

> (The double-rounding issues you mention don't appear to be documented;

It's obvious from the generated code.

-fexcess-precision doesn't mean floating-point operations conform to IEEE-754
double; all it means is that floating-point values are representable as IEEE-754
double. This is why one cannot rely on -fexcess-precision=standard to get
reproducible results.

> The minor issue fixed by dropping support
> for pre-SSE x86 can, if I understand the GCC docs correctly, be evaded
> by making sure the C code does the appropriate amount of casting.

That won't suffice. On x87+387, GCC preserves excess precision through casts,
even if -ffloat-store is specified.

> SSE instructions require special OS support, too.

The Linux kernel has supported SSE2 since Linux 2.4 (2001). Any Linux kernel
that doesn't support SSE2 is so old that I suspect it won't run current Emacs
anyway, for other reasons.

> I also think it's unwise to establish that Emacs uses 64-bit IEEE-754
> floating point numbers exclusively.

What, will we switch to IBM mainframe floating-point format? :-)

Part of the problem we're trying to solve here is rounding discrepancies between
build-time and run-time computation. The idea is that an Elisp floating-point
operation should yield the same value regardless of whether it's byte-compiled
(or even machine-compiled, if we want to do that). Even if Emacs changed
floating-point format (by stealing a few bits for tags, say), we'd still run
into the same problem.


PS. I finally got around to benchmarking, and on my usual benchmark (make
compile-always, Fedora 31 x86), using SSE2 sped up Emacs by 4.6%. So there is a
performance argument for the change as well as a fix-the-rounding-glitches 
argument.