Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> > That patch would be more intrusive.
>> Arguably, yes, but it would have the advantage to attack more precisely
>> the actual core of the problem, so it "reifies" in the code our
>> deeper understanding of the problem.

> I don't know what you mean by "actual core".  As I
> understand it the change you're proposing would require an
> O(N**2) pass through a stack with N 32-bit words (assuming
> 32-bit registers and 64-bit EMACS_INT).

No, that would be a "real fix".  What I suggest is just to take the O(N)
pointer-sized entities on the stack, cast them to EMACS_INT, and pass
them to mark_maybe_object.

>> As for that change, the reasoning for why it's correct doesn't seem
>> obvious to me (I understand why it's correct in the current
>> WIDE_EMACS_INT case, but generalizing from that to the case
>> "UINTPTR_MAX >> VALBITS != 0" seems risky).
> I don't understand what you mean by "generalizing"; can you give
> an example of the more-general situation you're worried about?

No, the problem is theoretical: what is the logical justification?

> Are you worried that pointers might be aligned more-strictly
> than EMACS_INT values?

Not really.  I'm just trying to construct a proof in my head that your
optimization is correct, and I can't seem to connect your
hypothesis "UINTPTR_MAX >> VALBITS != 0" with the conclusion.
Your additional alignment hypothesis might be the key, but I'm still
struggling to see how the proof would work.

> +  /* The mark_maybe_pointer loop will suffice, since it will recognize
> +     the bottom bits of any Lisp_Object containing a pointer, if we
> +     can assume that Lisp_Object values are aligned at least as
> +     strictly as pointers.  Although this assumption is true on all
> +     practical Emacs porting targets, check it anyway, to be safer.  */
> +  { verify (GC_LISP_OBJECT_ALIGNMENT % GC_POINTER_ALIGNMENT == 0); }

I really don't think such complexity is warranted for such a minor
optimization of a compilation option which is currently not enabled
by default.  If/when we enable it by default, we may revisit this
choice, but for now, I'd rather not go there.


        Stefan