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 69BE93857C4D for ; Fri, 8 Apr 2022 17:32:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69BE93857C4D 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 238HV5pd017375; Fri, 8 Apr 2022 12:31:05 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 238HV5fJ017374; Fri, 8 Apr 2022 12:31:05 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 8 Apr 2022 12:31:05 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: Jakub Jelinek , Bill Schmidt , Peter Bergner , GCC Patches , David Edelsohn Subject: Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623] Message-ID: <20220408173105.GU614@gate.crashing.org> References: <20220407110952.GM614@gate.crashing.org> 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=-9.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 08 Apr 2022 17:32:07 -0000 On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote: > As Jakub noted here, we don't have the soft-float support for both m32 and m64 > before, as the bifs are always guarded under hard-float previously. But that bug was fixed for GCC 12. Or we thought so, at least :-( > >> What makes it ICE on (at least some configurations of) 32-bit now? Can > >> you exclude just 32-bit soft float? > > As clarified above, both 32-bit and 64-bit has the same root cause for the ICE, > the existing define_insn* supports for these bifs only consider hard-float, such > as for the given test case in the PR, it fails in reload as the recognized > unpacktf_nodm doesn't have any available alternatives at soft-float. eg: we only > have register constraint "d" for > (match_operand:FMOVE128 1 "register_operand" "d,d") > but it's only available for hard-float. For me it fails during combine: the unspec suddenly doesn't recog anymore. That might be that "d" thing yes, that is problematical. If you want to add "nosoft" now, please add a FIXME comment everywhere you do, so we do not forget to fix this for GCC 13. Or, try this patch? === diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index fdfbc6566a5c..f05b8358ba0a 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -14580,10 +14580,10 @@ (define_insn_and_split "unpack_dm" [(set_attr "type" "fp,fpstore,mtvsr,mfvsr,store")]) (define_insn_and_split "unpack_nodm" - [(set (match_operand: 0 "nonimmediate_operand" "=d,m") + [(set (match_operand: 0 "nonimmediate_operand" "=d,m,m") (unspec: - [(match_operand:FMOVE128 1 "register_operand" "d,d") - (match_operand:QI 2 "const_0_to_1_operand" "i,i")] + [(match_operand:FMOVE128 1 "register_operand" "d,d,r") + (match_operand:QI 2 "const_0_to_1_operand" "i,i,i")] UNSPEC_UNPACK_128BIT))] "(!TARGET_POWERPC64 || !TARGET_DIRECT_MOVE) && FLOAT128_2REG_P (mode)" "#" @@ -14600,7 +14600,7 @@ (define_insn_and_split "unpack_nodm" operands[3] = gen_rtx_REG (mode, fp_regno); } - [(set_attr "type" "fp,fpstore")]) + [(set_attr "type" "fp,fpstore,store")]) (define_insn_and_split "pack" [(set (match_operand:FMOVE128 0 "register_operand" "=&d") === Segher