<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jan 3, 2014, at 4:36 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 3, 2014 at 7:24 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Jan 3, 2014, at 2:19 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><blockquote type="cite"><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the exposure of this facility to library-level consumers.</div>

</blockquote><div><br></div></div><div>I hadnít considered AssertVH, and I agree that losing it isnít an option.</div><div><br></div><div>Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds?  I havenít looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something.</div>

</div></blockquote><div><br></div><div>If you want methods to still be inlined in the non-assert case, you still have an ABI break in how you interpret the pointer...</div><div> </div></div></div></div></blockquote>
<br></div></div><div>Iím suggesting that AssertVH be redesigned: it could be a PointerUnion (in all build modes) and .o files which are built in debug mode would put a callback vh into it.  Clients built in release mode would put a raw pointer in it.</div>
<div><br></div><div>Release builds would pay some small cost to check the tag bit, but I think that would be acceptable.</div></blockquote></div><br>I just don't see why this substantial complexity and lower performance of AssertingVH is worth having the ability to mix and match NDEBUG and !NDEBUG translation units both in LLVM and in consuming libraries.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I thought the motivation was for user code to turn assertions on and off in their code without re-building LLVM to match? That would be addressed by just making the assertions in LLVM keyed off of an LLVM-specific build time flag (like any of the other ABI impacting such flags, for example the particular subset of C++11 supported).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Is there some other use case?<br></div></div>
</blockquote></div><br><div>Chandler and I spoke about this a bit on IRC, he convinced me (not that Iím the only voice here :) that there isnít a strong motivation for doing this: even today you can build llvm as release+asserts and clang debug+asserts, which is the most common mixed mode.</div><div><br></div><div>-Chris</div></body></html>