http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
torvald at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.8.0
--- Comment #2 from torvald at gcc dot gnu.org 2012-01-06 14:03:00 UTC ---
(In reply to comment #1)
> Ok, I'm a complete neophyte on this, but that seems very restrictive. Does
> that mean that basically we can't hoist any loads inside a transaction...ever?
>
> __transaction_atomic
> {
> for (i = 0; i < 10; i++)
> if (x[i])
> x[i] += data;
> }
We can hoist them if they are guaranteed to happen anyway. However, if whether
the abstract machine would execute them is data-dependent on another load, the
other load must come first. We can also hoist them if they are never published
by anyone else, or never written to nontransactionally by other threads
(constant data, thread-local data, etc.).
In the example, "data" might never be accessed. But if it would be accessed
after the loop anyway, for example, then we can hoist it to before the loop.
This is possible because we can assume that the program is data-race-free in
the first place, and if a load is going to happen anyway, we can assume that
the transaction could also run before the other thread's writes to x[i], the
other thread isn't publishing "data", and so there must be no race condition
(and thus, no difference) even if we hoist the load.
Note that if we would synchronize with atomics instead of transactions, the
programmer would need to specify at least acquire memory order for the load of
x[i] to prevent a data race.
