From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6984 invoked by alias); 29 Jun 2009 16:27:13 -0000 Received: (qmail 6975 invoked by uid 22791); 29 Jun 2009 16:27:12 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 16:27:06 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5TGR4Ab006888; Mon, 29 Jun 2009 12:27:04 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5TGR3DY031477; Mon, 29 Jun 2009 12:27:04 -0400 Received: from toll.yyz.redhat.com (toll.yyz.redhat.com [10.15.16.165]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5TGR2Mf003180; Mon, 29 Jun 2009 12:27:02 -0400 Message-ID: <4A48EB5A.2030205@redhat.com> Date: Mon, 29 Jun 2009 18:04:00 -0000 From: Vladimir Makarov User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dave Korn CC: Albert Cohen , reply@meinersbur.de, gcc@gcc.gnu.org, Sid Touati , Frederic Brault Subject: Re: Register Pressure in Instruction Level Parallelism References: <4A47462E.1080402@uni-paderborn.de> <4A4759F6.7010808@gmail.com> <4A47EDDB.3070709@inria.fr> <4A47F8EC.6060909@gmail.com> In-Reply-To: <4A47F8EC.6060909@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; 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: 2009-06/txt/msg00679.txt.bz2 Dave Korn wrote: > Albert Cohen wrote: > > >> Unfortunately, the state of the art (more recent that the thesis >> referenced in the original email, see Touati's web page) is limited to >> basic block and software-pipelining scopes, and limited to scheduling. >> >> Compared to the tasks currently managed by reload, it certainly misses a >> whole bunch of instruction selection and immediate operand/address mode >> corner case problems (depending on the target). It also misses global >> scheduling, but extended BB scheduling is not very hard to approximate, >> as well as superblock scheduling. >> >> I'm not at all a knowledgeable person to tell you what to do in the case >> of GCC, but for sure saturation/sufficiency-based approches are not >> sufficient to kill the dragon. >> > > In a brief exchange I had with Michael off-list, we discussed that. I > observed that of the things that reload does, > constraint-satisfaction/insn-variant-selection is its primary purpose, and > spill/reload code generation is something it often does suboptimally (and > secondary reloads even worse). If a clever pass running before reload could > insert explicit spill/reload code at well-chosen places (bearing in mind > class-based register pressure), it could relieve reload of the necessity to > generate its own spill code most of the time, and let it just do what it does > best. IRA actually already inserts spill code in most important places (on loop borders). Besides loop regions, IRA could be extended to other regions (and even bb parts to relief pressure inside the blocks). I am going to work on it to evaluate how much it could give. Most spill/restore code at least for x86 is generated by reload because one insn operand should be a register. Some cooperation of IRA and reload on this issue, I hope, has a potential to improve code performance more. > So, yes, it doesn't kill the dragon, reload would need to be retained > and would still need the last-resort ability to do all the stuff it does now - > but mostly it wouldn't have to in practice, and a sleeping dragon is still an > improvement on a wide-awake one that's stomping round in a furious bad temper > burning everything in sight.... Reload would definitely generate better code > if it was fed stuff that avoided exercising its weakest points; sounds like a > pre-conditioning pass based on your techniques might work really well. > >