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

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.
> 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?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/d061eb1c/attachment.html>

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/llvm-dev/attachments/20140103/1786124e/attachment.html>

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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/c37f259e/attachment.html>