From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Date: Sat, 28 Dec 2019 16:49:05 +0100 Message-ID: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org> References: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="69267"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38708@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 28 16:50:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ilELz-000Hro-T6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 16:50:12 +0100 Original-Received: from localhost ([::1]:44178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilELx-0005yI-AN for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 10:50:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37960) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilELr-0005yC-7t for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 10:50:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilELq-00038V-2W for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 10:50:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52834) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilELp-00036W-Lk for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 10:50:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ilELp-0003Yk-Jt for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 10:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2019 15:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38708 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 38708-submit@debbugs.gnu.org id=B38708.157754815713624 (code B ref 38708); Sat, 28 Dec 2019 15:50:01 +0000 Original-Received: (at 38708) by debbugs.gnu.org; 28 Dec 2019 15:49:17 +0000 Original-Received: from localhost ([127.0.0.1]:58807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilEL6-0003Xf-Oy for submit@debbugs.gnu.org; Sat, 28 Dec 2019 10:49:16 -0500 Original-Received: from mail1458c50.megamailservers.eu ([91.136.14.58]:40930 helo=mail267c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilEL5-0003XQ-3q for 38708@debbugs.gnu.org; Sat, 28 Dec 2019 10:49:16 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1577548148; bh=GUS/fcK4SSn3UFuEeXXe1b6S5JeLsL323ORJvngI5gw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XPrvmsX0TQ+0kY9MoMF24KR/WrKwhEyZFDsj3/J4xKYTZg2fitzQyTBt3a+OhOruz lA1xFDDYqBFlA9VNagxdpd4m3wqlQOLAVTTFY5N0RMSDbeLJiKpnpBnr73X/Ynrj4I rPgylO8d+NGCTyAX8g4ZiGbwvb2RXLpwlqPofB60= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail267c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id xBSFn5Eu013911; Sat, 28 Dec 2019 15:49:07 +0000 In-Reply-To: X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020C.5E077974.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=OY7m8SbY c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=pGLkceISAAAA:8 a=yVy3ZpRlzR0wyFvDlZgA:9 a=e57Ci6lTW0uizT97:21 a=HehN7hDJsigzIX43:21 a=CjuIK1q_8ugA:10 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173851 Archived-At: 27 dec. 2019 kl. 18.07 skrev Pip Cet : > I don't have a strong opinion about this (well, I do, actually: 'eq > and 'eql should be equal), but my impression from the last time this > was discussed is that the problems this causes (different code > behavior for byte-compiled code versus evaluated code) outweighed the > benefits (very tiny code size reduction). Thank you for inspecting my change! And sorry, I didn't know this had = been debated before. Is there a record of that discussion anywhere? > Most importantly, I think that we should be able to be define >=20 > (defun f () (eq 18446744073709551616 18446744073709551616)) >=20 > That function should always return t on sane systems that have eq =3D > eql, and always return nil on systems that have <64 bits in a fixnum > and the old-style eq. I'm not sure I understand. Surely such a criterion imposes a rather low = limit on permissible optimisations? For example, shouldn't (eq (ash 1 x) (ash 1 x)) be allowed to be optimised to t (after CSE, say), even if x can be 64, = despite the fact that interpreted or low-optimised compiled code would = yield nil in that case? Perhaps the change should really be done on the emacs-27 branch, to = avoid changing bignum behaviour, but that is just a slightly weaker = version of the same restriction. Unless we decide to turn eq into a = synonym for eql, eq is a one-sided conservative approximation of eql for = bignums and flonums. > Anyway, I still think the right course of action here is to fix (or > deprecate) eq rather than changing minor details of the byte compiler > in incompatible ways. However, if we decide the gain is significant > for floating point numbers, let's restrict this to floating point > numbers and leave bignums alone? What would anyone gain from such a restriction? And the change is minor = because it's a small thing to do; what I thought looked like an obvious = oversight, or one that made more sense back when Elisp didn't have = bignums.