[libcxx-dev] proposal: decoupling Freestanding atomic<T> from libatomic.a

Ben Craig via libcxx-dev libcxx-dev at lists.llvm.org
Tue Jan 1 07:55:06 PST 2019


Are you hoping to enable this just on the device side, or also on the host side?  If it is just on the device side, then the ABI is yours to choose and/or break.  If it's on the host side, that gets trickier.  I'm also wondering if you are trying to make it possible for the layout of std::atomic to match between host and device to enable cross domain synchronization.


If your work extends to the host side of things, then it seems like you are falling into the camp that wants to mix freestanding and hosted in the same application, and that feels like an ODR trap waiting to spring.


________________________________
From: Olivier Giroux <OGiroux at nvidia.com>
Sent: Monday, December 31, 2018 8:53 PM
To: Ben Craig; libcxx-dev at lists.llvm.org
Subject: Re: [libcxx-dev] proposal: decoupling Freestanding atomic<T> from libatomic.a


The best reason I can see to layer libcxx atomics on the C11 atomics is that there’s probably no other way to ensure interoperability between C1* and C++1* for toolchains that want to do that. I agree with your assessment that a toolchain using embeddeds lock for C1* _Atomic(T) will just work with libcxx – I haven’t any doubt.



There are at least two issues RE: _Atomic(T) where my situation is concerned:

  1.  We’re not interested in implementing C1* at the moment, and it’s not actually a requirement to implement C++1* either. Hence we’re more interested in the __atomic_* backend than the __c11_atomic_* backend to libcxx atomic.
     *   This is a great reason for libcxx to retain this backend: implementations of C++ that don’t depend on C.
  2.  We don’t control what host CPU compilers will do for _Atomic(T) and even if we did, we’re locked into platform ABI choices for host CPUs that have largely shied from embedded locks (except on Windows) and we’d still have to match.
     *   Given our C++ centric focus, it’s much simpler to address this in the library layer.



This being said, my proposed change makes it possible to turn this path on or off regardless of whether the __c11_atomic_* or the __atomic_* backend is used. At the moment I’m poposing to turn it on merely because LIBCXX_FREESTANDING is set, but we could be more selective than that, it could be part of what __config selects when in a Freestanding configuration. We do need to be careful that there exist at least one public configuration that uses it; I don’t want to put this path in there and only turn it on in a private configuration.



Olivier



From: Ben Craig <ben.craig at ni.com>
Date: Monday, December 31, 2018 at 6:16 PM
To: Olivier Giroux <OGiroux at nvidia.com>, "libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
Subject: Re: [libcxx-dev] proposal: decoupling Freestanding atomic<T> from libatomic.a



I think the most robust solution is for your compiler to implement C11 _Atomic, and for that type to be sufficiently large to hold your value and your spin lock.  I think that most of the libcxx implementation will "just work" at that point, although there are possibly some hidden bugs where something mistakenly assumes that sizeof(T) = = sizeof(_Atomic(T)).



Making the compiler generate _Atomic correctly also gives you a lot of C compatibility.



If C11 compatibility isn't a big concern, and / or getting that feature into the compilers that you need isn't an option, then your approach sounds fine to me.  I don't make the decisions around here though :)



For the binary compatibility concerns... I don't have great answers.  On the one hand, I want to believe that the choice of freestanding or hosted is a platform decision, and that you shouldn't ever mix freestanding object files with hosted object files.  On the other hand, an awful lot of people that aren't doing embedded, drivers, or GPU programming seem interested in freestanding, and I'm afraid that they may very well want to build one chunk of code with a freestanding flag as a style checker / optimizer, and another part of their code with hosted.  I'm not sure if it make sense to try and support that second group.



Another binary compatibility note... my search skills are failing me, but I recall seeing some blog post or documentation that basically states that, when in doubt, you should generate a library call.  You can migrate from a library call to inline code over time, but you can't migrate the other direction without breaking compatibility.  I don't think that affects the specific design questions you had though.

________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190101/fefe3d4d/attachment.html>


More information about the libcxx-dev mailing list