From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30683 invoked by alias); 3 Jan 2011 15:41:57 -0000 Received: (qmail 30674 invoked by uid 22791); 3 Jan 2011 15:41:57 -0000 X-SWARE-Spam-Status: No, hits=-6.9 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; Mon, 03 Jan 2011 15:41:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p03FfpiQ029867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Jan 2011 10:41:51 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p03Ffoou025806; Mon, 3 Jan 2011 10:41:50 -0500 Received: from [10.3.113.38] (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p03Ffnh5010833; Mon, 3 Jan 2011 10:41:49 -0500 Message-ID: <4D21EE2F.7070202@redhat.com> Date: Mon, 03 Jan 2011 15:41:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: roy rosen CC: Vladimir Makarov , gcc@gcc.gnu.org Subject: Re: register allocation References: <4D137DDE.8010904@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00039.txt.bz2 On 12/27/10 08:43, roy rosen wrote: >> >> I'd recommend to try ira-improv branch. I think that part of the problem is >> in usage of cover classes. The branch removes the cover classes and permits >> IRA to use intersected register classes and that helps to assign better hard >> registers. >> >> > I tried now this branch and got better results for some cases but > still in other cases I get lots of redundent register copies. > I might be missing something from the gcc history but I wonder why do > we need to limit the coloring stage to select a hard reg from a class > that was chosen by a prior stage. It was a design decision with the introduction of IRA. It made certain problems easier to resolve at the time and in reality, most of the time the set of legitimate and profitable hard registers for a given pseudo maps to a register class reasonably well. > Why not simply put in the interference graph edges for all registers > which are not possible for a pseudo and let the coloring algorithm > select the best hard reg. That's largely what the ira-improv branch does. Register classes at that point are used primarily to drive the costing model. jeff