all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Daniel Colascione <dancol@dancol.org>,
	emacs-devel@gnu.org, eggert@cs.ucla.edu
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use	'assume'.
Date: Fri, 11 Oct 2013 08:42:20 -0400	[thread overview]
Message-ID: <jwvr4bsugu9.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87a9ighzkp.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Fri, 11 Oct 2013 19:27:50 +0900")

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

Indeed, the cases where the compiler can optimize the code based on the
assume statement are fairly rare, because in most cases the programmer
has already done most of this work by hand.

I tend to agree with Daniel that `assert' should pretty much always be
"assert + assume", in theory.  In practice the fact that "assume" may
occasionally have a cost, and the fact that it rarely offers further
optimization opportunities, makes it less attractive than it appears
at first.

At the same time, this is all a tempest in a teapot: the difference
is minuscule either way.


        Stefan


PS: Cases where assert+assume could make a difference is if we only had
(say) the CAR macro but not the XCAR macro, in which case an
"assert+assume (CONSP (x))" could be used to tell the compiler that the
type test embedded in CAR can be skipped.
But of course, we don't trust the compiler to do this optimization for
us, so instead we created the XCAR macro, at which point the
"assert+assume (CONSP (x))" is no better than just "assert (CONSP (x))".



  reply	other threads:[~2013-10-11 12:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1VTxwB-0001h8-7E@vcs.savannah.gnu.org>
2013-10-11  2:31 ` [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume' Daniel Colascione
2013-10-11  6:36   ` Paul Eggert
2013-10-11  7:00     ` Eli Zaretskii
2013-10-11  7:41       ` Daniel Colascione
2013-10-11  8:08         ` Eli Zaretskii
2013-10-11  8:19           ` Daniel Colascione
2013-10-11  8:59             ` Stephen J. Turnbull
2013-10-11  9:10               ` Daniel Colascione
2013-10-11 10:27                 ` Stephen J. Turnbull
2013-10-11 12:42                   ` Stefan Monnier [this message]
2013-10-11 15:24                     ` Stephen J. Turnbull
2013-10-11  9:06             ` Eli Zaretskii
2013-10-11  9:18               ` Daniel Colascione
2013-10-11  9:36                 ` Eli Zaretskii
2013-10-11  9:55                   ` Daniel Colascione
2013-10-11 10:31                     ` Dmitry Antipov
2013-10-11 15:22                       ` Paul Eggert
2013-10-11 15:41                         ` Daniel Colascione
2013-10-12  7:37                           ` Paul Eggert
2013-10-11 11:19                     ` Eli Zaretskii
2013-10-11 15:57                       ` Daniel Colascione

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvr4bsugu9.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dancol@dancol.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.