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

Previous Next

Package: emacs;

Reported by: Andrea Corallo <andrea_corallo <at> yahoo.it>

Date: Tue, 30 Jun 2020 22:28:02 UTC

Severity: normal

Found in version 28.0.50

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 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, 02 Jul 2020 17:41:31 -0400
> Anyway, since we now have bignums and have standardised on IEEE 754 binary64
> floats, is there a reason to keep byte-opt-portable-numberp?

Indeed, it seems like it might not be needed any more.

> If we want to make allowance for capricious x87 rounding, what about
> rewriting it to accept integral floats in the ±2^53 range, as well as any
> integer? This is what it might look like:

I must say I don't know what x87 rounding has to do with it.

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.
Or are we worried about the double-rounding of x87?


        Stefan





This bug report was last modified 4 years and 282 days ago.

Previous Next


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