From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Date: Fri, 27 Dec 2019 17:07:11 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="115183"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38708@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 27 18:08:20 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 1ikt64-000Tpx-6R for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Dec 2019 18:08:20 +0100 Original-Received: from localhost ([::1]:37358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikt63-0007It-0m for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Dec 2019 12:08:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41768) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikt5o-0007Ft-8U for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2019 12:08:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ikt5m-0008VI-7s for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2019 12:08:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51770) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ikt5m-0008Ur-1x for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2019 12:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ikt5l-0006ro-TR for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2019 12:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Dec 2019 17:08: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.157746647626384 (code B ref 38708); Fri, 27 Dec 2019 17:08:01 +0000 Original-Received: (at 38708) by debbugs.gnu.org; 27 Dec 2019 17:07:56 +0000 Original-Received: from localhost ([127.0.0.1]:57743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikt5g-0006rU-06 for submit@debbugs.gnu.org; Fri, 27 Dec 2019 12:07:56 -0500 Original-Received: from mail-oi1-f194.google.com ([209.85.167.194]:34179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikt5d-0006rB-HV for 38708@debbugs.gnu.org; Fri, 27 Dec 2019 12:07:54 -0500 Original-Received: by mail-oi1-f194.google.com with SMTP id l136so9714026oig.1 for <38708@debbugs.gnu.org>; Fri, 27 Dec 2019 09:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v6HTCHOztvteOsohKokBgGSaxElVjIPmEFPxAk87hXI=; b=ql5RBa71tbUn9jcmfhmp0FJv5IBJfarPq4hQ/lsfVX/AQE7fB0O7kT9kD9OV4WixBU LsTjhtkX80KTNms7JmejOL3Vm1u6q6y9NyZZSNPEwJIV/eZ3EoI653KSTKlcLivuEoL+ MYp5Xs/EX2ldBCVkkrM03urh0p3QkwktJrF9wa+ivqihoW9NdRX6AbBcIItwlRJPfMN4 ybC1uPMOG9/0kSiOVPeGJVnqX8Ua5CPhCJca7N3F4oP4qN2/U2B0mRAZzFz68E1wIcUI iIcfK147AMNEwOuKkfKPbFQJLPJhietFph4mDEnBzqQagy1to9S/6TUQenj9zPkwYugt c9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v6HTCHOztvteOsohKokBgGSaxElVjIPmEFPxAk87hXI=; b=OqlLZwoJWCfVaQu9Re7Rkc5AclAiWofOr+hgP9mKEvmJwTneo3K8uzGnDMLv7Sz6Z7 xwHR7DLy65ud5/8SdLJXjN6QWdDoK3Ty1l6cifE847+ElLTVYKiAfBNihAcBnkpQxyN7 ps7ICYCWXGmPNaIcwBGMvVOAxAdSDq/X4qZn+lqoEqGnDcaK7uRukgPbnNzjj6QB5MoS eyxZdJAXmFJywvHREmqIHh6YNJA+fOY6aAVhC5iZThDKxfQkguELu+KGFKIy0vN/MjrI Mya3Qtr3VBDwQkqzLG0l6b7Mfc03ILWS7ci+CWop6GPu0TGWQLH4jX2512UtY4+iETll OVTQ== X-Gm-Message-State: APjAAAV9pXqPy6pbnpppK2eVb3TllMWUkY7vd/kcWQZK56yqQ+9Y15So b41WB0ofcrZhgVGMSEKZNJkNTUQQPLHTPAFxciM= X-Google-Smtp-Source: APXvYqxvnKFkKWcp8chD+Hg6LM9js0EHHuvJXI0CY9Xa3wfpThCJYykO5lV82gSV0AhAsHdhZJCQ5vU2YtGa/ojXfB8= X-Received: by 2002:a05:6808:208:: with SMTP id l8mr3627003oie.112.1577466467953; Fri, 27 Dec 2019 09:07:47 -0800 (PST) In-Reply-To: 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:173828 Archived-At: On Sun, Dec 22, 2019 at 5:11 PM Mattias Engdeg=C3=A5rd w= rote: > Minor improvement to avoid duplication of some numbers in bytecode. 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). I don't think different floating point representations are still an issue. Most importantly, I think that we should be able to be define (defun f () (eq 18446744073709551616 18446744073709551616)) 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. With your patch, f will return t if it is byte-compiled without optimizations, but nil if it isn't byte-compiled or is byte-compiled with optimizations. > No significant degradation in compilation speed observed. That's good, that was another concern, IIRC. > The savings aren't huge either: 1382 bytes in all .elc files, but the in-= memory savings are probably higher, since an extra small flonum (1.0, say) = only costs 4 bytes in the .elc file, but something like 16-24 bytes in memo= ry (pointer + boxed flonum). I don't see how you end up with 24 bytes in that case, though, unless you over-align floats (which we should, it gives us an extra tag bit). 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?