On 04/08/2021 18:59, Segher Boessenkool wrote: > 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 >
arm_sve.h isn't large either, but that's because all it contains (other than a couple of typedefs is #pragma GCC aarch64 "arm_sve.h" :) R.
