Re: [RFC] Adding a new attribute to function param to mark it as constant

[Florian Weimer <fweimer@redhat.com>]

* 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