C++0x Memory model and gcc

[Andrew MacLeod]

Ian Lance Taylor wrote:
> 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.
>   

which is why the ability to regression test it is so important :-).  

Right now its my intention to modify the optimizations based on the flag 
settings. Some cases will be quite tricky.  If we're CSE'ing something 
in the absence of atomics, and it is shared memory, it is still possible 
to move it if there is already a load from that location on all paths.  
So the optimization itself will need to taught how to figure that out.

ie

if ()
  a_1 = glob
else
  if ()
      b_2 = glob
   else
      c_3 = glob

we can still common glob and produce

tmp_4 = glob
if ()
  a_1 = tmp_4
else
  if ()
    b_2 = tmp_4
  else
    c_3 = tmp4

all paths loaded glob before, so we can do this safely.

but if we had:

if ()
  a_1 = glob
else
  if ()
     b_2 = notglob
  else
     c_3 = glob

then we can no longer do anything since we'd be introducing a new load 
of 'glob' on the path that sets b_2 which wasn't performed before. If 
there was another load of glob somewhere before the first 'if', then 
commoning becomes possible again.

Some other cases won't be nearly so tricky, thankfully :-). I do think 
we need to do it in the optimizations because of some of the complex 
situations which can arise. We can at least try to do a good job and 
then punt if it gets too hard.

Now, thankfully, on most architectures we care about, hardware detection 
of data race loads isn't an issue.  So most of the time  its only the 
stores that we need to be careful about introducing new ones.  Im hoping 
the actual impact to codegen is low most of the time



> 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
>   

I'm fine with alternatives. I'm focused mostly on the internals and I 
want an individual flag for each of those things to cleanly separate 
them out.  How we expose it I'm ambivalent about as long as testing can 
turn it them on and off individually. 

There will be people using software data race detectors which may want 
to be able to turn things on or off from the system default. I think 
-fmemory-model=   with options enabling at a minimum some form of 'off', 
'system default', and 'on' would probably work for external exposure.

Andrew