[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: Eli Zaretskii
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 11:08:35 +0300

> Date: Fri, 11 Oct 2013 00:41:00 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> > I'm also curious as to why this is needed.  Again, 'assume' is an
> > optimization device, and 'eassert' is not normally compiled in
> > optimized builds.  What are the use cases for this?
> True, assertions and assume declarations are different, but they're 
> similar in that they both communicate information about constraints.  A 
> macro like eassume is useful because, with one line of code, it informs 
> the optimizer about a possible optimization _and_ checks (when checking 
> is on) that what we told the optimizer isn't full of lies. The last bit 
> is important because the consequence of an incorrect assume declaration 
> is incorrect code generation.
> The side effect problem Dmitry found is the reason I didn't just fold 
> assume into eassert myself. Having a single macro available that assumes 
> and asserts can be useful to avoid duplication when touching new code 
> that wants both kinds of semantics. IIRC from the other thread, Emacs is 
> smaller when we merge the two constructs, so it looks like there are 
> real gains to be had.
> I think the bulk of assertions can be converted: while it's easy to 
> imagine IT_STRING_CHARPOS turning into a call to some expensive 
> function, it's harder to imagine something like EQ gaining new side effects.

Maybe I'm missing something, but I don't think this answers my

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, 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.

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

reply via email to

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