From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 53FB93858007 for ; Thu, 5 Aug 2021 09:32:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 53FB93858007 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B5C9B6D; Thu, 5 Aug 2021 02:32:24 -0700 (PDT) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 110313F719; Thu, 5 Aug 2021 02:32:23 -0700 (PDT) Subject: Re: [RFC] Adding a new attribute to function param to mark it as constant To: Segher Boessenkool , Florian Weimer Cc: GCC Development References: <20210803215538.GU1583@gate.crashing.org> <20210804101722.GD1583@gate.crashing.org> <20210804124619.GF1583@gate.crashing.org> <07900439-bc29-1f24-2522-4d2d79a86d4f@foss.arm.com> <20210804134028.GG1583@gate.crashing.org> <02e9660a-5772-97f4-ea0b-c7b024631dc6@foss.arm.com> <20210804161645.GI1583@gate.crashing.org> <8735rp6suf.fsf@oldenburg.str.redhat.com> <20210804175925.GJ1583@gate.crashing.org> From: Richard Earnshaw Message-ID: <7c8fd478-e34e-ec7c-4afc-764ab68a0684@foss.arm.com> Date: Thu, 5 Aug 2021 10:32:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210804175925.GJ1583@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 09:32:26 -0000 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 ' | gcc -E - | wc -l >> 41045 > > $ echo '#include ' | 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.