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 6760A3858C66 for ; Tue, 22 Nov 2022 10:36:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6760A3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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 4940D1FB; Tue, 22 Nov 2022 02:36:49 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0647F3F587; Tue, 22 Nov 2022 02:36:41 -0800 (PST) From: Richard Sandiford To: Tamar Christina via Gcc-patches Mail-Followup-To: Tamar Christina via Gcc-patches ,Richard Biener , Tamar Christina , Richard Biener , nd , richard.sandiford@arm.com Cc: Richard Biener , Tamar Christina , Richard Biener , nd Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions from bitfields and array_refs References: Date: Tue, 22 Nov 2022 10:36:40 +0000 In-Reply-To: (Tamar Christina via Gcc-patches's message of "Mon, 7 Nov 2022 11:56:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-34.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tamar Christina via Gcc-patches writes: >> So it's not easily possible the within current infrastructure. But it does look >> like ARM might eventually benefit from something like STV on x86? >> > > I'm not sure. The problem with trying to do this in RTL is that you'd have to be > able to decide from two psuedos whether they come from extracts that are > sequential. When coming in from a hard register that's easy yes. When coming in > from a load, or any other operation that produces psuedos that becomes harder. Yeah. Just in case anyone reading the above is tempted to implement STV for AArch64: I think it would set a bad precedent if we had a paste-&-adjust version of the x86 pass. AFAIK, the target capabilities and constraints are mostly modelled correctly using existing mechanisms, so I don't think there's anything particularly target-specific about the process of forcing things to be on the general or SIMD/FP side. So if we did have an STV-ish thing for AArch64, I think it should be a target-independent pass that uses hooks and recog, even if the pass is initially enabled for AArch64 only. (FWIW, on the patch itself, I tend to agree that this is really an SLP optimisation. If the vectoriser fails to see the benefit, or if it fails to handle more complex cases, then it would be good to try to fix that.) Thanks, Richard