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

[Daniel Colascione]

On 10/11/13 12:00 AM, Eli Zaretskii wrote:
> > Date: Thu, 10 Oct 2013 23:36:24 -0700
> > From: Paul Eggert <address@hidden>
> >
> > Daniel Colascione wrote:
> > > By merging eassert_and_assume with eassert, then removing the assume from 
> > > eassert, you've essentially removed calls to assume and pessimized the code.
> >
> > OK, in trunk bzr 114622 I restored eassert_and_assume
> > (under the shorter name 'eassume'), but can you measure
> > how much performance you're gaining with this change?

I don't expect major gains yet, since I haven't fully fleshed out my 
actual use of the feature. That said, I don't like the code generation 
that happens without the assume: the compiler has to generate code as if 
we could be working with negative numbers, but that never happens in 
reality.

> > The eassume macro is tricky to use (as it sometimes makes
> > performance worse) so I'd rather omit it if any
> > performance gains are insignificant.

I'd rather keep it in so it gains more use, especially if we insist on 
using signed arithmetic everywhere.  It doesn't "make performance worse" 
per se: what it does is evaluate side effects in its argument, and 
sometimes those side effects are expensive. If used with an argument 
that's cheap to evaluate --- say, eassume (x < y) --- it should only 
help performance.

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