Potentially merging cxx-mem-model with mainline.

[Andrew MacLeod <amacleod at redhat dot com>]

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.

With a few C++ template changes to utilize these new built-ins, 
libstdc++-v3  should have a fully functional implementation of atomics 
for this release.

What it doesn't do
=================

It does not address other missing aspects of the c++ memory model.  In 
particular, bitfields are still not compliant with not introducing new 
potential data races.

There are flags for load and store data races in mainline already, and 
some work has gone into limiting store data races, but testing is by no 
means thorough.


Whats left
===========
Functionality is pretty much complete, but there are a few minor lose 
ends still to deal with. They could be done after a merge, in the next 
stage, or required before... you tell me :-)

- potentially implement -f[no]-inline-atomics  (to never produce inline 
code and always call the library) and -f[no]-atomic-compare-swap-loop  
(To not fall back to a compare_and_swap loop to implement missing 
functionality)

- unaligned objects have undefined behaviour at the moment.  Behaviour 
could be defined and add alignment checks and a parameter to 
__atomic_is_lock_free() for alignment checking purposes.  Anything which 
doesn't map to one of the properly aligned  5 sized built-ins gets a 
library call.

- A bit of C++ template restructuring in the include files to remove the 
old fall back locked implementation and fully use the new __atomic 
builtins. (*in progress now*)

- Change external library calls for __atomic_op_fetch routines. (*patch 
submitted already*)

- There are a bunch of new tests that have been developed along the way, 
but I I expect to spend the next 2 months writing more detailed and 
specific runtime and compile time tests. And of course, fixing any of 
the fall out from those tests.

- There have been no new __atomic RTL patterns created. I was thinking 
about leaving this until the next release, but I suppose we could 
migrate a couple of the more popular targets

The final word
=============
So what is the opinion/consensus on merging the branch?  It would be 
nice to get this infrastructure in place for this release so we can get 
people to start using it, and then we can work out any issues that arise.

I'd have Aldy do the actual merge because if I do something will go amok 
for sure.  I wont be around this weekend to fix any fallout, but I am 
around until Friday evening.  I'm around all next week.  I don't 
anticipate much problem since this is all new functionality for the most 
part, and mainline was merged with the branch a week or two ago.

Andrew