From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37399 invoked by alias); 3 Aug 2018 16:26:47 -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 36674 invoked by uid 89); 3 Aug 2018 16:26:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=tip, H*r:0700 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Aug 2018 16:26:45 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1flcuY-0005Pu-GM from Sandra_Loosemore@mentor.com ; Fri, 03 Aug 2018 09:26:42 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 3 Aug 2018 09:26:39 -0700 Subject: Re: [2/5] C-SKY port: Backend implementation To: Jeff Law , =?UTF-8?B?556/5LuZ5re8?= CC: "gcc-patches@gcc.gnu.org" , Yunhai Shang References: <49d0a2c8-51a0-4a74-d015-0bf1c1098e38@codesourcery.com> <28cb3a6e-4594-3545-5236-c68784af6a57@codesourcery.com> <8a1b9bac-82dc-bb4f-e0a2-9a9b9cbea98a@redhat.com> <56004587-F43E-4004-B618-B819CF7A5E4A@c-sky.com> <1632a78d-4244-fe7b-91ae-ffdd1dd8cf60@redhat.com> From: Sandra Loosemore Message-ID: Date: Fri, 03 Aug 2018 16:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1632a78d-4244-fe7b-91ae-ffdd1dd8cf60@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00294.txt.bz2 On 08/02/2018 04:27 PM, Jeff Law wrote: > I think the cse_cc pass is really just working around one or more bugs > in CSE and/or a backend bug. The RTL above clearly shows a common > subexpression that is not eliminated by CSE. > > What CSE should be trying to do is changing the second and third > occurrences of (gt:CC (reg 77) (reg 78)) with (reg 33) which would > create nop-sets which would be subsequently deleted. I suspect you do > not have an insn which matches that nop set of the CC register. If you > fix that I suspect CSE will work better and eliminate the need for your > cse_cc pass. Thanks for the tip about that! I hacked things up to do as you suggest and it appears to work. I'll post a new patch set once I've had time for more testing, probably Monday-ish. -Sandra