From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28838 invoked by alias); 29 Jun 2009 00:30:16 -0000 Received: (qmail 28825 invoked by uid 22791); 29 Jun 2009 00:30:15 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail-qy0-f194.google.com (HELO mail-qy0-f194.google.com) (209.85.221.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 00:30:06 +0000 Received: by qyk32 with SMTP id 32so4134501qyk.0 for ; Sun, 28 Jun 2009 17:30:03 -0700 (PDT) Received: by 10.224.53.200 with SMTP id n8mr1345657qag.245.1246235402505; Sun, 28 Jun 2009 17:30:02 -0700 (PDT) Received: from ?192.168.1.10? (pool-98-113-157-216.nycmny.fios.verizon.net [98.113.157.216]) by mx.google.com with ESMTPS id 7sm111256qwb.30.2009.06.28.17.30.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 17:30:01 -0700 (PDT) Message-ID: <4A480B27.2040704@naturalbridge.com> Date: Mon, 29 Jun 2009 06:28:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: David Edelsohn , Albert Cohen , Dave Korn , Frederic Brault , gcc@gcc.gnu.org Subject: Re: Fwd: Register Pressure in Instruction Level Parallelism References: <4A47462E.1080402@uni-paderborn.de> <4A4759F6.7010808@gmail.com> <4A47EDDB.3070709@inria.fr> <303e1d290906281549t4ebfce81m5152069742fa9a1@mail.gmail.com> In-Reply-To: <303e1d290906281549t4ebfce81m5152069742fa9a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00664.txt.bz2 David Edelsohn wrote: > ---------- Forwarded message ---------- > From: Albert Cohen > Date: Sun, Jun 28, 2009 at 6:25 PM > Subject: Re: Register Pressure in Instruction Level Parallelism > To: Dave Korn > Cc: reply@meinersbur.de, gcc@gcc.gnu.org, Sid Touati > , Frederic Brault > > > Hi all, > > I'm convinced that saturation and sufficiency based approaches are the > future of register pressure management. > > [Please keep my colleague Sid Touati in CC of this thread, until he > registers to the list.] > > 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. > > However, I will strongly advise anybody (= Kenny Zadeck) looking at a > fresh SSA-based backend design to consider such an approach to avoid > messing up with pressure-aware-* where * is any backend pass that > bears a risk of blowing up register pressure. > > I am considering such a design and i did, late last week to go public with my project. I am now working to put up a project in the public spaces. I would very much like the help of anyone who is interested in working in this area to consider working on it in gcc. kenny > If you interested in collaboration on the topic, we are about to start > extending those approaches to general control-flow, and implementing > it in a production compiler (not GCC, but a free one, and not LLVM > either). > > Albert > > > Dave Korn wrote: > >> Michael Kruse wrote: >> >> >>> So, now my questions: How much do you think could this could improve >>> compiled code speed? Would the current GCC/YARA benefit from such an >>> optimization pass at all? What are the chances that this could get into >>> the main GCC tree if it shows up to be an improvement? >>> >> One of the major problems in gcc is the intertangling of instruction >> selection with register allocation and spill generation. If these could be >> separated it would almost certainly generate better code and be welcomed with >> open arms! >> >> >>> I'd prefer to implement this for the gcc, but my advisor wants me to do >>> it for the university's own compiler. Therefore I could also need >>> arguments why to do it for the GCC. >>> >> Because destroying reload(*) would be an incalculable public service and >> your name will be remembered in history as the one who slew the dragon? ;-) >> >> cheers, >> DaveK >>