From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#65491: [PATCH] Improve performance allocating vectors Date: Sat, 16 Sep 2023 21:19:29 +0300 Message-ID: <83o7i2gevi.fsf@gnu.org> References: <6B2EDD07-AAEB-40E8-B369-F634296BD3D9@gmail.com> <83v8cagkqv.fsf@gnu.org> <83ttrugkj2.fsf@gnu.org> <83r0mygi4y.fsf@gnu.org> <8758CDE8-40F1-48DB-9B94-38F771DC8C6C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40411"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65491@debbugs.gnu.org, eggert@cs.ucla.edu, monnier@iro.umontreal.ca To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 16 20:20:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qhZtu-000AH6-63 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Sep 2023 20:20:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhZtd-0000VL-17; Sat, 16 Sep 2023 14:19:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhZtb-0000Ug-Fl for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 14:19:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhZta-0005Sv-SR for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 14:19:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhZth-0006JA-Lo for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 14:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 18:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65491 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65491-submit@debbugs.gnu.org id=B65491.169488839424228 (code B ref 65491); Sat, 16 Sep 2023 18:20:01 +0000 Original-Received: (at 65491) by debbugs.gnu.org; 16 Sep 2023 18:19:54 +0000 Original-Received: from localhost ([127.0.0.1]:48508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhZtZ-0006Ih-Nc for submit@debbugs.gnu.org; Sat, 16 Sep 2023 14:19:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhZtU-0006IN-MQ for 65491@debbugs.gnu.org; Sat, 16 Sep 2023 14:19:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhZtG-0005Qa-LM; Sat, 16 Sep 2023 14:19:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ahpGsW+Eb0HHxgbjYzd1V17g7eo8gpdTcbqJJap/nPc=; b=NSv9LFmsTXMsBhIIsnoE Yxiqhi9VS4lAxoWBbG+fFTatrh4/QMrEXG0X+gekb9aj38VX9q70UU5VyUMZUuMrp8PdpxFs+MgXA EIdK7jPypszd5v9S1HmxNdQd4GgmhVzNdZnRETf1NWkz8HijL0cFoOTqG4gNmJQklGUMIJGIphAzM JrGU6Y76hYMS0vaHEi6b6xoPF1bHU168lPUFC+JXBmvxVrQOYtsY4HJAnlfa2drSEQTBxqBJXWAaa 3xsePPGmocDDGc5HDWqohUAKwU3v2kYbyS5p+1WIdrh3qJh7RqD4JI9wgqHZwwGWfqKjZdndz7dgC Am9lemWWxv12tQ==; In-Reply-To: <8758CDE8-40F1-48DB-9B94-38F771DC8C6C@gmail.com> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sat, 16 Sep 2023 19:22:54 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270642 Archived-At: > From: Mattias Engdegård > Date: Sat, 16 Sep 2023 19:22:54 +0200 > Cc: Paul Eggert , > 65491@debbugs.gnu.org, > monnier@iro.umontreal.ca > > 16 sep. 2023 kl. 19.09 skrev Eli Zaretskii : > > > 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.