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

[Chandler Carruth]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/4ec931e4/attachment.html>