From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Bruno Haible Newsgroups: gmane.emacs.bugs Subject: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Fri, 28 Jun 2019 14:14:14 +0200 Message-ID: <8979488.cRkkfcT1mV__30843.806445931$1561726518$gmane$org@omega> References: <2715311.ceefYqj39C@omega> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="140523"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: KMail/5.1.3 (Linux/4.4.0-151-generic; KDE/5.18.0; x86_64; ; ) Cc: 36370@debbugs.gnu.org, Paul Eggert , bug-gnulib@gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 28 14:55: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 1hgqPI-000aPv-Gh for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 14:55:12 +0200 Original-Received: from localhost ([::1]:59464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqPC-0005R5-Rb for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 08:55:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38912) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqAQ-0000ml-Vj for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 08:39:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgqAN-0006qf-4t for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 08:39:49 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55194) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgqAL-0006mB-5T for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 08:39:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgpmQ-0005EC-Im for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 08:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bruno Haible Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2019 12:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36370 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36370-submit@debbugs.gnu.org id=B36370.156172406520035 (code B ref 36370); Fri, 28 Jun 2019 12:15:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 28 Jun 2019 12:14:25 +0000 Original-Received: from localhost ([127.0.0.1]:40479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgplo-0005D4-V2 for submit@debbugs.gnu.org; Fri, 28 Jun 2019 08:14:25 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.20]:21337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgpll-0005Cu-No for 36370@debbugs.gnu.org; Fri, 28 Jun 2019 08:14:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1561724059; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=cVrvP86fVI4HbdtgdDoi57Pb+3PlWDZrJVaoYWNwDeg=; b=kTgnW6BqLehyaiTn4ExYwM83tTnM6EH1QByCtpUA2r/0oZJmcZ5R2hkri2OjpQ2xzs 5E/WUJvNONri+h1PeLl6nEWHV6GEe9vAlFIna6YUNgvfyRMAVWtganIb/saAHkHK9521 XjzhMO/o+rsya70RyCWgmmA1l2zKw4oHfLwmvlYZLOG2mhFaHzIU9Y+Di+LW6TNuuTJ/ 5GkQ6vFpkGg2V5PtzpNgJzJ4dNwD5vES2rfgIwzefVaxKz7pT0v9hBr+iY0j1Rk0htk2 /QeDnTWrB9h6CP2qd19txqokBLsDQBO5+XKKoO5sJzpm9c+cLDsJpAAlFnDhI804bC/F H8lQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGaf0zJZW" X-RZG-CLASS-ID: mo00 Original-Received: from bruno.haible.de by smtp.strato.de (RZmta 44.24 DYNA|AUTH) with ESMTPSA id v018bcv5SCEFhnF (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 28 Jun 2019 14:14:15 +0200 (CEST) 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:161707 Archived-At: Pip Cet wrote: > Or, more realistically: > > extern int potentially_inlined_function(int i); > > int main(void) > { > ... > eassume(potentially_inlined_function(i)); > return i >= 0; > } OK, I see... > This makes it safe to use function expressions in eassume, whether the > function is inlined or not. By "safe" you mean that you want the function call to not be evaluated. You are mentioning a limitation: > eassume(i >= 0 && i < complicated_function ()); > > will not "split" the && expression, so it'll behave differently from > > eassume(i >= 0); > eassume(i < complicated_function ()); And I would mention a regression: When -flto is in use and the expression invokes an external potentially-inlined function, the old 'assume' would work fine, i.e. do optimizations across compilation-unit boundaries. Whereas the new 'assume' does not. Test case: ================================ foo.c ================================= #include #define assume(R) ((R) ? (void) 0 : __builtin_unreachable ()) //#define assume(R) (!__builtin_constant_p (!(R) == !(R)) || (R) ? (void) 0 : __builtin_unreachable ()) extern int complicated (int i); extern int nonnegative (int i); int f_generic (int i) { printf("%d\n", i & 0x80000000); return 0; } int f_condition (int i) { if (complicated (i) && i >= 0) printf("%d\n", i & 0x80000000); return 0; } int f_assume (int i) { assume (complicated (i) && i >= 0); printf("%d\n", i & 0x80000000); return 0; } ================================= bar.c ================================ int complicated (int i) { return (i & 7) == 3; } int nonnegative (int i) { return i >= 0; } ======================================================================== $ gcc -O2 -m32 -flto foo.c bar.c -shared -o libfoo.so && objdump --disassemble libfoo.so With the old 'assume': 000005f0 : 5f0: 83 ec 10 sub $0x10,%esp 5f3: 6a 00 push $0x0 5f5: 68 74 06 00 00 push $0x674 5fa: 6a 01 push $0x1 5fc: e8 fc ff ff ff call 5fd 601: 31 c0 xor %eax,%eax 603: 83 c4 1c add $0x1c,%esp 606: c3 ret 607: 89 f6 mov %esi,%esi 609: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi With the new 'assume': 00000610 : 610: 83 ec 10 sub $0x10,%esp 613: 8b 44 24 14 mov 0x14(%esp),%eax 617: 25 00 00 00 80 and $0x80000000,%eax 61c: 50 push %eax 61d: 68 48 06 00 00 push $0x648 622: 6a 01 push $0x1 624: e8 fc ff ff ff call 625 629: 31 c0 xor %eax,%eax 62b: 83 c4 1c add $0x1c,%esp 62e: c3 ret 62f: 90 nop 00000630 : 630: eb de jmp 610 > But even in those cases, this approach is better than the old approach > of actually evaluating complicated_function. I disagree that it is better: 1. The new 'assume' is worse when -flto is in use. 2. You recommend to users to split assume(A && B) into assume(A); assume(B); which is unnatural. > At first, I thought it would be better to have a __builtin_assume > expression at the GCC level, but even that would have to have "either > evaluate the entire condition expression, or evaluate none of it" > semantics. No. At GCC level, it could have a "make the maximum of inferences - across all optimization phases -, but evaluate none of it" semantics. Bruno