From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id C1F4B3858015 for ; Wed, 4 Aug 2021 00:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C1F4B3858015 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 1740wjoR018542; Tue, 3 Aug 2021 19:58:45 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 1740wisq018541; Tue, 3 Aug 2021 19:58:44 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 3 Aug 2021 19:58:44 -0500 From: Segher Boessenkool To: Bill Schmidt Cc: will schmidt , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 53/55] rs6000: Update altivec.h for automated interfaces Message-ID: <20210804005844.GB1583@gate.crashing.org> References: <73472f2fd31f8f848789c121708110d5cfb25494.1623941442.git.wschmidt@linux.ibm.com> <2ee50a9bc2d8c7b1b4453a269c0d9679910d3e38.camel@vnet.ibm.com> <5d465251-53c5-5057-7ab0-c3ed0811d843@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5d465251-53c5-5057-7ab0-c3ed0811d843@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 00:59:46 -0000 On Wed, Jul 28, 2021 at 03:58:02PM -0500, Bill Schmidt wrote: > On 7/27/21 4:07 PM, will schmidt wrote: > >On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote: > >>+#ifdef _ARCH_PWR8 > >>+#define vec_vclz vec_cntlz > >>+#define vec_vgbbd vec_gb > >>+#define vec_vmrgew vec_mergee > >>+#define vec_vmrgow vec_mergeo > >>+#define vec_vpopcntu vec_popcnt > >>+#define vec_vrld vec_rl > >>+#define vec_vsld vec_sl > >>+#define vec_vsrd vec_sr > >>+#define vec_vsrad vec_sra > >>+#endif > > > >Does anything bad happen if these are simply defined, without the > >#ifdef/#endif protection? > >I'm wondering if there is some scenario with > >pragma GCC target "cpu=powerX" where we may want them defined > >anyway. > > Yes, you're right about that.  We could run into such problems, I > think.  I think it's best to always define these.  If the builtin isn't > supported for the specific target configuration, it'll be flagged during > the lookup process. I don't think it will ever cause problems. But yes, it certainly is not the best place to do it here, and it is done elsewhere already, as you say. It does make a user-visible difference though: without the #if user code using the name "vec_vgbbd" for some other purpose will stop working (when building for older machines, it already will break on power8). These aren't reserved names. We don't really care though I guess ;-) Segher