From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11961 invoked by alias); 11 Dec 2003 19:36:50 -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 11954 invoked from network); 11 Dec 2003 19:36:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Dec 2003 19:36:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBBJal225912; Thu, 11 Dec 2003 14:36:47 -0500 Received: from speedy.slc.redhat.com (vpn50-10.rdu.redhat.com [172.16.50.10]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBBJaj210254; Thu, 11 Dec 2003 14:36:46 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id hBBJabGj024859; Thu, 11 Dec 2003 12:36:37 -0700 Message-Id: <200312111936.hBBJabGj024859@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Diego Novillo cc: Zdenek Dvorak , "gcc@gcc.gnu.org" Reply-To: law@redhat.com Subject: Re: [tree-ssa] Lazy updating of stmt operands In-Reply-To: Your message of "Sun, 07 Dec 2003 12:29:46 EST." <1070818186.7334.30.camel@frodo.toronto.redhat.com> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 2003 19:38:00 -0000 X-SW-Source: 2003-12/txt/msg00670.txt.bz2 In message <1070818186.7334.30.camel@frodo.toronto.redhat.com>, Diego Novillo w rites: >> > tree-dfa.c:compute_immediate_uses() >> >> 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. jeff