Re: [PATCH] LoongArch: Fix atomic_exchange make comparison and may jump out

[Xi Ruoyao <xry111@xry111.site>]

On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:

> > > +  return "%G6\\n\\t"
> > > +        "1:\\n\\t"
> > > +        "ll.<amo>\\t%0,%1\\n\\t"
> > > +        "and\\t%7,%0,%z3\\n\\t"
> > > +        "or%i5\\t%7,%7,%5\\n\\t"
> > > +        "sc.<amo>\\t%7,%1\\n\\t"
> > > +        "beqz\\t%7,1b\\n\\t";
> > Do we need a "dbar 0x700" after beqz?
> > 
> > /* snip */
> 
> That's worth discussing. Actually I don't see any dbar hint definition
> like 0x700 in the manual right now.
> Besides, I think what should be provided here is a relaxed version. And
> whether the barrier exsit or not is depend on the specific memory_order.

It's not related to memory order, but for a hardware issue workaround. 
Jiaxun told me (via LKML):

   I had checked with Loongson guys and they confirmed that the
   workaround still needs to be applied to latest 3A4000 processors,
   including 3A4000 for MIPS and 3A5000 for LoongArch.
   
   Though, the reason behind the workaround varies with the evaluation
   of their uArch, for GS464V based core, barrier is required as the
   uArch design allows regular load to be reordered after an atomic
   linked load, and that would break assumption of compiler atomic
   constraints.

Without these dbar instructions I'd got random test failures in GCC
libgomp test suite.

We use a non-zero hint here because it is treated exactly same as zero
in 3A5000, and the future LoongArch processors can fix the issue and
ignore the dbar 0x700 instruction.


-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University