From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13727 invoked by alias); 7 Dec 2003 17:30:00 -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 13720 invoked from network); 7 Dec 2003 17:29:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Dec 2003 17:29:59 -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 hB7HTw229509; Sun, 7 Dec 2003 12:29:58 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hB7HTv210181; Sun, 7 Dec 2003 12:29:57 -0500 Received: from dnovillo.cipe.redhat.com (dnovillo.cipe.redhat.com [10.0.0.106]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id hB7HTtPq008210; Sun, 7 Dec 2003 12:29:56 -0500 Subject: Re: [tree-ssa] Lazy updating of stmt operands From: Diego Novillo To: Zdenek Dvorak Cc: "gcc@gcc.gnu.org" In-Reply-To: <20031207171454.GA12827@atrey.karlin.mff.cuni.cz> References: <20031207161929.GA10638@atrey.karlin.mff.cuni.cz> <1070816155.7334.13.camel@frodo.toronto.redhat.com> <20031207171454.GA12827@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1070818186.7334.30.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Sun, 07 Dec 2003 17:36:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00474.txt.bz2 On Sun, 2003-12-07 at 12:14, Zdenek Dvorak wrote: > right. But this would as well be the case if the information was always > kept up-to-date. > Not possible. In DOM we build hash tables that do value numbering on the operands and voperands. If we used and eager scheme to keep this information up-to-date, we would not be able to remove statements from hash tables after modifying them. See how DOM very carefully avoids calling get_stmt_operands while it's doing its thing. Also, mark_new_vars_to_rename relies on the stale operands to still be there to find what variables need to be renamed. Changing the current lazy approach into an eager scheme, would mean modifying several, seemingly unrelated, things. > > 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). Diego.