From: Sergey Fedorov <serge.fdrv@gmail.com>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: "Richard Henderson" <rth@twiddle.net>,
"open list:All patches CC here" <qemu-devel@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
Date: Mon, 6 Jun 2016 19:14:28 +0300 [thread overview]
Message-ID: <5755A164.9040709@gmail.com> (raw)
In-Reply-To: <CAJhHMCBqyPC5T17T+wsCeRmZxPXCBtrV16pOQs144yM7g7ffYg@mail.gmail.com>
On 06/06/16 18:58, Pranith Kumar wrote:
> On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> On 06/06/16 18:47, Pranith Kumar wrote:
>>> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>>>> On 03/06/16 21:27, Pranith Kumar wrote:
>>>>> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson <rth@twiddle.net> wrote:
>>>>>> What if we have tcg_canonicalize_memop (or some such) split off the barriers
>>>>>> into separate opcodes. E.g.
>>>>>>
>>>>>> MO_BAR_LD_B = 32 // prevent earlier loads from crossing current op
>>>>>> MO_BAR_ST_B = 64 // prevent earlier stores from crossing current op
>>>>>> MO_BAR_LD_A = 128 // prevent later loads from crossing current op
>>>>>> MO_BAR_ST_A = 256 // prevent later stores from crossing current op
>>>>>> MO_BAR_LDST_B = MO_BAR_LD_B | MO_BAR_ST_B
>>>>>> MO_BAR_LDST_A = MO_BAR_LD_A | MO_BAR_ST_A
>>>>>> MO_BAR_MASK = MO_BAR_LDST_B | MO_BAR_LDST_A
>>>>>>
>>>>>> // Match Sparc MEMBAR as the most flexible host.
>>>>>> TCG_BAR_LD_LD = 1 // #LoadLoad barrier
>>>>>> TCG_BAR_ST_LD = 2 // #StoreLoad barrier
>>>>>> TCG_BAR_LD_ST = 4 // #LoadStore barrier
>>>>>> TCG_BAR_ST_ST = 8 // #StoreStore barrier
>>>>>> TCG_BAR_SYNC = 64 // SEQ_CST barrier
>>>>> I really like this format. I would also like to add to the frontend:
>>>>>
>>>> Actually, the acquire barrier is a combined load-load + load-store
>>>> barrier; and the release barrier is a combo of load-store + store-store
>>>> barriers.
>>>>
>>> All the above are two-way barriers. Acquire/Release are one-way
>>> barriers. So we cannot combine the above to get acquire/release
>>> semantics without being conservative.
>> Do you mean *barriers* or *memory access* operations implying memory
>> ordering?
> I meant the latter. I know no arch which has acquire/release barriers.
> Sorry for the confusion.
So I am. By the way, what's the difference between sequential consistent
*barrier* and a combination of all the other barriers?
Kind regards,
Sergey
next prev parent reply other threads:[~2016-06-06 16:14 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 18:39 [Qemu-devel] [RFC v2 PATCH 00/13] tcg: Add fence gen support Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier Pranith Kumar
2016-05-31 20:24 ` Richard Henderson
2016-06-01 18:43 ` Pranith Kumar
2016-06-01 21:35 ` Richard Henderson
2016-06-02 16:18 ` Sergey Fedorov
2016-06-02 16:30 ` Sergey Fedorov
2016-06-02 18:42 ` Pranith Kumar
2016-06-02 20:36 ` Richard Henderson
2016-06-02 20:36 ` Richard Henderson
2016-06-02 20:38 ` Sergey Fedorov
2016-06-02 21:18 ` Richard Henderson
2016-06-02 21:37 ` Sergey Fedorov
2016-06-03 1:08 ` Richard Henderson
2016-06-03 15:16 ` Sergey Fedorov
2016-06-03 15:45 ` Richard Henderson
2016-06-03 16:06 ` Sergey Fedorov
2016-06-03 18:30 ` Pranith Kumar
2016-06-03 19:49 ` Sergey Fedorov
2016-06-03 20:43 ` Peter Maydell
2016-06-03 21:33 ` Sergey Fedorov
2016-06-06 16:19 ` Alex Bennée
2016-06-03 18:27 ` Pranith Kumar
2016-06-03 19:52 ` Sergey Fedorov
2016-06-06 15:44 ` Sergey Fedorov
2016-06-06 15:47 ` Pranith Kumar
2016-06-06 15:49 ` Sergey Fedorov
2016-06-06 15:58 ` Pranith Kumar
2016-06-06 16:14 ` Sergey Fedorov [this message]
2016-06-06 17:11 ` Pranith Kumar
2016-06-06 19:23 ` Richard Henderson
2016-06-06 19:28 ` Pranith Kumar
2016-06-06 20:30 ` Sergey Fedorov
2016-06-06 21:00 ` Peter Maydell
2016-06-06 21:49 ` Sergey Fedorov
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 02/13] tcg/i386: Add support for fence Pranith Kumar
2016-05-31 20:27 ` Richard Henderson
2016-06-01 18:49 ` Pranith Kumar
2016-06-01 21:17 ` Richard Henderson
2016-06-01 21:44 ` Pranith Kumar
2016-05-31 18:39 ` [RFC v2 PATCH 03/13] tcg/aarch64: " Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] " Pranith Kumar
2016-05-31 18:59 ` Claudio Fontana
2016-05-31 18:59 ` [Qemu-devel] " Claudio Fontana
2016-05-31 20:34 ` Richard Henderson
2016-05-31 20:34 ` [Qemu-devel] " Richard Henderson
2016-06-16 22:03 ` Pranith Kumar
2016-06-16 22:03 ` [Qemu-devel] " Pranith Kumar
2016-05-31 18:39 ` [RFC v2 PATCH 04/13] tcg/arm: " Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] " Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 05/13] tcg/ia64: " Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 06/13] tcg/mips: " Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 07/13] tcg/ppc: " Pranith Kumar
2016-05-31 20:41 ` Richard Henderson
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 08/13] tcg/s390: " Pranith Kumar
2016-06-02 19:31 ` Sergey Fedorov
2016-06-02 20:38 ` Richard Henderson
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 09/13] tcg/sparc: " Pranith Kumar
2016-05-31 20:45 ` Richard Henderson
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 10/13] tcg/tci: " Pranith Kumar
2016-05-31 18:39 ` [RFC v2 PATCH 11/13] target-arm: Generate fences in ARMv7 frontend Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] " Pranith Kumar
2016-06-02 19:37 ` Sergey Fedorov
2016-06-04 14:50 ` Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 12/13] target-alpha: Generate fence op Pranith Kumar
2016-05-31 18:39 ` [Qemu-devel] [RFC v2 PATCH 13/13] tcg: Generate fences only for SMP MTTCG guests Pranith Kumar
2016-05-31 18:46 ` [Qemu-devel] [RFC v2 PATCH 00/13] tcg: Add fence gen support Pranith Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5755A164.9040709@gmail.com \
--to=serge.fdrv@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=bobby.prani@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.