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. Now I could ask how this monster came to be this big, but I will wisely back away. Slowly :-) Segher
