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.
Arghh... I took Andrew's testcase unmodified, and assumed it did not
conform to the model. Sorry for the confusion.
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.
And in this variant, we no longer have a data race. The load from
global is guarded by the limit check.
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.
Frankly, I agree. The standard (and the aforementioned paper) says that
load data races are disallowed...
"If we had hypothetical hardware (or a virtual machine) that aborted the
program when a race was detected, compilers would not be allowed to
introduce potentially racing loads... even if the result of the load
were unused would change the semantics of the program. Although such
environments are not commonplace, they have certainly been proposed, and
may well turn out to be very useful."
...but, if there's no hardware for it, I see no need for spending time
on this. Do y'all agree, so I can drop this witch hunt?
In which case, unfortunately, all the tests I had from Andrew (that
actually trigger) are load data races. So I'll have to hunt for invalid
speculative stores instead.
Back to the drawing board.
Thanks folks.
