From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id ABC46384400A for ; Thu, 22 Oct 2020 22:26:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABC46384400A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 09MMOdO2008963; Thu, 22 Oct 2020 17:24:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 09MMOcgu008962; Thu, 22 Oct 2020 17:24:38 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 22 Oct 2020 17:24:38 -0500 From: Segher Boessenkool To: Jeff Law Cc: Henri Cloetens , gcc-help Subject: Re: How to recognize registers after reload ?. Message-ID: <20201022222438.GX2672@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 22:26:30 -0000 On Thu, Oct 22, 2020 at 03:30:08PM -0600, Jeff Law via Gcc-help wrote: > On 10/22/20 2:02 AM, Henri Cloetens wrote: > > Motivation for the split was problems with the "combine" step. Suppose > > following code: > >     *a = 10. > >     Even if my front_end (define_expand) splits this in > >     r100 = 10 > >    *r101 = r100 > >    the combine step, if these is only one movesi_internal, willl group > > it again, to then find out > >    there is no instruction pattern. > > This is an indication the insn's condition or operand's predicate or > operand constraints are wrong. Yes, but I do not understand what Henri means at all. On one side, combine will try to combine any such pair, and then it does discover there is no insn for that, and then not do the combination. This is exactly what combine is supposed to do. On the other side, it could mean combine *does* allow the combo. Then, you *do* have a define_insn for it, or it would *not* allow it. And then some time later that is a problem? But that has nothing to do with combine, that just is a buggy machine description. (My money is on the predicate btw ;-) ) Segher