[cxx-mem-model] disallow load data races (1 of some)

[Andrew MacLeod]

> On Thu, 24 Mar 2011, Aldy Hernandez wrote:
>
>> This work is independent of the C++ memory model.  It is just to prevent the
>> optimizers from introducing new data races due to code movement. This initial
>> pass is just to make the optimizations data race safe so that if you have a
>> program which is proven to be free of data races, you can run the optimizers
>> and it will still be data race free after the optimizers have been run.
>>
>> See the following summary by Andrew (which in turn is based on a paper by Hans
>> Boehm):
>>
>> http://gcc.gnu.org/wiki/Atomic/GCCMM/DataRaces
> But hoisting global in this case doesn't result in a data race, since the
> loop always accesses global and contains no synchronisation code.  If it
> were only accessed conditionally, as in the examples under "Avoiding
> Speculation" on that page, then there would be a race in hoisting it, but
> not for the code you gave; any data races with the hoisting would still
> have been present without it.
>
My fault for not being specific about it... I tend to just use data race 
as a catch all for all these types of things when talking about them 
with Aldy.

the testcase should have      for (x=0; x< limit; x++)  sum[x] = global; 
     rather than x<5,  so that its not a known loop count.

The hoisted load is then not allowed as it become a speculative load of 
'global' on the main path which would not otherwise have been there. 
When the value of limit < 0, this can cause a load race detection on 
systems with either a software or hardware data race detector.

It can be allowed as long as the load happens inside a guard for the 
loop, but I dont think we are that sophisticated yet.

Bottom line is these flags are to prevent the introduction of loads of 
globals on code paths which didn't have had them before.

Andrew