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 CB7AA383B782 for ; Tue, 31 May 2022 23:57:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB7AA383B782 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 24VNu1xF003579; Tue, 31 May 2022 18:56:01 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 24VNu0Et003576; Tue, 31 May 2022 18:56:00 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 31 May 2022 18:56:00 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: HAO CHEN GUI , David , Peter Bergner , gcc-patches Subject: Re: [PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736] Message-ID: <20220531235600.GU25951@gate.crashing.org> References: <41da7001-549d-c7ae-fa6b-534a8faf673e@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.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, 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: Tue, 31 May 2022 23:57:03 -0000 Hi! On Mon, May 30, 2022 at 06:12:26PM +0800, Kewen.Lin wrote: > on 2022/5/26 15:35, HAO CHEN GUI wrote: > > This patch fixes the ICE reported in PR100736. It removes the condition > > check of finite math only flag not setting in "*_cc" pattern. > > With or without this flag, we still can use "cror" to check if either > > two bits of CC is set or not for "fp_two" codes. We don't need a reverse > > comparison (implemented by crnot) here when the finite math flag is set, > > as the latency of "cror" and "crnor" are the same. > > --- a/gcc/config/rs6000/rs6000.md > > +++ b/gcc/config/rs6000/rs6000.md > > @@ -12995,9 +12995,9 @@ (define_insn_and_split "*_cc" > > [(set (match_operand:GPR 0 "gpc_reg_operand" "=r") > > (fp_two:GPR (match_operand:CCFP 1 "cc_reg_operand" "y") > > (const_int 0)))] > > - "!flag_finite_math_only" > > + "" > > "#" > > - "&& 1" > > + "" > > Segher added this hunk, not sure if he prefer to keep the condition unchanged > and update the expansion side, looking forward to his comments. :) It's not clear to me how this can ever happen without finite_math_only? The patch is safe, sure, but it may the real problem is elsewhere. > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/powerpc/pr100736.c > > @@ -0,0 +1,12 @@ > > +/* { dg-do compile } */ > > +/* { dg-require-effective-target powerpc_p8vector_ok } */ > > +/* { dg-options "-mdejagnu-cpu=power8 -O2 -ffinite-math-only" } */ The usual flag to use would be -ffast-math :-) > > +/* { dg-final { scan-assembler {\mcror\M} } } */ > > The case of PR100736 fails with ICE as reported, maybe we can remove this dg-final check, > since as you noted in the description above either "cror" or "crnor" are acceptable, > this extra check could probably make this case fragile. Check for \mcrn?or\M then? But, is crnor something we want here ever? The reason we do not have cror for finte-math-only is that comparisons can only (validly :-) ) return LT, GT, or EQ then, and we can branch on that without twiddling CRF bits first. Is this not true for BCD compares, is that what the problem is? Or, is our builtin expansion returning something invalid? Or something else :-) Segher