"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:

> I'd not agree. I mean: I like the idea of hinting to the compiler, but I'd
> use a different macro. Something like ASSERT_OR_HINT, or simply HINT.

Right, a separate macro seems safer.

> But we also have ASSERTs that calls functions!
> e.g. in mpn/generic/hgcd_reduce.c we have, twice, the line:
>       ASSERT (mpn_zero_p (tp + nn, modn - nn));
> that hardly translate into a good hint for the compiler...

If mpn_zero_p is declared properly to have no side effects, then I
think the function call should be optimized away, so it should be
harmless, although no useful hinting either.

Marc's example,

  ASSERT (refmpn_mul_1c (prod, rp, size, divisor, carry) == carry_orig)

wouldn't be optimized away, since it has side effects, and it's hard for
the compiler to tell if the rest of the code depends on them or not.
This is test code though, I hope it's rare to call ASSERT with
(irrelevant) side effects in the library code.

So perhaps it's best to just keep our eyes open for places where a hint
using __builtin_unreachable actually improves code generation, and
introduce ASSERT_HINT at that point.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Reply via email to