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 <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
