<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 12:35 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com">maskray@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Apr 10, 2020 at 12:26 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 10:15 AM Fangrui Song via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-10, Michael Kruse via llvm-dev wrote:<br>
>#ifndef NDEBUG in the LLVM source and assert() are at least somewhat<br>
>linked. For instance, consider<br>
><a href="https://github.com/llvm/llvm-project/blob/8423a6f36386aabced2a367c0ea53487901d31ca/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp#L2668" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/8423a6f36386aabced2a367c0ea53487901d31ca/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp#L2668</a><br>
><br>
>The #ifndef NDEBUG is used to guard the value that checked in an<br>
>assert() later. Only enabling assert() will cause the build to fail<br>
>because the value is not defined. Another example is a loop only for<br>
>the assert, eg.<br>
><br>
>    #ifndef NDEBUG<br>
>    for (auto &Val : Container)<br>
>      assert(Val && "all");<br>
>    #endif<br>
><br>
>where the loop would loop over nothing with assertions disable. We<br>
>cannot have a 'change all 'NDEBUG to LLVM_NO_DEBUG_CHECKS'. Even if we<br>
>manage to leave all NDEBUG that are linked to some use of assert(), it<br>
>doubles the number of configurations that might break in some<br>
>configuration such as IndVarSimplify. I understand NDEBUG as `remove<br>
>all the code only useful for developers`, independent of whether we<br>
>also want debug symbols.<br>
><br>
>I'd find it more useful to discuss what should NOT be covered under<br>
>the blanket term LLVM_ENABLE_ASSERTIONS. Example from the past are<br>
>LLVM_ENABLE_STATS and LLVM_ENABLE_DUMP that once was also using<br>
>NDEBUG. <br>
<br>
+1 for bring up this topic.<br>
<br>
<br>
The code base sometimes uses #ifdef NDEBUG to guard the definitions of<br>
some struct/class members and functions.<br>
<br>
This means there are inherent ABI incompatibility between non-NDEBUG and<br>
NDEBUG object files. I hoped that mixing object files could work(at<br>
least in some configurations.  Also note that having different<br>
definitions of inline functions leads to ODR violation) but I think this<br>
cannot be changed any more.<br></blockquote><div><br>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 LLVM_ENABLE_ABI_BREAKING_CHECKS.</div></div></div></blockquote><div><br></div><div>I agree that many NDEBUG uses are actually LLVM_ENABLE_ABI_BREAKING_CHECKS. By "cannot be changed anymore" I mean there are so many NDEBUG (700+ files),</div><div>I am not sure we can still make mixing non-NDEBUG and NDEBUG object files work...</div></div></div></blockquote><div><br>I'm not sure that "many NDEBUG uses should actually be LLVM_ENABLE_ABI_BREAKING_CHECKS" - I would guess that most NDEBUG uses are correctly non-abi breaking, but those that are abi-breaking can/should be changed/fixed. Not all of those 700+ are abi breaking, probably most aren't. And the folks that introduced LLVM_ENABLE_ABI_BREAKING_CHECKS and other folks who've found that mode valuable have made fixes/continued to maintain the feature I think.<br><br>Perhaps not - perhaps the feature has bitrotted to the point of uselessness, in which case if no one's interested in it, it could be removed. I don't believe that's the case, though - just a guess.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>As was mentioned, Support/Debug.h might be another candidate.<br>
>But IMHO the compile-time/execution-time/code-size impact of these are<br>
>too small to justify the increase combinatorial complexity of<br>
>configuration. At the last LLVM DevMtg we actually discussed how to<br>
>*reduce* the number of independent configuration parameters.<br>
><br>
>Michael<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div><br></div>
</blockquote></div></div>