Re: pdumper on Solaris 10

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>>> If a Lisp_Object looks like this
>>>
>>>   0                 32                   64
>>>   +------------------+-------------------+
>>>   | tag | pointer    |  ...              |
>>>   +------------------+-------------------+
>>>
>>> there is a chance it could be made to work, if ugly. That's USE_LSB_TAG
>>> == 1.
>>
>> It does appear to work.  I'm not sure how it is "ugly", to be honest,
>> since MPS only sees 32-bit words, and that's the tagged pointer and
>> 0. No changes required.
>
> I was just assuming it would end up ugly in some form. But I haven't
> thought about it much. WIDE_INT and 32-bits are in an SEP field for
> me :-).
>
>>> If it looks like this
>>>
>>>   0                 32                   64
>>>   +------------------+-------------------+
>>>   |       pointer    |  ...         |tag |
>>>   +------------------+-------------------+
>>>
>>> it gets a lot more ugly. That's USE_LSB_TAG == 0.
>>
>> Given that gcc likes storing the two 32-bit words of a 64-bit integer in
>> non-adjacent places on the stack, it would be quite expensive to get
>> this working.
>
> Yeah, that's for sure. Nightmare.
>
>> And if we decided to do that, it would become a lot more complicated to
>> change our tagging scheme (which we should do, some time after merging
>> MPS, to speed up EQ by having a "may be EQ to a different object" tag
>> or, ideally, bit: EQ could then be simplified to
>>
>> if (x == y)
>>   return true;
>> else if (((x|y) & BIT) == 0)
>>   return false;
>>
>> <expensive non-inlined code here>)
>
> Hm, interesting idea. One would have to try it out of course to know,
> but from a gut feeling, would you say one would notice a difference?
> I don't have an "educated" gut feeling wrt EQ.

My gut feeling is that EQ happens so often that it's worth
micro-optimizing. Andrea has started doing that by using
__builtin_expect, but the assembler code we produce still looks very
inefficient. In particular, we don't even perform a quick exit if the
arguments are BASE_EQ, or attempt to move the cold code into its own
function, which shouldn't be inlined (there are about 2000 locations GDB
thinks correspond to EQ calls in my current Emacs, so that's a lot of
duplicated code).

I was going to suggest a patch to change that...

Of course it's entirely possible that EQ just doesn't matter for
performance.

My entire post-MPS proposal is to have bignums, floats and
symbols-with-position as the "exotic" tags that (may) need special handling in
EQ. That leaves four tags for fixnums, strings, vectorlikes, symbols,
and cons cells, which doesn't work out.

I _think_ the least painful option is to give strings the "treat
specially in EQ" bit, since comparing strings with EQ, while legal, is
rare.

(and, yes, this approach would use Lisp_Type_Unused0 and reduce fixnum
range by one bit).

Pip