On Wed, Nov 23, 2016 at 11:31 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> 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.
Thanks, Richard, I've cc-ed Joseph (who is both frontend maintainer
and also commented on old version of this patch).
> 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.
Definitely, aggressively abusing assertions like this should be a
per-project decision. E.g. I've seen code which parallels assertions
with error checking i.e. something like
FILE *p = fopen(...);
assert(p); // Quickly abort in debug mode
if (!p)
return ERROR;
Enabling __ASSUME_ASSERTS__ for such code would effectively disable
all safety checks.
On the other hand many projects use assert(0) to mark unreachable
regions of code (e.g. in default branches of switch statements) and
optimizing these out sounds like a viable decision to me.
-Iurii
