From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'. Date: Fri, 11 Oct 2013 01:19:21 -0700 Message-ID: <5257B489.2050609@dancol.org> References: <52576305.9000703@dancol.org> <52579C68.1040904@cs.ucla.edu> <83iox4pa0w.fsf@gnu.org> <5257AB8C.40309@dancol.org> <83eh7sp6v0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1381479632 22138 80.91.229.3 (11 Oct 2013 08:20:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2013 08:20:32 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 11 10:20:35 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 1VUXxb-0000hZ-NC for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 10:20:35 +0200 Original-Received: from localhost ([::1]:53010 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXxb-0001aM-8h for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 04:20:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXxP-0001ZH-ML for emacs-devel@gnu.org; Fri, 11 Oct 2013 04:20:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUXxH-00024W-4f for emacs-devel@gnu.org; Fri, 11 Oct 2013 04:20:23 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXx7-00020L-W4; Fri, 11 Oct 2013 04:20:06 -0400 Original-Received: from [173.252.71.189] (helo=dcolascione-mbp.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VUXx6-0001C1-Vi; Fri, 11 Oct 2013 01:20:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <83eh7sp6v0.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:164078 Archived-At: On 10/11/13 1:08 AM, Eli Zaretskii wrote: > Let me rephrase: assertions are used in unoptimized code, and compile > to nothing in optimized code. 'assume' is not needed in unoptimized > code, since that code is grossly inefficient anyway. Thus, it sounds > like the two are almost perfectly orthogonal Say we have this function: void foo (int *a, int *b) { *a = *a / *b; } Suppose it's part of foo's contract that it never be called with *b == 0. In checked builds, we add an assertion to catch callers that violate the contract: void foo (int *a, int *b) { eassert (*b != 0); *a = *a / *b; } Now suppose we also want the optimizer to take advantage of the fact that *b != 0. Because we have the assertion, we're confident that callers never actually pass a *b equal to 0. void foo (int *a, int *b) { eassert (*b != 0); assume (*b != 0); *a = *a / *b; } Now we've said *b != 0 twice. That's silly. We should just combine the eassert and assume into a single construct: void foo (int *a, int *b) { eassume (*b != 0); *a = *a / *b; } The connection between assume and assert is that both of them accept an expression that we expect to always evaluate to true. It's only what the program does with that information that differs: in the assert case, we check that the constraint is met. In the assume case, we optimize assuming the constraint has been met. The condition itself is almost always the same. > , and lumping them > together into a single construct is likely to continue bumping upon > problems that stem from basic incompatibility between the use cases, > which target two different non-overlapping build types. Only when we have side effects. Looking through the code just now, I only saw a few assertions that weren't obviously free of side effects. > IOW, you should almost _never_ need to use 'assume' where you use > 'eassert', and vice versa. So why do we need a single macro that does > both? I'd actually argue that you should almost always combine assert and assume. You've gone through the trouble of spelling out constraints on program execution: why not let the optimizer take advantage of that information?