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

[Pip Cet]

On Sat, Jul 4, 2020 at 5:01 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 7/4/20 9:33 AM, Stefan Monnier wrote:
> > Is there a way to tell gcc to try and avoid x87's idiosyncrasies without
> > being platform-dependent (or at least without imposing SSE2, since
> > I still use Emacs on my old Thinkpad X30)?
>
> Not as far as I know. GCC's -fexcess-precision=standard option tries to do 
> that,
> by causing GCC to convert 80-bit results to 64-bit results after every 80-bit
> operation. However, this still suffers from double-rounding on the x86 unless
> you also specify -msse2 -mfpmath=sse. (-fexcess-precision=standard supports 
> the
> C standard better than the older -ffloat-store option, which generates code 
> that
> is faster but has more double-rounding problems than 
> -fexcess-precision=standard
> does.)

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

(The double-rounding issues you mention don't appear to be documented;
but -fexcess-precision=standard is documented to be a nop if
-mfpmath=sse is specified...)

> Several GNU/Linux distributions have already dropped support for x86-only
> hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the
> distributions that still support i686, you can still build and run Emacs on 
> your
> laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse
> -mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not 
> all)
> of the rounding problems.

I think we should either drop x86 entirely or support it, and the
former is not yet an option. 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.

FWIW, SSE instructions require special OS support, too. We still have
things like the (broken) snprintf implementation in sysdep.c, so
people may be forgiven for getting the impression we care about
non-typical hardware/OS combinations.

I also think it's unwise to establish that Emacs uses 64-bit IEEE-754
floating point numbers exclusively. I'm inclined to believe that the
current consensus on that particular format is likely to be temporary
only.