From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46574 invoked by alias); 17 Sep 2015 17:01:45 -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 46561 invoked by uid 89); 17 Sep 2015 17:01:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Sep 2015 17:01:39 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id E9DF58E690; Thu, 17 Sep 2015 17:01:37 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HH1bhr014391; Thu, 17 Sep 2015 13:01:37 -0400 Subject: Re: [RFC][PATCH] Preferred rename register in regrename pass To: Robert Suchanek , "gcc-patches@gcc.gnu.org" References: From: Jeff Law Message-ID: <55FAF1F1.3070607@redhat.com> Date: Thu, 17 Sep 2015 17:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01318.txt.bz2 On 09/17/2015 08:38 AM, Robert Suchanek wrote: > Hi, > > We came across a situation for MIPS64 where moves for sign-extension were > not converted into a nop because of IRA spilled some of the allocnos and > assigned different hard register for the output operand in the move. > LRA is not fixing this up as most likely the move was not introduced by > the LRA itself. I found it hard to fix this in LRA and looked at > an alternative solution where regrename pass appeared to be the best candidate. Yea, we've never been great at tying the source & destination of sign/zero extensions. The inherently different modes often caused the old allocator (and pre-allocator bits like regmove, and post-allocator bits like reload) to 'give up'. > > I'm not sure if this is something that should be enabled by default for everyone > or a target hook should be added. Any other comments/suggestions? I'll let Bernd comment on the patch itself. But I would say that if you're setting up cases where we can tie the source/dest of an extension together, then it's a good thing. It'll cause more of them to turn into NOPs and it'll make the redundant extension elimination pass more effective as well. This would be something that I'd expect to benefit most architectures (obviously to varying degrees). Jeff