On Wed, Feb 26, 2014 at 02:04:30PM +0100, Torvald Riegel wrote: > xagsmtp2.20140226130517.3625@xxxxxxxxxxxxxxxxxxxx > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) > > On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote: > > On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Matz wrote: > > > Hi, > > > > > > On Thu, 20 Feb 2014, Linus Torvalds wrote: > > > > > > > But I'm pretty sure that any compiler guy must *hate* that current odd > > > > dependency-generation part, and if I was a gcc person, seeing that > > > > bugzilla entry Torvald pointed at, I would personally want to > > > > dismember somebody with a rusty spoon.. > > > > > > Yes. Defining dependency chains in the way the standard currently seems > > > to do must come from people not writing compilers. There's simply no > > > sensible way to implement it without being really conservative, because > > > the depchains can contain arbitrary constructs including stores, > > > loads and function calls but must still be observed. > > > > > > And with conservative I mean "everything is a source of a dependency, and > > > hence can't be removed, reordered or otherwise fiddled with", and that > > > includes code sequences where no atomic objects are anywhere in sight [1]. > > > In the light of that the only realistic way (meaning to not have to > > > disable optimization everywhere) to implement consume as currently > > > specified is to map it to acquire. At which point it becomes pointless. > > > > No, only memory_order_consume loads and [[carries_dependency]] > > function arguments are sources of dependency chains. > > However, that is, given how the standard specifies things, just one of > the possible ways for how an implementation can handle this. Treating > [[carries_dependency]] as a "necessary" annotation to make exploiting > mo_consume work in practice is possible, but it's not required by the > standard. > > Also, dependencies are specified to flow through loads and stores > (restricted to scalar objects and bitfields), so any load that might > load from a dependency-carrying store can also be a source (and that > doesn't seem to be restricted by [[carries_dependency]]). OK, this last is clearly totally unacceptable. :-/ Leaving aside the option of dropping the whole thing for the moment, the only thing that suggests itself is having all dependencies die at a specific point in the code, corresponding to the rcu_read_unlock(). But as far as I can see, that absolutely requires "necessary" parameter and return marking in order to correctly handle nested RCU read-side critical sections in different functions. Thanx, Paul -- 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
