Re: [PING][RFC] Assertions as optimization hints

[Yuri Gribov <tetra2005 at gmail dot com>]

On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> On 2016-11-23 16:03:44 +0000, Yuri Gribov wrote:
>> 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.
>
> Yes, the problem comes from the fact that ISO C provides only one
> form of assertions. In GNU MPFR, we have two kinds of assertions
> (different from the one used above), but they are not based on
> assert():
>
>    MPFR_ASSERTN(expr): assertions that should normally be checked,
>      otherwise give a hint to the compiler.
>
>    MPFR_ASSERTD(expr): assertions that should be checked when testing,
>      otherwise give a hint to the compiler.
>
> Basically, MPFR_ASSERTN() will be used to do some checks on data
> provided by the caller (e.g. to detect some API misuse), and
> MPFR_ASSERTD() is there to detect internal inconsistencies (i.e.
> bugs in MPFR).
>
> IMHO, this is the correct way to do, as one can then enables hints
> without breaking code like the above one.

Yes, many projects adopted similar approach. And it's indeed a pity
that standard does not distinguish between assume and assert so we
don't have universal mechanism to inform compiler about exploitable
code invariants.

> Concerning the "per-project decision", I'm not sure that's a good
> idea: as soon as one includes a header file, __ASSUME_ASSERTS__
> could potentially break code.

Sorry, not sure I understood. __ASSUME_ASSERTS__ is supplied via
cmdline when compiling project's shared libraries and executables to
treat assertions as hints (effectively similar to MS __assume
directives). It does not propagate to project's public header files.

> Said otherwise, if the user wants
> optimization hints, it should not be based on assert().

If project can invest time in refactoring their error checking code
and instructing compiler about internal invariants - that's certainly
the way to go. The only advantage of suggested approach is ease of use
(it can be deployed in couple of minutes).

> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)