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 6C33C385DC13 for ; Tue, 26 Sep 2023 16:24:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C33C385DC13 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 291031FB; Tue, 26 Sep 2023 09:25:27 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 626853F6C4; Tue, 26 Sep 2023 09:24:48 -0700 (PDT) From: Richard Sandiford To: Robin Dapp via Gcc-patches Mail-Followup-To: Robin Dapp via Gcc-patches ,Jeff Law , Robin Dapp , richard.sandiford@arm.com Cc: Jeff Law , Robin Dapp Subject: Re: [PATCH] fwprop: Allow UNARY_P and check register pressure. References: <5a90c8a9-1570-5af4-bfdc-19d097bfee6e@gmail.com> <9acc1a24-5d01-40ad-b4b2-5948585d3e8c@gmail.com> <48bed106-190e-ab5f-4099-fdfd4f5a193f@gmail.com> <77daf152-e1fe-4980-8297-d37901d925e8@gmail.com> <3f2b6571-4c47-3ea5-2932-4060e45a94ea@gmail.com> Date: Tue, 26 Sep 2023 17:24:47 +0100 In-Reply-To: <3f2b6571-4c47-3ea5-2932-4060e45a94ea@gmail.com> (Robin Dapp via Gcc-patches's message of "Thu, 7 Sep 2023 16:25:45 +0200") 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=-18.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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: Robin Dapp via Gcc-patches writes: > Thanks for looking at it in detail. > >> Yeah, I think this is potentially a blocker for propagating A into B >> when A is used elsewhere. Combine is able to combine A and B while >> keeping A in parallel with the result. I think either fwprop would >> need to try that too, or it would need to be restricted to cases where A >> is only used in B. > > That seems a rather severe limitation and my original use case would > not get optimized considerably anymore. The intention was to replace > all uses (if register pressure allows). Of course the example is simple > enough that a propagation is always useful if the costs allow it, so > it might not be representative. > > I'm wondering if we could (my original misunderstanding) tentatively > try to propagate into all uses of a definition and, when reaching > a certain ratio, decide that it might be worth it, otherwise revert. > Would be very crude though, and not driven by the actual problem we're > trying to avoid. > >> I think the summary is: >> >> IMO, we have to be mindful that combine is still to run. We need to >> avoid making equal-cost changes if the new form is more complex, or >> otherwise likely to interfere with combine. > > I guess we don't have a good measure for complexity or "combinability" > and even lower-cost changes could result in worse options later. > Would it make sense to have a strict less-than cost policy for those > more complex propagations? Or do you consider the approach in its > current shape "hopeless", given the complications we discussed? > >> Alternatively, we could delay the optimisation until after combine >> and have freer rein, since we're then just mopping up opportunities >> that other passes left behind. >> >> A while back I was experimenting with a second combine pass. That was >> the original motiviation for rtl-ssa. I never got chance to finish it >> off though. > > This doesn't sound like something that would still materialize before > the end of stage 1 :) > Do you see any way of restricting the current approach to make it less > intrusive and still worthwhile? Limiting to vec_duplicate might be > much too arbitrary but would still help for my original example. FWIW, I sent an RFC for a late-combine pass that might help: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631406.html I think it'll need some tweaking for your use case, but hopefully it's "just" a case of expanding the register pressure tests. Thanks, Richard