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 E32243858C53 for ; Sat, 7 Oct 2023 12:58:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E32243858C53 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 2F607C15; Sat, 7 Oct 2023 05:58:59 -0700 (PDT) Received: from localhost (unknown [10.32.110.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EDFDE3F762; Sat, 7 Oct 2023 05:58:18 -0700 (PDT) From: Richard Sandiford To: Robin Dapp Mail-Followup-To: Robin Dapp ,gcc-patches@gcc.gnu.org, Jeff Law , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Jeff Law Subject: Re: [PATCH] RFC: Add late-combine pass [PR106594] References: Date: Sat, 07 Oct 2023 13:58:17 +0100 In-Reply-To: (Robin Dapp's message of "Mon, 2 Oct 2023 17:18:06 +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.4 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: Robin Dapp writes: > Hi Richard, > > cool, thanks. I just gave it a try with my test cases and it does what > it is supposed to do, at least if I disable the register pressure check :) > A cursory look over the test suite showed no major regressions and just > some overly specific tests. > > My test case only works before split, though, as the UNSPEC predicates will > prevent further combination afterwards. > > Right now the (pre-RA) code combines every instance disregarding the actual > pressure and just checking if the "new" value does not occupy more registers > than the old one. > > - Shouldn't the "pressure" also depend on the number of available hard regs > (i.e. an nregs = 2 is not necessarily worse than nregs = 1 if we have 32 > hard regs in the new class vs 16 in the old one)? Right, that's what I meant by extending/tweaking the pressure heuristics for your case. > - I assume/hope you expected my (now obsolete) fwprop change could be re-used? Yeah, I was hoping you'd be able to apply similar heuristics to the new pass. (I didn't find time to look at the old heuristics in detail, though, sorry.) I suppose the point of comparison would then be "new pass with current heuristics" vs. "new pass with relaxed heuristics". It'd be a good/interesting test of the new heuristics to apply them without any constraint on the complexity of the SET_SRC. > Otherwise we wouldn't want to unconditionally "propagate" into a loop for example? > For my test case the combination of the vec_duplicate into all insns leads > to "high" register pressure that we could avoid. > > How should we continue here? I suppose you'll first want to get this version > to the trunk before complicating it further. Yeah, that'd probably be best. I need to split the patch up into a proper submission sequence, do more testing, and make it RFA quality. Jeff has also found a couple of regressions that I need to look at. But the substance probably won't change much, so I don't think you'd be wasting your time if you developed the heuristics based on the current version. I'd be happy to review them on that basis too (though time is short at the moment). Thanks, Richard