Richard Guenther wrote:
On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod <amacl...@redhat.com> wrote:
Richard Guenther wrote:
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.
They are independent as far as dependencies within this compilation unit.
The problem is if thread number 2 is performing
a.j = val
b.i = val2
now there are data races on both A and B if we load/store full words and
the struct was something like:
struct {
char i;
char j;
} a, b;
The store to B is particularly unpleasant since you may lose one of the
2 stores. The load data race on A is only in the territory of hardware
or software race detectors.
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?
If the other thread is doing something like:
if (!p)
load = something
then there was no data race before since your thread wasn't performing a
load when this thread was storing. ie, 'p' was being used as the
synchronization guard that prevented a data race. When you do the
transformation, there is now a potential race that wasn't there before.
Some hardware can detect that and trigger an exception, or a software
data race detector could trigger, and neither would have before, which
means the behaviour is detectably different.
Thats also why I've separated the loads and stores for handling
separately. under normal circumstances, we want to allow this
transformation. If there aren't any detection abilities in play, then
the transformation is fine... you can't tell that there was a race.
With stores you can actually get different results, so we do need to
monitor those.
Andrew
