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 ADF3C3858D3C for ; Wed, 25 Aug 2021 23:28:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADF3C3858D3C 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 17PNRFek003424; Wed, 25 Aug 2021 18:27:15 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 17PNREYY003423; Wed, 25 Aug 2021 18:27:14 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 25 Aug 2021 18:27:14 -0500 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, willschm@linux.ibm.com Subject: Re: [PATCH 14/34] rs6000: Add remaining overloads Message-ID: <20210825232714.GW1583@gate.crashing.org> References: <0e8dad82a5f7863278258c97384dad46ff1e08b7.1627562851.git.wschmidt@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e8dad82a5f7863278258c97384dad46ff1e08b7.1627562851.git.wschmidt@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.6 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, 25 Aug 2021 23:28:16 -0000 On Thu, Jul 29, 2021 at 08:31:01AM -0500, Bill Schmidt wrote: > * config/rs6000/rs6000-overload.def: Add remaining overloads. > +; TODO: Note that the entry for VEC_ADDE currently gets ignored in > +; altivec_resolve_overloaded_builtin. Revisit whether we can remove > +; that. We still need to register the legal builtin forms here. > +[VEC_ADDE, vec_adde, __builtin_vec_adde] > + vsq __builtin_vec_adde (vsq, vsq, vsq); > + VADDEUQM VADDEUQM_VSQ > + vuq __builtin_vec_adde (vuq, vuq, vuq); > + VADDEUQM VADDEUQM_VUQ I'm not sure what this means. "Currently" is the problem I think. Do you mean that the existing code (before this patch) ignores it already? > +; #### XVRSPIP{TARGET_VSX};VRFIP > +[VEC_CEIL, vec_ceil, __builtin_vec_ceil] > + vf __builtin_vec_ceil (vf); > + VRFIP > + vd __builtin_vec_ceil (vd); > + XVRDPIP Is that a comment you forgot to remove, or is there work to be done here? > +[VEC_CMPEQ, vec_cmpeq, __builtin_vec_cmpeq] > +; #### XVCMPEQSP{TARGET_VSX};VCMPEQFP And this. > +; #### XVCMPEQSP_P{TARGET_VSX};VCMPEQFP_P > +[VEC_CMPEQ_P, SKIP, __builtin_vec_vcmpeq_p] And more! And more later. It isn't clear to me at all what those comments mean, and they are formatted haphazardly, so looks like a WIP? > +; Note that the entries for VEC_MUL are currently ignored. See rs6000-c.c: > +; altivec_resolve_overloaded_builtin, where there is special-case code for > +; VEC_MUL. TODO: Is this really necessary? Investigate. Seven missing > +; prototypes here...no corresponding builtins. Also added "vmulld" in P10 > +; which could be used instead of MUL_V2DI, conditionally? Space after "..." :-P > +; Opportunity for improvement: We can use XVRESP instead of VREFP for > +; TARGET_VSX. We would need conditional dispatch to allow two possibilities. > +; Some syntax like "XVRESP{TARGET_VSX};VREFP". > +; TODO. #### > +[VEC_RE, vec_re, __builtin_vec_re] Don't we already anyway? The only difference is whether all VSRs are allowed or only the VRs, no? The RTL generated is just the same? Or maybe I am overlooking something :-) > +; ************************************************************************** > +; ************************************************************************** > +; **** Deprecated overloads that should never have existed at all **** > +; ************************************************************************** > +; ************************************************************************** The coding conventions say not to use showy block comments like that, but it seems appropriate here :-) Okay for trunk with the #### looked at. Please don't repost this one. Thanks! Segher