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 2B339385734C for ; Wed, 15 Jun 2022 11:36:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B339385734C 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 C9217152B; Wed, 15 Jun 2022 04:36:22 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B7143F66F; Wed, 15 Jun 2022 04:36:21 -0700 (PDT) From: Richard Sandiford To: Jeff Law via Gcc-patches Mail-Followup-To: Jeff Law via Gcc-patches , Richard Biener , Jeff Law , richard.sandiford@arm.com Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart. References: Date: Wed, 15 Jun 2022 12:36:20 +0100 In-Reply-To: (Jeff Law via Gcc-patches's message of "Mon, 13 Jun 2022 11:34:02 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-52.1 required=5.0 tests=BAYES_00, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 15 Jun 2022 11:36:25 -0000 Jeff Law via Gcc-patches writes: > On 6/13/2022 5:54 AM, Richard Biener wrote: >> On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches >> wrote: >> [...] >>> On a related topic, any thoughts on keeping complex objects as complex >>> types/modes through gimple and into at least parts of the RTL pipeline? >>> >>> The way complex arithmetic instructions work on our chip is going to be >>> extremely tough to utilize in GCC -- we really need to the complex >>> types/arithmetic up through RTL generation at the least. Ideally we'd >>> even expose complex modes all the way to final. Is that something >>> y'all could benefit from as well? Have y'all poked at this problem at = all? >> Since you are going to need to "recover" complex operations from people >> open-coding them (both fortran and C and also C++ with std::complex) it >> should be less work to just do that ;) I think that complex modes and t= ypes >> exist solely for ABI purposes. > I don't see any reasonable way to do that.=C2=A0 Without going into all t= he=20 > details, our complex ops work on low elements within a vector=20 > register.=C2=A0=C2=A0 Trying to recover them after gimple->rtl expansion = would be=20 > similar to trying to SLP vectorize on RTL, something I'm not keen to chas= e. > > It would be a hell of a lot easier to leave the complex ops as complex=20 > ops to the expanders, then make the decision to use the complex=20 > instructions or decompose into components. Realise you might not be in a position to answer this for confidentiality reasons, but: would normal tree SLP not help here? We already try to recognise complex add & multiply, and in principle we could do the same for other operations as well. It shouldn't matter that a vector multiply on 2 elements is really just a single-data operation. Thanks, Richard