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

[Olivier Giroux via libcxx-dev]

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/2e67146c/attachment-0001.html>