Potentially merging cxx-mem-model with mainline.

David Gilbert david.gilbert@linaro.org
Wed Oct 26 18:59:00 GMT 2011

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?


More information about the Gcc mailing list