From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22556 invoked by alias); 26 May 2011 08:47:46 -0000 Received: (qmail 22543 invoked by uid 22791); 26 May 2011 08:47:44 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from dair.pair.com (HELO dair.pair.com) (209.68.1.49) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 26 May 2011 08:47:30 +0000 Received: (qmail 49059 invoked by uid 20157); 26 May 2011 08:47:29 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 May 2011 08:47:29 -0000 Date: Thu, 26 May 2011 09:34:00 -0000 From: Hans-Peter Nilsson To: Vladimir Makarov cc: gcc-patches Subject: Re: RFA: another patch to solve PR49154 In-Reply-To: <4DDDB1EA.4080902@redhat.com> Message-ID: References: <4DDD7705.9020003@redhat.com> <4DDDB1EA.4080902@redhat.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes 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 X-SW-Source: 2011-05/txt/msg01976.txt.bz2 On Wed, 25 May 2011, Vladimir Makarov wrote: > On 11-05-25 6:58 PM, Hans-Peter Nilsson wrote: > > On Wed, 25 May 2011, Vladimir Makarov wrote: > > > > > This patch solves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for > > > CRIS. > > > The problem was in that the pressure classes did not contain SRP register > > > and > > > the assert failed. > > I'm not sure I understand the basic requirement. > > > It is ambiguous area. Register pressure classes are used for register > pressure evaluation in several parts of the compiler: > > register pressure sensitive loop invariant motion > register pressure sensitive insn scheduling > and in IRA to form regions for allocation > > In some way register pressure classes are what cover classes were when they > were defined. Just a note here; for cover classes, SPECIAL_REGS was sufficient. > But right definition of register pressure classes are not so > critical as the right definition of cover classes were earlier because > register pressure calculation is in some way approximation (even if we know > what exact classes will be used for each pseudo during the allocation, but we > don't know it yet exactly when the register pressure is calculated) because > classes used for allocation (allocno classes) are calculated dynamicly and > they can be different from register pressure classes and the old cover classes > and, the most important thing, the allocno classes can be intersected in any > way which makes the register pressure caclulation is inaccurate. Still the > register pressure calculation is useful. > > I added an assertion which checks that the calculated register pressure > classes contains all allocatable hard registers. When the assertion fails we > have this problem. But the compiler will work well even if the assertion > fails. Generally speaking, we could remove the assertion without harm. The > assertion is just a check for *the most* targets that the pressure classes > calculation is not broken because for the most targets the register pressure > classes should contain all available hard registers. > > The assertion failed for CRIS because we had pressure classes only CC0_REGS > and GENERAL_REGS which do not includes SRP register. It sounds like a bug that CC0_REGS was considered at all, as the only register is not allocatable. SPECIAL_REGS should be chosen; the only allocatable register would be SRP_REGS (additionally, MOF_REGS for the v10 multilib). I'll have a look. > > Can you please suggest an update to the target macro > > documentation to reflect the requirement it's currently failing? > > To feel ok with this change I need to understand why it's not ok > > as is: I can't see the error, just a random change narrowing a > > register class that at a glance *should* not be needed. To wit, > > I need to understand why the bug is here and that it's not the > > failing assert in IRA that's wrong. > > > I don't think it is necessary because as I know only CRIS requires register > classes modification. On the contrary. I think at least a "should" needs to change to "must" regarding register classes, or we can't say what to change. The documentation is not "what works for most targets"! It sounds like you're saying that "the narrowest register classes must be formed of registers for which there are trivial instructions to move between registers inside the class"? I think that'd be reasonable and if you agree I'll do the update. In either case, your patch wouldn't be complete as more changes are needed, for example for secondary reloads the new SRP_REGS has to be considered. brgds, H-P