This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available
- From: Steve Ellcey <sellcey at cavium dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, nd at arm dot com
- Date: Tue, 24 Jul 2018 14:55:46 -0700
- Subject: Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available
- References: <firstname.lastname@example.org> <20180724210423.GA28802@arm.com>
- Reply-to: sellcey at cavium dot com
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.
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.