From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101650 invoked by alias); 11 Sep 2015 22:06:55 -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 101628 invoked by uid 89); 11 Sep 2015 22:06:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e39.co.us.ibm.com Received: from e39.co.us.ibm.com (HELO e39.co.us.ibm.com) (32.97.110.160) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 11 Sep 2015 22:06:52 +0000 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 11 Sep 2015 16:06:50 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 11 Sep 2015 16:06:49 -0600 X-MailFrom: pthaugen@linux.vnet.ibm.com X-RcptTo: gcc-patches@gcc.gnu.org Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 5B89F19D801C for ; Fri, 11 Sep 2015 15:57:43 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t8BM6nCU40108076 for ; Fri, 11 Sep 2015 15:06:49 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t8BM6mLb005219 for ; Fri, 11 Sep 2015 16:06:49 -0600 Received: from oc1687012634.ibm.com (sig-9-49-157-83.ibm.com [9.49.157.83]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t8BM6mnk005157; Fri, 11 Sep 2015 16:06:48 -0600 Subject: Re: [PATCH] v2 shrink-wrap: Rewrite To: Segher Boessenkool , gcc-patches@gcc.gnu.org References: Cc: bschmidt@redhat.com From: Pat Haugen Message-ID: <55F35077.4030603@linux.vnet.ibm.com> Date: Fri, 11 Sep 2015 22:14: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-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15091122-0033-0000-0000-000005D8C872 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00847.txt.bz2 On 09/11/2015 02:49 PM, Segher Boessenkool wrote: > On PowerPC, this enables shrink-wrapping of about 2%-3% more functions. > I expected more, but in most cases this would help we cannot yet shrink- > wrap because there are non-volatile registers used, often in the first > block already. I looked into shrink-wrapping earlier this year and noticed the same. I tried expanding ira.c:split_live_ranges_for_shrink_wrap() to do a more general live range splitting than the limited parm_reg->pseudo copies it tries splitting now, but the splits ended up getting coalesced back together and a non-volatile chosen. Unfortunately my digging got put on the back burner and I haven't looked at it for a while. Another issue I saw for PowerPC that prevented shrink-wrapping was the case where non-volatile CR's are used somewhere in the function. This causes a 'mfcr' to be generated in the prolog to save the non-volatile CR's, which currently lists all CR's as used. This kills shrink-wrapping since the early exit test will define a CR which then fails the shrink-wrap requirement of not defining a register used in the prolog. I tried a simple hack of just removing the volatile CR's from the 'movesi_from_cr' define_insn and it solved the issue, but never submitted a patch for just that piece. -Pat