Messages in this thread | | | Date | Fri, 17 Sep 2010 16:12:22 -0700 | From | "Paul E. McKenney" <> | Subject | Re: memory barrier question |
| |
On Sat, Sep 18, 2010 at 07:49:08AM +1000, Benjamin Herrenschmidt wrote: > > > Right but in the concrete namei example I can't see how a compiler > > optimization can make a difference. The order of the loads is quite > > clear: > > > > LOAD inode = next.dentry->inode > > if (inode != NULL) > > LOAD inode->f_op > > > > What is there the compiler can optimize? > > Those two loads depend on each other, I don't think any implementation > can re-order them. In fact, such data dependency is typically what is > used to avoid having barriers in some cases. The second load cannot be > issued until the value from the first one is returned.
Sufficiently sadistic compiler and CPU implementations could do value speculation, for example, driven by profile-feedback optimization. Then the guess might initially incorrect, but then a store by some other CPU could make the subsequent test decide (wrongly) that the guess had in fact been correct.
Needless to say, I am not a fan of value speculation. But other people do like it a lot.
Thanx, Paul
| |