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

[Chandler Carruth]

On Fri, Jan 3, 2014 at 5:04 PM, Chris Lattner <clattner at apple.com> wrote:

> On Jan 3, 2014, at 1:55 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> >
>> > The key thing then is to make sure that it's safe to enable the
>> > assertions in the headers if an application is built with !NDEBUG and
>> > linked against an NDEBUG version of LLVM.
>>
>> Sounds great.  I'm pretty confident that there will be no problems - in
>> practice - from any ODR violations that might arise from "assert" differing
>> across library boundaries.  We would want some pretty strong practical
>> justification for breaking away from standard assert.
>
>
> Sorry to dig up this thread, but when re-reading it, I was surprised that
> everyone seems to think this will be easily done across all of LLVM.
>
> How can we support AssertingVH, which behaves as a POD-like struct around
> a pointer in NDEBUG, and as a class with significant (important)
> functionality to implement asserts on dangling value handles in !NDEBUG
> builds?
>
> 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...


>
> We also have quite a few places in LLVM today that conserve memory usage
> in non-assert builds by removing unnecessary members of classes. We can say
> that this makes the ABI more fragile, but it is a valuable space
> optimization. Chris, are you saying to strongly believe that these should
> only be allowed for classes that are not visible in the C++ API? I find
> that surprising, as LLVM has historically prioritized efficiency and
> developer tools over ABI stability in our C++ APIs. Build-level instability
> is certainly a different beast from version stability, but I wanted to make
> sure the ramifications of this shift were being considered by everyone.
> (They hadn't by me.)
>
>
> Do you have any specific examples in mind?
>

Several passes do this, but currently they are hidden in a single TU. It
would only become a problem if/when they had logic hoisted to an analysis.
The best current example I found with a quick search is
FunctionLoweringInfo, but maybe we could pay the cost there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140103/1786124e/attachment.html>