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

[Segher Boessenkool <segher@kernel.crashing.org>]

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