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: Sat, 29 Jun 2019 01:30:06 +0200 Message-ID: <2067160.1HRgjLhtDS__29468.1845627323$1561764700$gmane$org@omega> References: <11002295.LrvMqknVDZ@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="95887"; 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 Sat Jun 29 01:31:35 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 1hh0L8-000OrN-GL for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2019 01:31:34 +0200 Original-Received: from localhost ([::1]:36956 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh0L7-0002e4-FT for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 19:31:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53298) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh0Kw-0002dr-Rx for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 19:31:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hh0Ki-0004hC-QD for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 19:31:12 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57859) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hh0Kb-0004ak-Ul for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 19:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hh0Kb-00083q-Ot for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 19:31:01 -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 23:31:01 +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.156176461830937 (code B ref 36370); Fri, 28 Jun 2019 23:31:01 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 28 Jun 2019 23:30:18 +0000 Original-Received: from localhost ([127.0.0.1]:43170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hh0Ju-00082r-3B for submit@debbugs.gnu.org; Fri, 28 Jun 2019 19:30:18 -0400 Original-Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.53]:24819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hh0Jq-00082T-R7 for 36370@debbugs.gnu.org; Fri, 28 Jun 2019 19:30:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1561764612; 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=cYsmjqwtpXxnTJoa7z+/gsFh01ttYXSjKaz0dq8zJIs=; b=bCAN5XBVD4CX7y4aBjp8qScakbQtuUwt0r+GLNwNLYrRNrVdmIV32dArFINWNxmb3X B0wkIycA2MDfU+ywmMZqJc82qnd1hEgY0vRVz72fxVsSP/CoCsiFuBgPU9KAfZ1YdlGN fcD3tkwxKzApXLI3d2ByVCM+GzNTjVDEbhSyY20UVJRiPgoYuKUI/0PW7YZX+ztxyzRS mqdLOJM4Zo/GAnLYPjvM19iiR/jMeE6K5vRYh+zyfJsdrF/6B5NAZ3Cw1VbObOa+DNMh 72k28WG4JRCONOziB+Ic5GGASTX6XQM2HYraOQRcfVEm+7f9y9ABBFdtPtVqOruxW9dW 5U5w== 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 v018bcv5SNU7kUW (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 29 Jun 2019 01:30:07 +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:161779 Archived-At: Pip Cet wrote: > have started believing the "an inline function is as fast as a macro" > mantra*, assuming you include inline functions with "function calls". Ah, that's where the entire topic with the function calls inside assume() comes from! I agree it's an important case (more important than the functions defined in other compilation units). So let's test this: ==================================== foo.c ==================================== #include #define assume(R) ((R) ? (void) 0 : __builtin_unreachable ()) //#define assume(R) (!__builtin_constant_p (!(R) == !(R)) || (R) ? (void) 0 : __builtin_unreachable ()) #if USE_MACROS # define complicated(i) (((i) & 7) == 3) # define nonnegative(i) ((i) >= 0) #else static inline int complicated (int i) { return (i & 7) == 3; } static inline int nonnegative (int i) { return i >= 0; } #endif #if COMPLEX_CONDITION # define CONDITION complicated (i) && nonnegative (i) #else # define CONDITION nonnegative (i) #endif int f_generic (int i) { printf("%d\n", i & 0x80000000); return 0; } int f_condition (int i) { if (CONDITION) printf("%d\n", i & 0x80000000); return 0; } int f_assume (int i) { assume (CONDITION); printf("%d\n", i & 0x80000000); return 0; } =============================================================================== $ gcc -O2 -m32 -S foo.c && fgrep -v .cfi foo.s Results: // old 'assume', !COMPLEX_CONDITION, USE_MACROS -> f_assume optimized // old 'assume', COMPLEX_CONDITION, USE_MACROS -> f_assume optimized // old 'assume', !COMPLEX_CONDITION, !USE_MACROS -> f_assume optimized // old 'assume', COMPLEX_CONDITION, !USE_MACROS -> f_assume optimized // new 'assume', !COMPLEX_CONDITION, USE_MACROS -> f_assume optimized // new 'assume', COMPLEX_CONDITION, USE_MACROS -> f_assume optimized // new 'assume', !COMPLEX_CONDITION, !USE_MACROS -> f_assume not optimized // new 'assume', COMPLEX_CONDITION, !USE_MACROS -> f_assume not optimized So, the main effect of the proposed new 'assume' is that it de-optimizes the case where the CONDITION is defined using inline functions! The other case - that the CONDITION calls functions defined in other compilation units - is a fringe case. And the topic regarding the COMPLEX_CONDITION versus simple condition is also less important. Based on these results, I formally object against the proposed patch. > > (2) that the generated code will never include these function calls, > > because the generated code with the 'assume' invocation should be > > optimized at least as well as the generated code without the > > 'assume' invocation. > > I think it should be the rarest of exceptions for an assume() to > result in slower code, yes. I believe that includes the case where > functions marked inline aren't inlined, because of compiler options, > for example. Then, I think we should change the documentation of 'assume' to say that when it invokes functions, these functions should be marked '__attribute__ ((__always_inline__))', otherwise performance will be worse than without the 'assume', not better. > (1) implement the documented API, and don't change it > (2) when optimizing for speed, do not produce slower code with > eassume() than we would without it. Even when the programmer wrongly > guessed that a function would be inlined. > (3) when optimizing for size, do not produce larger code with > eassume() than we would without it. Even when inline functions are not > inlined. > (4) be at least as fast as gnulib assume() You evidently have slightly different quality criteria than I do. :) > > I believe the only way to attain the goals and the quality criteria > > is, as you suggested, to ask the GCC people to add a __builtin_assume > > built-in. > > I think there's a significant probability that the GCC people would > agree to add such a built-in, but insist on its having "may or may not > evaluate its argument" semantics. We can tell them that it would be important for us that is does not evaluate its argument. Like sizeof (EXPRESSION) does not evaluate EXPRESSION. > Sorry if I'm being a bit dense here. No problem. I'm also often being dense. Bruno