GNU bug report logs - #65491
[PATCH] Improve performance allocating vectors

Previous Next

Full log

Message #85 received at 65491 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 65491 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca
Subject: Re: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 16 Sep 2023 21:19:29 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sat, 16 Sep 2023 19:22:54 +0200
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
>  65491 <at> debbugs.gnu.org,
>  monnier <at> iro.umontreal.ca
> 
> 16 sep. 2023 kl. 19.09 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > Sorry, I cannot accept this kind of "discussions" when such tricky
> > issues come up.  What's the rush of installing changes when you still
> > didn't answer my questions, and we still are not sure these changes
> > are correct?
> 
> I'm confident that they are correct. Moreover, I'm also confident that the old code was incorrect, which is why the change was carried out. Both the C standard and modern C compilers agree.
> 
> There's nothing strange or unusual that the 32-bit --with-wide-int configuration sees unexpected warnings when code is changed. You must have seen that many times before. It doesn't mean that there is anything wrong with the change; in this case it was just a somewhat pedantic GCC warning, quickly silenced.

I get it that you are confident, but I want to be confident as well,
and I'm not there yet.  A discussion is not over until all of its
parties say it is.  By rushing to install changes while the discussion
is still not over you create an unhealthy atmosphere where some people
might conclude their opinions, questions, and doubts are ignored, and
that doesn't contribute to the sense of cooperation towards common
goals.

> >>> It does, but LISP_WORD_TAG(type) is a 64=bit type with the only bits
> >>> set above 32 bit, so how casting it to uintptr_t is TRT?
> >> 
> >> Because XUNTAG is used to get the pointer part; we don't want the tag bits. 
> > 
> > Then just casting should do, no?  Why the subtraction?
> 
> Because when Lisp_Object is pointer-sized we need to remove the tag bits from the word. Only in the special configuration with a Lisp_Object that is larger than pointers can we simply cast away the tag bits.

Those special configurations have telltale traits that can be used in
cpp conditionals.  IOW, we could have different definitions of XUNTAG
for different configurations.  It isn't unheard off, and other macros,
including some that are involved in XUNTAG, do indeed have separate
definitions for several configurations.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.