[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mattias Engdegård
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Thu, 2 Jul 2020 20:01:23 +0200

2 juli 2020 kl. 17.49 skrev Stefan Monnier <monnier@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:

Attachment: 0001-Relax-portable-number-predicate-in-byte-compiler.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]