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 CF4E83AAAC81 for ; Fri, 13 Mar 2020 10:29:10 +0000 (GMT) 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 84F7930E; Fri, 13 Mar 2020 03:29:10 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E99573F534; Fri, 13 Mar 2020 03:29:09 -0700 (PDT) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law , Segher Boessenkool , gcc-patches List , richard.sandiford@arm.com Cc: Segher Boessenkool , gcc-patches List Subject: Re: [RFA] [PR rtl-optimization/90275] Handle nop reg->reg copies in cse References: <10930ad518483e1d3d4fea149045802313cac45e.camel@redhat.com> <20200206135649.GZ22482@gate.crashing.org> <2a46a1ab3d68ce31d109ef9aedcc40e991498936.camel@redhat.com> <20200208164128.GZ22482@gate.crashing.org> <20200312182357.GI22482@gate.crashing.org> <6450d3fd3267fe014142323a147696503b336857.camel@redhat.com> <20200312202654.GK22482@gate.crashing.org> Date: Fri, 13 Mar 2020 10:29:08 +0000 In-Reply-To: (Jeff Law's message of "Thu, 12 Mar 2020 14:56:55 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 10:29:11 -0000 Jeff, thanks for picking this up. Jeff Law writes: > On Thu, 2020-03-12 at 15:26 -0500, Segher Boessenkool wrote: >> On Thu, Mar 12, 2020 at 12:47:04PM -0600, Jeff Law wrote: >> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote: >> > > > else if (n_sets == 1 >> > > > - && MEM_P (trial) >> > > > + && ! CALL_P (insn) >> > > > + && (MEM_P (trial) || REG_P (trial)) >> > > > && MEM_P (dest) >> > > > && rtx_equal_p (trial, dest) >> > > > && !side_effects_p (dest) >> > > >> > > This adds the !CALL_P (no space btw) condition, why is that? >> > Because n_sets is not valid for CALL_P insns which resulted in a failure on >> > ppc. >> > See find_sets_in_insn which ignores the set on the LHS of a call. So imagine >> > if >> > we had a nop register set in parallel with a (set (reg) (call ...)). We'd >> > end up >> > deleting the entire PARALLEL which is obviously wrong. >> >> Ah, I see. So this is exposed on Power by the TOC stuff, I guess? CSE >> sees a TOC set parallel with a call as a no-op because it is set to the >> same value (an unspec, not an unspec_volatile) that GCC can derive is >> already in the TOC reg? Or is this some other case? > Not entirely sure. Richard's message didn't include the precise details. Yeah, that was exactly it. On the bright side, removing many calls as dead made for an easy-to-debug bootstrap failure :-) Richard