[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