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 2E5D33858CDB for ; Fri, 31 Mar 2023 12:13:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E5D33858CDB 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 296692F4; Fri, 31 Mar 2023 05:14:37 -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 556723F73F; Fri, 31 Mar 2023 05:13:52 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2 1/2] combine: Split code out of make_compound_operation_int References: <20230331110645.GU25951@gate.crashing.org> Date: Fri, 31 Mar 2023 13:13:51 +0100 In-Reply-To: <20230331110645.GU25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 31 Mar 2023 06:06:45 -0500") 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=-25.6 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: Segher Boessenkool writes: > Hi! > > On Thu, Mar 09, 2023 at 12:09:59PM +0000, Richard Sandiford wrote: >> This patch just splits some code out of make_compound_operation_int >> into a new function called make_compound_operation_and. It is a >> prerequisite for the fix for PR106594. >> >> It might (or might not) make sense to put more of the existing >> "and" handling into the new function, so that the subreg+lshiftrt >> case can be handled through recursion rather than duplication. >> But that's certainly not necessary to fix the bug, so is at >> best stage 1 material. >> >> No behavioural change intended. > > That doesn't sound as if you are very sure about things. I'll just > pretend it says "no functional changes" :-) Heh. Stock phrase borrowed from LLVM. I'm not going to sign off with "this patch contains no bugs". :-) > (*Is* this a pure refactoring?) Yeah, this patch is a pure refactoring. It's the follow-on 2/2 part that does something useful. Thanks, Richard