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 primitives. 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
