[llvm-dev] [RFC] Usage of NDEBUG as a guard for non-assert debug code
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 10 12:26:40 PDT 2020
On Fri, Apr 10, 2020 at 10:15 AM Fangrui Song via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
> >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
> +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.
Not sure I'm following - what "cannot be changed anymore"? If there are ABI
changing uses of NDEBUG they can and should be changed to
> >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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev