Bruno Haible wrote:
+ 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__))'. */
A reader of that might incorrectly conclude that using such functions will
always improve performance, compared to using functions not declared that way.
And I'm leery of putting such GCC-specific info into the documentation of a
generic macro.
Also, given Pip Cet's misunderstanding it'd be helpful to add a word or two
about the intent of 'assume (R)'.
How about the attached patch?
> - evaluated. Behavior is undefined if R is false. */
> + evaluated. The behavior is undefined if R is false.
This is a nit, but to my ears the shorter version is better, and has a
more-accurate connotation as "the behavior" connotes "the behavior of 'assume
(R)'", whereas behavior is also undefined for code before or after a call to an
incorrect 'assume (R)'.
diff --git a/lib/verify.h b/lib/verify.h
index f8e4eff02..168a7afdb 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -259,9 +259,11 @@ template <int w>
# define __has_builtin(x) 0
#endif
-/* 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. */
+/* Assume that R always holds. Behavior is undefined if R is false.
+ R should lack side effects, as it may be evaluated only partially.
+ Although 'assume (R)' is typically intended to help performance,
+ performance may degrade if R uses hard-to-optimize features
+ such as calls to non-inlined functions. */
#if (__has_builtin (__builtin_unreachable) \
|| 4 < __GNUC__ + (5 <= __GNUC_MINOR__))
