[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers
From: |
Bruno Haible |
Subject: |
Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers |
Date: |
Sat, 29 Jun 2019 12:31:27 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-151-generic; KDE/5.18.0; x86_64; ; ) |
Pip Cet wrote:
> I would like to state that the current assume does
> behave very badly when combined with -fno-inline-small-functions
> -fno-inline.
Since we can't address this limitation through an acceptable change
to the 'assume' macro, we need to address it through documentation.
> marking it
> as __attribute__((always_inline)) is problematic because it might
> directly contradict what the programmer was trying to achieve by
> passing -fno-inline.
__attribute__((always_inline)) exists precisely to make a distinction
between functions where inlining is usually desirable vs. functions
where inlining is essential. We don't need to warn against the uses
of __attribute__((always_inline)) -- confusing behaviour in the debugger
etc. -- becauses these drawbacks are already well-known.
Paul Eggert wrote:
> I suggest something simpler and a little more general. The Emacs
> documentation
> for 'eassume' says this:
>
> This can improve performance in some cases,
> though it can degrade performance in others. It's often suboptimal
> for COND to call external functions or access volatile storage.
>
> and we could migrate that into the documentation for 'assume'.
As a user of the 'assume' macro, I want a definitive statement about what
I need to provide so that the macro works in the sense of improved performance.
A statement about "often" is too vague.
How about this proposed patch?
diff --git a/lib/verify.h b/lib/verify.h
index f8e4eff..ed1ba19 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -261,7 +261,10 @@ template <int w>
/* Assume that R always holds. This lets the compiler optimize
accordingly. R should not have side-effects; it may or may not be
- evaluated. Behavior is undefined if R is false. */
+ evaluated. The behavior is undefined if R is false.
+ If you want the use of this macro to improve, not deteriorate,
+ performance, R should not contain function calls except to functions
+ that are declared 'inline __attribute__((__always_inline__))'. */
#if (__has_builtin (__builtin_unreachable) \
|| 4 < __GNUC__ + (5 <= __GNUC_MINOR__))
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, (continued)
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/28
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Paul Eggert, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Paul Eggert, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/30
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Bruno Haible, 2019/06/28
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/28
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Bruno Haible, 2019/06/28
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Paul Eggert, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers,
Bruno Haible <=
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Paul Eggert, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Bruno Haible, 2019/06/29
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/30
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Bruno Haible, 2019/06/30
- Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Richard Stallman, 2019/06/30
Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers, Pip Cet, 2019/06/27