Re: [PATCH v2 1/2] LoongArch: Add 128-bit atomic cmpxchg support

[Xi Ruoyao]

On Tue, 2025-11-25 at 10:43 +0800, George Guo wrote:
> > > +         "=ZB" (__ptr[0])
> > >      \
> > 
> > "ZB" isn't a legal constraint for the address operand in sc.q. When
> > assembled, it turns into something like sc.q $r,$r,$r,0, which clearly
> > doesn't match the instruction format, yet gas happily accepts it wheil
> > clang rightfully rejects it. Classic GNU-as leniency biting again. :)

I clearly remember when Jiajie submitted the sc.q support to GAS
Qinggang was really insistent on supporting the additional ",0" here. 
But I don't really understand why we must support it...
> 
> Thanks for your advice, I tried sc.q with r or ZC. the result as
> below: (with gcc 14.2.1 in fedora-42)
>    - sc.q with "r"  caused system hang

It won't work because it'll pass the value (not address) of __ptr[0].

>    - sc.q with "ZC" caused compiler error:
>      {standard input}: Assembler messages:
>      {standard input}:10037: Fatal error: Immediate overflow.

It won't work because the only accepted immediate of sc.q is 0, but ZC
would allow any factor of 4 in [-32768, 32768).  I.e. ZC is for
{ldptr,stptr,ll,sc}.{w,d}.

As ZB is only used for sc.q (yet) in GCC backend maybe we can change ZB
to print simply $rX instead of $rX,0 and make LLVM do the same.  Would
someone submit a GCC patch for that?  Or is there already such a
constraint but I don't know?

BTW for the barrier between ll.d and ld.d, "dbar 0x700" is enough to
order two loads on the same address, and a Loongson hardware engineer
just confirmed me privately that "same address" can be read as "in the
same cacheline" here.  Thus it's enough in our case and it has a lower
overhead than "dbar 0".

-- 
Xi Ruoyao <xry111@xxxxxxxxxxx>