I have a macro used all over my code that in debug mode does:
#define contract(condition) \ if (!(condition)) \ throw exception("a contract has been violated");
... but in release mode:
#define contract(condition) \ if (!(condition)) \ __builtin_unreachable();
What this does over an assert()
is that, in release builds, the compiler can heavily optimize the code thanks to UB propagation.
For example, testing with the following code:
int foo(int i) { contract(i == 1); return i; } // ... foo(0);
... throws an exception in debug mode, but produces assembly for an unconditional return 1;
in release mode:
foo(int): mov eax, 1 ret
The condition, and everything that depended on it, has been optimized out.
My issue arises with more complex conditions. When compiler cannot prove that the condition has no side effect, it does not optimize it out, which is a runtme penalty compared to not using the contract.
Is there a way to express that the condition in the contract has no side effect, so that it is always optimized out?
GCC has a range of optimization levels, plus individual options to enable or disable particular optimizations. The overall compiler optimization level is controlled by the command line option -On, where n is the required optimization level, as follows: -O0 . (default).
To be pedantic, there are 8 different valid -O options you can give to gcc, though there are some that mean the same thing.
GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O , this option increases both compilation time and the performance of the generated code.
The compiler optimizes to reduce the size of the binary instead of execution speed. If you do not specify an optimization option, gcc attempts to reduce the compilation time and to make debugging always yield the result expected from reading the source code.
Is there a way to express that the condition in the contract has no side effect, so that it is always optimized out?
Not likely.
It's known that you cannot take a big collection of assertions, turn them into assumptions (via __builtin_unreachable
) and expect good results (e.g. Assertions Are Pessimistic, Assumptions Are Optimistic by John Regehr).
Some clues:
CLANG, while already having the __builtin_unreachable
intrinsic, introduced __builtin_assume exactly for this purpose.
N4425 - Generalized Dynamic Assumptions(*) notes that:
GCC does not explicitly provide a general assumption facility, but general assumptions can be encoded using a combination of control flow and the
__builtin_unreachable
intrinsic...
The existing implementations that provide generic assumptions use some keyword in the implementationreserved identifier space (
__assume
,__builtin_assume
, etc.). Because the expression argument is not evaluated (side effects are discarded), specifying this in terms of a special library function (e.g.std::assume
) seems difficult.
The Guidelines Support Library (GSL, hosted by Microsoft, but in no way Microsoft specific) has "merely" this code:
#ifdef _MSC_VER #define GSL_ASSUME(cond) __assume(cond) #elif defined(__clang__) #define GSL_ASSUME(cond) __builtin_assume(cond) #elif defined(__GNUC__) #define GSL_ASSUME(cond) ((cond) ? static_cast<void>(0) : __builtin_unreachable()) #else #define GSL_ASSUME(cond) static_cast<void>(!!(cond)) #endif
and notes that:
// GSL_ASSUME(cond) // // Tell the optimizer that the predicate cond must hold. It is unspecified // whether or not cond is actually evaluated.
*) Paper rejected: EWG's guidance was to provide the functionality within the proposed contract facilities.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With