Re: [Gc] Fwd: Re: AArch64: Shareability domain for dmb st overly conservative (#11)

Hi Ivan,

yes, for Arm even on trunk it is still a "dmb sy" that is generated,
it is the goal of the proposed patch I mentioned to change this but it
is wasn't approved so far.

To give a full picture of the __atomic_thread_fence builtin for
AArch64, here is the generated code (by trunk) for each model:

__ATOMIC_RELAXED -> nothing
__ATOMIC_CONSUME -> nothing
__ATOMIC_ACQUIRE -> dmb ishld
__ATOMIC_RELEASE -> dmb ish
__ATOMIC_ACQ_REL -> dmb ish
__ATOMIC_SEQ_CST -> dmb ish

Yvan

On 1 November 2014 20:10, Ivan Maidanski <[email protected]> wrote:
> Hi Yvan and Hans,
>
> dmb st -> dmb ishst done:
> https://github.com/ivmai/libatomic_ops/commit/719d90c7f805189f133cf9a140eb79879bf98e92
>
> About GCC builtin primitives:
> https://github.com/ivmai/libatomic_ops/blob/master/src/atomic_ops/sysdeps/gcc/generic.h
> already has AO_nop_write defined as ATOMIC_RELEASE. But we still use
> assembly-based nop_write definition for AArch64 because ATOMIC_RELEASE does
> not emitt "dmb ishst" (at least at the moment when the code was written).
> Today I rechecked which dmb type do builtin primitives generate for Arm (I
> used NDK r9b gcc 4.8) - ATOMIC_RELEASE is translated to "dmb sy".
>
> Tue, 28 Oct 2014 11:29:33 +0100 from Yvan Roux <[email protected]>:
>
> Hi, (sorry for my late answer, I'm on vacation with a limited network
> access)
>
> Yes I think I was too conservative when I implemented it, I took the
> libatomic_ops arm port and GCC as example which both use the system
> domain, but now AArch64 GCC atomic uses already inner shareable domain
> and there is a proposition to change the Arm (32-bit) memory-barrier:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00489.html
>
> Thanks,
> Yvan
>
> On 28 October 2014 00:24, Hans Boehm <[email protected]> wrote:
>> I agree that we should be using "dmb ish"/"dmb ishst" everywhere. The
>> plain
>> variants are theoretically slower, and should not be needed. That said,
>> with limited experimentation, I have not yet found a processor
>> implementation for which it actually matters, though I have heard that
>> they
>> exist.
>>
>> Note that the "st"/"ishst" barriers are actually quite weak and, as the
>> libatomic_ops documentation states, usually not what you really want. And
>> at this stage we should really move towards the C11 primitives anyway.
>>
>> This all applies to both Aarch64 and Arm32.
>>
>> Hans
>>
>> On Sat, Oct 25, 2014 at 10:29 AM, Ivan Maidanski <[email protected]> wrote:
>>>
>>> Forwarding to ML..
>>>
>>> From: Ivan Maidanski <[email protected]>
>>> To: Yvan Roux <[email protected]>, Hans Boehm <[email protected]>
>>> CC: ivmai/libatomic_ops <[email protected]>,
>>> ivmai/libatomic_ops
>>>
>>> <reply+i-46004519-50324839f75648d459559128d780ac126d37fdde-460469@reply.github.com>,
>>> Boehm GC <[email protected]>
>>> Date: Thu, 23 Oct 2014 12:36:39 +0400
>>> Subject: Re: [libatomic_ops] AArch64: Shareability domain for dmb st
>>> overly conservative (#11)
>>>
>>> Hi Yvan and Hans,
>>>
>>> Is the proposed change correct for ARM64 AO_nop_write? What's about
>>> 32-bit
>>> ARM?
>>>
>>> Thank you
>>>
>>> Thu, 16 Oct 2014 09:08:26 -0700 from stevecapperlinaro
>>> <[email protected]>:
>>>
>>> Hello,
>>> In src/atomic_ops/sysdeps/gcc/aarch64.h, we have the following code:
>>> __asm__ __volatile__("dmb st" : : : "memory");
>>>
>>> This will target the system domain and thus be overly conservative as the
>>> CPUs will occupy the inner shareable domain.
>>>
>>> Could this please be changed to:
>>> __asm__ __volatile__("dmb ishst" : : : "memory");
>>>
>>> That way the barriers will occupy the inner shareable domain.
>>>
>>> Thanks,
>>> Steve Capper
>>>
>>> —
>>>
>>>
>>>
>>> ________________________________
>>>
>>> _______________________________________________
>>> bdwgc mailing list
>>> [email protected]
>>> https://lists.opendylan.org/mailman/listinfo/bdwgc
>>
>>
>>
>> _______________________________________________
>> bdwgc mailing list
>> [email protected]
>> https://lists.opendylan.org/mailman/listinfo/bdwgc
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>
>
_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc