Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches

[Pip Cet <pipcet@gmail.com>]

On Fri, Aug 24, 2018 at 8:55 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On my to-do list of things to try is to use 4 adjacent type codes for fixnums,
> bignums, immediate floats and indirect floats, so that INTEGERP, BIGNUMP,
> FIXNUMP, FLOATP, and NUMBERP can each be done by a single mask-and-compare.

I'm already using a separate tag value for bignums, though it might
help to use tag value 0 instead of a nonzero one (but then Qnil
couldn't be all-zeroes in memory).

I've discovered that the sequence gcc (trunk) emits for a mask-and-compare is:
    mov %rax, %rbx
    and $7, %rbx
    cmp $7, %rbx
where I would use
    lea 1(%rax), %ebx
    test $7, %bl

I can force the latter by testing ((char)((int)(XLI (x) + 8 -
Lisp_String)) & 7) == 0 rather than the (equivalent, AFAICS) (XLI (x)
& 7) == Lisp_String (sometimes gcc uses a longer sequence, though). At
this point, I think gcc should be emitting the shorter two-insn
sequence for both C expressions.

With this "improvement", the code size difference is 13184 bytes. I'm
unable to measure a performance difference, since it is lost in the
noise.

I've benchmarked the hash-cons approach, though the implementation I
used was rather trivial, and simple bignum calculations appear to be
about 20-50% slower. Again, I expect that number to increase once the
extra copy in make_number is removed. (For floats, the slowdown is
worse.)

I still think there are problems with collisions, accidental or
intentional, and with shrinking the hash table again after a
calculation is finished. And I think those problems would be worse if
strings ever become immutable but eq-when-equal.