Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.

[Daniel Colascione <dancol@dancol.org>]

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?