From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65410 invoked by alias); 14 Sep 2016 19:33:07 -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 65397 invoked by uid 89); 14 Sep 2016 19:33:07 -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= 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; Wed, 14 Sep 2016 19:33:06 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 C3456C04B331; Wed, 14 Sep 2016 19:33:04 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-109.phx2.redhat.com [10.3.116.109]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8EJX4Yd022715; Wed, 14 Sep 2016 15:33:04 -0400 Subject: Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped To: Segher Boessenkool References: <7e74a019-d477-348f-2dc6-744e1db38f2f@redhat.com> <20160909204107.GC21356@gate.crashing.org> <14ff3e40-4c2c-7e8b-b822-07ff3575b771@redhat.com> <20160910064052.GA7255@gate.crashing.org> <32231187-0fa2-815d-ab89-7e3d15b646d4@redhat.com> <20160914130458.GA4896@gate.crashing.org> <85cb1e59-f383-129e-bea7-e179f913c0c9@redhat.com> <20160914190353.GA22273@gate.crashing.org> Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com From: Jeff Law Message-ID: <92f35909-2f70-487a-5e24-d38bff9daa4b@redhat.com> Date: Wed, 14 Sep 2016 19:38: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: <20160914190353.GA22273@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/msg00885.txt.bz2 On 09/14/2016 01:03 PM, Segher Boessenkool wrote: >> If you think about it, conceptually we want the return insn to make the >> callee saved registers "used" so that DCE, regrename and friends don't >> muck with them. The fact that we don't is as much never having to care >> all that much until recently. > > (There is no return insn at those exits; these are exits *without* > successor block, not the exit block). Ugh. Anywhere we could attach this stuff in the insn chain? If not, the DF side of this problem gets uglier. > > It is puzzling to me why adding USEs for just the registers that *are* > separately shrink-wrapped does not work; only all those that *could* be > shrink-wrapped does. Do you have any idea about that? Nope. No clue on that one. It almost seems like a book-keeping error somewhere. > >> I continue to wonder if we could add something similar to >> CALL_INSN_FUNCTION_USAGE where we attach uses for all the call-saved >> registers onto a return insn. We would attach them at the end of >> prologue/epilogue generation and only attach those where were live >> somewhere in the code. > > Maybe adding the new insns to the {pro,epi}logue_insn_hash will help > something. Or maybe it will blow up spectacularly. Will know in a > bit. I think that'll resolve the sel-sched issue, but I doubt the rest. > >> I pondered just doing it for the separately wrapped components on that >> particular path, but I've yet to convince myself that's actually correct. > > If that is not correct, how is the status quo correct? That is what > puzzles me above, too. I couldn't convince myself that we could trivially find all the separately wrapped components on a particular path -- ie, we may have had components saved/restored in some sub-graph. If an exit point from the function is reachable from that sub-graph, then we need to make sure any components from the subgraph are marked as live in addition to those which are restored on the exit path. While it is just a reachability problem, I don't think we need to solve it if we mark anything that was separately shrink wrapped as live at all the exit points. > > There is a well-defined way to turn it off, via common/config/*/*-common.c , > TARGET_OPTION_OPTIMIZATION_TABLE. We disagree on whether most targets will > want it enabled, i.e. whether it should (eventually) be enabled by default. I'm aware of TARGET_OPTION_OPTIMIZATION_TABLE -- I was thinking more along the lines of trying to describe the conditions under which it is not profitable and expose that. TARGET_OPTION_OPTIMIZATION_TABLE is a lame way to attack this problem. Jeff