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

[Paul Eggert <eggert@cs.ucla.edu>]

Dmitry Antipov wrote:

> May be I missed something, but could you please provide an example where
> assume (...) really yields in better code?

I observed minor performance improvements, though it wasn't
clear to me that they would result in significant
user-visible performance wins.  Here's a toy example:

	#include <verify.h>
	#define BITS_PER_WORD 16
	int arem (int x) { return x % BITS_PER_WORD; }
	int brem (int x) { assume (x >= 0); return x % BITS_PER_WORD; }

On Fedora 19 x86-64 with gcc -O2, this generates:

	arem:
		movl	%edi, %edx
		sarl	$31, %edx
		shrl	$28, %edx
		leal	(%rdi,%rdx), %eax
		andl	$15, %eax
		subl	%edx, %eax
		ret

	brem:
		movl	%edi, %eax
		andl	$15, %eax
		ret

brem is simpler and faster because the compiler knows that
the dividend is nonnegative.

This is a simple case.  In other, more complicated cases, it
wasn't clear to me that the code with 'assume (COND)' was
faster -- it could be slower, as far as I could see, even
when COND was obviously side-effect free.  I worry that at
least some of these cases reflect optimization glitches in
GCC, but perhaps in the long run these glitches will get
fixed.

My main worry about 'eassume' vs 'eassert' is the maintenance
hassle.  Obviously one shouldn't use 'eassume' on expressions
with side effects, but that's not always obvious.  For example:

  eassert (input_blocked_p ());

Is it OK to replace this with eassume?  At first it seems
so, as input_blocked_p is an inline function that only reads
a variable.  But that'd be incorrect, as the variable is
volatile, and accessing a volatile variable counts as a side
effect, and GCC cannot optimize it away.  This is fairly
tricky stuff, alas; is it worth worrying about this sort
of thing?

This is why I asked Daniel for a performance assessment of
how well 'assume' really helped Emacs.  For example, currently
Emacs does this in alloc.c:

  eassume (exact_payload_bytes <= total_payload_bytes);

Does this result in significant performance improvements?
If not, it's probably not worth the maintenance hassle to
distinguish 'eassume' from 'eassert', and we should simply
replace this 'eassume' calls with 'eassert'.  But if if
there's an important performance win sometimes with
'eassume', then it is probably worth the maintenance hassle,
at least for the cases where there is such a win.