This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++0x Memory model and gcc


On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod <amacleod@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]