From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28908 invoked by alias); 24 Aug 2005 03:10:58 -0000 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 Received: (qmail 28899 invoked by uid 22791); 24 Aug 2005 03:10:52 -0000 Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.130) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 24 Aug 2005 03:10:52 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7O3AeuD595676 for ; Tue, 23 Aug 2005 23:10:41 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7O3AncA375750 for ; Tue, 23 Aug 2005 21:10:49 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7O3AeF2028928 for ; Tue, 23 Aug 2005 21:10:40 -0600 Received: from [192.168.1.102] (vorma.rchland.ibm.com [9.10.86.186]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7O3Acb5028923; Tue, 23 Aug 2005 21:10:39 -0600 Subject: Re: Problem with the special live analyzer in global alloc From: Peter Bergner To: Bernd Schmidt Cc: Steven Bosscher , gcc@gcc.gnu.org, Daniel Berlin , Andreas Krebbel , James E Wilson In-Reply-To: <430B7870.9000007@t-online.de> References: <20050816135150.GA3617@de.ibm.com> <1124809003.7123.14.camel@linux.site> <430B3B61.9010302@t-online.de> <200508231712.16188.stevenb@suse.de> <430B7870.9000007@t-online.de> Content-Type: text/plain Date: Wed, 24 Aug 2005 04:10:00 -0000 Message-Id: <1124853038.4518.75.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-08/txt/msg00656.txt.bz2 On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote: > As Jim points out, we may have to do that for IA64 anyway, so we could > consider doing it on all targets. Dan is correct that this can > introduce new code that won't be eliminated. One question is how often > this is going to occur in practice. The IBM iSeries (aka AS/400) compiler actually inserts definitions on edges where a pseudo/register is undefined. However, unlike the discussion here, our "pseudo" definitions never lead to generated code. Our pseudo definitions were added to simplify some analysis phases in the compiler (eg, liveness can be simplified down to LIVE rather than LIVE & AVAL). Note that we needed to handle these pseudo definitions specially in some cases so they don't reduce optimization opportunities. If I remember correctly (it's been a while since I left the team): 1) All pseudo defs get the value of so rematerialization, etc. are not pessimized. 2) Pseudo definitions are ignored during the interference graph construction (ie, they never cause edges to be added to the interference graph). 3) More things I can't think of at the moment. This was a win for the iSeries compiler since a fair number of applications were/are written in RPG which is essentially a one procedure application, so the number of basic blocks and live ranges/webs can be quite high. I recall one program we ran into that had about 150K basic blocks and about 1.5M live ranges. I know we used to have a white paper describing the internals of the iSeries compiler (titled "The AS/400 Optimizing Translator"), but all of the links I can find are stale. However, I did come across their patent (5,761,514) describing the idea: "Register allocation method and apparatus for truncating runaway lifetimes of program variables in a computer system". I have no idea whether this was one of the patents made available by IBM for use by the OSS community or not. Peter -- Peter Bergner Linux on Power Toolchain IBM Linux Technology Center