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
