From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations? Date: Sun, 5 Jul 2020 02:56:23 -0700 Organization: UCLA Computer Science Department Message-ID: References: <3A9CC2A3-8307-47B2-8D80-795C0AF020E1@acm.org> <1621669100.2102667.1593639091621@mail.yahoo.com> <775819003.2516724.1593687594435@mail.yahoo.com> <5F2B4684-34D1-4474-8909-9F435369FE54@acm.org> <705260433.2731607.1593698199171@mail.yahoo.com> <6CF8EE58-9A49-40E7-AA86-48AB39BF94BA@acm.org> <28B19D86-343C-4126-B95F-1F38735F73F2@acm.org> <1288c6a5-545b-f68c-ff6b-7683db3e54c1@cs.ucla.edu> <0AF276D8-FB28-4745-AAE4-DC30E0441F89@acm.org> <793d67e0-68a0-fc53-89a9-0902747d6389@cs.ucla.edu> <83zh8ftfwr.fsf@gnu.org> <672f15b0-04f9-e884-4815-85ca1d1af9bb@cs.ucla.edu> <6d8ba3b1-86b8-3dc8-3d80-17222d436b80@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33641"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: mattiase@acm.org, Stefan Monnier , andrea_corallo@yahoo.it, 42147@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 05 11:57:10 2020 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 1js1OX-0008dP-MX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jul 2020 11:57:09 +0200 Original-Received: from localhost ([::1]:58296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1js1OW-0004op-P7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jul 2020 05:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1js1OQ-0004oe-3q for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 05:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1js1OP-0003Qd-QZ for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 05:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1js1OP-0001x7-OF for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 05:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jul 2020 09:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42147 X-GNU-PR-Package: emacs Original-Received: via spool by 42147-submit@debbugs.gnu.org id=B42147.15939429937470 (code B ref 42147); Sun, 05 Jul 2020 09:57:01 +0000 Original-Received: (at 42147) by debbugs.gnu.org; 5 Jul 2020 09:56:33 +0000 Original-Received: from localhost ([127.0.0.1]:60054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1js1Nx-0001wQ-JE for submit@debbugs.gnu.org; Sun, 05 Jul 2020 05:56:33 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1js1Nv-0001wD-8G for 42147@debbugs.gnu.org; Sun, 05 Jul 2020 05:56:32 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D287D160084; Sun, 5 Jul 2020 02:56:24 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ia7xvO3LaH0v; Sun, 5 Jul 2020 02:56:24 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E7159160093; Sun, 5 Jul 2020 02:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GuhGwsxFxlmo; Sun, 5 Jul 2020 02:56:23 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AC152160084; Sun, 5 Jul 2020 02:56:23 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:182732 Archived-At: On 7/4/20 11:37 AM, Pip Cet wrote: > So it's a GCC bug? Wouldn't it be better to fix that? Not without such a performance hit that nobody has wanted to do it. I expect it would need software emulation for most floating-point operations. Also, in theory the Linux kernel could emulate missing SSE2 instructions. However, this is another workaround that nobody has wanted to do because it's not worth the hassle to support these old CPUs. > (The double-rounding issues you mention don't appear to be documented; It's obvious from the generated code. -fexcess-precision doesn't mean floating-point operations conform to IEEE-754 double; all it means is that floating-point values are representable as IEEE-754 double. This is why one cannot rely on -fexcess-precision=standard to get reproducible results. > The minor issue fixed by dropping support > for pre-SSE x86 can, if I understand the GCC docs correctly, be evaded > by making sure the C code does the appropriate amount of casting. That won't suffice. On x87+387, GCC preserves excess precision through casts, even if -ffloat-store is specified. > SSE instructions require special OS support, too. The Linux kernel has supported SSE2 since Linux 2.4 (2001). Any Linux kernel that doesn't support SSE2 is so old that I suspect it won't run current Emacs anyway, for other reasons. > I also think it's unwise to establish that Emacs uses 64-bit IEEE-754 > floating point numbers exclusively. What, will we switch to IBM mainframe floating-point format? :-) Part of the problem we're trying to solve here is rounding discrepancies between build-time and run-time computation. The idea is that an Elisp floating-point operation should yield the same value regardless of whether it's byte-compiled (or even machine-compiled, if we want to do that). Even if Emacs changed floating-point format (by stealing a few bits for tags, say), we'd still run into the same problem. PS. I finally got around to benchmarking, and on my usual benchmark (make compile-always, Fedora 31 x86), using SSE2 sped up Emacs by 4.6%. So there is a performance argument for the change as well as a fix-the-rounding-glitches argument.