From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39382 invoked by alias); 9 Sep 2016 22:40:29 -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 39364 invoked by uid 89); 9 Sep 2016 22:40:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=LIVE, overly, optimistic, 2016-08-29 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; Fri, 09 Sep 2016 22:40:18 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 DCD598553F; Fri, 9 Sep 2016 22:40:15 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u89MeCUW022846; Fri, 9 Sep 2016 18:40:12 -0400 Subject: Re: [PATCH] df: Keep return address register undefined until epilogue_completed To: Segher Boessenkool , gcc-patches@gcc.gnu.org References: Cc: bonzini@gnu.org, seongbae.park@gmail.com, zadeck@naturalbridge.com From: Jeff Law Message-ID: <4b577e76-bcb7-9fd2-e77f-41a6358b7e4c@redhat.com> Date: Fri, 09 Sep 2016 22:42: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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00558.txt.bz2 On 08/29/2016 10:50 AM, Segher Boessenkool wrote: > For separate shrink-wrapping we need to find out which basic blocks > need what components set up by a prologue, so that we can move those > prologue pieces deeper into the function, so that those pieces are > executed less frequently, improving performance. > > To do this, target code will normally look at the LIVE info: a block > needs a register set up if that register is in the IN, GEN, or KILL > sets. This works fine for the callee-saved registers, since those > are not in entry_block_defs, but it does not work for the rs6000 link > register, because df_get_entry_block_def_set unconditinally adds the > register that is INCOMING_RETURN_ADDR_RTX (if it is a register). > > This patch changes that so that that def is only added after > epilogue_completed. > > With that, in the rs6000 backend we can use the same IN+GEN+KILL > condition to see whether LR is used (in the current patch set, only > KILL is used, which isn't correct; the backend can write to LR to > temporarily hold other values; a crazy idea, on modern hardware anyway, > but it does regardless). > > Does this work on all other targets? Should anything else be done? > > > Segher > > > 2016-08-29 Segher Boessenkool > > * df-scan.c (df_get_entry_block_def_set): Do not add the > INCOMING_RETURN_ADDR_RTX register until epilogue_completed. Right now the dataflow is conservatively correct WRT the return register. If we made the change you want to make than the dataflow becomes overly optimistic about the range over which the return register is live prior to inserting the prologue/epilogue into the insn chain. This seems unsafe to me. jeff