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

Previous Next

Full log

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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, 2 Jul 2020 20:01:23 +0200

[Message part 1 (text/plain, inline)]

2 juli 2020 kl. 17.49 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> Better yet, there's still hope that we change things such that `eq`
> behaves like `eql` on bignums (and maybe also on floats).

Speaking of which, Andrea may be in a good position to provide us with performance data about such a change, since making 'eq' more expensive is likely to be more visible in native code (assuming the operation is open-coded) than in bytecode or interpreted lisp. On the other hand, perhaps his compiler thingamajig is able to eliminate some checks statically by type propagation?

Anyway, since we now have bignums and have standardised on IEEE 754 binary64 floats, is there a reason to keep byte-opt-portable-numberp?

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:

[0001-Relax-portable-number-predicate-in-byte-compiler.patch (application/octet-stream, attachment)]

Previous Next

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