emacs-devel
[Top][All Lists]
Advanced

[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: Stephen J. Turnbull
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 19:27:50 +0900

Daniel Colascione writes:
 > On 10/11/13 1:59 AM, Stephen J. Turnbull wrote:

 > > apparently optimizers are sufficiently stupid as to compile worse
 > > code when assume is present (at least that's what Paul seemed to
 > > claim).
 > 
 > I don't think that's actually the case. We implement assume using GCC's 
 > __builtin_unreachable:
 >     if (!(assumed_condition)) {  __builtin_unreachable(); }.
 > If assumed_condition has side effects, then normal semantics
 > requires that the compiler emit code to implement [them].

Ah, OK, it's not the optimizer that's stupid, it's just GCC.  What
else is new, eh?[1]

However, I have to agree with Eli.[2]  One writes "assert(width>0)" when
one is about to write "aspect_ratio = height/width", and doesn't want
to write

    if (width > 0)
        aspect_ratio = height/width;
    else
        beep_loudly_to_annoy_user();  /* or other error recovery */

One would hope that a optimizing compiler given

    assume(width > 0);                /* Look Ma, all plusses! */
    if (width > 0)
        aspect_ratio = height/width;
    else
        beep_loudly_to_annoy_user();  /* or other error recovery */

would produce the same machine code as just

    aspect_ratio = height/width;

but look! we've already done that optimization.  It just comes
naturally.

I've seen a lot of handwaving, but if there's a case where assume
helps the compiler produce better code in Emacs, I've yet to see it
presented.


Footnotes: 
[1]  I'm sure they have their reasons.  Whatever they are, they sure
weren't invented by Emacs hackers.

[2]  Note that it's not necessarily a question of valid use cases that
the programmer didn't imagine.  There may be a bug elsewhere in the
program that manifests here, or even in the compiler.




reply via email to

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