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 F345B3858C30 for ; Mon, 28 Nov 2022 17:57:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F345B3858C30 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 2ASHuVfH027975; Mon, 28 Nov 2022 11:56:31 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2ASHuUng027974; Mon, 28 Nov 2022 11:56:30 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Nov 2022 11:56:30 -0600 From: Segher Boessenkool To: Richard Biener Cc: HAO CHEN GUI , gcc-patches , David , Peter Bergner , "Kewen.Lin" Subject: Re: Ping [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn Message-ID: <20221128175629.GO25951@gate.crashing.org> References: <4a052a62-7861-ed6f-9801-3b58ac384f81@linux.ibm.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.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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 Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote: > Since the function seems to be allowed to fail the patch looks > reasonable - still I wonder > what the "fallback" for a MODE_CC style compare-and-branch is? There > are callers > of this function that do not seem to expect failure at least, some > suspiciously looking > like MODE_CC candiates. Hi! cbranchcc4 is *not* a compare-and-branch, like ccbranch4 for other modes are. Instead, it is a conditional branch. I still think it is a bad idea to use this same pattern name for a completely different (and much more basic) concept, it just confuses many things, makes us need exceptions in most users of cbranch4 :-( cbranchcc4 does not do a comparison. Instead, it uses the result of some previous comparison in some CC register (or anything else that set such a register). We want to use a cbranchcc4 to reuse some earlier comparison here. Which is great of course! But, redoing the (potentially expensive) computation to prepare the CC for a more complicated condition is not a good idea. Also, Power's conditional branch insns just branch on one of the 32 condition bits (either set or unset), not on a logical combination of multiple of those bits, as we need with LTGT, UNLT, UNGT, UNEQ, and LE and GE without fastmath. So it is much cleaner (and causes fewer problems later on) if we only allow those codes we do support. Example of LTGT: fcmpu 0,0,1 # compare f0 <=> f1 to cr0 (exactly one of # cr0.lt, cr0.gt, cr0.eq, cr0.un will be set) cror 2,0,1 # cr0.eq = cr0.lt | cr0.gt beq 0 # branch if cr0.eq is set So, we want the cbranchcc4 here to just do that last insn, not the last two insns (or all three as any other cbranch4 is!) Segher