From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF6dw-0003gE-M9 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:22:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF6dt-0008Ni-D2 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:22:04 -0400 Received: from mail-lf0-x242.google.com ([2a00:1450:4010:c07::242]:36465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF6dt-0008NX-55 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:22:01 -0400 Received: by mail-lf0-x242.google.com with SMTP id a2so6844467lfe.3 for ; Mon, 20 Jun 2016 14:22:01 -0700 (PDT) References: <20160618040343.19517-1-bobby.prani@gmail.com> <20160618040343.19517-2-bobby.prani@gmail.com> From: Sergey Fedorov Message-ID: <57685E76.5040805@gmail.com> Date: Tue, 21 Jun 2016 00:21:58 +0300 MIME-Version: 1.0 In-Reply-To: <20160618040343.19517-2-bobby.prani@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v3 PATCH 01/14] Introduce TCGOpcode for memory barrier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pranith Kumar , Richard Henderson , "open list:All patches CC here" Cc: alex.bennee@linaro.org On 18/06/16 07:03, Pranith Kumar wrote: > diff --git a/tcg/tcg.h b/tcg/tcg.h > index db6a062..36feca9 100644 > --- a/tcg/tcg.h > +++ b/tcg/tcg.h > @@ -408,6 +408,20 @@ static inline intptr_t QEMU_ARTIFICIAL GET_TCGV_PTR(TCGv_ptr t) > #define TCG_CALL_DUMMY_TCGV MAKE_TCGV_I32(-1) > #define TCG_CALL_DUMMY_ARG ((TCGArg)(-1)) > > +typedef enum { > + TCG_MO_LD_LD = 1, > + TCG_MO_ST_LD = 2, > + TCG_MO_LD_ST = 4, > + TCG_MO_ST_ST = 8, > + TCG_MO_ALL = 0xF, // OR of all above So TCG_MO_ALL specifies a so called "full" memory barrier? > +} TCGOrder; > + > +typedef enum { > + TCG_BAR_ACQ = 32, > + TCG_BAR_REL = 64, I'm convinced that the only practical way to represent a standalone acquire memory barrier is to order all previous loads with all subsequent loads and stores. Similarly, a standalone release memory barrier would order all previous loads and stores with all subsequent stores. [1] On the other hand, acquire or release semantic associated with a memory operation itself can be directly mapped into e.g. AArch64's Load-Acquire (LDAR) and Store-Release (STLR) instructions. A standalone barrier adjacent to a memory operation shouldn't be mapped this way because it should provide more strict guarantees than e.g. AArch64 instructions mentioned above. Therefore, I advocate for clear distinction between standalone memory barriers and implicit memory ordering semantics associated with memory operations themselves. [1] http://preshing.com/20130922/acquire-and-release-fences/ > + TCG_BAR_SC = 128, How's that different from TCG_MO_ALL? > +} TCGBar; > + > /* Conditions. Note that these are laid out for easy manipulation by > the functions below: > bit 0 is used for inverting; Kind regards, Sergey