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 27EBF38344FF for ; Mon, 27 Jun 2022 15:04:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 27EBF38344FF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 25RF3qK3008671; Mon, 27 Jun 2022 10:03:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 25RF3qp9008670; Mon, 27 Jun 2022 10:03:52 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 27 Jun 2022 10:03:51 -0500 From: Segher Boessenkool To: Uros Bizjak Cc: Roger Sayle , "gcc-patches@gcc.gnu.org" Subject: Re: [x86 PATCH] PR rtl-optimization/96692: ((A|B)^C)^A using andn with -mbmi. Message-ID: <20220627150351.GZ25951@gate.crashing.org> References: <025701d88954$f281ca40$d7855ec0$@nextmovesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 27 Jun 2022 15:04:55 -0000 Hi! On Sun, Jun 26, 2022 at 07:07:35PM +0200, Uros Bizjak via Gcc-patches wrote: > On Sun, Jun 26, 2022 at 2:04 PM Roger Sayle wrote: > > I'll investigate whether this optimization can also be implemented > > more generically in simplify_rtx when the backend provides > > accurate rtx_costs for "(and (not ..." (as there's no optab for > > andn). "Accurate rtx_cost" is a fallacy. insn_cost can be seen as somewhat accurate (in some simplified model of reality), but rtx_cost always misses too much context to be useful as anything but a rough estimate. > *combine splitter is described in the documentation as the splitter > pattern that does *not* match any existing insn pattern. Yeah, that documentation is somewhat misleading, in both directions :-( combine can and will and does use any splitter, whether or not there is an insn with that insn pattern. If there is an insn that passes recog() combine will not even try a split, but this is not the same thing at all: if the insn conditions are not met, the insn does not recog(). It is quite common to have the same instruction pattern with different insn conditions. In the other direction, other passes can call split_insns as well, of course. Nothing currently does, but that does not change much :-) Segher