[PATCH] libstdc++: Improve code generation for atomic reference counting

[Jonathan Wakely]

I missed this patch until today and have only just seen it, sorry.

On 09/11/16 23:26 +0200, Pauli wrote:
>Atomic reference counting generates pessimistic code in platforms where
>builtin atomics could optimize code for following branch with subtract
>instruction.

Which targets are affected?

>To allow better code generation with compile time constant addition can
>be checked for negative value. Those cases can then be better optimized
>with __atomic_fetch_sub builtin.

OK, that makes sense.

>Extra branch checking presence of threads in application generates a
>lot extra instructions when builtin atomics often generate very few
>instructions.

I'd like to see more justification for this. My understanding was that
the __gthread_active_p() check was cheap in many cases, and that
things like std::string reference counting in single-threaded
applications benefit from avoiding the atomics.

I don't feel comfortable making this change without data.

>Can I assume that __builtin_constant_p is available in all compilers
>with _GLIBCXX_ATOMIC_BUILTINS is available?

Yes, that's fine. It's always available.

>--- a/libstdc++-v3/include/ext/atomicity.h
>+++ b/libstdc++-v3/include/ext/atomicity.h
>@@ -35,6 +35,14 @@
> #include <bits/gthr.h>
> #include <bits/atomic_word.h>
>
>+#if defined(__GCC_ATOMIC_INT_LOCK_FREE)

Isn't this always defined?

>+#define _GLIBCXX_INT_LOCK_FREE __GCC_ATOMIC_INT_LOCK_FREE
>+#else
>+#define _GLIBCXX_INT_LOCK_FREE 2

Why assume always lock-free if the macro isn't defined?

>+#endif
>+#define _GLIBCXX_ATOMIC_INLINE \
>+  (_GLIBCXX_ATOMIC_BUILTINS && _GLIBCXX_INT_LOCK_FREE == 2)
>+
> namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
> {
> _GLIBCXX_BEGIN_NAMESPACE_VERSION