From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43602)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZU4VC-0002xU-8k
	for qemu-devel@nongnu.org; Mon, 24 Aug 2015 23:02:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZU4V9-0004Po-3P
	for qemu-devel@nongnu.org; Mon, 24 Aug 2015 23:02:22 -0400
Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36893)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZU4V8-0004Pj-Vh
	for qemu-devel@nongnu.org; Mon, 24 Aug 2015 23:02:19 -0400
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailout.nyi.internal (Postfix) with ESMTP id 7753520972
	for <qemu-devel@nongnu.org>; Mon, 24 Aug 2015 23:02:18 -0400 (EDT)
Date: Mon, 24 Aug 2015 23:02:40 -0400
From: "Emilio G. Cota" <cota@braap.org>
Message-ID: <20150825030240.GD8880@flamenco>
References: <1440375847-17603-1-git-send-email-cota@braap.org>
	<1440375847-17603-21-git-send-email-cota@braap.org>
	<55DA7443.3030901@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55DA7443.3030901@redhat.com>
Subject: Re: [Qemu-devel] [RFC 20/38] tcg/i386: implement fences
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: mttcg@greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, alex.bennee@linaro.org, Frederic Konrad <fred.konrad@greensocs.com>

On Sun, Aug 23, 2015 at 18:32:51 -0700, Paolo Bonzini wrote:
> 
> 
> On 23/08/2015 17:23, Emilio G. Cota wrote:
> > +    case INDEX_op_fence_load:
> > +        tcg_out_fence(s, 0xe8);
> > +        break;
> > +    case INDEX_op_fence_full:
> > +        tcg_out_fence(s, 0xf0);
> > +        break;
> > +    case INDEX_op_fence_store:
> > +        tcg_out_fence(s, 0xf8);
> > +        break;
> > +
> 
> lfence and sfence are not needed in generated code; all loads are
> acquires and all stores are release on x86.

lfence and sfence here serve two purposes:

1) Template for other architectures
2) x86 code does sometimes have lfence/sfence (e.g. movntq+sfence),
   so I guessed they should remain in the translated code.
   If on x86 we always ignore the Write-Combining from the
   guest, maybe we could claim the l/sfence pair here is really unnecessary.
   I'm no x86 expert so for a first stab I decided to put them there.
   
   I didn't intend to translate say *all* PPC/ARM load barriers
   into lfences when generating x86, which is I think your point.

> Also, on targets that do not have MFENCE you want to generate something
> like "lock addl $0, (%esp)".

Good point, will fix.

Thanks,

		Emilio