GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

Message #65 received at 42147 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Mattias Engdegård <mattiase <at> acm.org>
Cc: Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
Subject: Re: bug#42147: 28.0.50; pure vs side-effect-free, missing
 optimizations?
Date: Thu, 2 Jul 2020 16:16:04 -0700

On 7/2/20 2:41 PM, Stefan Monnier wrote:
> I'd tend to assume that x87 rounding can virtually never be seen from
> Elisp because it's hard to imagine how the C compiler will manage to
> keep our Elisp floats long enough in the x87 stack to avoid rounding
> back to 64bit floats between every Elisp-level operation.

It can happen in floatop_arith_driver, which has an accumulator of type 'double'
that on x87 is put into an 80-bit register. For example, on x86+x87 compiled
with the usual gcc -O2, (+ 1e16 2.9999 2.9999) returns 10000000000000008.0 (the
exact answer rounded to 'double'), whereas with SSE2 the same expression yields
10000000000000004.0 (which is a bit off, because the accumulator is only 64 bits
and suffered from rounding intermediate results).

> Or are we worried about the double-rounding of x87?

That too. For example, with x87, (+ 1e16 2.9999) yields 10000000000000004.0 due
to double-rounding, whereas with SSE2 the same expression yields
10000000000000002.0 which is the correctly-rounded answer.

As you can see, sometimes SSE2 is closer to the mathematically-correct answer
and sometimes x87 is. In typical C math code, x87 is better; in Emacs I imagine
the reverse is true (for the reasons you mentioned), though I have not attempted
to measure this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.