From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30433 invoked by alias); 23 Nov 2005 20:50:11 -0000 Received: (qmail 30426 invoked by uid 22791); 23 Nov 2005 20:50:10 -0000 X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 20:50:09 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jANKo7ZH003333 for ; Wed, 23 Nov 2005 15:50:07 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jANKpSi6054126 for ; Wed, 23 Nov 2005 13:51:30 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jANKo56c020905 for ; Wed, 23 Nov 2005 13:50:05 -0700 Received: from [192.168.4.1] (vorma.rchland.ibm.com [9.10.86.186]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jANKnwFH020182; Wed, 23 Nov 2005 13:50:03 -0700 Subject: Re: Register Allocation From: Peter Bergner To: Michael Matz Cc: Andrew MacLeod , gcc mailing list In-Reply-To: References: <1132246411.10098.153.camel@localhost.localdomain> <1132687596.7748.32.camel@otta.rchland.ibm.com> Content-Type: text/plain Date: Wed, 23 Nov 2005 20:50:00 -0000 Message-Id: <1132778991.5621.30.camel@otta.rchland.ibm.com> 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-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg01164.txt.bz2 On Wed, 2005-11-23 at 15:05 +0100, Michael Matz wrote: > > Spill Cost Engine [page(s) 26-29]: > > * The register allocator should not be estimating the execution > > frequency of a basic block as 10^nesting level. That information > > should be coming from the cfg which comes from profile data or > > from a good static profile. The problem with 10^loop nesting > > level is that we can overestimate the spill costs for some > > pseudos. For example: > > while (...) { > > > > if (...) > > > > else > > > } > > In the code above, "b"'s spill cost will be twice that of "a", > > when they really should have the same spill cost. > > Nearly. "b" _is_ more costly to spill, code size wise. All else being > equal it's better to spill "a" in this case. But the cost is of course > not twice as large, as you say. I.e. I agree with you that the metric > should be based exclusively on the BB frequencies attached to the CFG, not > any nesting level. Also like in new-ra ;) The spill cost for a pseudo in a classic Chaitin/Briggs allocator does not take number of spill instructions inserted into account, so "b"'s spill cost would be twice that of "a" if we were to use 10^nesting level. That said, I think we're all in agreement that using basic block frequencies from the cfg is the correct thing to do and that taking static spill instruction counts into account is a good idea which Andrew's proposal does by using it as a tie breaker. I assume it goes without saying that when using -Os, spill cost will be used as the tie breaker when two pseudos have the same static spill instruction counts. Peter