On Fri, 2010-09-17 at 16:12 -0700, Paul E. McKenney wrote: > 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. Well, this verges on insanity... we get to a point where nobody's going to get any code right :-) I don't think the powerpc arch allows that, that leaves us with the compiler, but so far I don't think gcc is -that- crazy. Those constructs are common enough... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
