This is the mail archive of the
mailing list for the GCC project.
Potentially merging cxx-mem-model with mainline.
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: GCC <gcc at gcc dot gnu dot org>
- Date: Wed, 26 Oct 2011 11:38:23 -0400
- Subject: Potentially merging cxx-mem-model with mainline.
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
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
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
- 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
- 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
- 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.