[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 00:41:00 -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 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.

reply via email to

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