This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available


On Tue, Jul 24, 2018 at 10:55 PM, Steve Ellcey <sellcey@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
> sellcey@cavium.com
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]