On 28/05/14 09:03, Matthew Fortune wrote: >> You shouldn't need to declare __builtin_* functions anyway. And if a >> function can be represented directly with GNU C vector extensions, it's >> preferred to implement it that way inline in the header rather than having >> built-in functions duplicating existing GNU C functionality. (Look at >> what AArch64 arm_neon.h does where possible, and what ARM arm_neon.h has >> been moved towards lately. I don't now what the msa.h functions do, so I >> don't know if this actually applies to any of them - but it's something to >> consider, so that built-in functions are only defined where actually >> needed.) > > In the aarch64 arm_neon.h header there are a decent number of inline asm > implementations too instead of builtins. It is not immediately obvious to me > as to what the deciding factor is between adding a builtin and using inline > asm when vector extensions do not support the operation. Do you happen to > know why inline asm is used in places? >
Speed of implementation. We're gradually replacing these with proper builtins, but that takes a lot more work. > This looks like a reasonable idea to use GNU extensions where available. The > down-side to this approach is that it may be necessary to write quite > dis-similar headers for LLVM vs GCC which I think is part of the reason why > the header is written as it is. I don't know if that is a good reason to > require builtins or not though. > I regard these headers as part of the compiler. In an ideal world the contents of arm_neon.h should be replacable with #pragma GCC neon_intrinsics which would make parsing pretty much instantaneous. It's never that simple, though; sadly :-( R.
