[cfe-dev] Goal for 3.5: Library-friendly headers

[Chris Lattner]

On Jan 3, 2014, at 4:36 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Fri, Jan 3, 2014 at 7:24 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jan 3, 2014, at 2:19 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>> 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.
>> 
>> I hadn’t considered AssertVH, and I agree that losing it isn’t an option.
>> 
>> 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.
>> 
>> 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...
>>  
> 
> 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.
> 
> Release builds would pay some small cost to check the tag bit, but I think that would be acceptable.
> 
> 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.
> 
> 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).
> 
> Is there some other use case?

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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140107/97d911ec/attachment.html>