[cpp-threads] Review comments on N2176 WRT dependency ordering
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Thu Apr 19 09:13:35 BST 2007
On Thu, Apr 19, 2007 at 01:29:36AM +0300, Peter Dimov wrote:
> Paul E. McKenney wrote:
> >On Wed, Apr 18, 2007 at 02:08:57PM +0300, Peter Dimov wrote:
>
> >>I think that if we have compiler fences at all, we'll have this
> >>problem of optimization validity in their presence anyway.
> >
> >The acquire and release operations that imply actual machine
> >instructions must also impose constraints on code-motion
> >optimization, so this is a more general requirement, right?
>
> Very true. For example the compiler should not transform:
>
> r1 = *p;
> r2 = load_acquire( &q );
> r3 = *r2;
>
> into:
>
> r1 = *p;
> r2 = load_acquire( &q );
> r3 = r2 == p? r1: *r2;
>
> which seems basically the same problem.
Agreed!!! The existence of things like ordered loads and stores
implies the need for the functionality of a compiler barrier, as
well.
> Local dependency propagation would
> still be needed for things such as r1 - r1, though.
Yes. The local dependency propagation would need to happen before
optimizations. Of course, the compiler could choose to perform
the optimization, as long as it inserted a compensating memory fence
or artificial data dependency (or even code dependency on system
supporting this notion).
Thanx, Paul
More information about the cpp-threads
mailing list