On Fri, May 27, 2016 at 03:34:13PM -0400, Chris Metcalf wrote: > >Does TILE never speculate reads? Because in that case the control > >dependency already provides a full load->load,store barrier and you'd > >want smp_acquire__after_ctrl_dep() to be a barrier() instead of > >smp_rmb(). > > Yes, that's a good point. I didn't look at the definition of smp_acquire__after_ctrl_dep(), > but it certainly sounds like that's exactly a compiler barrier for tile. There is no load > speculation performed. The only out-of-order stuff that happens is in the memory > subsystem: stores will become visible in arbitrary order, and loads will arrive in > arbitrary order, but as soon as the result of a load is used in any other kind of > instruction, the instruction issue will halt until the pending load(s) for the instruction > operands are available. OK; for now I'll just put in barrier() and a big comment, I'll look at making smp_acquire__after_ctrl_dep() a proper (per arch) barrier later. There's a little header head-ache involved. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
