From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21550 invoked by alias); 29 Jun 2009 00:03:47 -0000 Received: (qmail 21538 invoked by uid 22791); 29 Jun 2009 00:03:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 00:03:14 +0000 Received: from versailles.c0hen.net (HELO [192.168.0.3]) ([82.240.29.21]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2009 02:03:11 +0200 Message-ID: <4A48050B.1030403@inria.fr> Date: Mon, 29 Jun 2009 06:13:00 -0000 From: Albert Cohen User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Dave Korn CC: 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/msg00663.txt.bz2 Dave Korn wrote: > (...) I fully agree with your arguments. Managing register pressure early, and simplifying downstream passes (to avoid poluting them with pressure concerns) is a very tempting design. Yet from dream to reality there is a long way. > :) I'm not up on advanced compiler theory, I'll have to sit back at this > point and leave it to the collective genii to get on with! (I'll just suggest > that one advantage of implementing things in GCC is that it runs in such a > huge range of environments and targets, it's a good way to expose any new > algorithm to "interesting" problems caused by quirky architectures.) Exactly. Much register allocation and scheduling work is completely useless for a retargettable compilers for real architectures due to the lack of realistic constraint modeling. Of course, there are many other reasons that make academic research results useless, this is just one possible way to miss the point... Register saturation is a very powerful concept that remains to be extended to real conditions and beyond the interplay of allocation and scheduling. Albert