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
