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 E420A3959E49 for ; Wed, 16 Nov 2022 12:14:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E420A3959E49 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 2AGCD1xp028462; Wed, 16 Nov 2022 06:13:01 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2AGCD0dD028461; Wed, 16 Nov 2022 06:13:00 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 16 Nov 2022 06:13:00 -0600 From: Segher Boessenkool To: David Edelsohn Cc: HAO CHEN GUI , gcc-patches , "Kewen.Lin" , Peter Bergner Subject: Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000 Message-ID: <20221116121300.GV25951@gate.crashing.org> References: <153badc6-8afc-0695-32b2-ab5a9e0a161d@linux.ibm.com> <20221116120619.GU25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221116120619.GU25951@gate.crashing.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,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: On Wed, Nov 16, 2022 at 06:06:19AM -0600, Segher Boessenkool wrote: > Hi guys, > > On Tue, Nov 15, 2022 at 10:04:04PM -0500, David Edelsohn wrote: > > On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI wrote: > > > The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to > > > indicate if branch by CC bits is invalid or not. As rs6000 already has > > > "*cbranch" insn which does branching according to CC bits, the flag > > > should be enabled and relevant branches can be optimized out. The test > > > case illustrates the optimization. > > cbranch4 normally compares the mode operands 2 and 3, and > jumps to operands[0] if operands[1] (a relation of operands 2 and 3) is > true. See emit_cmp_and_jump_insns for example. But cbranchcc4 does > not do any comparison; instead, it branches based on the result of a > previous comparison, stored in operands[2], and operands[3] has to be > const_int 0. Apparently the operand order is different? Where is that documented at all anyway? Grr. Please adjust my comments to taste :-/ Segher