[RFC PATCH v3 05/12] C-SKY: Atomic and Locking Routines

[Joseph Myers]

On Tue, 3 Jul 2018, Mao Han wrote:

> The macro seems someting to reduce architecture-specific code
> needed to support C11-like atomics? If compiler can expands the
> atomic built-in to the correct call, either libgcc or libatomic(inline)
> , it is suggested to define USE_ATOMIC_COMPILER_BUILTINS to 1?

If the compiler expands the calls inline, defining 
USE_ATOMIC_COMPILER_BUILTINS to 1 is appropriate unless you have a clear 
reason not to do so (and such a reason would need to have detailed 
comments in glibc explaining it).

If the compiler generates out-of-line libatomic calls for atomic 
operations used in glibc, you need to use inline asm there instead of 
USE_ATOMIC_COMPILER_BUILTINS; glibc is not linked with libatomic.

If the compiler generates out-of-line libgcc calls for atomic operations 
used in glibc, it's possible inline asm will be more efficient.

The main reason for the compiler to generate out-of-line calls is if those 
calls need to use kernel helpers (vDSO / syscalls / etc.).  If the 
processors supported by the port always support suitable atomic 
instructions that can be called directly without needing such kernel 
helpers, the compiler should expand the calls inline, and you should 
define USE_ATOMIC_COMPILER_BUILTINS to 1.

> According to comment in pthread_spin_trylock.c ATOMIC_EXCHANGE_USES_CAS
> should define to 1 if exchange is not supported? I did not found any

Yes.

-- 
Joseph S. Myers
joseph@codesourcery.com