This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Use lwsync on 64bit
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 13 Feb 2017 12:23:49 -0200
- Subject: Re: [PATCH] powerpc: Use lwsync on 64bit
- Authentication-results: sourceware.org; auth=none
- References: <20170213102220.31ba7d56@kryten> <87h93y436y.fsf@linux.vnet.ibm.com>
On 13/02/2017 11:42, Tulio Magno Quites Machado Filho wrote:
> Anton Blanchard <anton@samba.org> writes:
>
>> Either an isync or an lwsync can be used as an acquire barrier after
>> a larx/stcx/bne sequence. All 64bit CPUs support lwsync and since the
>> isync instruction has other side effects that we don't need, use lwsync.
>>
>> 2017-02-12 Anton Blanchard <anton@samba.org>
>>
>> * sysdeps/powerpc/atomic-machine.h: Allow __ARCH_ACQ_INSTR to be
>> overridden.
>> * sysdeps/powerpc/powerpc64/atomic-machine.h: define __ARCH_ACQ_INSTR
>
> LGTM.
>
I do not think this is correct for all the primitives that use
__ARCH_ACQ_INSTR. For instance __arch_atomic_exchange_32_acq is defined as
#define __arch_atomic_exchange_32_acq(mem, value) \
({ \
__typeof (*mem) __val; \
__asm __volatile ( \
"1: lwarx %0,0,%2" MUTEX_HINT_ACQ "\n" \
" stwcx. %3,0,%2\n" \
" bne- 1b\n" \
" " __ARCH_ACQ_INSTR \
: "=&r" (__val), "=m" (*mem) \
: "b" (mem), "r" (value), "m" (*mem) \
: "cr0", "memory"); \
__val; \
})
Which is analogous to C11:
#include <stdatomic.h>
#include <stdint.h>
uint32_t foo (uint32_t *x)
{
return atomic_exchange_explicit (x, 0, memory_order_acquire);
}
And GCC 6.2.1 uses and 'isync' a memory barrier. It is also on par with [1]
which defines acquire semantics to require 'isync' instructions.
[1] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html