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

[Olivier Giroux via libcxx-dev]

In my last mail, and in some F2F discussions, I volunteered to write a first patch to use a Freestanding configuration. My motivation is to decouple non-lock-free atomic<T> from platform libraries, from libatomic.a, for Freestanding implementations.

I’ve gone ahead and prototyped this a few different ways. Here is the approach I would like to submit a patch for.

= Background =

To the best of my ability to tell:

  1.  The libcxx implementation of atomic<T> is layered on __c11_atomic_* builtins, in all cases.
  2.  If they’re missing, but __atomic_* builtins are there, then a fake __c11_atomic_* API is layered onto __atomic_*.
     *   If neither are there, the configuration is unsupported.
  3.  If something is needed that’s not in C11, then it uses __atomic_* for that, even when it uses __c11_atomic_* for the rest.
     *   e.g. __atomic_always_lock_free, in C++17 mode.

This is working fine, but it makes it hard to customize behaviors like “send non-lock-free atomics to another backend” because in the case when __c11_atomic_* builtins are there, they are used directly without any adaptation. This makes it so you can only customize in the atomic<T> object specializations, which are set in your ABI and .

= Proposed Changes =

This approach is the best of three I tried on trunk libcxx:

  1.  Create a single __cxx_atomic_* layer which is an adaptation of either __c11_atomic_*, preferentially, or else __atomic_*. (For __atomic_*, it’s a rename of the layer that’s there now. For __c11_atomic_*, it’s a new but boring wrapper that just forwards calls.)
  2.  Create a __cxx_atomic_type<> template that is an alias to what should wrap the _Tp inside of an atomic<T> / atomic_flag. Defaults to the same _Atomic(_Tp) as today, either from C11 or from the adaptation layer.
  3.  Under #ifdef LIBCXX_FREESTANDING, introduce __cxx_locked_atomic_type<> with an implementation of __cxx_atomic_*, and redirect __cxx_atomic_type<> based on always-lock-freedom.
     *   In C++17 mode, it uses __atomic_is_always_lock_free.
     *   Otherwise, it uses the C lock-free macros as shown in wg21.link/p0152.
  4.  Add a test that instantiates every specialization flavor of atomic<T>, as well as at least one “large” type that ought not be lock-free. It’s kind of weird that this isn’t in the test suite.

= Disclaimer =

I don’t have a strong grasp of what’s an ABI break here, my proposal reflects my limited mental model.

Some of the code parsed in Hosted builds does change, but none of the atomic<T> object sizes/alignments and member function signatures change in that configuration. In the Freestanding configuration, the non-lock-free atomic<T> change in size. My limited sense says this is OK – first that Hosted is going to be OK, and that it’s OK for Freestanding to differ here.

= Next Steps =

I’ll take all your feedback and questions, or I can make a patch and discuss it over code. But I think you mean to poke at motivation/design first.

I know it’s New Year’s Eve-ish and you’re all away, I’ll be patient.

Oh, and Happy New Year!

Olivier


-----------------------------------------------------------------------------------
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/20181231/d1837da7/attachment-0001.html>