From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency Date: Sun, 6 Jan 2019 23:23:07 -0500 Message-ID: <20190106231756-mutt-send-email-mst@kernel.org> References: <20190102205715.14054-1-mst@redhat.com> <20190102205715.14054-4-mst@redhat.com> <86023cbe-d1ae-a0d6-7b75-26556f1a0c1f@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <86023cbe-d1ae-a0d6-7b75-26556f1a0c1f@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Jason Wang Cc: Andrea Parri , linux-doc@vger.kernel.org, Peter Zijlstra , Akira Yokosawa , Will Deacon , virtualization@lists.linux-foundation.org, David Howells , linux-arch@vger.kernel.org, Jonathan Corbet , linux-sparse@vger.kernel.org, Alan Stern , Matt Turner , "Paul E. McKenney" , Daniel Lustig , Arnd Bergmann , Boqun Feng , Nicholas Piggin , Ivan Kokshaysky , Luc Maranget , Richard Henderson , Jade Alglave , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.orgLuc Van Oostenryck List-Id: linux-arch.vger.kernel.org T24gTW9uLCBKYW4gMDcsIDIwMTkgYXQgMTE6NTg6MjNBTSArMDgwMCwgSmFzb24gV2FuZyB3cm90 ZToKPiAKPiBPbiAyMDE5LzEvMyDkuIrljYg0OjU3LCBNaWNoYWVsIFMuIFRzaXJraW4gd3JvdGU6 Cj4gPiBJdCdzIG5vdCB1bmNvbW1vbiB0byBoYXZlIHR3byBhY2Nlc3MgdHdvIHVucmVsYXRlZCBt ZW1vcnkgbG9jYXRpb25zIGluIGEKPiA+IHNwZWNpZmljIG9yZGVyLiAgQXQgdGhlIG1vbWVudCBv bmUgaGFzIHRvIHVzZSBhIG1lbW9yeSBiYXJyaWVyIGZvciB0aGlzLgo+ID4gCj4gPiBIb3dldmVy LCBpZiB0aGUgZmlyc3QgYWNjZXNzIHdhcyBhIHJlYWQgYW5kIHRoZSBzZWNvbmQgdXNlZCBhbiBh ZGRyZXNzCj4gPiBkZXBlbmRpbmcgb24gdGhlIGZpcnN0IG9uZSB3ZSB3b3VsZCBoYXZlIGEgZGF0 YSBkZXBlbmRlbmN5IGFuZCBubwo+ID4gYmFycmllciB3b3VsZCBiZSBuZWNlc3NhcnkuCj4gPiAK PiA+IFRoaXMgYWRkcyBhIG5ldyBpbnRlcmZhY2U6IGRlcGVuZGVudF9wdHJfbWIgd2hpY2ggZG9l cyBleGFjdGx5IHRoaXM6IGl0Cj4gPiByZXR1cm5zIGEgcG9pbnRlciB3aXRoIGEgZGF0YSBkZXBl bmRlbmN5IG9uIHRoZSBzdXBwbGllZCB2YWx1ZS4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogTWlj aGFlbCBTLiBUc2lya2luIDxtc3RAcmVkaGF0LmNvbT4KPiA+IC0tLQo+ID4gICBEb2N1bWVudGF0 aW9uL21lbW9yeS1iYXJyaWVycy50eHQgfCAyMCArKysrKysrKysrKysrKysrKysrKwo+ID4gICBh cmNoL2FscGhhL2luY2x1ZGUvYXNtL2JhcnJpZXIuaCAgfCAgMSArCj4gPiAgIGluY2x1ZGUvYXNt LWdlbmVyaWMvYmFycmllci5oICAgICB8IDE4ICsrKysrKysrKysrKysrKysrKwo+ID4gICBpbmNs dWRlL2xpbnV4L2NvbXBpbGVyLmggICAgICAgICAgfCAgNCArKysrCj4gPiAgIDQgZmlsZXMgY2hh bmdlZCwgNDMgaW5zZXJ0aW9ucygrKQo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvRG9jdW1lbnRhdGlv bi9tZW1vcnktYmFycmllcnMudHh0IGIvRG9jdW1lbnRhdGlvbi9tZW1vcnktYmFycmllcnMudHh0 Cj4gPiBpbmRleCBjMWQ5MTM5NDRhZDguLjlkYmFhMmUxZGJmNiAxMDA2NDQKPiA+IC0tLSBhL0Rv Y3VtZW50YXRpb24vbWVtb3J5LWJhcnJpZXJzLnR4dAo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9t ZW1vcnktYmFycmllcnMudHh0Cj4gPiBAQCAtNjkxLDYgKzY5MSwxOCBAQCBjYXNlIHdoYXQncyBh Y3R1YWxseSByZXF1aXJlZCBpczoKPiA+ICAgCQlwID0gUkVBRF9PTkNFKGIpOwo+ID4gICAJfQo+ ID4gK0FsdGVybmF0aXZlbHksIGEgY29udHJvbCBkZXBlbmRlbmN5IGNhbiBiZSBjb252ZXJ0ZWQg dG8gYSBkYXRhIGRlcGVuZGVuY3ksCj4gPiArZS5nLjoKPiA+ICsKPiA+ICsJcSA9IFJFQURfT05D RShhKTsKPiA+ICsJaWYgKHEpIHsKPiA+ICsJCWIgPSBkZXBlbmRlbnRfcHRyX21iKGIsIHEpOwo+ ID4gKwkJcCA9IFJFQURfT05DRShiKTsKPiA+ICsJfQo+ID4gKwo+ID4gK05vdGUgaG93IHRoZSBy ZXN1bHQgb2YgZGVwZW5kZW50X3B0cl9tYiBtdXN0IGJlIHVzZWQgd2l0aCB0aGUgZm9sbG93aW5n Cj4gPiArYWNjZXNzZXMgaW4gb3JkZXIgdG8gaGF2ZSBhbiBlZmZlY3QuCj4gPiArCj4gPiAgIEhv d2V2ZXIsIHN0b3JlcyBhcmUgbm90IHNwZWN1bGF0ZWQuICBUaGlzIG1lYW5zIHRoYXQgb3JkZXJp bmcgLWlzLSBwcm92aWRlZAo+ID4gICBmb3IgbG9hZC1zdG9yZSBjb250cm9sIGRlcGVuZGVuY2ll cywgYXMgaW4gdGhlIGZvbGxvd2luZyBleGFtcGxlOgo+ID4gQEAgLTgzNiw2ICs4NDgsMTIgQEAg b3V0LWd1ZXNzIHlvdXIgY29kZS4gIE1vcmUgZ2VuZXJhbGx5LCBhbHRob3VnaCBSRUFEX09OQ0Uo KSBkb2VzIGZvcmNlCj4gPiAgIHRoZSBjb21waWxlciB0byBhY3R1YWxseSBlbWl0IGNvZGUgZm9y IGEgZ2l2ZW4gbG9hZCwgaXQgZG9lcyBub3QgZm9yY2UKPiA+ICAgdGhlIGNvbXBpbGVyIHRvIHVz ZSB0aGUgcmVzdWx0cy4KPiA+ICtDb252ZXJ0aW5nIHRvIGEgZGF0YSBkZXBlbmRlbmN5IGhlbHBz IHdpdGggdGhpcyB0b286Cj4gPiArCj4gPiArCXEgPSBSRUFEX09OQ0UoYSk7Cj4gPiArCWIgPSBk ZXBlbmRlbnRfcHRyX21iKGIsIHEpOwo+ID4gKwlXUklURV9PTkNFKGIsIDEpOwo+ID4gKwo+ID4g ICBJbiBhZGRpdGlvbiwgY29udHJvbCBkZXBlbmRlbmNpZXMgYXBwbHkgb25seSB0byB0aGUgdGhl bi1jbGF1c2UgYW5kCj4gPiAgIGVsc2UtY2xhdXNlIG9mIHRoZSBpZi1zdGF0ZW1lbnQgaW4gcXVl c3Rpb24uICBJbiBwYXJ0aWN1bGFyLCBpdCBkb2VzCj4gPiAgIG5vdCBuZWNlc3NhcmlseSBhcHBs eSB0byBjb2RlIGZvbGxvd2luZyB0aGUgaWYtc3RhdGVtZW50Ogo+ID4gQEAgLTg3NSw2ICs4OTMs OCBAQCB0byB0aGUgQ1BVIGNvbnRhaW5pbmcgaXQuICBTZWUgdGhlIHNlY3Rpb24gb24gIk11bHRp Y29weSBhdG9taWNpdHkiCj4gPiAgIGZvciBtb3JlIGluZm9ybWF0aW9uLgo+ID4gKwo+ID4gKwo+ ID4gICBJbiBzdW1tYXJ5Ogo+ID4gICAgICgqKSBDb250cm9sIGRlcGVuZGVuY2llcyBjYW4gb3Jk ZXIgcHJpb3IgbG9hZHMgYWdhaW5zdCBsYXRlciBzdG9yZXMuCj4gPiBkaWZmIC0tZ2l0IGEvYXJj aC9hbHBoYS9pbmNsdWRlL2FzbS9iYXJyaWVyLmggYi9hcmNoL2FscGhhL2luY2x1ZGUvYXNtL2Jh cnJpZXIuaAo+ID4gaW5kZXggOTJlYzQ4NmE0ZjllLi5iNDkzNGU4YzU1MWIgMTAwNjQ0Cj4gPiAt LS0gYS9hcmNoL2FscGhhL2luY2x1ZGUvYXNtL2JhcnJpZXIuaAo+ID4gKysrIGIvYXJjaC9hbHBo YS9pbmNsdWRlL2FzbS9iYXJyaWVyLmgKPiA+IEBAIC01OSw2ICs1OSw3IEBACj4gPiAgICAqIGFz IEFscGhhLCAieSIgY291bGQgYmUgc2V0IHRvIDMgYW5kICJ4IiB0byAwLiAgVXNlIHJtYigpCj4g PiAgICAqIGluIGNhc2VzIGxpa2UgdGhpcyB3aGVyZSB0aGVyZSBhcmUgbm8gZGF0YSBkZXBlbmRl bmNpZXMuCj4gPiAgICAqLwo+ID4gKyNkZWZpbmUgQVJDSF9ORUVEU19SRUFEX0JBUlJJRVJfREVQ RU5EUyAxCj4gPiAgICNkZWZpbmUgcmVhZF9iYXJyaWVyX2RlcGVuZHMoKSBfX2FzbV9fIF9fdm9s YXRpbGVfXygibWIiOiA6IDoibWVtb3J5IikKPiA+ICAgI2lmZGVmIENPTkZJR19TTVAKPiA+IGRp ZmYgLS1naXQgYS9pbmNsdWRlL2FzbS1nZW5lcmljL2JhcnJpZXIuaCBiL2luY2x1ZGUvYXNtLWdl bmVyaWMvYmFycmllci5oCj4gPiBpbmRleCAyY2FmZGJiOWFlNGMuLmZhMmUyZWY3MmI2OCAxMDA2 NDQKPiA+IC0tLSBhL2luY2x1ZGUvYXNtLWdlbmVyaWMvYmFycmllci5oCj4gPiArKysgYi9pbmNs dWRlL2FzbS1nZW5lcmljL2JhcnJpZXIuaAo+ID4gQEAgLTcwLDYgKzcwLDI0IEBACj4gPiAgICNk ZWZpbmUgX19zbXBfcmVhZF9iYXJyaWVyX2RlcGVuZHMoKQlyZWFkX2JhcnJpZXJfZGVwZW5kcygp Cj4gPiAgICNlbmRpZgo+ID4gKyNpZiBkZWZpbmVkKENPTVBJTEVSX0hBU19PUFRJTUlaRVJfSElE RV9WQVIpICYmIFwKPiA+ICsJIWRlZmluZWQoQVJDSF9ORUVEU19SRUFEX0JBUlJJRVJfREVQRU5E UykKPiA+ICsKPiA+ICsjZGVmaW5lIGRlcGVuZGVudF9wdHJfbWIocHRyLCB2YWwpICh7CQkJCQlc Cj4gPiArCWxvbmcgZGVwZW5kZW50X3B0cl9tYl92YWwgPSAobG9uZykodmFsKTsJCQlcCj4gPiAr CWxvbmcgZGVwZW5kZW50X3B0cl9tYl9wdHIgPSAobG9uZykocHRyKSAtIGRlcGVuZGVudF9wdHJf bWJfdmFsOwlcCj4gPiArCQkJCQkJCQkJXAo+ID4gKwlCVUlMRF9CVUdfT04oc2l6ZW9mKHZhbCkg PiBzaXplb2YobG9uZykpOwkJCVwKPiA+ICsJT1BUSU1JWkVSX0hJREVfVkFSKGRlcGVuZGVudF9w dHJfbWJfdmFsKTsJCQlcCj4gPiArCSh0eXBlb2YocHRyKSkoZGVwZW5kZW50X3B0cl9tYl9wdHIg KyBkZXBlbmRlbnRfcHRyX21iX3ZhbCk7CVwKPiA+ICt9KQo+ID4gKwo+ID4gKyNlbHNlCj4gPiAr Cj4gPiArI2RlZmluZSBkZXBlbmRlbnRfcHRyX21iKHB0ciwgdmFsKSAoeyBtYigpOyAocHRyKTsg fSkKPiAKPiAKPiBTbyBmb3IgdGhlIGV4YW1wbGUgb2YgcGF0Y2ggNCwgd2UnZCBiZXR0ZXIgZmFs bCBiYWNrIHRvIHJtYigpIG9yIG5lZWQgYQo+IGRlcGVuZGVudF9wdHJfcm1iKCk/Cj4gCj4gVGhh bmtzCgpZb3UgbWVhbiBmb3Igc3Ryb25nbHkgb3JkZXJlZCBhcmNoaXRlY3R1cmVzIGxpa2UgSW50 ZWw/ClllcywgbWF5YmUgaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBkZXBlbmRlbnRfcHRyX3NtcF9y bWIsCmRlcGVuZGVudF9wdHJfZG1hX3JtYiBhbmQgZGVwZW5kZW50X3B0cl92aXJ0X3JtYi4KCm1i IHZhcmlhbnQgaXMgdW51c2VkIHJpZ2h0IG5vdyBzbyBJJ2xsIHJlbW92ZSBpdC4KCgo+IAo+ID4g Kwo+ID4gKyNlbmRpZgo+ID4gKwo+ID4gICAjaWZkZWYgQ09ORklHX1NNUAo+ID4gICAjaWZuZGVm IHNtcF9tYgo+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvY29tcGlsZXIuaCBiL2luY2x1 ZGUvbGludXgvY29tcGlsZXIuaAo+ID4gaW5kZXggNjYwMWQzOWU4YzQ4Li5mNTk5YzMwZjFiMjgg MTAwNjQ0Cj4gPiAtLS0gYS9pbmNsdWRlL2xpbnV4L2NvbXBpbGVyLmgKPiA+ICsrKyBiL2luY2x1 ZGUvbGludXgvY29tcGlsZXIuaAo+ID4gQEAgLTE1Miw5ICsxNTIsMTMgQEAgdm9pZCBmdHJhY2Vf bGlrZWx5X3VwZGF0ZShzdHJ1Y3QgZnRyYWNlX2xpa2VseV9kYXRhICpmLCBpbnQgdmFsLAo+ID4g ICAjZW5kaWYKPiA+ICAgI2lmbmRlZiBPUFRJTUlaRVJfSElERV9WQVIKPiA+ICsKPiA+ICAgLyog TWFrZSB0aGUgb3B0aW1pemVyIGJlbGlldmUgdGhlIHZhcmlhYmxlIGNhbiBiZSBtYW5pcHVsYXRl ZCBhcmJpdHJhcmlseS4gKi8KPiA+ICAgI2RlZmluZSBPUFRJTUlaRVJfSElERV9WQVIodmFyKQkJ CQkJCVwKPiA+ICAgCV9fYXNtX18gKCIiIDogIj1ybSIgKHZhcikgOiAiMCIgKHZhcikpCj4gPiAr Cj4gPiArI2RlZmluZSBDT01QSUxFUl9IQVNfT1BUSU1JWkVSX0hJREVfVkFSIDEKPiA+ICsKPiA+ ICAgI2VuZGlmCj4gPiAgIC8qIE5vdC1xdWl0ZS11bmlxdWUgSUQuICovCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClZpcnR1YWxpemF0aW9uIG1haWxpbmcg bGlzdApWaXJ0dWFsaXphdGlvbkBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xp c3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby92aXJ0dWFsaXphdGlvbg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:40648 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726180AbfAGEXP (ORCPT ); Sun, 6 Jan 2019 23:23:15 -0500 Date: Sun, 6 Jan 2019 23:23:07 -0500 From: "Michael S. Tsirkin" Subject: Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency Message-ID: <20190106231756-mutt-send-email-mst@kernel.org> References: <20190102205715.14054-1-mst@redhat.com> <20190102205715.14054-4-mst@redhat.com> <86023cbe-d1ae-a0d6-7b75-26556f1a0c1f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86023cbe-d1ae-a0d6-7b75-26556f1a0c1f@redhat.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Jason Wang Cc: linux-kernel@vger.kernel.org, Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , linux-arch@vger.kernel.org, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, Jonathan Corbet , Richard Henderson , Ivan Kokshaysky , Matt Turner , Arnd Bergmann , Luc Van Oostenryck , linux-doc@vger.kernel.org, linux-alpha@vger.kernel.org, linux-sparse@vger.kernel.org Message-ID: <20190107042307.rXtRKRY30ectVPpRecOxZ4rvxWsnqy2D19S1iJX2fzI@z> On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote: > > On 2019/1/3 上午4:57, Michael S. Tsirkin wrote: > > It's not uncommon to have two access two unrelated memory locations in a > > specific order. At the moment one has to use a memory barrier for this. > > > > However, if the first access was a read and the second used an address > > depending on the first one we would have a data dependency and no > > barrier would be necessary. > > > > This adds a new interface: dependent_ptr_mb which does exactly this: it > > returns a pointer with a data dependency on the supplied value. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > Documentation/memory-barriers.txt | 20 ++++++++++++++++++++ > > arch/alpha/include/asm/barrier.h | 1 + > > include/asm-generic/barrier.h | 18 ++++++++++++++++++ > > include/linux/compiler.h | 4 ++++ > > 4 files changed, 43 insertions(+) > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > index c1d913944ad8..9dbaa2e1dbf6 100644 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -691,6 +691,18 @@ case what's actually required is: > > p = READ_ONCE(b); > > } > > +Alternatively, a control dependency can be converted to a data dependency, > > +e.g.: > > + > > + q = READ_ONCE(a); > > + if (q) { > > + b = dependent_ptr_mb(b, q); > > + p = READ_ONCE(b); > > + } > > + > > +Note how the result of dependent_ptr_mb must be used with the following > > +accesses in order to have an effect. > > + > > However, stores are not speculated. This means that ordering -is- provided > > for load-store control dependencies, as in the following example: > > @@ -836,6 +848,12 @@ out-guess your code. More generally, although READ_ONCE() does force > > the compiler to actually emit code for a given load, it does not force > > the compiler to use the results. > > +Converting to a data dependency helps with this too: > > + > > + q = READ_ONCE(a); > > + b = dependent_ptr_mb(b, q); > > + WRITE_ONCE(b, 1); > > + > > In addition, control dependencies apply only to the then-clause and > > else-clause of the if-statement in question. In particular, it does > > not necessarily apply to code following the if-statement: > > @@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy atomicity" > > for more information. > > + > > + > > In summary: > > (*) Control dependencies can order prior loads against later stores. > > diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h > > index 92ec486a4f9e..b4934e8c551b 100644 > > --- a/arch/alpha/include/asm/barrier.h > > +++ b/arch/alpha/include/asm/barrier.h > > @@ -59,6 +59,7 @@ > > * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb() > > * in cases like this where there are no data dependencies. > > */ > > +#define ARCH_NEEDS_READ_BARRIER_DEPENDS 1 > > #define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > > #ifdef CONFIG_SMP > > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > > index 2cafdbb9ae4c..fa2e2ef72b68 100644 > > --- a/include/asm-generic/barrier.h > > +++ b/include/asm-generic/barrier.h > > @@ -70,6 +70,24 @@ > > #define __smp_read_barrier_depends() read_barrier_depends() > > #endif > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \ > > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS) > > + > > +#define dependent_ptr_mb(ptr, val) ({ \ > > + long dependent_ptr_mb_val = (long)(val); \ > > + long dependent_ptr_mb_ptr = (long)(ptr) - dependent_ptr_mb_val; \ > > + \ > > + BUILD_BUG_ON(sizeof(val) > sizeof(long)); \ > > + OPTIMIZER_HIDE_VAR(dependent_ptr_mb_val); \ > > + (typeof(ptr))(dependent_ptr_mb_ptr + dependent_ptr_mb_val); \ > > +}) > > + > > +#else > > + > > +#define dependent_ptr_mb(ptr, val) ({ mb(); (ptr); }) > > > So for the example of patch 4, we'd better fall back to rmb() or need a > dependent_ptr_rmb()? > > Thanks You mean for strongly ordered architectures like Intel? Yes, maybe it makes sense to have dependent_ptr_smp_rmb, dependent_ptr_dma_rmb and dependent_ptr_virt_rmb. mb variant is unused right now so I'll remove it. > > > + > > +#endif > > + > > #ifdef CONFIG_SMP > > #ifndef smp_mb > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > > index 6601d39e8c48..f599c30f1b28 100644 > > --- a/include/linux/compiler.h > > +++ b/include/linux/compiler.h > > @@ -152,9 +152,13 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, > > #endif > > #ifndef OPTIMIZER_HIDE_VAR > > + > > /* Make the optimizer believe the variable can be manipulated arbitrarily. */ > > #define OPTIMIZER_HIDE_VAR(var) \ > > __asm__ ("" : "=rm" (var) : "0" (var)) > > + > > +#define COMPILER_HAS_OPTIMIZER_HIDE_VAR 1 > > + > > #endif > > /* Not-quite-unique ID. */