On Tue, Nov 22, 2016 at 6:52 PM, Yuri Gribov <tetra2...@gmail.com> wrote:
> Hi all,
>
> I've recently revisited an ancient patch from Paolo
> (https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00551.html) which uses
> asserts as optimization hints. I've rewritten the patch to be more
> stable under expressions with side-effects and did some basic
> investigation of it's efficacy.
>
> Optimization is hidden under !defined NDEBUG && defined
> __ASSUME_ASSERTS__. !NDEBUG-part is necessary because assertions often
> rely on special !NDEBUG-protected support code outside of assert
> (dedicated fields in structures and similar stuff, collectively called
> "ghost variables"). __ASSUME_ASSERTS__ gives user a choice whether to
> enable optimization or not (should probably be hidden under a friendly
> compiler switch e.g. -fassume-asserts).
>
> I do not have access to a good machine for speed benchmarks so I only
> looked at size improvements in few popular projects. There are no
> revolutionary changes (0.1%-1%) but some functions see good reductions
> which may result in noticeable runtime improvements in practice. One
> good  example is MariaDB where you frequently find the following
> pattern:
>   struct A {
>     virtual void foo() { assert(0); }
>   };
>   ...
>   A *a;
>   a->foo();
> Here the patch will prevent GCC from inlining A::foo (as it'll figure
> out that it's impossible to occur at runtime) thus saving code size.
>
> Does this approach make sense in general? If it does I can probably
> come up with more measurements.
>
> As a side note, at least some users may consider this a useful feature:
> http://www.nntp.perl.org/group/perl.perl5.porters/2013/11/msg209482.html

You should CC relevant maintainers or annotate the subject -- this is
a C/C++ frontend patch introducing __builtin_has_side_effects_p
plus a patch adding a GCC supplied assert.h header.

Note that from a distribution point of view I wouldn't enable assume-asserts
for a distro-build given the random behavior of __builtin_unreachable in case
of assert failure.

Richard.

> -I

Reply via email to