From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'. Date: Fri, 11 Oct 2013 08:22:01 -0700 Organization: UCLA Computer Science Department Message-ID: <52581799.3060501@cs.ucla.edu> References: <52576305.9000703@dancol.org> <52579C68.1040904@cs.ucla.edu> <83iox4pa0w.fsf@gnu.org> <5257AB8C.40309@dancol.org> <83eh7sp6v0.fsf@gnu.org> <5257B489.2050609@dancol.org> <83k3hkrxao.fsf@gnu.org> <5257C27B.9090400@dancol.org> <83hacorvww.fsf@gnu.org> <5257CB20.4030809@dancol.org> <5257D36B.4090305@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1381512681 24864 80.91.229.3 (11 Oct 2013 17:31:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2013 17:31:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 11 19:31:24 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VUgYc-0002f5-NH for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 19:31:22 +0200 Original-Received: from localhost ([::1]:55064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUeja-0005CQ-2z for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 11:34:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUeXh-00016X-ON for emacs-devel@gnu.org; Fri, 11 Oct 2013 11:22:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUeXa-0002Cf-Ag for emacs-devel@gnu.org; Fri, 11 Oct 2013 11:22:17 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:56922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUeXa-0002CY-2P for emacs-devel@gnu.org; Fri, 11 Oct 2013 11:22:10 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 46524A60006; Fri, 11 Oct 2013 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viVnBD9kgGwT; Fri, 11 Oct 2013 08:22:08 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id A2375A60005; Fri, 11 Oct 2013 08:22:08 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <5257D36B.4090305@yandex.ru> X-Enigmail-Version: 1.5.2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164102 Archived-At: Dmitry Antipov wrote: > May be I missed something, but could you please provide an example where > assume (...) really yields in better code? I observed minor performance improvements, though it wasn't clear to me that they would result in significant user-visible performance wins. Here's a toy example: #include #define BITS_PER_WORD 16 int arem (int x) { return x % BITS_PER_WORD; } int brem (int x) { assume (x >= 0); return x % BITS_PER_WORD; } On Fedora 19 x86-64 with gcc -O2, this generates: arem: movl %edi, %edx sarl $31, %edx shrl $28, %edx leal (%rdi,%rdx), %eax andl $15, %eax subl %edx, %eax ret brem: movl %edi, %eax andl $15, %eax ret brem is simpler and faster because the compiler knows that the dividend is nonnegative. This is a simple case. In other, more complicated cases, it wasn't clear to me that the code with 'assume (COND)' was faster -- it could be slower, as far as I could see, even when COND was obviously side-effect free. I worry that at least some of these cases reflect optimization glitches in GCC, but perhaps in the long run these glitches will get fixed. My main worry about 'eassume' vs 'eassert' is the maintenance hassle. Obviously one shouldn't use 'eassume' on expressions with side effects, but that's not always obvious. For example: eassert (input_blocked_p ()); Is it OK to replace this with eassume? At first it seems so, as input_blocked_p is an inline function that only reads a variable. But that'd be incorrect, as the variable is volatile, and accessing a volatile variable counts as a side effect, and GCC cannot optimize it away. This is fairly tricky stuff, alas; is it worth worrying about this sort of thing? This is why I asked Daniel for a performance assessment of how well 'assume' really helped Emacs. For example, currently Emacs does this in alloc.c: eassume (exact_payload_bytes <= total_payload_bytes); Does this result in significant performance improvements? If not, it's probably not worth the maintenance hassle to distinguish 'eassume' from 'eassert', and we should simply replace this 'eassume' calls with 'eassert'. But if if there's an important performance win sometimes with 'eassume', then it is probably worth the maintenance hassle, at least for the cases where there is such a win.