From patchwork Fri Dec 6 19:02:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 298201 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9EBD02C00A8 for ; Sat, 7 Dec 2013 06:03:17 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=bssXgSD0OnPVubwOdv95bxbmbTcR1U6HHLbQjlJT22zs4guE/X4W3 XGMpCHbEyjl1ebGLOqhh9u6z2RG1LQI6Jwou+oPnseVH7euHkWiAPSsrVo86OgOl ivzQxyOj4nWr6wZNOeRXzkF3mnOey//5xU9j42/aWSD6kUtodgooMM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=oemAVt4oAA9vLKKSp8YEdFm1zjw=; b=F1lPEuT8RZ/jfIx7Xg5p8/PeRV0Z K1Egky+hgRp9GmevU4JfeE1h+1pJq0jPQfjP97dPOad5PKOHNVZ1ZCu3nWdH4H5F fGG9SO5MUNU+zB4jFTmMdd0oOXA+M/+1y5YksH/iPjWitQV/mtZovtHkuHMSKwc5 q3skJBsI21nMWIo= Received: (qmail 10193 invoked by alias); 6 Dec 2013 19:03:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 10183 invoked by uid 89); 6 Dec 2013 19:03:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2013 19:03:07 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6J2xAd016929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 14:02:59 -0500 Received: from Mair-2.local (vpn-59-205.rdu2.redhat.com [10.10.59.205]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB6J2wmp020938; Fri, 6 Dec 2013 14:02:58 -0500 Message-ID: <52A21F61.5080308@redhat.com> Date: Fri, 06 Dec 2013 14:02:57 -0500 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Meissner , GCC Patches , David Edelsohn , Alan Modra , Peter Bergner Subject: Re: RFA: patch to fix 2 testsuite failures for LRA on PPC References: <52A0BA81.2030108@redhat.com> <20131206162845.GA14285@ibm-tiger.the-meissners.org> <52A209AA.7070409@redhat.com> In-Reply-To: <52A209AA.7070409@redhat.com> X-IsSubscribed: yes On 12/6/2013, 12:30 PM, Vladimir Makarov wrote: > On 12/6/2013, 11:28 AM, Michael Meissner wrote: >> On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote: >>> The following patch fixes two GCC testsuite failures for LRA. The >>> patch makes swap through registers instead of memory for the test >>> cases when LRA is used. >>> >>> There are differences in reload and LRA constraint matching >>> algorithm which results in different alternative choices when the >>> original pattern is used. >>> >>> Actually my first proposed solution variant used one pattern which >>> is now for LRA in this patch. But some doubt arose that it may >>> affect reload pass in some bad way. >>> >>> Ok to commit? >> >> I must admit to not remembering why I used ??&r. I know I wanted it >> to prefer >> doing the memory patterns. I would think we should try just the pattern >> without the ??. >> > > I tried it about 2 months ago. I did not see any problems of such > change for reload and LRA. There were no regressions on GCC testsuite. > > So, Mike, if you don't see any compelling reason to keep ??, probably > we should remove them. > > If you don't mind, I'll make the patch and test again and after that > submit it for approval. > Here is the patch. Tested and bootstrapped on gcc110.fsffrance.org. Ok to commit? 2013-12-05 Vladimir Makarov * config/rs6000/rs600.md (*bswapdi2_64bit): Remove ?? from the constraint. Index: config/rs6000/rs6000.md =================================================================== --- config/rs6000/rs6000.md (revision 205753) +++ config/rs6000/rs6000.md (working copy) @@ -2379,7 +2379,7 @@ ;; Non-power7/cell, fall back to use lwbrx/stwbrx (define_insn "*bswapdi2_64bit" - [(set (match_operand:DI 0 "reg_or_mem_operand" "=&r,Z,??&r") + [(set (match_operand:DI 0 "reg_or_mem_operand" "=&r,Z,&r") (bswap:DI (match_operand:DI 1 "reg_or_mem_operand" "Z,r,r"))) (clobber (match_scratch:DI 2 "=&b,&b,&r")) (clobber (match_scratch:DI 3 "=&r,&r,&r"))