RFC: linux-aarch64 and LSE support

[Kim Barrett]

> On Sep 20, 2022, at 7:15 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> > […]
> > To summarize, for memory_order_conservative with ll/sc-style atomics
> > - For cmpxchg, use <fence> <relaxed-cmpxchg> <fence>
> 
> I think you found a bug in the pre-LSE code.
> 
> aarch64_atomic_cmpxchg_8_default_impl:
> #ifdef __ARM_FEATURE_ATOMICS
>        mov     x3, x1
>        casal   x3, x2, [x0]
> #else
>        dmb     ish
>        prfm    pstl1strm, [x0]
> 0:      ldxr    x3, [x0]
>        cmp     x3, x1
>        b.ne    1f
>        stxr    w8, x2, [x0]
>        cbnz    w8, 0b
> #endif
> 1:      dmb     ish
>        mov     x0, x3
>        ret
> 
> This should be LDAXR;STLXR. CASAL is correct.

I don't think it needs to be LDAXR;STLXR.  And neither does
https://patchwork.kernel.org/patch/3575821/

The surrounding DMB-ISH pair provide the needed ordering.  The "traditional"
implementation for all of these operations on ll/sc has been a relaxed ll/sc
loop preceeded and followed by fences.

> > […]
> > (A) The default (ll/sc) implementations (atomic_linux_aarch64.S) are all
> > "acq-rel" rather than "release".
> 
> Good.

Not good if one believes the afore-mentioned kernel.org analysis, which is
what we relied on until 8261027 for linux, and are still relying on for bsd.
That analysis says "release" is sufficient, and "acq-rel" is just an
unnecessary "acquire".  I didn't find any justification in the bug or PR
discussion for that change.

> >  Meanwhile, the generated stubs for "xchg" variants are "release".
> 
> Really? I see
> 
>  void gen_swpal_entry(Assembler::operand_size size) {
>    Register prev = r2, addr = c_rarg0, incr = c_rarg1;
>    __ swpal(size, incr, prev, addr);
>    __ membar(Assembler::StoreStore|Assembler::StoreLoad);
> 
> That's acquire/release. What are you looking at?

My comment was about that PR, not about later changes that are now on
mainline.  That is, I was referring to this:

https://github.com/openjdk/jdk/pull/2434/files#diff-9112056f732229b18fec48fb0b20a3fe824de49d0abd41fbdb4202cfe70ad114R5607-R5621

from the 8261027 PR.  Note the `__ atomic_xchgl`.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221003/8b12f9b2/signature.asc>