From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31289 invoked by alias); 23 Nov 2005 14:06:07 -0000 Received: (qmail 31279 invoked by uid 22791); 23 Nov 2005 14:06:06 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 14:06:03 +0000 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 1291D1BB25; Wed, 23 Nov 2005 15:06:00 +0100 (CET) Date: Wed, 23 Nov 2005 14:06:00 -0000 From: Michael Matz To: Peter Bergner Cc: Andrew MacLeod , gcc mailing list Subject: Re: Register Allocation In-Reply-To: <1132687596.7748.32.camel@otta.rchland.ibm.com> Message-ID: References: <1132246411.10098.153.camel@localhost.localdomain> <1132687596.7748.32.camel@otta.rchland.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg01151.txt.bz2 Hi, On Tue, 22 Nov 2005, Peter Bergner wrote: > Spill Location Optimizer [page(s) 11]: > * The IBM iSeries backend has this optimization. During spilling, > it inserts copies to/from spill pseudos (essentially like another > register class) which represent the stores/loads from the stack. > These spill pseudos can then be dead code eliminated, coalesced > and colored (using an interference graph) just like any other > normal pseudo. Normal Chaitin coloring (using k = infinity) does > a good job of minimizing the amount of stack space used for > spilled pseudos. This is btw. also done by the new-ra branch. Instead of spilling to stack directly it spills to special new pseudo regs. The obvious problem with that is a phase ordering problem, namely that if you only have pseudo stack locations (the pseudo regs in this case) you don't know the final insn sequence (e.g. if the final stack offset happens to be unrepresentable so that insns are necessary to actually construct the stack address for the load/store). That's why new-ra leaves the stack slots as pseudos only for one round, and then assign real stack positions to them (and recolors the possibly new insns and affected pseudos). > 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 ;) Ciao, Michael.