* Segher Boessenkool: > On Wed, Aug 04, 2021 at 03:27:00PM +0100, Richard Earnshaw wrote: >> On 04/08/2021 14:40, Segher Boessenkool wrote: >> >On Wed, Aug 04, 2021 at 02:00:42PM +0100, Richard Earnshaw wrote: >> >>We don't want to have to resort to macros. Not least because at some >> >>point we want to replace the content of arm_neon.h with a single #pragma >> >>directive to remove all the parsing of the header that's needed. What's >> >>more, if we had a suitable pragma we'd stand a fighting chance of being >> >>able to extend support to other languages as well that don't use the >> >>pre-processor, such as Fortran or Ada (not that that is on the cards >> >>right now). >> > >> >So how do you want to handle constants-that-are-not-yet-constant, say >> >before inlining? And how do you want to deal with those possibly not >> >ever becoming constant, perhaps because you used a too low "n" in -On >> >(but there are very many random other causes)? And, what *is* a >> >constant, anyway? This is even more fuzzy if you consider those >> >other languages as well. >> > >> >(Does skipping parsing of some trivial header save so much time? Huh!) >> >> Trivial? arm_neon.h is currently 20k lines of source. What's more, it >> has to support inline functions that might not be available when the >> header is parsed, but might become available if the user subsequently >> compiles a function with different attributes enabled. It is very >> definitely *NOT* trivial. > > Ha yes :-) I just assumed without looking that it would be like other > architectures' intrinsics headers. Whoops.
But isn't it? $ echo '#include <x86intrin.h>' | gcc -E - | wc -l 41045 Thanks, Florian
