From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 131032 invoked by alias); 12 Sep 2016 16:59:09 -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 131021 invoked by uid 89); 12 Sep 2016 16:59:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=treats 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 ESMTP; Mon, 12 Sep 2016 16:58:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 55AAC9B0FD; Mon, 12 Sep 2016 16:58:57 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CGwu4G020159; Mon, 12 Sep 2016 12:58:57 -0400 Subject: Re: [PATCH 4/9] regrename: Don't rename restores To: Segher Boessenkool References: <3d1c2c877df1da0be9eca7cb1016e8b7a7d287c8.1470015604.git.segher@kernel.crashing.org> <20160909205953.GE21356@gate.crashing.org> Cc: gcc-patches@gcc.gnu.org, bschmidt@redhat.com From: Jeff Law Message-ID: <752685ea-507e-5437-908b-35d8800d340f@redhat.com> Date: Mon, 12 Sep 2016 17:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160909205953.GE21356@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00646.txt.bz2 On 09/09/2016 02:59 PM, Segher Boessenkool wrote: > On Thu, Sep 08, 2016 at 11:51:53AM -0600, Jeff Law wrote: >> On 07/31/2016 07:42 PM, Segher Boessenkool wrote: >>> A restore is supposed to restore some certain register. Restoring it >>> into some other register will not work. Don't. >>> >>> 2016-06-07 Segher Boessenkool >>> >>> * regrename.c (build_def_use): Invalidate chains that have a >>> REG_CFA_RESTORE on some instruction. >> Again, how is this different from a normal epilogue that restores >> registers which regrename seems to not muck with. > > Good question. Either way, it is always wrong to rename a register we > restore from stack. Agreed. Somehow register renaming does the right thing for a normal epilogue. I don't see anything in regrename that obviously treats the epilogue specially, there's check_new_reg_p, but I don't see that it inherently handles this case. regrename seems to use the DF infrastructure, so I wouldn't be surprised if this is a symptom of incorrect DF information for the epilogues. One way to potentially find out would be to tweak the DF code to mark all the callee saved regs as live at the return insns and see how that affects regrename's decision making. jeff