[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 01:19:21 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0

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

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]