From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-87270-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22937 invoked by alias); 11 Dec 2003 23:31:05 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 22929 invoked from network); 11 Dec 2003 23:31:03 -0000
Received: from unknown (HELO mx2.redhat.com) (66.187.237.31)
  by sources.redhat.com with SMTP; 11 Dec 2003 23:31:03 -0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id hBBNAqA17710;
	Thu, 11 Dec 2003 18:10:52 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBBNUxb09005;
	Thu, 11 Dec 2003 18:31:00 -0500
Received: from p4 (vpn50-27.rdu.redhat.com [172.16.50.27])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBBNUwM08065;
	Thu, 11 Dec 2003 15:30:58 -0800
Subject: Re: [tree-ssa] Lazy updating of stmt operands
From: Andrew MacLeod <amacleod@redhat.com>
To: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
Cc: Jeff Law <law@redhat.com>, Diego Novillo <dnovillo@redhat.com>,
   gcc
	mailing list <gcc@gcc.gnu.org>
In-Reply-To: <20031211223056.GA20061@atrey.karlin.mff.cuni.cz>
References: <1070818186.7334.30.camel@frodo.toronto.redhat.com>
	<200312111936.hBBJabGj024859@speedy.slc.redhat.com> 
	<20031211223056.GA20061@atrey.karlin.mff.cuni.cz>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Thu, 11 Dec 2003 23:34:00 -0000
Message-Id: <1071185459.14253.325.camel@p4>
Mime-Version: 1.0
X-SW-Source: 2003-12/txt/msg00681.txt.bz2

On Thu, 2003-12-11 at 17:30, Zdenek Dvorak wrote:
> Hello,
> 
>
> > While it's nice to think about a world where you always have immediate uses,
> > you end up with FUD chains if you do that -- with ultimately a tangled nest
> > of pointers that is bloody impossible to work with in the real world.
> 
> here is the patch.  It increases time for compiling preprocessed gcc
> sources from 3m43.734s to 3m47.967s.  It does not use interface of
> immediate uses, since that is not well suited for updating; instead it
> just keeps lists of uses for each ssa name.  The old interface and ccp
> that uses it are not changed by the patch, so in fact the cost would
> be a bit smaller.

More interesting is the time effectit has on larger C++ cases like
Geralds where we already have memory problem we are trying to resolve.
Thats where it was a significant issue for CCP in the system swap time.

Andrew