From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15642 invoked by alias); 11 Dec 2003 19:41:34 -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 15630 invoked from network); 11 Dec 2003 19:41:33 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 11 Dec 2003 19:41:33 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id B2CD64C026B; Thu, 11 Dec 2003 20:41:32 +0100 (CET) Date: Thu, 11 Dec 2003 19:52:00 -0000 From: Zdenek Dvorak To: law@redhat.com Cc: Diego Novillo , "gcc@gcc.gnu.org" Subject: Re: [tree-ssa] Lazy updating of stmt operands Message-ID: <20031211194132.GA7601@atrey.karlin.mff.cuni.cz> References: <1070818186.7334.30.camel@frodo.toronto.redhat.com> <200312111936.hBBJabGj024859@speedy.slc.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312111936.hBBJabGj024859@speedy.slc.redhat.com> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-12/txt/msg00673.txt.bz2 Hello, > >> Which needs to pass through every single statement in the program. Not > >> really terribly efficient. > >> > >*shrug*, it's used by SSA-CCP. Since def-use edges are only needed by > >some passes, I don't think it would be worth our while trying to > >maintain them in get_stmt_operands. > > > >But I'm ready to be convinced otherwise. Say, with an implementation > >comparing both approaches with timings over a reasonable code base (a > >typical GCC bootstrap or one of the compile-time related PRs). > IMHO, when we have the need, then we'll expand on the immediate uses > interface -- either by having a way to incrementally update it, or > rebuild it. > > 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. why? I have this written and it does not seem very complicated. I didn't get to measuring its speed yet, and of course there is unpleasant memory overhead, but I don't see any other problems. Zdenek