On Tue, Jul 24, 2018 at 10:55 PM, Steve Ellcey <sell...@cavium.com> wrote: > On Tue, 2018-07-24 at 22:04 +0100, James Greenhalgh wrote: >> >> >> I'd say this patch isn't desirable for trunk. I'd be interested in use cases >> that need a static decision on presence of LSE that are not better expressed >> using higher level language features. >> >> Thanks, >> James > > How about when building the higher level features?
> Right now, > in sysdeps/aarch64/atomic-machine.h, we > hardcode ATOMIC_EXCHANGE_USES_CAS to 0. If we had __ARM_FEATURE_LSE we > could use that to determine if we wanted to set > ATOMIC_EXCHANGE_USES_CAS to 0 or 1 which would affect the call > generated in nptl/pthread_spin_lock.c. That would be useful if we > built a lipthread specifically for a platform that had LSE. No, you don't need to define ATOMIC_EXCHANGE_USES_CAS=1 to get LSE instructions in libpthread. You get that already with -march=armv8-a+lse on the command line. ATOMIC_EXCHANGE_USES_CAS =1 in glibc implies that a CAS is faster than a SWP and that on AArch64 is a per micro-architectural decision *not* an architectural decision for the port unless someone can categorically say that the majority of implementations that glibc cares about *have* better CAS performance than SWP performance. Both the SWP and CAS instructions are part of v8.1-A / LSE thus all you need to build libpthread with lse is merely the command line option -march=armv8-a+lse. So, no you don't need this macro to build libpthread for v8.1 or LSE . You need that macro to statically choose a cas implementation over a swp implementation. See comment in include/atomic.h : /* ATOMIC_EXCHANGE_USES_CAS is non-zero if atomic_exchange operations are implemented based on a CAS loop; otherwise, this is zero and we assume that the atomic_exchange operations could provide better performance than a CAS loop. */ regards Ramana > > Steve Ellcey > sell...@cavium.com >
