From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney via llvm-dev" Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition Date: Mon, 29 Feb 2016 17:28:20 -0800 Message-ID: <20160301012820.GJ3577@linux.vnet.ibm.com> References: <20160218011033.GA1505@linux.vnet.ibm.com> <20160220021516.4898897.32908.5212@gmail.com> <20160220195318.GF3522@linux.vnet.ibm.com> <20160227170615.GU3522@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: llvm-dev-bounces@lists.llvm.org Sender: "llvm-dev" To: Michael Matz Cc: linux-arch@vger.kernel.org, gcc@gcc.gnu.org, Jade Alglave , parallel@lists.isocpp.org, llvm-dev@lists.llvm.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, dhowells@redhat.com, peterz@infradead.org, Ramana.Radhakrishnan@arm.com, Luc Maranget , akpm@linux-foundation.org, torvalds@linux-foundation.org, mingo@kernel.org List-Id: linux-arch.vger.kernel.org T24gTW9uLCBGZWIgMjksIDIwMTYgYXQgMDc6MTc6NTVQTSArMDEwMCwgTWljaGFlbCBNYXR6IHdy b3RlOgo+IEhpLAo+IAo+IE9uIFNhdCwgMjcgRmViIDIwMTYsIFBhdWwgRS4gTWNLZW5uZXkgd3Jv dGU6Cj4gCj4gPiBCdXQgd2UgZG8gYWxyZWFkeSBoYXZlIHNvbWV0aGluZyB2ZXJ5IHNpbWlsYXIg d2l0aCBzaWduZWQgaW50ZWdlcgo+ID4gb3ZlcmZsb3cuICBJZiB0aGUgY29tcGlsZXIgY2FuIHNl ZSBhIHdheSB0byBnZW5lcmF0ZSBmYXN0ZXIgY29kZSB0aGF0Cj4gPiBkb2VzIG5vdCBoYW5kbGUg dGhlIG92ZXJmbG93IGNhc2UsIHRoZW4gdGhlIHNlbWFudGljcyBzdWRkZW5seSBjaGFuZ2UKPiA+ IGZyb20gdHdvcy1jb21wbGVtZW50IGFyaXRobWV0aWMgdG8gc29tZXRoaW5nIHZlcnkgc3RyYW5n ZS4gIFRoZSBzdGFuZGFyZAo+ID4gZG9lcyBub3Qgc3BlY2lmeSBhbGwgdGhlIHdheXMgdGhhdCB0 aGUgaW1wbGVtZW50YXRpb24gbWlnaHQgZGVkdWNlIHRoYXQKPiA+IGZhc3RlciBjb2RlIGNhbiBi ZSBnZW5lcmF0ZWQgYnkgaWdub3JpbmcgdGhlIG92ZXJmbG93IGNhc2UsIGl0IGluc3RlYWQKPiA+ IHNpbXBseSBzYXlzIHRoYXQgc2lnbmVkIGludGVnZXIgb3ZlcmZsb3cgaW52b2tlZCB1bmRlZmlu ZWQgYmVoYXZpb3IuCj4gPiAKPiA+IEFuZCBpZiB0aGF0IGlzIGEgcHJvYmxlbSwgeW91IHVzZSB1 bnNpZ25lZCBpbnRlZ2VycyBpbnN0ZWFkIG9mIHNpZ25lZAo+ID4gaW50ZWdlcnMuCj4gPiAKPiA+ IFNvIGl0IHNlZW1zIHRoYXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZG8gc29tZXRoaW5nIHZlcnkg c2ltaWxhciBoZXJlLgo+IAo+IEZvciB0aGlzIGNhc2UgdGhlIGltcG9ydGFudCBwaWNlIG9mIGlu Zm9ybWF0aW9uIHRvIGNvbnZleSBvbmUgb3IgdGhlIG90aGVyIAo+IG1lYW5pbmcgaW4gc291cmNl IGNvZGUgaXMgdGhlIF90eXBlXyBvZiBpbnZvbHZlZCBlbnRpdGllcywgbm90IGFubm90YXRpb25z IAo+IG9uIHRoZSBvcGVyYXRpb25zLiAgc2lnbmVkIHR5cGUgLT4gdW5kZWZpbmVkIG92ZXJmbG93 LCB1bnNpZ25lZCB0eXBlIC0+IAo+IG1vZHVsbyBhcml0aG1ldGljOyBlYXN5LCBhbmQgaXQgbmlj ZWx5IGNhcnJpZXMgYXV0b21hdGljYWxseSB0aHJvdWdoIAo+IG9wZXJhdGlvbiBjaGFpbnMgKGFu ZCBwb2ludGVycykgd2l0aG91dCBhbnkgYW5ub3RhdGlvbnMuCj4gCj4gSSBmZWVsIG11Y2ggb2Yg dGhlIGNvbXBsZXhpdHkgaW4gdGhlIG1lbW9yeSBvcmRlciBzcGVjaWZpY2F0aW9ucywgYWxzbyAK PiB3aXRoIHlvdXIgcmVjZW50IChtdWNoIGJldHRlcikgd29yZGluZyB0byBleHBsYWluIGRlcGVu ZGVuY3kgY2hhaW5zLCB3b3VsZCAKPiBiZSBtdWNoIGVhc2llciBpZiB0aGUgJ2NhcnJpZXMtZGVw ZW5kZW5jeScgd291bGQgYmUgZW5jb2RlZCBpbnRvIHRoZSB0eXBlcyAKPiBvZiBvcGVyYW5kcy4g IEZvciBwdXJwb3NlIG9mIGV4YW1wbGUsIGxldCdzIGNhbGwgdGhlIG1hcmtlciAiYmxhZWgiIChu b3QgCj4gYXRvbWljIHRvIG5vdCBjb25mdXNlIHdpdGggZXhpc3RpbmcgdXNlIDopICk6Cj4gCj4g aW50IGZvbzsKPiBibGFlaCBpbnQgZ2xvYmFsOwo+IGludCAqc29tZXA7Cj4gYmxhZSBpbnQgKmJs YWVocDsKPiBmICgpIHsKPiAgIGJsYWVocCA9ICZmb287ICAvLyBtaWdodCBiZSBva2F5LCBhZGRz IHJlc3RyaWN0aW9ucyBvbiBhY2Nlc3NlcyB0aHJvdWdoIAo+ICAgICAgICAgICAgICAgICAgIC8v IGJsYWVocCwgYnV0IG5vdCB0aHJvdWdoICdmb28nIGRpcmVjdGx5Cj4gICBibGFlaHAgPSAmZ2xv YmFsOwo+ICAgaWYgKHNvbWVwID09IGJsYWVocCkKPiAgICAgewo+ICAgICAgIC8qIEV2ZW4gdGhv dWdoIHRoZSB2YWx1ZSBpcyBlcXVhbCAuLi4gKi8KPiAgICAgICAuLi4gKmJsYWVocCAuLi4gLyog Li4uIGEgY29tcGlsZXIgY2FuJ3QgcmV3cml0ZSB0aGlzIGludG8gKnNvbWVwICovCj4gICAgIH0K PiB9Cj4gCj4gQSAiY2Fycmllcy1kZXBlbmRlbmN5IiBvbiBzb21lIG9wZXJhdGlvbiAoZS5nLiBh IGNhbGwpIHdvdWxkIGJlIGFkZGVkIGJ5IAo+IHVzaW5nIGEgcHJvcGVybHkgdHlwZWQgcG9pbnRl ciBhdCB0aG9zZSBhcmd1bWVudHMgKG9yIHJldHVybiB0eXBlKSB3aGVyZSAKPiBpdCBtYXR0ZXJz LiAgWW91IGNhbid0IGdpdmUgYSBibGFlaCBwb2ludGVyIHRvIHNvbWV0aGluZyBvbmx5IGFjY2Vw dGluZyAKPiBub24tYmxhZWggcG9pbnRlcnMgKHdpdGhvdXQgY2FzdCkuCj4gCj4gUG9pbnRlciBh ZGRpdGlvbiBhbmQgc2ltaWxhciB0cmFuc2Zvcm1hdGlvbnMgaW52b2x2aW5nIGEgYmxhZWggcG9p bnRlciBhbmQgCj4gc29tZSBpbnRlZ2VyIHdvdWxkIHN0aWxsIGdpdmUgYSBibGFlaCBwb2ludGVy LCBhbmQgaGVuY2UgYnkgZGVmYXVsdCBhbHNvIAo+IHNvbHZlIHRoZSBwcm9ibGVtIG9mIGNhbmNl bGxhdGlvbnMuCj4gCj4gU3VjaCBtYXJraW5nIHZpYSB0eXBlcyB3b3VsZCBub3Qgc29sdmUgYWxs IHByb2JsZW1zIGluIGFuIG9wdGltYWwgd2F5IGlmIAo+IHlvdSBoYWQgdHdvIG92ZXJsYXBwaW5n IGJ1dCBpbmRlcGVuZGVuZCBkZXBlbmRlbmN5IGNoYWlucyAoYWxsIG9mIHRoZW0gCj4gd291bGQg Y29sbGFwc2UgdG8gb25lIGNoYWluIGFuZCBoZW5jZSBtYWRlIGRlcGVuZGVuZCwgd2hpY2ggc3Rp bGwgaXMgCj4gY29uc2VydmF0aXZlbHkgY29ycmVjdCkuCj4gCj4gT1RPSCBpbnRyb2R1Y2luZyBu ZXcgdHlwZSBxdWFsaWZpZXJzIGlzIGEgbXVjaCBsYXJnZXIgdW5kZXJ0YWtpbmcsIHNvIEkgCj4g Y2FuIHVuZGVyc3RhbmQgb25lIHdhbnRzIHRvIGF2b2lkIHRoaXMuICBJIHRoaW5rIGl0J2QgdWx0 aW1hdGVseSBiZSAKPiBjbGVhcmVyLCB0aG91Z2guCgpBcyBoYXMgYmVlbiBzdGF0ZWQgaW4gdGhp cyB0aHJlYWQsIHdlIGRvIG5lZWQgdGhlIHVubWFya2VkIHZhcmlhbnQuCgpGb3IgdGhlIG1hcmtl ZCB2YXJpYW50LCB0aGVyZSBhcmUgcXVpdGUgYSBmZXcgcG9zc2libGUgc29sdXRpb25zIHdpdGgK dmFyeWluZyBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzOgoKbwlBdHRyaWJ1dGUgYWxyZWFk eSBleGlzdHMsIGJ1dCBpcyBub3QgY2FycmllZCBieSB0aGUgdHlwZSBzeXN0ZW0uCglDb3VsZCBi ZSBlbmZvcmNlZCBieSBleHRlcm5hbCB0b29scy4KCm8JU3RvcmFnZSBjbGFzcyBjb3VsZCBiZSBh ZGRlZCB3aXRoIGZld2VyIGVmZmVjdHMgb24gdGhlIHR5cGUKCXN5c3RlbSwgYnV0IHRoZSByZWFj dGlvbiB0byB0aGlzIHN1Z2dlc3Rpb24gaW4gT2N0b2JlciB3YXMKCW5vdCBhbGwgdGhhdCBwb3Np dGl2ZS4KCm8JTm9uLXR5cGUga2V5d29yZHMgZm9yIG9iamVjdHMgaGFzIGJlZW4gc3VnZ2VzdGVk LCBtaWdodCBiZSB3b3J0aAoJcmV2aXNpdGluZy4KCm8JQWRkaW5nIHRvIHRoZSB0eXBlIHN5c3Rl bSBhbGxvd3MgdHlwZSBlbmZvcmNlbWVudCBvbiB0aGUgb25lCgloYW5kLCBidXQgbWFrZXMgaXQg aGFyZGVyIHRvIHdyaXRlIGNvZGUgdGhhdCBjYW4gYmUgdXNlZCBmb3IKCWJvdGggUkNVLXByb3Rl Y3RlZCBhbmQgbm90LVJDVS1wcm90ZWN0ZWQgZGF0YSBzdHJ1Y3R1cmVzLgoJKFRoaXMgc29ydCBv ZiB0aGluZyBpcyBub3QgdW5jb21tb24gaW4gdGhlIExpbnV4IGtlcm5lbC4pCgpUaGVyZSBhcmUg cHJvYmFibHkgb3RoZXJzLCBidXQgdGhvc2UgYXJlIHRoZSBvbmVzIEkgcmVjYWxsIGF0IHRoZQpt b21lbnQuCgoJCQkJCQkJVGhhbngsIFBhdWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCkxMVk0gRGV2ZWxvcGVycyBtYWlsaW5nIGxpc3QKbGx2bS1kZXZA bGlzdHMubGx2bS5vcmcKaHR0cDovL2xpc3RzLmxsdm0ub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0 aW5mby9sbHZtLWRldgo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e19.ny.us.ibm.com ([129.33.205.209]:39304 "EHLO e19.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750699AbcCAB22 (ORCPT ); Mon, 29 Feb 2016 20:28:28 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Feb 2016 20:28:26 -0500 Date: Mon, 29 Feb 2016 17:28:20 -0800 From: "Paul E. McKenney" Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition Message-ID: <20160301012820.GJ3577@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160218011033.GA1505@linux.vnet.ibm.com> <20160220021516.4898897.32908.5212@gmail.com> <20160220195318.GF3522@linux.vnet.ibm.com> <20160227170615.GU3522@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Michael Matz Cc: parallel@lists.isocpp.org, linux-arch@vger.kernel.org, gcc@gcc.gnu.org, p796231 , llvm-dev@lists.llvm.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, dhowells@redhat.com, peterz@infradead.org, Ramana.Radhakrishnan@arm.com, Luc Maranget , akpm@linux-foundation.org, Jade Alglave , torvalds@linux-foundation.org, mingo@kernel.org Message-ID: <20160301012820.fZNgApeK7t_MHnOt-jdIyJMukUq81kXO7493GrvhH3w@z> On Mon, Feb 29, 2016 at 07:17:55PM +0100, Michael Matz wrote: > Hi, > > On Sat, 27 Feb 2016, Paul E. McKenney wrote: > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > > does not handle the overflow case, then the semantics suddenly change > > from twos-complement arithmetic to something very strange. The standard > > does not specify all the ways that the implementation might deduce that > > faster code can be generated by ignoring the overflow case, it instead > > simply says that signed integer overflow invoked undefined behavior. > > > > And if that is a problem, you use unsigned integers instead of signed > > integers. > > > > So it seems that we should be able to do something very similar here. > > For this case the important pice of information to convey one or the other > meaning in source code is the _type_ of involved entities, not annotations > on the operations. signed type -> undefined overflow, unsigned type -> > modulo arithmetic; easy, and it nicely carries automatically through > operation chains (and pointers) without any annotations. > > I feel much of the complexity in the memory order specifications, also > with your recent (much better) wording to explain dependency chains, would > be much easier if the 'carries-dependency' would be encoded into the types > of operands. For purpose of example, let's call the marker "blaeh" (not > atomic to not confuse with existing use :) ): > > int foo; > blaeh int global; > int *somep; > blae int *blaehp; > f () { > blaehp = &foo; // might be okay, adds restrictions on accesses through > // blaehp, but not through 'foo' directly > blaehp = &global; > if (somep == blaehp) > { > /* Even though the value is equal ... */ > ... *blaehp ... /* ... a compiler can't rewrite this into *somep */ > } > } > > A "carries-dependency" on some operation (e.g. a call) would be added by > using a properly typed pointer at those arguments (or return type) where > it matters. You can't give a blaeh pointer to something only accepting > non-blaeh pointers (without cast). > > Pointer addition and similar transformations involving a blaeh pointer and > some integer would still give a blaeh pointer, and hence by default also > solve the problem of cancellations. > > Such marking via types would not solve all problems in an optimal way if > you had two overlapping but independend dependency chains (all of them > would collapse to one chain and hence made dependend, which still is > conservatively correct). > > OTOH introducing new type qualifiers is a much larger undertaking, so I > can understand one wants to avoid this. I think it'd ultimately be > clearer, though. As has been stated in this thread, we do need the unmarked variant. For the marked variant, there are quite a few possible solutions with varying advantages and disadvantages: o Attribute already exists, but is not carried by the type system. Could be enforced by external tools. o Storage class could be added with fewer effects on the type system, but the reaction to this suggestion in October was not all that positive. o Non-type keywords for objects has been suggested, might be worth revisiting. o Adding to the type system allows type enforcement on the one hand, but makes it harder to write code that can be used for both RCU-protected and not-RCU-protected data structures. (This sort of thing is not uncommon in the Linux kernel.) There are probably others, but those are the ones I recall at the moment. Thanx, Paul