On Fri, Mar 25, 2011 at 12:57 AM, Andrew MacLeod <amacl...@redhat.com> wrote: >> 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.
But speculative loads are never a problem. So I'd like to avoid cluttering GCC code with stuff to avoid them. I honestly don't care about diagnostic tools that fail to see if a value read is used or not. Richard. > 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 > > >
