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: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Steve Ellcey <sellcey at cavium 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 22:04:24 +0100
- Subject: Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available
- References: <firstname.lastname@example.org>
On Tue, Jul 24, 2018 at 03:22:02PM -0500, Steve Ellcey wrote:
> This is a patch for PR 86538, to define an __ARM_FEATURE_LSE macro
> when LSE is available. Richard Earnshaw closed PR 86538 as WONTFIX
> because the ACLE (Arm C Language Extension) does not require this
> macro and because he is concerned that it might encourage people to
> use inline assembly instead of the __sync and atomic intrinsics.
> (See actual comments in the defect report.)
> While I agree that we want people to use the intrinsics I still think
> there are use cases where people may want to know if LSE is available
> or not and there is currrently no (simple) way to determine if this feature
> is available since it can be turned or and off independently of the
> architecture used. Also, as a general principle, I think any feature
> that can be toggled on or off by the compiler should provide a way for
> users to determine what its state is.
Well, we blow that design principle all over the place (find me a macro
which tells you whether AARCH64_EXTRA_TUNE_SLOW_UNALIGNED_LDPW is on for
example :-) )
A better design principle would be that if we think language programmers
may want to compile in different C code depending on a compiler option, we
should consider adding a feature macro.
> So what do other ARM maintainers and users think? Is this a useful
> feature to have in GCC?
I'm with Richard on this one.
Whether LSE is available or not at compile time, the best user strategy is
to use the C11/C++11 atomic extensions. That's where the memory model is
well defined, well reasoned about, and well implemented.
Purely in ACLE we're not keen on providing macros that don't provide choice
to a C level programmer (i.e. change the prescence of intrinsics).
You could well imagine an inline asm programmer wanting to choose between an
LSE path and an Armv8.0-A path; but I can't imagine what they would want to
do on that path that couldn't be expressed better in the C language. You
might say they want to validate presence of the instruction; but that will
need to be a dynamic check outside of ACLE anyway.
All of which is to say, I don't think that this is a neccessary macro. Each
time I've seen it requested by a user, we've told them the same thing; what
do you want to express here that isn't better expressed by C atomic
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.