On Thu, May 6, 2010 at 5:50 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod <amacl...@redhat.com> wrote: >> I've been working for a while on understanding how the new memory model and >> Atomics work, and what the impacts are on GCC. >> >> It would be ideal to get as many of these changes into GCC 4.6 as possible. >> I've started work on some of the modifications and testing, and the overall >> impact on GCC shouldn't be *too* bad :-) >> >> The plan is to localize the changes as much as possible, and any intrusive >> bits like optimization changes will be controlled by a flag enabling us to >> keep the current behaviour when we want it. >> >> I've put together a document summarizing how the memory model works, and how >> I propose to make the changes. I've converted it to wiki pages. Maybe no >> one will laugh at my choice of document format this time :-) >> >> The document is linked off the Atomics wiki page, or directly here: >> http://gcc.gnu.org/wiki/Atomic/GCCMM >> >> It consists mainly of describing the 2 primary aspects of the memory model >> which affects us >> - Optimization changes to avoid introducing new data races >> - Implementation of atomic variables and synchronization modes >> as well as a new infrastructure to test these types of things. >> >> I'm sure I've screwed something up while doing it, and I will proofread it >> later today again and tweak it further. >> >> Please point out anything that isn't clear, or is downright wrong. >> Especially in the testing methodology since its all new stuff. >> Suggestions for improvements on any of the plan are welcome as well. > > First let me say that the C++ memory model is crap when it > forces data-races to be avoided for unannotated data like > the examples for packed data. > > Well, I hope that instead of just disabling optimizations you > will help to improve their implementation to be able to optimize > in a conformant manner.
And btw, if you are thinking on how to represent the extra data-dependencies required for the consistency models think of how to extend whatever you need in infrastructure for that to also allow FENV dependencies - it's a quite similar problem (FENV query/set are the atomic operations, usual arithmetic is what the dependency is to). It's completely non-trivial (because it's scalar code, not memory accesses). For atomics you should be able to just massage the alias-oracle data-dependence routines (maybe). Richard.