C++0x Memory model and gcc

Richard Guenther richard.guenther@gmail.com
Fri May 7 09:15:00 GMT 2010


On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> Richard Guenther wrote:
>>
>> On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>
>>>
>>> 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.
>>>
>
> And it isn't consistent across the board, since neighbouring bits normally
> don't qualify and can introduce data races. I don't like it when a solution
> has exceptions like that. It is what it is however, and last I heard the
> plan was for C to adopt the changes as well.

I would have hoped that only data races between independent
objects are covered, thus

 tmp = a.i;
 b.j = tmp;

would qualify as a load of a and a store to b as far as dependencies
are concerned.  That would have been consistent with the
exceptions for bitfields and much more friendly to architectures
with weak support for unaligned accesses.

>>>
>>> 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.
>>>
>
> I don't want to disable any more than required. SSA names aren't affected
> since they are local variables only,  its only operations on shared memory,
> and I am hopeful that I can minimize the restrictions placed on them.  Some
> will be more interesting than others... like CSE... you can still perform
> CSE on a global as long as you don't introduce a NEW load on some execution
> path that didn't have before. What fun.

I don't understand that restriction anyway - how can an extra
load cause a data-race if the result is only used when it was
used before?  (You'd need to disable PPRE and GCSE completely
if that's really a problem)

Thus,

if (p)
  tmp = load;
...
if (q)
  use tmp;

how can transforming that to

tmp = load;
...
if (q)
  use tmp;

ever cause a problem?

>> 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).
>>
>
> That's what I'm hoping actually..

We'll see.

Richard.

> Andrew.
>



More information about the Gcc mailing list