Re: C++0x Memory model and gcc

[Ian Lance Taylor <iant at google dot com>]

Andrew MacLeod <amacleod@redhat.com> writes:

> I've been working for a while on understanding how the new memory
> model and Atomics work, and what the impacts are on GCC.

Thanks for looking at this.

One issue I didn't see clearly was how to actually implement this in
the compiler.  For example, speculated stores are fine for local stack
variables, but not for global variables or heap memory.  We can
implement that in the compiler via a set of tests at each potential
speculated store.  Or we can implement it via a constraint expressed
directly in the IR--perhaps some indicator that this specific store
may not merge with conditionals.  The latter approach is harder to
design but I suspect will be more likely to be reliable over time.
The former approach is straightforward to patch into the compiler but
can easily degrade as people who don't understand the issues work on
the code.

I don't agree with your proposed command line options.  They seem fine
for internal use, but I think very very few users would know when or
whether they should use -fno-data-race-stores.  I think you should
downgrade those options to a --param value, and think about a
multi-layered -fmemory-model option.  E.g.,
    -fmemory-model=single
        Assume single threaded execution, which also means no signal
        handlers.
    -fmemory-model=fast
        The user is responsible for all synchronization.  Accessing
        the same memory words from different threads may break
        unpredictably.
    -fmemory-model=safe
        The compiler will do its best to protect you.

Ian