Re: [Qemu-devel] [PATCH v2] target-mips: generate fences

[Leon Alrae]

On Thu, Sep 08, 2016 at 10:04:05AM -0700, Richard Henderson wrote:
> > +static void gen_sync(int stype)
> > +{
> > +    TCGOrder tcg_mo = TCG_BAR_SC;
> > +
> > +    switch (stype) {
> > +    case 0x4: /* SYNC_WMB */
> > +        tcg_mo |= TCG_MO_ST_ST;
> > +        break;
> > +    case 0x10: /* SYNC_MB */
> > +        tcg_mo |= TCG_MO_ALL;
> > +        break;
> > +    case 0x11: /* SYNC_ACQUIRE */
> > +        tcg_mo |= TCG_MO_LD_LD | TCG_MO_LD_ST;
> > +        break;
> > +    case 0x12: /* SYNC_RELEASE */
> > +        tcg_mo |= TCG_MO_ST_ST | TCG_MO_LD_ST;
> > +        break;
> > +    case 0x13: /* SYNC_RMB */
> > +        tcg_mo |= TCG_MO_LD_LD;
> > +        break;
> > +    default:
> > +        tcg_mo |= TCG_MO_ALL;
> > +        break;
> > +    }
> 
> See git://github.com/rth7680/qemu.git tcg-next wherein this suggests that some
> enhancement is desired in tcg/mips/ as well.  Not that I have a mips32r6 board
> with which to test.  Would you or James Hogan be able to improve that?

Actually the lightweight variants of SYNC exist also in earlier revisions of
MIPS architecture; therefore this can be tested for example on mips32r2.

According to manuals the support is optional, and if given CPU doesn't
implement lightweight SYNCs (i.e. with stype != 0) then they are supposed
to behave in the same way as SYNC 0. (which also means I simplified that here
and always interpret the stype to take advantage of weaker ordering barriers).

Thanks,
Leon