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 7A99B3858288 for ; Thu, 7 Dec 2023 12:20:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A99B3858288 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7A99B3858288 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701951659; cv=none; b=FuxiARC6hP5Ijc1Qr04jlYcFRuR8B215IwtXVVvtJuboNAAn/eLwLY7UE9sRAeEMGF4bTw8QImre4cAkgjBALCToiroguU97DdjFudcgwZAqTM8UpFfk9l770UuUewy5+6WN4G9iiCjgYn9v/UBf92S+eJiSDsm5PajMRKl0Flg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701951659; c=relaxed/simple; bh=xjBuBAHixx09HmQkGKPjJ0LIYB47TgLyWKdhV6cP0Fo=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=fc1bhFJgAe+U/tu3ZGXesoLvzPltpS6SerLZi0Af6zMa7bUFdJgeRdZz4Hua9HXMMk35mgI5AxQy0a5/jGiPaexqKzZt+YFfwhLbB1T+BEDEQDx15kwqDOrHThSfA4Ko2wkvcd3Qnd11txZvSn/GO2I/JrMek2VqMl94izxPXmo= ARC-Authentication-Results: i=1; server2.sourceware.org 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 0E759139F; Thu, 7 Dec 2023 04:21:41 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 43E463F6C4; Thu, 7 Dec 2023 04:20:54 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Philipp Tomsich , Manos Anagnostakis , gcc-patches@gcc.gnu.org, Manolis Tsamis , richard.sandiford@arm.com Cc: Philipp Tomsich , Manos Anagnostakis , gcc-patches@gcc.gnu.org, Manolis Tsamis Subject: Re: [PATCH v6] aarch64: New RTL optimization pass avoid-store-forwarding. References: <20231206134653.29261-1-manos.anagnostakis@vrull.eu> Date: Thu, 07 Dec 2023 12:20:53 +0000 In-Reply-To: (Richard Biener's message of "Thu, 7 Dec 2023 08:31:36 +0100") 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=-16.0 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 List-Id: Richard Biener writes: > On Wed, Dec 6, 2023 at 7:44=E2=80=AFPM Philipp Tomsich wrote: >> >> On Wed, 6 Dec 2023 at 23:32, Richard Biener = wrote: >> > >> > On Wed, Dec 6, 2023 at 2:48=E2=80=AFPM Manos Anagnostakis >> > wrote: >> > > >> > > This is an RTL pass that detects store forwarding from stores to lar= ger loads (load pairs). >> > > >> > > This optimization is SPEC2017-driven and was found to be beneficial = for some benchmarks, >> > > through testing on ampere1/ampere1a machines. >> > > >> > > For example, it can transform cases like >> > > >> > > str d5, [sp, #320] >> > > fmul d5, d31, d29 >> > > ldp d31, d17, [sp, #312] # Large load from small store >> > > >> > > to >> > > >> > > str d5, [sp, #320] >> > > fmul d5, d31, d29 >> > > ldr d31, [sp, #312] >> > > ldr d17, [sp, #320] >> > > >> > > Currently, the pass is disabled by default on all architectures and = enabled by a target-specific option. >> > > >> > > If deemed beneficial enough for a default, it will be enabled on amp= ere1/ampere1a, >> > > or other architectures as well, without needing to be turned on by t= his option. >> > >> > What is aarch64-specific about the pass? >> > >> > I see an increasingly large number of target specific passes pop up (p= robably >> > for the excuse we can generalize them if necessary). But GCC isn't LL= VM >> > and this feels like getting out of hand? >> >> We had an OK from Richard Sandiford on the earlier (v5) version with >> v6 just fixing an obvious bug... so I was about to merge this earlier >> just when you commented. >> >> Given that this had months of test exposure on our end, I would prefer >> to move this forward for GCC14 in its current form. >> The project of replacing architecture-specific store-forwarding passes >> with a generalized infrastructure could then be addressed in the GCC15 >> timeframe (or beyond)? > > It's up to target maintainers, I just picked this pass (randomly) to make= this > comment (of course also knowing that STLF fails are a common issue on > pipelined uarchs). I agree there's scope for making some of this target-independent. One vague thing I've been wondering about is whether, for some passes like these, we should use inheritance rather than target hooks. So in this case, the target-independent code would provide a framework for iterating over the function and testing for forwarding, but the target would ultimately decide what to do with that information. This would also make it easier for targets to add genuinely target-specific information to the bookkeeping structures. In case it sounds otherwise, that's supposed to be more than just a structural C++-vs-C thing. The idea is that we'd have a pass for "resolving store forwarding-related problems", but the specific goals would be mostly (or at least partially) target-specific rather than target-independent. I'd wondered the same thing about the early-ra pass that we're adding for SME. Some of the framework could be generalised and made target-independent, but the main purpose of the pass (using strided registers with certain patterns and constraints) is highly target-specific. Thanks, Richard