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

[Louis Dionne via libcxx-dev]

> On Dec 30, 2018, at 21:17, Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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:
> The libcxx implementation of atomic<T> is layered on __c11_atomic_* builtins, in all cases.
> 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.
> 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:
> 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.)
> 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.
> 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 <http://wg21.link/p0152>.
> 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.

I just saw this, hence the late reply. At a high level, I'm fine with the proposed approach but I'd like to discuss it over a review to get things more concrete. Note that I'll only be back on Jan 21 though so don't expect a lot of feedback from me until then.

Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190109/7ee164fb/attachment-0001.html>