Re: Potentially merging cxx-mem-model with mainline.

[David Gilbert <david dot gilbert at linaro dot org>]

On 26 October 2011 16:38, Andrew MacLeod <amacleod@redhat.com> wrote:
> I'd like to have the cxx-mem-model branch considered for merging with
> mainline before we end stage 1 for GCC 4.7.
>
> What it is
> ==========
>
> GCC has had the __sync built-ins for atomic operations for a number of years
> now. ?They implement a "sequential consistent" (AKA seq-cst) synchronization
> model which is the most restrictive (ie expensive) form of synchronization.
> ?It requires that all processes can see a consistent value for other shared
> memory variables at the point of the atomic operation. ?The new C++ standard
> defines other less restrictive modes which many newer architecture can make
> use of for improved performance in multi-threaded environments. ?These will
> also allow the optimizer more freedom in moving code around as well.
>
> This branch has developed a new set of atomic built-ins which include a
> memory model parameter and meet the atomic requirements of C++11.
>
> During development, I've kept a wiki page pretty updates about what its all
> about, rooted here: http://gcc.gnu.org/wiki/Atomic/GCCMM
>
> What it involves
> ===============
>
> The new __atomic prefixed built-ins have been implemented with ease of
> target migration and maintenance in mind:
>
> ?- The __atomic expanders first look for a new __atomic RTL pattern and use
> that if present.
> ?- failing that, they fall back to using the original __sync implementation
> and patterns. This is less efficient if the memory model specified isn't
> seq-cst, but is correct in functionality. ?This also means all the __atomic
> built-ins work correctly today if a target has __sync support.
>
> The original __sync builtins now invoke the __atomic expanders with the
> seq-cst memory model. ?This means that if a target has not been migrated to
> the new __atomic patterns, the __sync functions behave exactly as they do
> today (since __atomic expanders fall back to the original __sync patterns).
> ? When a target does specify new __atomic RTL patterns, the legacy __sync
> routines will automatically start using those patterns.
>
> This means that a target does not need to support both __atomic and __sync
> patterns. ?Migrating involves simply renaming the __sync patterns and
> modifying them to deal with the memory model parameter.
>
> There are new generic __atomic routines which provide support for arbitrary
> sized objects. ?Whenever possible, atomic operations are mapped to lock-free
> instruction sequences. This is not always possible either due to target
> restrictions, or oddly/large sized objects.
>
> The __atomic builtins leave external function calls for these cases, but
> they target a well defined library interface documented here:
> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary ? I expect to spin off a small
> side project to implement this library in the next few months so that a
> library is easily available to resolve these calls.

So what happens on a target that implements the __sync calls via
routines in libgcc
(e.g. older ARM) ?  Will the __atomic's get turned into the __sync calls?

Dave