On Wed, Aug 04, 2021 at 07:08:08PM +0200, Florian Weimer wrote: > * 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
$ echo '#include <altivec.h>' | gcc -E - -maltivec | wc -l 9 Most of this file (774 lines) is #define's, which take essentially no time at all. And none of the other archs I have looked at have big headers either! Segher
