From patchwork Fri Jan 20 18:13:37 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 137068 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id DC1DDB6EEA for ; Sat, 21 Jan 2012 05:15:35 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1327688136; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=4ZioSJgbyLYBLs/GTDwnNPT9FKc=; b=eURnpDF6FvGBKaAhhWfYCWAn194vdiGUR27G6FSW3TTPTIx18Tz6sbdCnOd/y8 L4S1gXEgcR/MRylt1pmC8ppMAEfDVvWNd5ugCKYDNyCdoCJs27RZ1+9t6GH4k56F NZDGsjBUKKvpZVaS1umfRb10JhQ5mDq6lfqLhbPLXKnbA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=V8XKCVgmM0WCPV1DCYeewoINfXdthgqDyjXXS84Ianf4KyE6rpdvcr9Srsn3gv m2iRkPhGy3xF4NbCobF1OHF5ZRhgdxcvU6JBghUHD53XvnmQJ6pp1vqIrEarlvt6 BmkgeUtTxK2JTG5Bf74p8vXcJ1lgnjkwKSsfTz+fmPszA=; Received: (qmail 11663 invoked by alias); 20 Jan 2012 18:15:26 -0000 Received: (qmail 11638 invoked by uid 22791); 20 Jan 2012 18:15:22 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jan 2012 18:15:10 +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 (8.14.4/8.14.4) with ESMTP id q0KIF9Bx002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 13:15:09 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0KIF8U5029635; Fri, 20 Jan 2012 13:15:09 -0500 Received: from localhost.localdomain (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0KIF5ii018888; Fri, 20 Jan 2012 13:15:06 -0500 Message-ID: <4F19AED1.40008@redhat.com> Date: Fri, 20 Jan 2012 13:13:37 -0500 From: Vladimir Makarov User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Zamyatin, Igor" CC: Igor Zamyatin , "enkovich.gnu@gmail.com" , "gcc-patches@gcc.gnu.org" Subject: Re: FW: patch to fix PR21617 References: <0EFAB2BDD0F67E4FB6CCC8B9F87D75690EC81F@IRSMSX101.ger.corp.intel.com> <4F0C78FD.8050104@redhat.com> <0EFAB2BDD0F67E4FB6CCC8B9F87D756910D3FD@IRSMSX101.ger.corp.intel.com> <4F1882A9.2090408@redhat.com> In-Reply-To: <4F1882A9.2090408@redhat.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 01/19/2012 03:52 PM, Vladimir Makarov wrote: > On 01/18/2012 02:30 PM, Zamyatin, Igor wrote: >> Yes, we use Atom for EEMBC measurements. >> >> We'll be glad to help you with your findings. >> >> > Thanks. > > Unfortunately I tried several alternative patches but I did not find a > better solution (it is mostly code size degradation on CoreI7). Now I > am even thinking that the best action would have been ignoring the > original PR. > Could you try the attached patch. It might work. I've tried several approach to prevent small hole creation in ira-color.c::assign_hard_reg but it does not work well. Thanks. Index: ira-color.c =================================================================== --- ira-color.c (revision 183312) +++ ira-color.c (working copy) @@ -1798,16 +1798,16 @@ bucket_allocno_compare_func (const void int diff, a1_freq, a2_freq, a1_num, a2_num; int cl1 = ALLOCNO_CLASS (a1), cl2 = ALLOCNO_CLASS (a2); - /* Push pseudos requiring less hard registers first. It means that - we will assign pseudos requiring more hard registers first - avoiding creation small holes in free hard register file into - which the pseudos requiring more hard registers can not fit. */ - if ((diff = (ira_reg_class_max_nregs[cl1][ALLOCNO_MODE (a1)] - - ira_reg_class_max_nregs[cl2][ALLOCNO_MODE (a2)])) != 0) - return diff; a1_freq = ALLOCNO_FREQ (a1); a2_freq = ALLOCNO_FREQ (a2); - if ((diff = a1_freq - a2_freq) != 0) + /* Prefer to push pseudos requiring less hard registers first. It + means that we will assign pseudos requiring more hard registers + first avoiding creation small holes in free hard register file + into which the pseudos requiring more hard registers can not + fit. */ + if ((diff = (a1_freq * ira_reg_class_max_nregs[cl1][ALLOCNO_MODE (a1)] + - a2_freq * ira_reg_class_max_nregs[cl2][ALLOCNO_MODE (a2)])) + != 0) return diff; a1_num = ALLOCNO_COLOR_DATA (a1)->available_regs_num; a2_num = ALLOCNO_COLOR_DATA (a2)->available_regs_num;