From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13719 invoked by alias); 11 Jan 2011 16:11:09 -0000 Received: (qmail 13681 invoked by uid 22791); 11 Jan 2011 16:11:02 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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; Tue, 11 Jan 2011 16:10:52 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0BGAntn006204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jan 2011 11:10:50 -0500 Received: from toll.yyz.redhat.com (toll.yyz.redhat.com [10.15.16.165]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0BGAmTV003224; Tue, 11 Jan 2011 11:10:49 -0500 Message-ID: <4D2C8108.5070705@redhat.com> Date: Tue, 11 Jan 2011 16:11:00 -0000 From: Vladimir Makarov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: roy rosen CC: Jeff Law , gcc@gcc.gnu.org Subject: Re: register allocation References: <4D137DDE.8010904@redhat.com> <4D21EE2F.7070202@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/msg00126.txt.bz2 On 01/05/2011 09:44 AM, roy rosen wrote: > 2011/1/3 Jeff Law: >> 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. > Actually, I tried on this branch disabling the improve_allocation > function and now it is doing a great job. > For some reason the improve_allocation function only damaged the good > allocation that was done. > This function is pretty straight forward. It always improve allocation cost in given cost model. So either it only seems that the code is worse or the cost model is wrong for some reasons (it might be wrong definitions of target cost macros or the IRA cost model is inadequate). It is hard to say without more information. You could send me IRA dump with and without improve_allocation. You might want send the dumps only for me if you want keep confidentiality about you port. > In order to look at that I am trying to understand the conflict table: I see > > ;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0) > a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0) > a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0) > a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0) > a5(r253,l0) a7(r252,l0) a17(r261,l0) > ;; total conflict hard regs: 53 > ;; conflict hard regs: 53 > > I see here conflicts of the pseudo with other pseudos and conflict > with a hard reg - all are result of live range data. > How is the constraint data which limits a pseudo in an insn to be of a > certain class gets into this table? Constraints defines profitable allocno class (for example, in one insn the pseudo should be in floating point hard register and in many others it should be in general hard registers. In this case IRA most probably will use general register class for the allocno). But only reload pass really deals with constraints. > I have expected also all hard regs which are not allowed for this > pseudo because of constraints in the insns to be also in the conflict > table. I guess I miss something... > IRA reports only conflicting hard registers from allocno class to keep this list short. > If it isn't there then how is it guranteed that the pseudo would be > allocated to a hard reg which is allowed by the constraints? >