On 26 October 2011 16:38, Andrew MacLeod <amacl...@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
