This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PING][RFC] Assertions as optimization hints
- From: Allan Sandfeld Jensen <linux at carewolf dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>, Paolo Bonzini <bonzini at gnu dot org>, alexr at leftfield dot org
- Date: Mon, 28 Nov 2016 01:42:23 +0100
- Subject: Re: [PING][RFC] Assertions as optimization hints
- Authentication-results: sourceware.org; auth=none
- References: <CAJOtW+48=FfefSgyPakMmFzaHfCqNv0CpXY-1p3gva4ShuqgjA@mail.gmail.com> <CAFiYyc2oi9brPTnTBGNE8n4T5OOFSxOCF3oeFo=qcT2zMzo6Sg@mail.gmail.com>
On Wednesday 23 November 2016, Richard Biener wrote:
> On Tue, Nov 22, 2016 at 6:52 PM, Yuri Gribov <tetra2005@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.
>
One option could be to provide such behaviour as new builtins, to be used for
GSL implementations of Expects() and Ensures(). See
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
and https://github.com/Microsoft/GSL/blob/master/gsl/gsl_assert
But I think using the data from asserts should be safe and useful too, though
there might be problems here and there with assert that only makes sense as
#ifndef(NDEBUG) builds.
`Allan