[llvm-dev] [RFC] Usage of NDEBUG as a guard for non-assert debug code

[Fangrui Song via llvm-dev]

On 2020-04-10, Michael Kruse via llvm-dev wrote:
>#ifndef NDEBUG in the LLVM source and assert() are at least somewhat
>linked. For instance, consider
>https://github.com/llvm/llvm-project/blob/8423a6f36386aabced2a367c0ea53487901d31ca/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp#L2668
>
>The #ifndef NDEBUG is used to guard the value that checked in an
>assert() later. Only enabling assert() will cause the build to fail
>because the value is not defined. Another example is a loop only for
>the assert, eg.
>
>    #ifndef NDEBUG
>    for (auto &Val : Container)
>      assert(Val && "all");
>    #endif
>
>where the loop would loop over nothing with assertions disable. We
>cannot have a 'change all 'NDEBUG to LLVM_NO_DEBUG_CHECKS'. Even if we
>manage to leave all NDEBUG that are linked to some use of assert(), it
>doubles the number of configurations that might break in some
>configuration such as IndVarSimplify. I understand NDEBUG as `remove
>all the code only useful for developers`, independent of whether we
>also want debug symbols.
>
>I'd find it more useful to discuss what should NOT be covered under
>the blanket term LLVM_ENABLE_ASSERTIONS. Example from the past are
>LLVM_ENABLE_STATS and LLVM_ENABLE_DUMP that once was also using
>NDEBUG. 

+1 for bring up this topic.


The code base sometimes uses #ifdef NDEBUG to guard the definitions of
some struct/class members and functions.

This means there are inherent ABI incompatibility between non-NDEBUG and
NDEBUG object files. I hoped that mixing object files could work(at
least in some configurations.  Also note that having different
definitions of inline functions leads to ODR violation) but I think this
cannot be changed any more.

>As was mentioned, Support/Debug.h might be another candidate.
>But IMHO the compile-time/execution-time/code-size impact of these are
>too small to justify the increase combinatorial complexity of
>configuration. At the last LLVM DevMtg we actually discussed how to
>*reduce* the number of independent configuration parameters.
>
>Michael