From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 08:57:59 -0700 [thread overview]
Message-ID: <52582007.5080407@dancol.org> (raw)
In-Reply-To: <83d2ncrr5x.fsf@gnu.org>
On 10/11/13 4:19 AM, Eli Zaretskii wrote:
>> Date: Fri, 11 Oct 2013 02:55:44 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>>>> While the programmer may have written her C code under the assumption
>>>> that an asserted condition holds, the compiler can't know that the
>>>> asserted condition holds when generating its machine code. The point of
>>>> the assume mechanism is to provide this information to the compiler.
>>>
>>> The compiler will be unable to take advantage of that information,
>>> because there's no source code to apply that information to.
>>
>> I don't understand this argument. In my example, the assume would inform
>> the compiler that it didn't have to emit code to handle division in the
>> case that *b is zero.
>
> I think Stephen explained this already.
No, he didn't, and neither did you.
>>>>> In most cases, you won't see any code that can be optimized
>>>>> out using this assumption, as the programmer already did that --
>>>>> that's why she added the assertion in the first place.
>>>>
>>>> At the C level, not the code generation level.
>>>
>>> Code is generated from the C code, not out of thin air.
>>
>> And we're talking about giving the compiler more information about the C
>> code.
>
> Information about C code that just isn't there will not help the
> compiler.
We're asserting things about symbols that appear textually in nearby
code. That's the information we're providing. Claiming that we're not
providing information about real code is nonsense. You can't manually
perform all the transformations the compiler itself might. You can
perform some, but not all, optimization manually.
>> If the programmer really expects an assertion not to hold, he can
>> use a variant that doesn't assume the condition holds. But these
>> cases should be rare.
>
> You are wrong: in Emacs, these cases are the vast majority. Just take
> a look at the code which uses assertions.
No, I don't think those cases are the majority. I can compile Emacs
--enable-checking, then run it without seeing it insantly crash and
burn. That I can do so means these assertions are asserting things that
are actually true. The idea that we're putting into assert conditions
that might not be true is very strange. If a condition really might not
be true, the right thing is to signal an error or abort Emacs, not write
eassert.
>>>>> The problem is to make sure an assertion obviously _is_ free of side
>>>>> effects. With Emacs's massive use of macros, which call other macros,
>>>>> which call other macros, which... -- that is extremely hard. And why
>>>>> should a programmer who just wants to assert something go to such
>>>>> great lengths? That is just a maintenance burden for which I find no
>>>>> good justification.
>>>>
>>>> What great lengths? Most common macros --- things like EQ --- are
>>>> clearly free of side effects.
>>>
>>> There are a lot of macros much more complex than EQ.
>>
>> So don't use the assume-and-assert macros for questionable cases.
>
> People tend to forget subtle and obscure factoids. The risk of any
> one of us to forget and just treat this macro as a function call is
> real. See bug #15565 as a clear example.
Bug 15565 was caused by changing the semantics of existing calls to
eassert. This bug forms a poor argument against having a different macro
that asserts and assumes.
>>>> The more exotic assertions probably aren't worth assuming anyway.
>>>
>>> Not sure I understand what you are saying here.
>>
>> I'm speculating that the optimization value to be gained from assuming
>> very complex conditions is smaller than the value gained for assuming
>> relatively simple conditions.
>
> But if assume-and-assert macro exists, this abuse is exactly what is
> going to happen.
I can see changing eassert to eassume being problematic. I don't buy at
all the idea that somehow _having_ an assert-and-assume macro is
dangerous, especially if you document that this macro might evaluate its
argument even in assertion-disabled builds. It has a different name and
acts differently. That's what names are for, to distinguish behaviors.
But I'm clearly not winning this one. I think that 1) having a different
macro with different semantics is actually perfectly safe and
maintainable, and that 2) measurable (if minor) improvements in code
generation warrant changing some assertions to use this different macro
instead of eassert. But if others disagree this strongly, let's take out
the feature until we can show a specific case where it makes a bigger
difference.
prev parent reply other threads:[~2013-10-11 15:57 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
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 [this message]
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=52582007.5080407@dancol.org \
--to=dancol@dancol.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.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.