bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode

[Pip Cet <pipcet@gmail.com>]

On Sun, Dec 22, 2019 at 5:11 PM Mattias Engdegård <mattiase@acm.org> wrote:
> Minor improvement to avoid duplication of some numbers in bytecode.

I don't have a strong opinion about this (well, I do, actually: 'eq
and 'eql should be equal), but my impression from the last time this
was discussed is that the problems this causes (different code
behavior for byte-compiled code versus evaluated code) outweighed the
benefits (very tiny code size reduction). I don't think different
floating point representations are still an issue.

Most importantly, I think that we should be able to be define

(defun f () (eq 18446744073709551616 18446744073709551616))

That function should always return t on sane systems that have eq =
eql, and always return nil on systems that have <64 bits in a fixnum
and the old-style eq.

With your patch, f will return t if it is byte-compiled without
optimizations, but nil if it isn't byte-compiled or is byte-compiled
with optimizations.

> No significant degradation in compilation speed observed.

That's good, that was another concern, IIRC.

> The savings aren't huge either: 1382 bytes in all .elc files, but the in-memory savings are probably higher, since an extra small flonum (1.0, say) only costs 4 bytes in the .elc file, but something like 16-24 bytes in memory (pointer + boxed flonum).

I don't see how you end up with 24 bytes in that case, though, unless
you over-align floats (which we should, it gives us an extra tag bit).

Anyway, I still think the right course of action here is to fix (or
deprecate) eq rather than changing minor details of the byte compiler
in incompatible ways. However, if we decide the gain is significant
for floating point numbers, let's restrict this to floating point
numbers and leave bignums alone?