From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102995 invoked by alias); 2 Apr 2015 23:41:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 102985 invoked by uid 89); 2 Apr 2015 23:41:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: e33.co.us.ibm.com Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 02 Apr 2015 23:41:48 +0000 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 2 Apr 2015 17:41:45 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 2 Apr 2015 17:41:44 -0600 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 349083E4003B for ; Thu, 2 Apr 2015 17:41:44 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t32NflZ948693494 for ; Thu, 2 Apr 2015 16:41:48 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t32NfhK1017550 for ; Thu, 2 Apr 2015 17:41:43 -0600 Received: from ibm-tiger.the-meissners.org (dhcp-9-32-77-111.usma.ibm.com [9.32.77.111]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t32NfhFu017537; Thu, 2 Apr 2015 17:41:43 -0600 Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id ECA0545F1B; Thu, 2 Apr 2015 19:41:42 -0400 (EDT) Date: Thu, 02 Apr 2015 23:41:00 -0000 From: Michael Meissner To: gcc-patches@gcc.gnu.org, David Edelsohn , Michael Meissner Subject: Re: [RS6000] Fix 65576 regression Message-ID: <20150402234142.GA31174@ibm-tiger.the-meissners.org> Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Michael Meissner References: <20150402052235.GU26234@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150402052235.GU26234@bubble.grove.modra.org> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15040223-0009-0000-0000-000009DAF7BD X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00098.txt.bz2 On Thu, Apr 02, 2015 at 03:52:35PM +1030, Alan Modra wrote: > This cures an unrecognizable insn ICE by modifying a predicate of > extenddftf2_internal (the only place this predicate is used) to ensure > that rtl optimization passes do not substitute 0.0 for a register with > known 0.0 value, except when VSX is enabled. ie. Don't undo the > necessary register move emitted by the extenddftf2_fprs expander. > Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux > and powerpc-linux. OK to apply? > > PR target/65576 > PR target/65240 > * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude > 0.0 constant unless TARGET_VSX. > > Index: gcc/config/rs6000/predicates.md > =================================================================== > --- gcc/config/rs6000/predicates.md (revision 221805) > +++ gcc/config/rs6000/predicates.md (working copy) > @@ -964,7 +964,8 @@ > > ;; Return 1 if the operand is CONST_DOUBLE 0, register or memory operand. > (define_predicate "zero_reg_mem_operand" > - (ior (match_operand 0 "zero_fp_constant") > + (ior (and (match_test "TARGET_VSX") > + (match_operand 0 "zero_fp_constant")) > (match_operand 0 "reg_or_mem_operand"))) > > ;; Return 1 if the operand is a CONST_INT and it is the element for 64-bit > I definately prefer Alan's patch over mine. In looking at extenddftf2_internal, I believe you are correct David, in that final alternative will never match because 0.0 will not be valid (pre-VSX 0.0 won't be allowed as operand2, VSX 0.0 will not match "n" constraint). For the VSX case, the "n" should be either "j" or "E". If you are doing a double->long double conversion, and it happens to pick GPRs for some reason, the GPR side will do a load/move of 0.0 instead of using li to load 0 on pre-VSX systems. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797