From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4500 invoked by alias); 6 Nov 2009 12:53:56 -0000 Received: (qmail 4491 invoked by uid 22791); 6 Nov 2009 12:53:55 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailgate.blueteddy.net (HELO mailgate.blueteddy.net) (80.176.108.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 12:53:50 +0000 Received: from [10.10.40.103] (216.112.109.156.ptr.us.xo.net [216.112.109.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.blueteddy.net (Postfix) with ESMTPSA id 2F9A41086026; Fri, 6 Nov 2009 12:53:42 +0000 (GMT) Subject: RE: Understanding IRA From: Dave Hudson To: Ian Bolton Cc: Jeff Law , Vladimir Makarov , gcc@gcc.gnu.org In-Reply-To: <4D60B0700D1DB54A8C0C6E9BE69163700C1F257C@EXCHANGEVS.IceraSemi.local> References: <4D60B0700D1DB54A8C0C6E9BE69163700C1F254A@EXCHANGEVS.IceraSemi.local> <4D60B0700D1DB54A8C0C6E9BE69163700C1F257C@EXCHANGEVS.IceraSemi.local> Content-Type: text/plain; charset="UTF-8" Date: Fri, 06 Nov 2009 12:53:00 -0000 Message-ID: <1257512006.6620.28.camel@dhudson-ubuntult> Mime-Version: 1.0 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: 2009-11/txt/msg00123.txt.bz2 On Thu, 2009-11-05 at 18:05 +0000, Ian Bolton wrote: > I think I may have made a breakthrough! > > As mentioned above, IRA is correctly increasing the cost for TOP_REGS > when an allocno in region 1 is being used in one of our special > instructions that needs BOTTOM_REGS. We can also see that IRA is > passing that allocno cost up to the associated allocno in region 0 and > altering the total_cost for that allocno. > > However, it does not appear as though IRA is doing anything with the > total_costs, apart from using it to determine the preferred class for > the allocno. When the main logic of the algorithms comes into play, > we only look at allocno_costs, which do not take into account the > future usage of that register in the allocno in region 1. > > I believe that if the decisions were made based on total_costs then I > would get a better allocation with existing IRA. Before I experiment > with this, I was wondering what the motivation is for only looking > at allocno_costs? > > BTW, I did look into using the ! and * constraints, but I don't think > they could help. Our architecture is like Motorola 68k in that we have > some instructions that can use all the registers and some that can > only use the subset (BOTTOM_REGS). The latter type can only specify > "b" for their constraint, since they can only go in BOTTOM_REGS. The > former type might benefit from "b,!t", so we are more likely to get > things in BOTTOM_REGS for when they are later needed there, but the > flip-side is that we might also fill up BOTTOM_REGS when actually there > was no subsequent need for the value to be in BOTTOM_REGS. I may have > misunderstood how all this works, but it looks like constraints will > not help here and, in fact, the total_costs calculations that I > mention above are precisely the way IRA passes information about > register requirements upwards. I've been working on gcc for an ISA (Ubicom32) that seems to have some similarities to the problem you're seeing (we have some regs that can be used for many things but not all) and was seeing a ton a pointless moves introduced by reload. I've ended up trying quite a few different strategies including defining different cover classes and the strategy we're now using is to leave the cover classes the same way you have them but found that the most critical thing was to ensure that REGNO_REG_CLASS was returning a minimal class correctly. Once I had this right then IRA started to do the right thing most of the time (-Os still isn't great but -O2 usually looks very good now). We still see some problems but they're usually a result of reload messing things up or suboptimal handling of auto-incrementing in MEMs. I haven't found using "*" and "!" helped much except where we had a couple of different ways of encoding the same behaviour and where we wanted to avoid using one unless the register allocations worked out right. Cheers, Dave